Mail Archives: djgpp/2001/12/26/16:17:40
In my opinion, I have NO question that the C++ version would be
_significantly_ slower.
It has been my _long_term_ observation that C++ tends to suck the
(so-called) power right out of CPU's.
True, however, C++ provides for a functionality unattainable using any
other means, and can be quite worth the overhead _sometimes_ but not
always.
I too like dealing with LOTS of embedded information in an EXE, and I
have found C++ versions disappointingly SLOWER.
MSVC vs DJGPP for my applications: DJ is CLEARLY faster, Borland
disappointingly far behind.
I use technique which stores all fseek pointers to every line of text
in a file to "flip" it upsidedown, so I've some experience with this.
It's also an old technique for simple command-line text-editor manual
scrolling....
email: radsmail AT juno DOT com
http://members.tripod.com/~RadSurfer/
Join us on Yahoo at:
http://groups.yahoo.com/group/BorlandCPPBuilder
for informal discussions about all versions of Borland C/C++,
especially C++Builder... Win9x, and Console32, also DJGPP.
(you must be a Yahoo member to join)
On Sat, 22 Dec 2001 14:10:48 GMT, CBFalconer <cbfalconer AT yahoo DOT com>
wrote:
>C_CPP_guy wrote:
>>
>> cleaning up/rewriting some code from C to C++ I noticed that there
>> was a speed degradation that, to me, was not caused by my coding.
>> The program is I/O intensive. It counts all charaters in a file
>> and saves their offsets and and then checks that the saved values
>> are right.
>>
>> As data feeds I use small and large text and binary files and I
>> used VC++6 as env. , but also tested the code using deloire's
>> djgpp to make sure it was ANSI C/C++.
>>
>> In both cases code was compiled for speed; /O2 compiler option.
>>
>> /nologo /MLd /W3 /Gm /GX /O2 /D "WIN32" /D "_DEBUG" /D "_CONSOLE"
>> /D "_MBCS" /Fp"Debug/std_char_ptr.pch" /YX /Fo"Debug/" /Fd"Debug/"
>> /FD /c
>>
>> Here are my questions.
>>
>> Questions:
>> ._ I have always heard local arrays are faster then heap based
>> ones. I tested it and found no difference whatsoever. So, what is
>> it I don't quite understand here?
>>
>> ._ The same algorithm coded in plain ANSI C is 67% faster. Scott
>> Meyers and many other C++ gurus state that there is no or very
>> little, 5%, speed difference between C and C++ programs. What is
>> it I am doing wrong here?
>>
>> ._ Is this the most optimal compiler setting for speed using
>> Win32/VC++?
>
>... snip code ...
>
>I would be much more inclined to try to compile those if the code
>came over unharmed. This means keeping line length under about
>72, and NOT using // comments. Just the use of those comments
>makes the C code non-compliant under C90. Your djgpp/gcc compile
>should have showed that up if you used suitable flags (-W -ansi
>-Wall -pedantic -O2)
>
>The same line length limit should also apply to your article.
>BTW, that's delorie, not deloire.
>
>The speed difference between using malloc and local storage is not
>in the use, but in the getting. Local allocation is normally
>something like an add to a register on function entry (sp on the
>x86), while malloc, and the accompanying free, are system calls.
>
>The way to put your finger on the speed differences is to
>profile. You will probably find the hot spots are different.
>
>PS: I later found your article multi-posted on
>comp.os.msdos.djgpp. Don't do that, cross post instead. That way
>I would not have been bothered by having it appear twice, and the
>thread is joined between the two groups.
- Raw text -