speed vc++ vs. c++builder

im a visual c++ und borland c++builder newbie.
i have witten a simple mandelbrot algorithm and compiled it with both
vc++ (mfc) and cbuilder (vcl) (same code besides the drawing part).
the vc++ version is twice! as fast in release mode. in debug mode its
as fast as cbuilder. it seems i cant get cbuilder to compile a real
release version. when i check "Project options:compiler:release" it
even gets slower than debug! i have played around a bit with the
advanced compiler options without any result. i also dropped the
drawing part, supposing that it causes slowdown somehow. the cbuilder
version is not faster than the same code on delphi 7 (maybe the same
problem). what can i do? i cant believe cbuilder (and delphi) to be
that much slower than vc++. i think its just a problem of finding the
right compiler options.

Advertisements

"PDQBach" <> wrote...
> im a visual c++ und borland c++builder newbie.
> i have witten a simple mandelbrot algorithm and compiled it with both
> vc++ (mfc) and cbuilder (vcl) (same code besides the drawing part).
> the vc++ version is twice! as fast in release mode. in debug mode its
> as fast as cbuilder. it seems i cant get cbuilder to compile a real
> release version. when i check "Project options:compiler:release" it
> even gets slower than debug! i have played around a bit with the
> advanced compiler options without any result. i also dropped the
> drawing part, supposing that it causes slowdown somehow. the cbuilder
> version is not faster than the same code on delphi 7 (maybe the same
> problem). what can i do? i cant believe cbuilder (and delphi) to be
> that much slower than vc++. i think its just a problem of finding the
> right compiler options.

Right. And to solve it you need to post to the C++ Builder newsgroup
instead of C++ language one. You don't have a _language_ problem.
Your problem, as you so precisely determined, is in finding the right
compiler options. Try borland.public.cppbuilder.* hierarchy.

Advertisements

(PDQBach) wrote in message news:<>...
> Hello,
>
> im a visual c++ und borland c++builder newbie.
> i have witten a simple mandelbrot algorithm and compiled it with both
> vc++ (mfc) and cbuilder (vcl) (same code besides the drawing part).
> the vc++ version is twice! as fast in release mode. in debug mode its
> as fast as cbuilder.

It's off-topic, but this is fairly typical -- as a general rule,
Borland compilers optimize relatively poorly. With some work, you can
probably improve it somewhat, but chances are it'll remain somewhat
slower anyway.
Later,
Jerry.

<but chances are it'll remain somewhat slower anyway.
i wouldnt call twice as fast somewhat. i prefer bcb for the ease of
use but such differences are inacceptable. i get the same results with
the following:

I've crossposted this to what I believe to be the appropriate Borland
group, because as noted it's offtopic for clc++, and I as a Borland
user have some interest in the answer. You can read the Borland group
using newsgroups.borland.com as your news server, if the one you're
using now doesn't carry the Borland groups.

If it thinks anything other than "wrong", then it's not
standard-compliant. Unlike C, C++ does not permit alternative
implementation-defined forms for main() where the return type is not
int. In other words, implementation-defined forms are allowed, but they
must return int.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

In comp.lang.c++ Kevin Goodsell <> wrote:
> If it thinks anything other than "wrong", then it's not
> standard-compliant. Unlike C, C++ does not permit alternative
> implementation-defined forms for main() where the return type is not
> int. In other words, implementation-defined forms are allowed, but they
> must return int.

So the parameters but not the return type are up for grabs?

Not to dwell (again) on bcc32, but some of our code has

void CMAIN( int argc, char **argv );

as the main function, through some (dubious?) magic that I don't
necessarily understand; hence my uncertainty regarding this issue.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

Christopher Benson-Manica wrote:
> In comp.lang.c++ Kevin Goodsell <> wrote:
>
>
>>If it thinks anything other than "wrong", then it's not
>>standard-compliant. Unlike C, C++ does not permit alternative
>>implementation-defined forms for main() where the return type is not
>>int. In other words, implementation-defined forms are allowed, but they
>>must return int.
>
>
> So the parameters but not the return type are up for grabs?

That seems to be the case. Although, I don't think a diagnostic is
required for an incorrect main() return type. I should have mentioned
that before.
>
> Not to dwell (again) on bcc32, but some of our code has
>
> void CMAIN( int argc, char **argv );
>
> as the main function, through some (dubious?) magic that I don't
> necessarily understand; hence my uncertainty regarding this issue.
>

Scary. Here's hoping that elsewhere in your code, you have something
like this:

Now, even if you don't read Intel assembly language very well, you can
pretty easily see that the VC++ version does NOT include any FMUL
instruction -- i.e. it's not really doing a floating point
multiplication at all. To make a long story short, its output is
basically equivalent to:

for (double i=0; i<limit; ++i)
;

and that's it. The Borland version does pretty much what you asked
for: it does the multiplication inside of the loop, thus slowing
things down substantially.

