Delphi vs C++ Performance Comparison
Robert Lee
be continually in demand. However, in the name of fairness and
conservation of (my) resources, I'm not going to do it alone. Here's my
plan:
The goal is to compare Delphi, BCB and VC++ at the code level from a
performance perspective. I've made some very simplistic passes at this
in the pass, but to do it correctly requires more "real world" code
examples. Additionally, the comparison should be divided into several
areas (string, integer, floating point that sort of thing) and several
programming styles or approaches. Off the top of my head I thought
maybe 'literal translations', 'simplest code' and 'fastest possible'.
For example, given a string based snippet, the literal translations
would both (Pascal and C++) be pchar based, use while's etc with the
goal being that they be as similar a possible. For the simplest code
approach, the OP code would be string based, use built in functions etc.
For the fastest possible approach there would be no constraints, just
let 'er rip.
It would be nice to have several examples for each combination of coding
approach and target area so as you can see this is not a small project.
Consequently, I think that Code Central would provide the most
appropriate venue for this effort with one entry for each
routine/algorithm. Code Central now allows threaded commentary/review
by others and so provides an easy means of allowing group participation
on each entry. Thus the current contents of the entry would eventually
represent the consensus view for each approach. With appropriate
designation anybody could contribute the initial problem with the
understanding that they would be responsible for updating the entry with
the latest versions for each language and compiler and each programming
level. If anyone wants to submit an algorithm but doesn't want to
handle the babysitting then they can send it to me and I'll handle the
drudgework.
What say you? Given the amount of oxygen expended in just the most
recent go-round in the C++ vs OP debate surely there are some who would
be willing to participate in this? What I most need is one or more
people to champion the C++ side, and of course those "real" world
examples. Also there are a few niggling details to hash out.
--
Bob Lee
High Performance Delphi - http://www.econos.com/optimize/
Steve Griffiths
fine, but if it's tools, is performance just a measure of how fast the
examples run? It's not a great deal of comfort to have an application that
runs 10-15% faster (if it does) if you have to wait an extra month to get
it.
Not being negative, just a 2CW.
Grif
Robert Lee wrote in message <38A17EFD...@nwu.edu>...
>I've decided to break down and actually do the comparison that seems to
>be continually in demand. However, in the name of fairness and
>conservation of (my) resources, I'm not going to do it alone
[snip]
John Jacobson
performance in my Visual C++ vs Delphi paper (see Jake's Delphi Site at
http://www.xnet.com/~johnjac ) and was planning on doing my own performance
comparisons. For it to be useful I think you are right that such a
comparison should include both the normal types of code that would be
written by programmers in their everyday programming, and the
most-highly-optimized-as-we-can-make-it code. I was planning on starting
such a comparison this coming weekend (for me it will be a 4-day weekend),
for Delphi 5 Pro and Visual C++ 6 Pro. For C++, string testing code should
cover CString, null-terminated character arrays, and the STL string class,
because those are the three most commonly used strings.
If we can agree on code snippets that are fair comparisons across tools,
I'll use those code snippets to run tests on my PC. I wonder if we shouldn't
find out what code the big testing labs use for this stuff. Does anyone know
this?
Does anyone else want to write up the results, or should I do it?
Also, we could get the Visual C++ guys over in the Microsoft forums to
participate too, once the tests are defined. It could even be a contest or
challenge.
Chris Uzdavinis (TeamB)
>performance perspective. I've made some very simplistic passes at this
>in the pass, but to do it correctly requires more "real world" code
>examples.
Depends on your definition of real world code examples. The real world code
I am working on simply cannot be written in VC++ because it's functionally
lacking. If you choose to benchmark a subset the language such that VC++
can compile it, you are eliminating one of BCB's biggest strengths from the
competition. Everyone knows VC++ is faster than BCB. But I don't care how
fast it is if it isn't ANSI C++. Well, let me rephrase. I don't care how
fast it is if it can't compile my code. In that respect, VC++ is worthless
to me.
Chris (TeamB)
Wayne Sherman
I am interested in helping. I not very good with C/C++ but I can help
with some Delphi code. I think that separating the comparisons into
categories is a good idea.
Something like this:
Category
Subcategory
Code Example #1 (with some kind of description - maybe pseudocode)
Literal Object Pascal translation / Literal C++ Translation
Simplest OP implementation / Simplest C++ implementation
Fastest OP implementation / Fastest C++ implementation
Code Example #2 (with some kind of description - maybe pseudocode)
Literal Object Pascal translation / Literal C++ Translation
Simplest OP implementation / Simplest C++ implementation
Fastest OP implementation / Fastest C++ implementation
for instance:
String Manipulation Category
String Searching Subcategory
Example#1 - Description & pseudocode
Literal Object Pascal translation / Literal C++ Translation
Simplest OP implementation / Simplest C++ implementation
Fastest OP implementation / Fastest C++ implementation
Example#2 - Description & pseudocode
Literal Object Pascal translation / Literal C++ Translation
Simplest OP implementation / Simplest C++ implementation
Fastest OP implementation / Fastest C++ implementation
String Concatenation Subcategory
Example#1 - Description & pseudocode
Literal Object Pascal translation / Literal C++ Translation
Simplest OP implementation / Simplest C++ implementation
Fastest OP implementation / Fastest C++ implementation
Example#2 - Description & pseudocode
Literal Object Pascal translation / Literal C++ Translation
Simplest OP implementation / Simplest C++ implementation
Fastest OP implementation / Fastest C++ implementation
...
> Also there are a few niggling details to hash out.
Some questions:
1) How would the entries map to Code Central submissions?
One submission per Category, SubCategory, Example, or Coding approach?
When someone wants to review the various comparisons from this project,
there should be a way to "filter out" all submissions relating to it in Code
Central. How this query is done and its results will depend on how the CC
entries have been organized. I think that if a "system" is devised to use
CC then a single submitter should be used to ensure that all submissions are
consistent with the system. Maybe John can add another field to his CC
database for people who want to submit entries under their own custom
categories.
2) How should the literal translation be approached?
Would this be a "brute force" implementation of the psuedocode?
Will the OP version written first and literally translated into C++ or
vice versa?
Regards,
Wayne
Wayne Sherman
> be continually in demand. However, in the name of fairness and
Robert,
I am interested in helping. I don't have much experience with C/C++
but I can help with Delphi code. I think that separating the comparisons
Something like this:
for instance:
Would this be a "brute force" implementation of psuedocode?
Should the OP version written first and literally translated into C++ or
vice versa?
3) Will binaries be tested on more than one kind of processor?
PII, PIII, Athlon...
Regards,
Wayne
Robert Lee
> but I can help with Delphi code. I think that separating the comparisons
> into categories is a good idea.
>
> Something like this:
While getting that many examples would be great I expect that it will be
a bit more spotty. Consequently, it is likely that each example will be
its own sub catagory.
> > Also there are a few niggling details to hash out.
> Some questions:
> 1) How would the entries map to Code Central submissions?
> One submission per Category, SubCategory, Example, or Coding approach?
One per Example was what I was thinking.
> When someone wants to review the various comparisons from this project,
> there should be a way to "filter out" all submissions relating to it in Code
> Central. How this query is done and its results will depend on how the CC
> entries have been organized.
Yes this can be handled simply by placing the appropriate keywords in
the description.
I think that if a "system" is devised to use
> CC then a single submitter should be used to ensure that all submissions are
> consistent with the system.
I don't think that will be necessary as the system doesn't need to be
that complex:
Description:
C++ vs Delphi project
Catagory: Strings
SubCatagory: Quick Sort;
> 2) How should the literal translation be approached?
> Would this be a "brute force" implementation of psuedocode?
> Should the OP version written first and literally translated into C++ or
> vice versa?
I was thinking of simply starting with someones off the shelf code in
either language and then attempting a literal translation to the other.
If need be the original could be adjusted to bring the two more in line.
> 3) Will binaries be tested on more than one kind of processor?
> PII, PIII, Athlon...
I can test on all of those, the PII vs PII distinction is hardly worth
making though. Probably, we'll use a PII as a baseline and make note of
any significant deviations on Athlon as needed.
--
Wayne Sherman
Should BASM be allowed? BASM is part of the Delphi product, but some C++
compilers allow inline assembly also. The goal would be to compare the
performance of the code the compiler produces, no?
Wayne
Charles J. Eckenroed
I only have limited time for 'extracurricular' coding. <g>
Email me the Delpi code when you get it done and I'll redo it in VB and send
it back. It would be interesting to see how VB stacks up against Delphi and
C++
Robert Lee wrote:
> I've decided to break down and actually do the comparison that seems to
> be continually in demand. However, in the name of fairness and
> conservation of (my) resources, I'm not going to do it alone. Here's my
> plan:
>
> The goal is to compare Delphi, BCB and VC++ at the code level from a
> performance perspective. I've made some very simplistic passes at this
> in the pass, but to do it correctly requires more "real world" code
> examples. Also there are a few niggling details to hash out.
Robert Lee
No assembler. The point is to compare the compilers.
--
Bob Lee
High Performance Delphi - http://www.econos.com/optimize/
Updated January 20
Robert Lee
>
> Depends on your definition of real world code examples. The real world code
> I am working on simply cannot be written in VC++ because it's functionally
> lacking. If you choose to benchmark a subset the language such that VC++
> can compile it, you are eliminating one of BCB's biggest strengths from the
> competition.
A definite problem, but only on the "literal translation" part of the
comparison. Presumably, equivalent code could be developed and
compared.
The point of this exercise is not to compare entire development
platforms, but rather the compiler output. Yes, everyone knows that VC
produces faster code than BCB. But how much faster, it is commonly
tossed out that VC is *much* faster. I personally don't think that is
true. I think it is *much* faster at a small handful of things and the
same or only marginally faster on a bunch of others. The only way to
settle this is with a solid comparison, rather than a pathetic and
usually highly benchmark that some knocked off in 10 minutes.
Robert Lee
>
> Are you comparing languages or tools. If it's languages then your plan seems
> fine, but if it's tools, is performance just a measure of how fast the
> examples run? It's not a great deal of comfort to have an application that
> runs 10-15% faster (if it does) if you have to wait an extra month to get
> it.
Tools really. And I agree with your assessment. Nonetheless there is
always that "well, MS VC is *so* much faster" Followed by a bunch of
idle speculation, rumor and inuendo. The point of this exercise is to
eliminate that discussion by actually generating some public facts.
Robert Lee
>
> I find this very interesting, as I am planning on including a section on
> performance in my Visual C++ vs Delphi paper
Yes I thought there would be a tie-in there.
> If we can agree on code snippets that are fair comparisons across tools,
> I'll use those code snippets to run tests on my PC.
Basically, I thought we try to win this by volume. Lots of examples in
various areas. I dislike the one number benchmarks because unless that
benchmark is actually *your* program is could be irrelevant. Also by
having the whole thing in CodeCentral anybody would have access and the
ability to comment or complain about any perceived unfairness.
> Also, we could get the Visual C++ guys over in the Microsoft forums to
> participate too, once the tests are defined. It could even be a contest or
> challenge.
If they want to play that's fine by me.
Richard Bayarri Bartual
Robert Lee wrote:
> "Chris Uzdavinis (TeamB)" wrote:
> >
> > Depends on your definition of real world code examples. The real world code
> > I am working on simply cannot be written in VC++ because it's functionally
> > lacking. If you choose to benchmark a subset the language such that VC++
> > can compile it, you are eliminating one of BCB's biggest strengths from the
> > competition.
>
> A definite problem, but only on the "literal translation" part of the
> comparison. Presumably, equivalent code could be developed and
> compared.
One thing that could be done without a lot of effort is compile a bunch of those
example applications that come with the MS compiler using both it and the Borland
one. While not many of them are speed tests, one could at least get an idea of how
big the executables generated by each compiler are without worrying about the
VCL's overhead - some are WinAPI, while others use MFC, but that comes with both
systems anyway. Another thing to consider is DirectX: the SDKs come with the
source for some utilities that are meant to test the speed of graphics hardware,
so it might be interesting to see if compiling them with MS/Borland results in
different figures (MS supply libraries for BCB, so there shouldn't be too many
problems).
Another idea might be to write some examples that thrash the NAG C++ numerics
library, taking into account not only speed, but also the accuracy of the results
produced by both compilers.
If nothing else, fiddling with all this stuff might produce some optimisation
settings that help users of both compilers get the best possible results for their
applications.
John Jacobson
starts tonight, so I'm going to get started myself and then post the results
here and in my paper. Hopefully that can be a starting point for expanding
the tests.
Robert Lee
>
> I don't see any pseudo-code examples posted yet,
You don't because I haven't <g>. Actually, I've got one just about
ready. It is Linear regression test that I stripped out of one of my
simulators. I'll try and get it up by the end of the day. Basically,
I'm thinking that each version should be a unit with a 'test' procedure
that can be called and timed. That way one test rig can handle any of
the tests. Also I need to throw together a quickie timing mechanism
that can is more accurate than GetTickCount and can be implemented in
all enviroments without pulling in all of the Windows API.
> so I'm going to get started myself and then post the results
> here and in my paper. Hopefully that can be a starting point for expanding
> the tests.
Sounds good, we can organize as we go.
Based on my own prelim. test from about a year ago. It is very easy to
skew the results merely by including or excluding specific functions.
This is the "trick" that unscrupulus VC'ers have used to make Borland
look really bad at FP. They always bury an ATAN in it somewhere that VC
code does comparatively fast (but with some sloppiness) but is still so
slow that it swamps all the remaining FP computations. This is the
reason that I wanted to base this on "real" world code. What I'm trying
to say is that if you just cook up your benchmark, your are likely to
also be cooking your biases into the results.
John Jacobson
An ASCII copy of the book of Genesis, King James Version, is used as the
reference text. (This is public doman text.)
Test 1: Find and replace the word "the" with "that".
Test 2: Find and replace the letter "e" with "a".
Test 3: Count the number of times the word "god" (case insensitive) appears
in the text.
Test 4: sort the lines in the text alphabetically (forward and as a second
test, backward)
Test 5: remove sentences with the word "god" (case insensitive) in them.
Test 6: make the entire text uppercase.
Test 7: all tests in one loop
Say, 1000 iterations? Don't count the time used to load the text into
memory.
I'll start the C++ and Delphi code tonight.
--
Have a Delphi day.
John M. Jacobson
joh...@xnet.com
Visit Jake's Delphi Page at http://www.xnet.com/~johnjac
Robert Lee <rh...@nwu.edu> wrote in message
news:38A17EFD...@nwu.edu...
Robert Lee
>
> One thing that could be done without a lot of effort is compile a bunch of those
> example applications that come with the MS compiler using both it and the Borland
> one.
Good for BCB vs VC but doesn't address the Delphi leg of the issue.
Plus it leaves no room for anything but the literal translation and
whose to say that MS hasn't tweaked these with respect to there own
compiler.
> Another idea might be to write some examples that thrash the NAG C++ numerics
> library, taking into account not only speed, but also the accuracy of the results
> produced by both compilers.
Yes, this could be a good starting point.
NeilB
> How about this for the strings tests?
[complex string manipulation spec snipped]
Your post moved me to articulate my thoughts on bechmarking VC++ versus
Delphi versus BCB.
Almost by definition, this [snipped test] would test something, but I'm not
sure what! I could imagine many "cheats" to optimise this (convert the
whole thing to lowercase first, keep a list of occurences of words
beginning with "th" as you read the thing in, maintain two collections one
which sorts forward, and one backwards etc.) but what would it prove? That
one C++ programmer was better than one Delphi programmer?
Personally, I use C++ for the server side of things (COM etc.) and
Delphi/BCB/VB for the GUI, and this works out really well. Nobody is going
to select Delphi or BCB as a development tool because it is faster (or
slower) than VC++ for a particular artificial test - things like training
costs, availability of knowlegeable staff etc. will be much more important.
Bottom line: can't we push Delphi (and BCB) as being complementary to
VC++??? If not, we are losing the Windows environment which, despite the
current Linux fad, is still the only game in town.
NeilB
PS And yes, I do use Linux.
Robert Lee
>
> John Jacobson <joh...@xnet.com> wrote in message news:38a30e3e@dnews...
>
> > How about this for the strings tests?
>
> [complex string manipulation spec snipped]
>
> Your post moved me to articulate my thoughts on bechmarking VC++ versus
> Delphi versus BCB.
>
> Almost by definition, this [snipped test] would test something, but I'm not
> sure what!
Unquestioningly any given test is of only marginal significance. The
goal here is to have multiple tests so that the individual tests aren't
so heavily weighted. This particular test is roughly a mix of several
replacment schemes.
I could imagine many "cheats" to optimise this (convert the
> whole thing to lowercase first, keep a list of occurences of words
> beginning with "th" as you read the thing in, maintain two collections one
> which sorts forward, and one backwards etc.) but what would it prove?
With the entire process being open, the idea is to construct all
versions with the same fundamental algorithm. If say the C++ version is
faster then that algorithm could readily be tried in OP. Besides, that
is only the 1/3 of each test. The other parts are more restricted, for
instance the "simplest" category might be *really* simple in say OP but
probably alot slower than the simplest C++ version.
> Personally, I use C++ for the server side of things (COM etc.) and
> Delphi/BCB/VB for the GUI, and this works out really well. Nobody is going
> to select Delphi or BCB as a development tool because it is faster (or
> slower) than VC++ for a particular artificial test
Again, the idea here is to general a non-artificial test. It *is* worth
little on its own, but this is just one piece. Eventually there will be
many pieces with many (hopefully) from real world problems.
- things like training
> costs, availability of knowlegeable staff etc. will be much more important.
these are important short term. Long term is a different story. Many
people use C++ (and VC++) because they believe the are "supposed" to. I
see this all the time. I often run into a lot of flak for using pascal
for my simulators. "Oh my god! you should use a "real" language like C++
or fortran, your sims would be so much faster". I then proceed to
explain that this is simply not true, that I pay very little if anything
for my choice and my development time is dramatically less. They
typically remain unconvinced. What I would really like to do is be able
to throw some numbers at them.
> Bottom line: can't we push Delphi (and BCB) as being complementary to
> VC++???
Complementary? Do you mean comparable? I definitely think we can make a
statement about how they compare to VC++. Borland has been loathe to do
this, probably because they wouldn't "win" However, what if they loose
by only 5%? Would you pick VC over BCB and all its RAD tools because of
such a small difference?
NeilB
> Complementary? Do you mean comparable? I definitely think we can make a
> statement about how they compare to VC++. Borland has been loathe to do
> this, probably because they wouldn't "win" However, what if they loose
> by only 5%? Would you pick VC over BCB and all its RAD tools because of
> such a small difference?
No, you misunderstand me. I don't think performance is an issue, and I've
never had a (human) client who did. What it all comes down to is that:
- The Borland products (Delphi BCB) are demonstrably superior for building
GUIs.
- The Borland products are not so demonstrably superior for N-tier. The
reliance on CORBA prevents adoption in many (ectually most) business
environments where COM, DCOM and other MS technologies have been adopted.
- VC++ is clearly superior to BCB (by virtue of it's excellent debugger
[Borland, please copy]) for developing server and COM apps.
So Borland have (from my point of view, and I suspect from the point of
view that anyone who has had the misfortune of using VB or programming with
MFC) the GUI, and MS have the server. My question is why don't Borland
leverage the GUI advantage?
NeilB
Mark Reichert
news:87vb2f$cq...@bornews.borland.com...
> - The Borland products are not so demonstrably superior for N-tier. The
> reliance on CORBA prevents adoption in many (ectually most) business
> environments where COM, DCOM and other MS technologies have been adopted.
Delphi does COM.
--
Please respond only in the newsgroup. I will not respond
to newsgroup messages by e-mail.
Santiago Cimadevilla
>(snip)
>- The Borland products are not so demonstrably superior for N-tier. The
>reliance on CORBA prevents adoption in many (ectually most) business
>environments where COM, DCOM and other MS technologies have been adopted.
FWIW, I do lots of COM/DCOM stuff in Delphi with little or no
problems at all - I don't see where Delphi is preventing me from
adopting these technologies.
Santiago.-
Martin Waldenburg
Robert Lee schrieb:
> The other parts are more restricted, for
> instance the "simplest" category might be *really* simple in say OP but
> probably alot slower than the simplest C++ version.
Could also be a lot faster.
Martin
Richard Bayarri Bartual
Robert Lee wrote:
> Good for BCB vs VC but doesn't address the Delphi leg of the issue.
Well, your message text was about VC++ vs. BCB - Delphi wasn't actually mentioned in
the bit I was replying to.
>Plus it leaves no room for anything but the literal translation and
>whose to say that MS hasn't tweaked these with respect to there own
>compiler.
I don't think the MS examples are "tweaked" in any way because they're supposed to
be didactic - if anything, they'd hopefully sacrifice efficiency for clarity, although
one
never knows with MS!
>
> > Another idea might be to write some examples that thrash the NAG C++ numerics
> > library, taking into account not only speed, but also the accuracy of the results
> > produced by both compilers.
>
> Yes, this could be a good starting point.
Or perhaps a freeware offering would be more accessible. There's a fairly comprehensive
set
of C and C++ source code numerics routines at
www.brent.worden.org/products/numericsc.html and
www.brent.worden.org/products/numericscpp.html. I don't usually do heavy numeric stuff
in OP, but it shouldn't be too hard to convert the C ones to OP if there isn't anything
comparable available for Delphi. Note I haven't used these, so I don't know how good
they are - they just came up in a quick web search for freeware numerics libs. Even if
they're not particularly efficient, using the same set of algorithms with all languages
should provide a good starting point for some interesting benchmarks.
GenJerDan
> wrote: NeilB <neil_but...@lineone.net> wrote in message
> news:87vb2f$cq...@bornews.borland.com... > - The Borland products are not
> so demonstrably superior for N-tier. The > reliance on CORBA prevents
> adoption in many (ectually most) business > environments where COM, DCOM
> and other MS technologies have been adopted.
>
I prefer sockets. The added advantage of not having to be on the
same network to use it. (Or can COM do that? Never tried.
Probably won't get around to it, either.)
--
Daniel J. Wojcik
http://www.genjerdan.com/index.htm
--
Richard Bayarri Bartual
NeilB wrote:
> can't we push Delphi (and BCB) as being complementary to
> VC++??? If not, we are losing the Windows environment which, despite the
> current Linux fad, is still the only game in town.
This is pretty much the way I feel too. I use VC++ (Pro version) for the things
that benefit from a _traditional_ C++ coding environment, and Delphi for just
about everything else, or BCB if bits of those "everything else" projects
benefit from some of the things that C++ is better at than OP. They're all
complemetary tools for me, and I wouldn't want to be without any of them. I
must admit that I have little real use for VB and the other stuff that came
with Visual Studio 6 though, so I'll probably just upgrade VC++ and my Borland
tools next time around, as these are what I find myself using.
I do however think that good benchmarks (i.e. not pissing contests between
product advocates or company sponsored "independent tests") have their uses
because they indicate each compiler's strengths and weaknesses. This can be of
great assistance to those who have a particular job in mind, and are seeking
the best tool for it - notable deficiencies can also be used to lobby vendours
into improving subsequent releases of their products. Unfortunately, _good_
benchmarks are notably thin on the ground...
Richard Bayarri Bartual
Robert Lee wrote:
> However, what if they loose
> by only 5%? Would you pick VC over BCB and all its RAD tools because of
> such a small difference?
A few percentiles are not significant in any case, because you can get far bigger
differences by using two apparently identically specified computers from
different manufacturers. Even apparently large differences can in fact be
misleading, especially when they use normal Windows timing mechanisms to measure
processes that take only a few tens of milliseconds to execute.
BTW: one thing I've not seen mentioned in proposals for testing is OOP effciency,
i.e. class creation and destruction, static and virtual method invocations,
exception handling, etc. These could actually be more important in real world use
than the more usual benchmarks, as there are probably a lot more Delphi and
BCB/VC++ apps that frequently create/destroy objects and call methods than ones
that do loads of trig or massive string processing.
Robert Lee
> BTW: one thing I've not seen mentioned in proposals for testing is OOP effciency,
> i.e. class creation and destruction, static and virtual method invocations,
> exception handling, etc. These could actually be more important in real world use
> than the more usual benchmarks, as there are probably a lot more Delphi and
> BCB/VC++ apps that frequently create/destroy objects and call methods than ones
> that do loads of trig or massive string processing.
I've been thinking about this too, but I haven't come up with a
relatively simple example with which to work. I can always make up
something, but I prefer not to.
Mark Reichert
> I prefer sockets. The added advantage of not having to be on the
> same network to use it. (Or can COM do that? Never tried.
> Probably won't get around to it, either.)
I don't know. One would hope DCOM could work network to network.
Richard Bayarri Bartual
Robert Lee wrote:
There used to be some tests like this for evaluating Smalltalk implementations. I'll
dig around
and see if I can find them - if I can, I'll xlate them into C++ and Delphi where this
can be done. Unfortunately, I haven't seen them for years, so I can't make any promises
beyond dredging
around my old disks and listings.
Rudy Velthuis
>There used to be some tests like this for evaluating Smalltalk implementations. I'll
>dig around
>and see if I can find them - if I can, I'll xlate them into C++ and Delphi where this
>can be done. Unfortunately, I haven't seen them for years, so I can't make any promises
>beyond dredging
>around my old disks and listings.
Please also post the Smalltalk originals, if possible (I always found
Smalltalk very interesting, because it was a simple but powerful
concept, and had this very interesting syntax).
--
Rudy Velthuis
NeilB
news:38A496C6...@visual-limes.com...
>
>
> Rudy Velthuis wrote:
>
> > Please also post the Smalltalk originals,
Richard, you and Rudy are probably aware, but other readers of this thread
may not be, that an excellent (and free for the previous version)
implementation of Smalltalk for Win32 can be found at:
NeilB
Richard Bayarri Bartual
NeilB wrote:
Dolphin? I actually use the free one for prototyping Delphi apps - Smalltalk's
great for
that kind of thing. Even freer (but rather slower) is the open-source Squeak,
which was
originally written by some of the Smalltalk authors from the Xerox PARC days.
It's a "primal"
Smalltalk, so the UI is a bit strange for Windows users, but the thing is
entirely written in
itself, and has been ported to almost every imaginable platform. Find it on:
www.squeak.org.
The system's always being updated, and they're promising a JIT VM that offers
a 4x speed
improvement later this year, so it should soon become quite a sprightly
performer.
John Jacobson
TStringLists are faster than CStrings in CStringLists are in VC++ for basic
array-subscripted access, but CString::Replace outperforms Delphi's
ReplaceString. This seems to indicate that the Delphi compiler/linker does a
very good job but is sometimes thwarted by poor library routines. This is
the opposite of VC++, where a lackluster compiler/linker appears to be saved
by better library routines. FWIW, the fastest Delphi timing for strings was
faster than the fastest VC++ timing for strings, so far. TStringLists also
seem more efficient than CStringLists (which in turn are more efficient than
CStringArrays). In any event, it is proving very far from true that VC++
produces significantly faster code, at least when it comes to text
manipulation.
NeilB
> so the UI is a bit strange for Windows users
Something of an understatement :-) I tried Squeak and couldn't make head nor
tail of the GUI.
NeilB
Richard Bayarri Bartual
NeilB wrote:
It was easy for me because it was just like the Smalltalk I used on workstations
in
1981 - brought lots of memories flooding back. Unfortunately, like Oberon, it
doesn't
work very well with a 2-button mouse - you really need 3 buttons.
Ernie Deel
> So far my testing is leading to the conclusion that Delphi's strings in
> TStringLists are faster than CStrings in CStringLists are in VC++ for
> basic array-subscripted access, but CString::Replace outperforms
> Delphi's ReplaceString. This seems to indicate that the Delphi
> compiler/linker does a very good job but is sometimes thwarted by poor
> library routines.
For whatever reason, the word "replace" used in the context of a string function
seems to be almost synonymous with "poor performance" in the Delphi libraries.
The replace functions in HyperString will often beat the standard StringReplace
by an order of magnitude.
--
Ernie Deel, EFD Systems
-----------------------------------------------
First things first ... but not necessarily
in that order.
Erik Funkenbusch
the performance of a library.
I would imagine that TString uses the pascal string internally, while
CString uses it's own string handling functions. VC really takes hits when
calculating string lengths where pascal does not, since it has basic support
for this built in.
John Jacobson <joh...@xnet.com> wrote in message news:38a52bab@dnews...
> So far my testing is leading to the conclusion that Delphi's strings in
> TStringLists are faster than CStrings in CStringLists are in VC++ for
basic
> array-subscripted access, but CString::Replace outperforms Delphi's
> ReplaceString. This seems to indicate that the Delphi compiler/linker does
a
Robert Lee
>
> The replace functions in HyperString will often beat the standard StringReplace
> by an order of magnitude.
Quite true Ernie, but the point is more to the "out of the box"
performance comparison So HyperString is out unless you've managed to
get it on the CD somehow. <g>
Also this is only 1/3 of this test (simplest code). The fastest
possible version(s) won't be using any of those functions or CStrings
for that matter.
John Jacobson
reason why they are faster. I suspect another reason is the fact that the
default calling convention in Delphi is the register calling convention.
The point of the comparison is not to determine how fast each compiler is in
some theoretical situation but rather how fast they will be in everyday use.
My reference to the VC++ compiler as lackluster was made within this
context.
--
Have a Delphi day.
John M. Jacobson
joh...@xnet.com
Visit Jake's Delphi Page at http://www.xnet.com/~johnjac
Erik Funkenbusch <er...@visi.com> wrote in message
news:884b6s$fq...@bornews.borland.com...
Ernie Deel
> Quite true Ernie, but the point is more to the "out of the box"
> performance comparison
Yes, I understand. I was just pointing out that this is an area where the
Delphi libraries are known to be particularly vulnerable to any sort of speed
comparison.
> So HyperString is out unless you've managed to
> get it on the CD somehow. <g>
No, but interesting idea<g>.
Erik Funkenbusch
used.
Your argument is that using CString is a common everyday occurance, then
claim that CStrings poor performance is because the compiler is lackluster.
That makes no sense.
John Jacobson <joh...@xnet.com> wrote in message news:38a5f47f@dnews...
Robert Lee
>
> I still fail to see what the compiler has to do with the class library being
> used.
>
> Your argument is that using CString is a common everyday occurance,
The real question is where this is true or not. Do the work-a-day C++
types really use CString on a regular basis? If they do then it is the
proper choice for the "simple" test. If they don't then it is not.
John Jacobson
significantly faster code" is unfounded. If that is because the compiler is
lackluster or inferior libraries prevent it from creating faster code, is
not as material as the fact that it occurs. I myself am not comparing
compilers or languages but tools. Others in this thread may have other
motives.
--
Have a Delphi day.
John M. Jacobson
joh...@xnet.com
Visit Jake's Delphi Page at http://www.xnet.com/~johnjac
Erik Funkenbusch <er...@visi.com> wrote in message
news:887aq1$h4...@bornews.borland.com...
Erik Funkenbusch
code. Not the quality of the source code that is fed into it.
John Jacobson <joh...@xnet.com> wrote in message news:38a77eff@dnews...
NeilB
> The real question is where this is true or not. Do the work-a-day C++
> types really use CString on a regular basis? If they do then it is the
> proper choice for the "simple" test. If they don't then it is not.
I do all my main work in VC++ these days, and I never use CString.
NeilB
Peter N Roth
> I do all my main work in VC++ these days, and I never use CString.
Do you find the MS newsgroups helpful?
Are they still full of spam?
--
Grace + Peace
Peter N Roth, Engineering Objects International
http://www.inconresearch.com/eoi
Robert Lee
>
> Robert Lee <rh...@nwu.edu> wrote in message
> news:38A77E4F...@nwu.edu...
> > The real question is where this is true or not. Do the work-a-day C++
> > types really use CString on a regular basis? If they do then it is the
> > proper choice for the "simple" test. If they don't then it is not.
>
OK so what do you use for run-of-the-mill strings? PChars?
--
Bob Lee
High Performance Delphi - http://www.econos.com/optimize/
Updated January 20
NeilB
> OK so what do you use for run-of-the-mill strings? PChars?
std::string, from the standard C++ library.
What (in C++) is a "PChar"?
NeilB
Robert Lee <rh...@nwu.edu> wrote in message
news:38A8224B...@nwu.edu...
Mike Mormando
NeilB
news:8894pt$hu...@bornews.borland.com...
> Do you find the MS newsgroups helpful?
> Are they still full of spam?
I actually contribute there quite a bit. I think (hope?) a beginner in using
VC++ might find microsoft.public.vc.language quite useful. Unlike
comp.lang.c++ they don't get flamed quite so much for OT or merely stupid
postings.
NeilB
NeilB
news:889el5$i8...@bornews.borland.com...
> Char *
Not to get too pedantic, but what (in C++) is a "Char"? I'm familiar with
"char". And I've never come across PChar in C++ before.
NeilB
Mike Mormando <mi...@mormando.com> wrote in message
news:889el5$i8...@bornews.borland.com...
Robert Lee
>
> Mike Mormando <mi...@mormando.com> wrote in message
> news:889el5$i8...@bornews.borland.com...
> > Char *
>
> Not to get too pedantic, but what (in C++) is a "Char"? I'm familiar with
> "char". And I've never come across PChar in C++ before.
My mistake, PChar is a delphi type equivalent to char*. I.E. a pointer
to a string of characters terminated with a zero.
John Jacobson
faster than the fastest code I was able to get from either CStrings or
null-terminated strings in VC++. For these operations at least, the Delphi
is producing better code than VC++.
--
Have a Delphi day.
John M. Jacobson
joh...@xnet.com
Visit Jake's Delphi Page at http://www.xnet.com/~johnjac
Erik Funkenbusch <er...@visi.com> wrote in message
news:888jlo$ho...@bornews.borland.com...
Mike Mormando
PChar in Delphi is defined as a
^Char, which in c/c++ would be a char*
Mike
NeilB <neil_but...@lineone.net> wrote in message
news:889et8$i8...@bornews.borland.com...
Richard Bayarri Bartual
NeilB wrote:
> Robert Lee <rh...@nwu.edu> wrote in message
> news:38A8224B...@nwu.edu...
> > OK so what do you use for run-of-the-mill strings? PChars?
>
> std::string, from the standard C++ library.
Me too. Unlike CString, this one is both efficient and portable, and works with
any C++
compiler that supports the STL. CString is really for legacy applications that
were
written with MFC before the days when STL shipped with just about every
commercial
compiler - I don't know of any working C++ programmers who choose it for new
applications nowadays.
Erik Funkenbusch
> So far in my testing, the fastest Delphi strings code was significantly
> faster than the fastest code I was able to get from either CStrings or
> null-terminated strings in VC++. For these operations at least, the Delphi
> is producing better code than VC++.
And what were the operations you performed? Did you use std::string? Why
not?
In another thread, I've shown how VC++ with std::string outperforms TString
in the given examples by simple modifications to the code. Perhaps you are
doing something which has a faster way of doing it in C++.
In any event, since C++ has no native string capability, how you handle
strings is a user-defined function, thus clearly dependant upon how well the
tester writes his code.
John Jacobson
> not?
Lack of time is the reason. I did not have time to get it to compile if I
used the STL containers instead, though I really want to try out this test.
Also, everything in MFC is based on CStrings, so they seemed like a good
area to test.
>
> In another thread, I've shown how VC++ with std::string outperforms
TString
> in the given examples by simple modifications to the code. Perhaps you
are
> doing something which has a faster way of doing it in C++.
I depends on how far a person wants to go in order to optimize I guess.
Afterall, to be technical, a person could use assembler in either case and
acheive maximum speed. I just don't think that is useful if one is
evaluating the idea that one's everyday code is better served by VC++.
Nevertheless, if anyone wants to write the code that uses std::string in the
same way as the code samples I posted elsewhere, I'd be more than happy to
run the tests on this PC so that they are comparable to the other tests I've
been doing. I just did not have the time to investigate every permutation
yet.
> In any event, since C++ has no native string capability, how you handle
> strings is a user-defined function, thus clearly dependant upon how well
the
> tester writes his code.
Maybe, but that also discredits the claim that users will get faster code
if they use VC++.
John Jacobson
MFC and MFC uses CStrings, I think they are a valid area for testing.
--
Have a Delphi day.
John M. Jacobson
joh...@xnet.com
Visit Jake's Delphi Page at http://www.xnet.com/~johnjac
Robert Lee <rh...@nwu.edu> wrote in message
Erik Funkenbusch
> I depends on how far a person wants to go in order to optimize I guess.
> Afterall, to be technical, a person could use assembler in either case and
> acheive maximum speed. I just don't think that is useful if one is
> evaluating the idea that one's everyday code is better served by VC++.
> Nevertheless, if anyone wants to write the code that uses std::string in
the
> same way as the code samples I posted elsewhere, I'd be more than happy to
> run the tests on this PC so that they are comparable to the other tests
I've
> been doing. I just did not have the time to investigate every permutation
> yet.
I can write assembly code that performs worse than interpreted Java. I can
also write C++ code that runs worse than such. The point is that you should
test "optimal" methods against "optmal" methods. All you're doing is
evaluating how well you write C++ code.
> > In any event, since C++ has no native string capability, how you handle
> > strings is a user-defined function, thus clearly dependant upon how well
> the
> > tester writes his code.
>
> Maybe, but that also discredits the claim that users will get faster
code
> if they use VC++.
How? Does it also discredit that Assembly is faster than either language
simply because I'm not very good at writing Assembly?
Erik Funkenbusch
the
> same way as the code samples I posted elsewhere, I'd be more than happy to
> run the tests on this PC so that they are comparable to the other tests
I've
> been doing. I just did not have the time to investigate every permutation
> yet.
BTW, where did you post said code?
Martin Waldenburg
Erik Funkenbusch schrieb:
> thus clearly dependant upon how well the tester writes his code.
Every time and in every language.
Martin
Robert Lee
>
> I can write assembly code that performs worse than interpreted Java. I can
> also write C++ code that runs worse than such. The point is that you should
> test "optimal" methods against "optmal" methods.
I agree in principle. However, part of the basis for this comparison is
to compare code is both simple and could be considered common usage.
What you might consider your first attempt or base case when
optimizing. This is where John's test is comming from. It would seem
from the discussion that his using CStrings is questionable from the
"common usage" standpoint, and a std:strings version should also
probably be thrown into the mix.
Want to give it a try. Remember, simple and common usage are the
goals. Don't optimize it.
NeilB
> MFC uses CStrings throughout. Since the wizards in VC++ are centered
around
> MFC and MFC uses CStrings, I think they are a valid area for testing.
But a _very_ large number of VC++ users (most?) don't use MFC! They use ATL
(and the ATL wizard _doesn't_ use CString) or the standard C++ library.
NeilB
Bob Tasa
string lib with strtok, strstr etc
Hell and if you want to go faster just
use pointers and ++; That works.
Also whats the limit of a string size in
Pascal now? Used to be 256 bytes.
I would think its 64K today. LOL <G>
Bob
On Mon, 14 Feb 2000 10:52:39 -0700, "Mike Mormando"
<mi...@mormando.com> wrote:
>Char *
>
>NeilB <neil_but...@lineone.net> wrote in message
>news:889du2$i8...@bornews.borland.com...
>> What (in C++) is a "PChar"?
>
>
>
Bob Tasa
Director Of Technology
DNA Visual Buisness Solutions
NeilB
news:38a9dccc...@forums.inprise.com...
> Yeah really. There seems to be a whole
> string lib with strtok, strstr etc
> Hell and if you want to go faster just
> use pointers and ++; That works.
> Also whats the limit of a string size in
> Pascal now? Used to be 256 bytes.
> I would think its 64K today. LOL <G>
Um, what are you trying to say here? Have you been taking those pills the
nice doctor told you to?
> Bob Tasa
> Director Of Technology
> DNA Visual Buisness Solutions
I think it very brave of you to provide this information, but remind me
never to have business dealings with you :-)
NeilB
Erik Funkenbusch
> Erik Funkenbusch wrote:
> >
> > I can write assembly code that performs worse than interpreted Java. I
can
> > also write C++ code that runs worse than such. The point is that you
should
> > test "optimal" methods against "optmal" methods.
>
> I agree in principle. However, part of the basis for this comparison is
> to compare code is both simple and could be considered common usage.
common useage is not always best useage. As an example, people often pass
around complete structures when a pointer or reference would work a whole
lot better. I wouldn't call that an "optimization" so much as using common
sense.
Unfortunately, someone that is not very familiar with the language or the
libraries involved, may not have the information to make common sense
judgements about how to write the code.
Example: Writing this would provide much poorer performance:
CString s
for (int a=0; a<1000000, a++) {
s = s + "a"
}
than this:
CString s
for (int a=0; a<1000000, a++) {
s += "a"
}
The first generates needless temporary interim objets and makes the
performance roughly 3x slower, for syntacticly similar statements.
> What you might consider your first attempt or base case when
> optimizing. This is where John's test is comming from. It would seem
> from the discussion that his using CStrings is questionable from the
> "common usage" standpoint, and a std:strings version should also
> probably be thrown into the mix.
Well, there are times and places for everything. If you need performance,
use std::string, if you need MFC compatiblity, use CString, if you need
both... you'll have to create a hybrid.
> Want to give it a try. Remember, simple and common usage are the
> goals. Don't optimize it.
I most certainly will use common sense. But John has not posted his actual
code he used to test that I have found.
Colin Wilson
wrote:
> CString is really for legacy applications that
> were
> written with MFC before the days when STL shipped with just about every
> commercial
> compiler - I don't know of any working C++ programmers who choose it for new
> applications nowadays.
>
That's stretching it a bit. CString is still fundamental to VC++ MFC apps.
For instance the entire Class Wizard is CString oriented.
For instance, when you go into the class wizard (in the latest version of
VC++ 6) and add a member variable for any control on a dialog, the class
wizard gives you just one option for the type of the variable; CString.
Colin
e-mail :co...@wilsonc.demon.co.uk
web: http://www.wilsonc.demon.co.uk/delphi.htm
NeilB
> For instance, when you go into the class wizard (in the latest version of
> VC++ 6) and add a member variable for any control on a dialog, the class
> wizard gives you just one option for the type of the variable; CString.
This assumes that you are writing a GUI using MFC. Most places I've worked
over the past few years would fire you if you even thought of doing such a
thing :-)
NeilB
Erik Funkenbusch
> That's stretching it a bit. CString is still fundamental to VC++ MFC
apps.
> For instance the entire Class Wizard is CString oriented.
>
> VC++ 6) and add a member variable for any control on a dialog, the class
> wizard gives you just one option for the type of the variable; CString.
You mean only one option for string type variables.
Richard Bayarri Bartual
Colin Wilson wrote:
> In article <38A85762...@visual-limes.com>, Richard Bayarri Bartual
> wrote:
> > CString is really for legacy applications that
> > were
> > written with MFC before the days when STL shipped with just about every
> > commercial
> > compiler - I don't know of any working C++ programmers who choose it for new
> > applications nowadays.
> >
>
> That's stretching it a bit. CString is still fundamental to VC++ MFC apps.
> For instance the entire Class Wizard is CString oriented.
>
> For instance, when you go into the class wizard (in the latest version of
> VC++ 6) and add a member variable for any control on a dialog, the class
> wizard gives you just one option for the type of the variable; CString.
Two points:
(1) As many of us have stated, MFC is only used for a minority of VC++ projects
nowadays.
(2) Even in an MFC app, the fact that CStrings are used as GUI input devices or to
read resources does not mean that programmers would select them for string
processing,
any more than a (sensible) Delphi programmer would use variants to do internal
data processing in an OLE/ActiveX application.
Robert Lee
Cool! I seem to have posted from my own future.
--
Bob Lee
High Performance Delphi - http://www.econos.com/optimize/
Updated January 20
Glynn Owen
Charlie Vigue
>
> Cool! I seem to have posted from my own future.
>
>
If you could do that on a regular basis it would be really useful ....
Charlie
Ty Adams
> This assumes that you are writing a GUI using MFC. Most places I've worked
> over the past few years would fire you if you even thought of doing such a
> thing :-)
What would you build a GUI with if you didn't want to get fired?
NeilB
> What would you build a GUI with if you didn't want to get fired?
My last few contracts (in reverse order):
a) Software house producing s/w for the oil industry: ILog Views.
b) A really major international investment bank: VB for the GUI, talking to
COM objects
c) A Dutch software house: Delphi!
d) A large international IT consultancy: VB, SmallTalk and PowerBuilder
(yeuch!)
None of them would ever have considered MFC.
NeilB
John Jacobson
have some kind of reference or support for your claim?
--
Have a Delphi day.
John M. Jacobson
joh...@xnet.com
Visit Jake's Delphi Page at http://www.xnet.com/~johnjac
Richard Bayarri Bartual <r...@visual-limes.com> wrote in message
news:38AAAD21...@visual-limes.com...
NeilB
> All the VC++ programmers I know use character arrays and CStrings. Do you
> have some kind of reference or support for your claim?
Could _you_ say how many "All the VC++ programmers I know" is and what
kinds of projects they are working on?
NeilB
Alex Bakaev [TeamB]
alex
NeilB wrote:
[snip]
> This assumes that you are writing a GUI using MFC. Most places I've worked
> over the past few years would fire you if you even thought of doing such a
> thing :-)
>
> NeilB
--
HotSend - portable documents technology
http://www.hotsend.com/
eFax - get your faxes via email - Free !
http://www.efax.com
Richard Bayarri Bartual
John Jacobson wrote:
> All the VC++ programmers I know use character arrays and CStrings. Do you
> have some kind of reference or support for your claim?
>
Only personal experience, plus notable support from Erik and Neil, who have
both been trying to tell you the same thing. Most C++ programmers are C++
programmers first, and VC++ (or BCB, or whatever) programmers second, so
they tend to favour standard solutions over proprietary ones. There are two
standard solutions available for most jobs in C++: the ones inherited from C
which use the standard C library, and the C++-only ones in the standard C++
library.
NB: a similar situation exists with BCB and the VCL: most C++ programmers
prefer
the standard C++ collections to TList and such, and will therefore only use
the Delphi
data-structures when they are required for interfacing with the GUI.
Likewise, they
tend to use the C++ IOStreams for file IO instead of TStream descendents.
NeilB
NeilB
Alex Bakaev [TeamB] <al...@jetsuite.com> wrote in message
news:38AAFDB9...@jetsuite.com...
Alex Bakaev [TeamB]
a.
NeilB wrote:
[snip]
Alex Bakaev [TeamB]
a.
NeilB wrote:
>
> John Jacobson <joh...@xnet.com> wrote in message news:38aaf141@dnews...
> > All the VC++ programmers I know use character arrays and CStrings. Do you
> > have some kind of reference or support for your claim?
>
> Could _you_ say how many "All the VC++ programmers I know" is and what
> kinds of projects they are working on?
>
John Herbster
Delphi expects a little discipline of the programmer and
C expects the programmer to be a consenting adult.
bio...@erols.com
>
> But doing what??? Even I will admit to knocking up a quick & dirty MFC app
> in an environment where VC++ was the _only_ tool available. But I would
> never do more than a man hour or two development on such.
>
My current employer has almost 500K lines of code that are MFC-based.
Mark
NeilB
And this is a good thing???? Obviously there are a lot of Dilbertesque
organisations out there, but I doubt that many of us wish to work for them.
NeilB
<bio...@erols.com> wrote in message news:38AB9D65...@erols.com...
Alex Bakaev [TeamB]
Being on TeamB doesn't mean working in a Borland shop, unfortunately.
And I do talk to them and thanx to BCB a few source-code blunders are
corrected.
Alex
NeilB wrote:
[snip]
Erik Funkenbusch
publicly, the reply was actually more of a response to John than Robert. My
appologies. I'm posting it again.
> For this stage of the comparison, I compared using Delphi's default
> strings and TstringList against using Visual C++'s Cstrings and
> CstringList. In all these text tests an ASCII copy of the King James
> Version of the Bible was used as the reference text, as it is public
> domain text and is rather large with over 100,000 lines and over
> 4MB in size. The PC used for the test was a 400MHz K6-II with
> 96MB RAM. Both compiles were set to optimize the code for
> speed.
Where might someone get the particular file you used? You agree that the
same file should be used, since even subtle differences like the type of
linefeed used could severely skew the results.
> All these tests required first loading the string list with the text.
> In Delphi the code to do this is one line:
> Sl.LoadFromFile(FileName);
>
> This line took 0.770 seconds to load the entire file into memory.
> CstringList contains no such convenient class member, and so I used the
> following block of code to load the file into memory:
I used a slightly more efficient algorithm. Since I didn't have your exact
file, I created a test file that was 44 characters per line and 100794 lines
long, at about 4MB's in length.
CStringList sl;
CString s;
clock_t start, finish;
double duration;
char ts[1024];
Sleep(1);
start = clock(); file://start test
CStdioFile file("C:\\Winnt\\profiles\\funkenbusche\\desktop\\test.txt",
CFile::modeRead|CFile::typeBinary);
while(file.ReadString(s))
sl.AddTail(s);
finish = clock(); file://end test
duration = (double)(finish - start) / CLOCKS_PER_SEC;
sprintf( ts, "t += a Elapsed Time: %2.3f seconds", duration );
this prints:
time to read 4MB file: 0.671 seconds
Using CStringArray instead of CStringList was a little slower, at .741
seconds (and my system is only a PII-350 versus your K6-2/400).
> The block of code between the start timing and end timing comments took
> 2.08
> seconds to execute, which is more than twice as long as the Delphi code
> took. On to our more important tests.
Due to the less effecient algorithm used.
I don't have the actual file used to do the rest of the tests
John Jacobson
--
Have a Delphi day.
John M. Jacobson
joh...@xnet.com
Visit Jake's Delphi Page at http://www.xnet.com/~johnjac
Erik Funkenbusch <er...@visi.com> wrote in message news:38ac9b7f@dnews...
> Where might someone get the particular file you used? You agree that the
> same file should be used, since even subtle differences like the type of
> linefeed used could severely skew the results.
The test text used is kjv10.txt, the King James Version of the Bible,
downloaded from the Gutenberg project web site at http://www.gutenberg.org
> I used a slightly more efficient algorithm. Since I didn't have your
exact
> file, I created a test file that was 44 characters per line and 100794
lines
> long, at about 4MB's in length.
>
> CStringList sl;
> CString s;
> clock_t start, finish;
> double duration;
> char ts[1024];
>
> Sleep(1);
> start = clock(); file://start test
>
> CStdioFile file("C:\\Winnt\\profiles\\funkenbusche\\desktop\\test.txt",
> CFile::modeRead|CFile::typeBinary);
> while(file.ReadString(s))
> sl.AddTail(s);
>
> finish = clock(); file://end test
> duration = (double)(finish - start) / CLOCKS_PER_SEC;
> sprintf( ts, "t += a Elapsed Time: %2.3f seconds", duration );
>
> this prints:
>
> time to read 4MB file: 0.671 seconds
>
> Using CStringArray instead of CStringList was a little slower, at .741
> seconds (and my system is only a PII-350 versus your K6-2/400).
This weekend I'm going to trying sticking this algorithm into my test
program and see what happens with kjv10.txt.
>
> > The block of code between the start timing and end timing comments took
> > 2.08
> > seconds to execute, which is more than twice as long as the Delphi code
> > took. On to our more important tests.
>
> Due to the less effecient algorithm used.
Or differences in memory, or differences in file content, or...
Bob Tasa
Maybe I shooould go sloooower.
Maybe you dont remember that Pascal used to have the
256 character string limit? Guess not.. Delphi might
not have ever had it but Turbo Pascal by Borland on the
Mac used to. (Yes I owned 1.0)
I know that limit is not true now. (Did you understand the Grin??)
Guess not.
The other point I was making is compareing
String classes is not very good way to measure
the speed of compiled code since the speed
is totaly dependant on how well the class libraries
were written.
Are you trying to prove that Delphi makes better
assembler? Is that the point? Thats what
faster compiled code means. Yooou knooow
how maaany machiine cycles does it take to
dooo an iffff (Slowed down for Neil) and how fast
other basic language instructions are executed.
If the fundamental language instructions break
down to faster code (most optimized assembly
instructions) then the yes the compiled code
is faster.
If you are trying to compare the speeds of
the class libraries then say the Delphi Class
libraries are faster. Here is the proof.
Isss thaaaat theee poooint heeerrrreee?
Its not what it sounded like in the begining.
The begining of the thread was about
testing performance of the compiled code.
But I think it is based on totaly false premise
basing it on the Class libraries performance.
Bob
Hey Neil Didnt see you mention where you work,,
Good thing I did know that either. ;-)
Bob Tasa
What do you consider a string? Something in
class lib or a buffer of chars pointed by
a char *?
I have read to the bottom of the thread it seems
like my point has already to be made.
The speed of class libraried are based on the
coder not the compiler.
The compiler comes into play with how well
each of the languages basic instructions
are executed but NOT how well the class
libraries perform.
Bob
On Tue, 15 Feb 2000 22:12:47 -0600, "John Jacobson" <joh...@xnet.com>
wrote:
>See below...
>
>--
>Have a Delphi day.
>
>John M. Jacobson
>joh...@xnet.com
>
>Visit Jake's Delphi Page at http://www.xnet.com/~johnjac
>
>Bob Tasa <vi...@mediaone.net> wrote in message
>news:38a9dccc...@forums.inprise.com...
>> Yeah really. There seems to be a whole
>> string lib with strtok, strstr etc
>
> But they are SLOWER.
>
>> Hell and if you want to go faster just
>> use pointers and ++;
>
> No, that is slower too.
>
>> Also whats the limit of a string size in
>> Pascal now? Used to be 256 bytes.
>> I would think its 64K today. LOL <G>
>
> 2GB. And they are faster that the strings in C++.
Mike Mormando
reasons. Can you think of some tests that WOULD actually test this point?
Mike
Bob Tasa <vi...@mediaone.net> wrote in message
news:38b2069e....@forums.inprise.com...
Bob Tasa
C compilers developed a long time ago. These were to check how
fast Borlands C/C++ compiler were compared to M$.
Porting those to Delphi should yeild some results.
I dont know if any exist in the public domain but then again
I dont even try to keep up with this area. Lifes to short.
Someone here might know.
Bob
Bob Tasa
Mike Mormando
some compiler makers started putting optimizations in specifically for those
tests, so that if one was detected it would automatically default to the
hand tuned assembly implementation for that particular test.
So I put it out to everyone, the tests that have been proposed here sound
reasonable to me, plenty of people have complained about them though for one
reason or another, though from what I was able to see, most looked like the
old "nuh-uh" objections, so I ask what would be a good test? Or good tests
rather, as I doubt that there is a single test that would truly test the
entire product. I even read in this months C/C++ journal that they didn't
want to do a comparision of C++Builder and VC++, because they wouldn't be
able to fit meaningful results in a few thousand words!?!
A case of mass meekness breaking out?
Mike
Bob Tasa <vi...@mediaone.net> wrote in message
news:38b2ac6e...@forums.inprise.com...
John Jacobson
> I have read to the bottom of the thread it seems
> like my point has already to be made.
> The speed of class libraried are based on the
> coder not the compiler.
> each of the languages basic instructions
> are executed but NOT how well the class
> libraries perform.
Sorry, but this completely misses the point. It doesn't matter if the
compiler is the source of the greater speed, or the code that is passed to
the compiler. The fact is that it is "common knowledge" that using C++
results in faster code. Period. Testing that simple statement is my goal.
What is a C++ programmer likely to use, what is a Delphi programmer likely
to use, and what is the significant performance difference between the two?
So far, the result has been that C++ offers no such advantage in performance
for string manipulations, thus demonstrating the falseness of something that
"everyone knows". I'd like to do a few more string tests in C++, using the
Standard C++ Classes, before going on to other performance tests. The same
algorithms are being used in both C++ and Delphi, so the criticisms that it
just tests "how good a programmer" the tester is, is a bogus criticism.
Having said all that, I am relatively convinced that most C++ programmers
could never overturn their conviction that C++ creates the fastest code, no
matter what evidence is shown.
John Jacobson
"Erik Funkenbusch" <er...@visi.com> wrote in message news:38ad051c@dnews...
> BTW, you really shouldn't start the clock function until after you call
> GetWindowText() (since this can force windows to do a context switch).
No, it ought to be in the same spot in both the Delphi code and the C++
code, or it isn't comparable. The Delphi code gets the text from the control
inside the timed loop.
> Also, you should do a Sleep(1) just prior to calling clock() since this
will
> cause clock() to begin execution at the beginning of a time-slice, giving
> slightly more accurate results (at least for very time-critical
funcitons).
How large is a time slice? How much inaccuracy does this introduce, and
what is the Delphi equivalent? (I can't do this for just C++ if I want it to
mean anything)
>
> Are you running under NT or Windows 9x?
Windows 98.
Charlie Vigue
> the compiler. The fact is that it is "common knowledge" that using C++
> results in faster code. Period. Testing that simple statement is my goal.
Since they share the same code generator I wouldn't really expect a big
difference for similar code.
Try compiling your Delphi examples on a DEC Alpha - you'll see a
difference there. Ditto PowerMAC.
Charlie.
Erik Funkenbusch
> Sorry, but this completely misses the point. It doesn't matter if the
> compiler is the source of the greater speed, or the code that is passed to
> results in faster code. Period. Testing that simple statement is my goal.
Any such absolute statement will of course be wrong. Stating that "Delphi
will always be faster" would be equally wrong.
People that make absolute statements tend to be wrong. As I said in a
different thread, I can write assembly that's slower than Java, does that
means Assembly isn't faster than Java? No, it means that I'm a crappy
assembly programmer ;)
> What is a C++ programmer likely to use, what is a Delphi programmer likely
> to use, and what is the significant performance difference between the
two?
I'd argue that any developer that uses code that doesn't meet their
requirements (such as CString in a high performance requirement situation)
is not a very good developer. Much like the assemply programmer that
creates code that's slower than interpreted Java.
> So far, the result has been that C++ offers no such advantage in
performance
> for string manipulations, thus demonstrating the falseness of something
that
> "everyone knows".
No, all it illustrates is that you have deliberately 'rigged' said tests
(i've already proven how your code was incredibly ineffecient, even given
your restrictions).
> I'd like to do a few more string tests in C++, using the
> Standard C++ Classes, before going on to other performance tests. The same
> algorithms are being used in both C++ and Delphi, so the criticisms that
it
> just tests "how good a programmer" the tester is, is a bogus criticism.
No, it's right on the mark. C++ gives you the potential to write code that
is nearly as good as assembly if you want to. But if you rely strictly on
poorly performing code then no.
> Having said all that, I am relatively convinced that most C++
programmers
> could never overturn their conviction that C++ creates the fastest code,
no
> matter what evidence is shown.
I don't know of any C++ programmer that will say that C++ always creates the
fastest code. I do know many (including myself) that will say that C++
gives you the potential to create the fastest code if that's what you want
(outside of assembly).
Erik Funkenbusch
> "Erik Funkenbusch" <er...@visi.com> wrote in message
news:38ad051c@dnews...
> > BTW, you really shouldn't start the clock function until after you call
> > GetWindowText() (since this can force windows to do a context switch).
>
> No, it ought to be in the same spot in both the Delphi code and the C++
> code, or it isn't comparable. The Delphi code gets the text from the
control
> inside the timed loop.
The difference is how the control get's the text. Does the VCL actually
call the Windows GetWindowText()? Or does it store the window text inside
the VCL so that it doesn't have to call the Windows function? If it has to
call GetWindowText() then it means that context switches must occur from
kerenel mode to user mode, and it also means that depending on how many
messages are in the message queue, it can greatly effect timing.
Change it in the Delphi code as well if you like, just don't include it in
the timing.
> > Also, you should do a Sleep(1) just prior to calling clock() since this
> will
> > cause clock() to begin execution at the beginning of a time-slice,
giving
> > slightly more accurate results (at least for very time-critical
> funcitons).
>
> How large is a time slice? How much inaccuracy does this introduce, and
> what is the Delphi equivalent? (I can't do this for just C++ if I want it
to
> mean anything)
Depends on the OS you use. In NT this can vary depending on how you've got
the performance setting (network versus application). In any event, that's
not the real issue. The issue is that if there's only 10 clock cycles left
on the current quantum when you call clock, then switch contexts, it can be
upwards of 100ms before it gets backs to the task again in certain
circumstances. At a minimum it will probably be 50ms. It adds randomness
to the test results.
> > Are you running under NT or Windows 9x?
>
> Windows 98.
That's even worse. Since the OS can go off for as long as one second
between context switches for certain cases (such as swap file cleanup, which
you can't control).