X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f From: Radical DOT NetSurfer AT delorie DOT com Newsgroups: comp.os.msdos.djgpp Subject: Re: C 67% faster than C++?! Date: Wed, 26 Dec 2001 16:04:42 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <7rek2uo9l0m5v7a2sd2cn50fs8hb344jp5@4ax.com> References: <1009003660 DOT 300355 AT news> <3C248C53 DOT AF6F7DED AT yahoo DOT com> X-Newsreader: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: newsabuse AT supernews DOT com Lines: 86 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com 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 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.