This sort of thing tends to have a much smaller effect on real code
than on synthetic benchmarks like this; as a rule, you won't do 200
million multiplications unless you actually have some use for the
results they produce. When/if you use the results, VC++ will probably
have do the multiplications as well, and slow down substantially.
> i think theres nothing to optimize? how cant bcb optimizer screw up
> such simple things? (sorry for continuing an offtopic thread)

As you can see above, there's really quite a bit that's open to
optimization here -- but it probably wouldn't be with real code that
was otherwise similar.

Just for example, here's the same basic code, but modified to use
(i.e. print out) the result generated inside the loop:

With this, the difference I get is much smaller -- 2.734 seconds for
VC++ and 3.109 seconds for BCC 5.5.

That pretty much fits my earlier prediction: Borland does produce
slower output, but not by such a huge margin as to render it unusable.
They've evened out a lot because now they're at least doing the same
problem. The difference is that VC++ explicitly keeps most of what
it's working with in floating point registers, while BC++ loads a
value from memory, operates on it, and then stores the result back to
memory each iteration. The cache keeps this from being excruciatingly
slow, but even L1 cache is still slower than using a register
directly.

In case you care, the result this prints out is the Nth harmonic
number. Harmonic numbers are related to a number of interesting
questions. If you assign each card a length of 2, then N iterations
will tell you the length of overhang for N cards. With N=200000000,
we get an overhang of almost 10 complete cards in length -- but
assuming the cards are about the normal thickness, the stack would be
the tallest thing on earth, by quite a large margin -- you'd need
pretty old, thin cards to get it down to quadruple the height of Mt.
Everest!
Later,
Jerry.

> Let me rewrite your program, removing non-standard code and
> removing lines which have no effect (something that an optimiser
> would do):
for (double i=0; i<200000000; ++i) j = i*1000000;
why did you remove this? it has an effekt because j is changing each
time and for this reason vc++ doesnt remove too.
i just wanted to compare the multiplikation speed of vc++ and bcb (to
find out the reason why the upmentioned progamm is so slow on bcb).

Was thinking, the above may not be correct. Sure 'j' is now used in side
effects. But a super-smart compiler will see that the bounds of the for
loop
> > for (double i=0; i<200000000; ++i) j = i*1000000;

are known at compile time, and the body of the for loop is builtin math. So
it may evaluate the expression at compile time, and replace

Back in 2000, I think the KAI C++ compiler did these kinds of optimizations,
even if the body of the for loop invoked standard functions like std::sin
and std::strlen and the function arguments were could be known at compile
time.
> In addition, I think Borland uses STLPort iostreams, which may not as
> optimized as MSVC iostreams.

however, in the upmentioned (incomplete, sorry) mandelbrot algorithm,
there should be real floating point operations. i finished another
program to quickly color the inside of the mset according to the
periodicity of the point and have the same results. vc++ is again
twice as fast. in release mode bcb still is slower than in debug mode.
btw does anyone now an easy guessing algorithm for the mandelbrotset?
i could make my new program much faster (at the moment with vc++ its 3
times faster than ultrafractal (guessing turned off).) the trick is to
adapt the maximum iteration (easily up to 100000) if no period was
found at lower iteration and then continue iteration from the last z.
im not sure wether a guessing algorithm could be implemented with this
trick.

(PDQBach) wrote:
> > Let me rewrite your program, removing non-standard code and
> > removing lines which have no effect (something that an optimiser
> > would do):
> for (double i=0; i<200000000; ++i) j = i*1000000;
> why did you remove this? it has an effekt because j is changing each
> time and for this reason vc++ doesnt remove too.

'j' changing, does not count as an effect. Your code is like:
j = 1 * 1000000;
j = 2 * 1000000;
j = 3 * 1000000;
and any sane optimiser would remove all of these statements except the
final one. Then, 'j' is not used later on in the program either, so the
optimiser would remove it entirely.
> i just wanted to compare the multiplikation speed of vc++ and bcb (to
> find out the reason why the upmentioned progamm is so slow on bcb).

You should look at the assembly generated by each for that loop.
That is the only reliable way to check that you are comparing apples
with apples. It will also tell you what each compiler does differently.
I also suggest you read the manuals for your compiler options. Likely
options include 80686 code generation, and fast floating point.

For example, VC could be using a register for 'j' and BCC might be using
memory, which would certainly account for the discrepancy. Also, if BCC
is in 386 mode (the default) then it might not be using the latest CPU
multiplication instructions available.

> and any sane optimiser would remove all of these statements except the
> final one.
well, in my casevc++ seems to do something (but doesnt remove the
useless statements). just try it, if you own both vc++ and bcb 6. but
there are indeed situations where vc++ cuts out statements and bcb
doesnt. however, i decided to use vc++ now, because most of my
applications are time-critical. but, besides speed, vc++ 6 is quite a
mess compared to bcb (from the beginners standpoint...). as a non
professional programmer i would like a language that, in most parts,
is as simple as basic and in other, time-critical parts, allows to be
more complicated and faster. something like an hybrid language.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!