www.digitalmars.com Home | Search | C & C++ | D | DMDScript | News Groups | index | prev | next
Archives

D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger

C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows

digitalmars.empire
digitalmars.DMDScript

c++ - Raw speed! w00t!!

↑ ↓ ← "Matt Morgan" <geckofood yahoo.com> writes:
I have just written an application using wxWidgets that reads in large lists 
of text strings and stores them in memory. I wrote the application in such a 
manner that I can compile it with Digital Mars C++, Borland C++, MinGW, and 
OpenWatcom C++. It relies heavily on file streams and dynamic memory 
allocation. I decided to do a little test, based on a difference I was 
seeing between the four.

I put a timer on the load member function and I spit out the result to the 
screen. I then loaded the largest file of strings, approximately 350,000 
lines (a little more, actually). I did a series of loading and unloading of 
the files from disk to memory, and I found some nifty results. To load the 
file from disk to memory took each compiler's resulting executable the 
following amounts of time, on average.

Borland C++ v5.81 (the latest version, right out of the box) : 3650 ms.
Digital Mars C++ v8.47 : 300 ms.
MinGW version unknown : 1000 ms.
OpenWatcom C++ v1.3 : 1100 ms.

I tried a number of things to bring down the time on Borland's execution, 
and I got nowhere with it. Fully optimized and tweaked for performance still 
did not improve its performance. It did generate the smallest executable, 
though.

I was surprised by OpenWatcom. Past tests have shown it to be a poor 
performer, and this time it did reasonably ok.

DMC's time is not a typo. It was more than 10x faster than Borland and 3x 
faster than MinGW and OpenWatcom.

I did not bother with MS, because I cannot build the library due to an 
environment issue (yeah, the Surgeon General has determined that using MSVC 
is hazardous to your brain). I think I screwed it up when I installed 
something after it.

So, need raw speed? DMC delivers. More so than I ever imagined. Good job, 
Walter!!

w00t! 31337 haX0rz y00z DMC++! (Ok, maybe I'm getting a little carried 
away). 
Feb 09 2006
↑ ↓ → Heinz Saathoff <newshsaat arcor.de> writes:
Matt Morgan schrieb...
 I have just written an application using wxWidgets that reads in large lists 
 of text strings and stores them in memory. I wrote the application in such a 
 manner that I can compile it with Digital Mars C++, Borland C++, MinGW, and 
 OpenWatcom C++. It relies heavily on file streams and dynamic memory 
 allocation. I decided to do a little test, based on a difference I was 
 seeing between the four.
 
 I put a timer on the load member function and I spit out the result to the 
 screen. I then loaded the largest file of strings, approximately 350,000 
 lines (a little more, actually). I did a series of loading and unloading of 
 the files from disk to memory, and I found some nifty results. To load the 
 file from disk to memory took each compiler's resulting executable the 
 following amounts of time, on average.
 
 Borland C++ v5.81 (the latest version, right out of the box) : 3650 ms.
 Digital Mars C++ v8.47 : 300 ms.
 MinGW version unknown : 1000 ms.
 OpenWatcom C++ v1.3 : 1100 ms.
 
 I tried a number of things to bring down the time on Borland's execution, 
 and I got nowhere with it. Fully optimized and tweaked for performance still 
 did not improve its performance. It did generate the smallest executable, 
 though.

With your kind of application you probably test the runtime and standard library implementation rather than the compiler quality. That may be the reason why tweaking with optimizations will not increase performance. If this is true then Walters implementaion of runtime and standard library is very good. - Heinz
Feb 14 2006