Another benchmark. OOPack tries to evaluate the cost of using OOP against the cost of the "plain C" style.

The D port is a quick 'n' dirty hack ...

gdc-0.8(gcc-3.4.2): -O2 -frename-registers -fomit-frame-pointer -fweb
-frelease -finline-functions -march=i686
                         Seconds       Mflops
Test       Iterations     C    OOP     C    OOP  Ratio
----       ----------  -----------  -----------  -----
Iterator       100000  0.530 28.990  377.358 6.899  54.698 Complex          1000  0.020 801.01  400.000 0.010  40050.500 Matrix           1000  0.890 7.420  280.899 33.693  8.337 Max            100000  0.860 3.510  116.279 28.490  4.081

dmd-0.105: -O -release -inline
                         Seconds       Mflops
Test       Iterations     C    OOP     C    OOP  Ratio
----       ----------  -----------  -----------  -----
Iterator       100000  1.060 9.910  188.679 20.182  9.349 Complex          1000  0.040 3.990  200.000 2.005  99.750 Matrix           1000  1.460 6.720  171.233 37.202  4.603 Max            100000  0.790 3.530  126.582 28.329  4.468

g++-3.4.2: -O3 -march=i686
                         Seconds       Mflops
Test       Iterations     C    OOP     C    OOP  Ratio
----       ----------  -----------  -----------  -----
Iterator       100000    0.5   0.5  377.4 377.4    1.0
Complex          1000    0.0   0.1  400.0  57.1    7.0
Matrix           1000    0.9   0.7  274.7 342.5    0.8
Max            100000    0.8   0.8  126.6 126.6    1.0

icc-8.0: -O3 -march=i686
                         Seconds       Mflops
Test       Iterations     C    OOP     C    OOP  Ratio
----       ----------  -----------  -----------  -----
Iterator       100000    0.5   0.6  444.4 357.1    1.2
Complex          1000    0.0   0.0  400.0 400.0    1.0
Matrix           1000    0.7   0.7  384.6 384.6    1.0
Max            100000    0.7   0.7  137.0 137.0    1.0

gdc's Iterator and Complex test seem really bad. Both the frontend and the backend generate better results. This might be an integration problem or an optimization where the init code was in-lined into the OOP benchmark function.

Interestingly gcc's Matrix-C function is slower than it's Matrix-OPP function.

Intel's results are that good, because the bought the company(kai.com) that
wrote this benchmark along with their compiler(KAI C++) and tuned icc for
this benchmark.

OOPack (C++ & D) the original C++ page has vanished
svn://svn.kuehne.cn/dstress/benchmark/oopack

Thomas

This result looks not good for D.  I have never seen a benchmark where D performs so bad like this compared with C++.  Is it just because "The D port is a quick 'n' dirty hack"; or some other reasons.

D is designed to be a simpler language than C++, the object model should be more efficient, right?


In article <cmcp5c$41g$4@digitaldaemon.com>, Thomas Kuehne says...
>
>Another benchmark. OOPack tries to evaluate the cost of using OOP against the cost of the "plain C" style.
>
>The D port is a quick 'n' dirty hack ...
>
>gdc-0.8(gcc-3.4.2): -O2 -frename-registers -fomit-frame-pointer -fweb -frelease -finline-functions -march=i686
>                         Seconds       Mflops
>Test       Iterations     C    OOP     C    OOP  Ratio
>----       ----------  -----------  -----------  -----
>Iterator       100000  0.530 28.990  377.358 6.899  54.698 Complex          1000  0.020 801.01  400.000 0.010  40050.500 Matrix           1000  0.890 7.420  280.899 33.693  8.337 Max            100000  0.860 3.510  116.279 28.490  4.081
>
>dmd-0.105: -O -release -inline
>                         Seconds       Mflops
>Test       Iterations     C    OOP     C    OOP  Ratio
>----       ----------  -----------  -----------  -----
>Iterator       100000  1.060 9.910  188.679 20.182  9.349 Complex          1000  0.040 3.990  200.000 2.005  99.750 Matrix           1000  1.460 6.720  171.233 37.202  4.603 Max            100000  0.790 3.530  126.582 28.329  4.468
>
>g++-3.4.2: -O3 -march=i686
>                         Seconds       Mflops
>Test       Iterations     C    OOP     C    OOP  Ratio
>----       ----------  -----------  -----------  -----
>Iterator       100000    0.5   0.5  377.4 377.4    1.0
>Complex          1000    0.0   0.1  400.0  57.1    7.0
>Matrix           1000    0.9   0.7  274.7 342.5    0.8
>Max            100000    0.8   0.8  126.6 126.6    1.0
>
>icc-8.0: -O3 -march=i686
>                         Seconds       Mflops
>Test       Iterations     C    OOP     C    OOP  Ratio
>----       ----------  -----------  -----------  -----
>Iterator       100000    0.5   0.6  444.4 357.1    1.2
>Complex          1000    0.0   0.0  400.0 400.0    1.0
>Matrix           1000    0.7   0.7  384.6 384.6    1.0
>Max            100000    0.7   0.7  137.0 137.0    1.0
>
>gdc's Iterator and Complex test seem really bad. Both the frontend and the backend generate better results. This might be an integration problem or an optimization where the init code was in-lined into the OOP benchmark function.
>
>Interestingly gcc's Matrix-C function is slower than it's Matrix-OPP function.
>
>Intel's results are that good, because the bought the company(kai.com) that
>wrote this benchmark along with their compiler(KAI C++) and tuned icc for
>this benchmark.
>
>OOPack (C++ & D) the original C++ page has vanished
>svn://svn.kuehne.cn/dstress/benchmark/oopack
>
>Thomas

no@where.com schrieb am Donnerstag, 4. November 2004 23:19:
> This result looks not good for D.  I have never seen a benchmark where D performs so bad like this compared with C++.  Is it just because "The D port is a quick 'n' dirty hack"; or some other reasons.

The D port is "quick 'n' dirty hack" because it neither uses static/const attribute nor D's on constructs like "foreach". Currently it's only in the state where it might uncover serious problems like gdc's "Complex" test case. This benchmark requires review before it can provide comparable data. Comeon every one and tune this monster. ;) svn://svn.kuehne.cn/dstress/benchmark/oopack

> D is designed to be a simpler language than C++, the object model should be more efficient, right?
Guess so too, but keep in mind that - compared to dmc, gcc and icc - the
current D compilers are relativly young.
To figure out what is going on someone with some time to spare and a dual
boot Linux(dmd,gdc,gcc)/Windows(dmc,dmd,gdc,gcc) box should run the
benchmark. This way it should be possible to figure if the problem lies
within the frontent, backend, benchmark port or the interaction of the tool
chain.

Thomas

"Thomas Kuehne" <thomas-dloop@kuehne.cn> wrote in message news:cmei3a$34n$1@digitaldaemon.com...
> svn://svn.kuehne.cn/dstress/benchmark/oopack

The link doesn't work. Can you check it, please?

Walter wrote:

>>svn://svn.kuehne.cn/dstress/benchmark/oopack
> 
> The link doesn't work. Can you check it, please?

It seems to work fine from here: (it's a Subversion link)

> # svn checkout svn://svn.kuehne.cn/dstress/benchmark/oopack                                              [6]
> A  oopack/oopack_v1p8_d.d
> A  oopack/oopack_v1p8_cpp.cpp
> Checked out revision 125.

Maybe Thomas could provide zipped snapshots too ? (http)

--anders

PS. Subversion software at http://subversion.tigris.org/

Thomas Kuehne wrote:

> Another benchmark. OOPack tries to evaluate the cost of using
> OOP against the cost of the "plain C" style.
> 
> The D port is a quick 'n' dirty hack ...

Here are the test results from GDC, running on Mac OS X 10.3:

g++ 3.4.2: (g++ -O3 -mcpu=G4)

                         Seconds       Mflops
Test       Iterations     C    OOP     C    OOP  Ratio
----       ----------  -----------  -----------  -----
Iterator       100000    0.7   0.8  281.7 266.7    1.1
Complex          1000    0.0   0.2  400.0  42.1    9.5
Matrix           1000    0.9   0.9  280.9 274.7    1.0
Max            100000    1.5   1.9   65.8  52.1    1.3

gdc 0.8: (gdc -O2 -fweb -frelease -finline-functions -mcpu=G4)

                         Seconds       Mflops
Test       Iterations     C    OOP     C    OOP  Ratio
----       ----------  -----------  -----------  -----
Iterator            0  0.000 0.000    nan   nan    nan
Complex             0  0.000 0.000    nan   nan    nan
Matrix              0  0.000 0.000    nan   nan    nan
Max                 0  0.000 0.000    nan   nan    nan

Oops! Hmmm, seems like the clock functions are a bit off:

std/c/time.d:
>version (darwin) {
>const uint CLOCKS_PER_SEC = 100;
>const uint CLK_TCK        = 100;
>} else {
>const uint CLOCKS_PER_SEC = 1000;
>const uint CLK_TCK        = 1000;
>}

And the strtol function has the wrong return type: (64, not 32)

oopack_v1p8_d.d:
>version (darwin) {
>extern (C) int strtol(char *nptr, char **endptr, int base);
>} else {
>extern (C) long strtol(char *nptr, char **endptr, int base);
>}

                         Seconds       Mflops
Test       Iterations     C    OOP     C    OOP  Ratio
----       ----------  -----------  -----------  -----
Iterator       100000  0.070 1.279  2857.143 156.372  18.271
Complex          1000  0.002 0.483  4000.000 16.563  241.500
Matrix           1000  0.095 0.753  2631.579 332.005  7.926
Max            100000  0.233 0.375  429.185 266.667  1.609

Still seems off by a factor ten, but it did take way longer...


Both were using the same local gcc/gdc build, by the way.
(i.e. I used the g++ compiler from the gdc installation)

--anders


PS. "For a run to be accepted, adjust the number of iterations
     for each test so that each time reported is greater than
     10 seconds." (reported by program) I just used the same #.

In article <cmei3a$34n$1@digitaldaemon.com>, Thomas Kuehne says...
>
>no@where.com schrieb am Donnerstag, 4. November 2004 23:19:
>> This result looks not good for D.  I have never seen a benchmark where D performs so bad like this compared with C++.  Is it just because "The D port is a quick 'n' dirty hack"; or some other reasons.
>
>The D port is "quick 'n' dirty hack" because it neither uses static/const attribute nor D's on constructs like "foreach". Currently it's only in the state where it might uncover serious problems like gdc's "Complex" test case. This benchmark requires review before it can provide comparable data. Comeon every one and tune this monster. ;) svn://svn.kuehne.cn/dstress/benchmark/oopack
>

"finalizing" all of the classes gives much better results for everything except Complex - the main problem there is that several new Complex objects are created for each iteration of the oop_test..

Anyone have a solution for that?

>> D is designed to be a simpler language than C++, the object model should be more efficient, right?
>Guess so too, but keep in mind that - compared to dmc, gcc and icc - the
>current D compilers are relativly young.
>To figure out what is going on someone with some time to spare and a dual
>boot Linux(dmd,gdc,gcc)/Windows(dmc,dmd,gdc,gcc) box should run the
>benchmark. This way it should be possible to figure if the problem lies
>within the frontent, backend, benchmark port or the interaction of the tool
>chain.
>
>Thomas

"Anders F Björklund" <afb@algonet.se> wrote in message news:cmfj31$21j4$1@digitaldaemon.com...
> Walter wrote:
>
> >>svn://svn.kuehne.cn/dstress/benchmark/oopack
> >
> > The link doesn't work. Can you check it, please?
>
> It seems to work fine from here: (it's a Subversion link)
>
> > # svn checkout svn://svn.kuehne.cn/dstress/benchmark/oopack
[6]
> > A  oopack/oopack_v1p8_d.d
> > A  oopack/oopack_v1p8_cpp.cpp
> > Checked out revision 125.
>
> Maybe Thomas could provide zipped snapshots too ? (http)

Or just make .txt files out of the code and link to them? That way we can examine the code without needing to download, unzip, etc.

Walter wrote:

>>Maybe Thomas could provide zipped snapshots too ? (http)
> 
> Or just make .txt files out of the code and link to them? That way we can
> examine the code without needing to download, unzip, etc.

AFAIK, there should be web interfaces to Subversion that
let's you do both things automatically from the repository...

I know such things exists for CVS, at least.

--anders

Anders F Björklund schrieb:
> >>Maybe Thomas could provide zipped snapshots too ? (http)
> >
> > Or just make .txt files out of the code and link to them? That way we can examine the code without needing to download, unzip, etc.
>
> AFAIK, there should be web interfaces to Subversion that let's you do both things automatically from the repository...
>
> I know such things exists for CVS, at least.

I am going to enable http access soon - before that I have to make sure that the different access rights are correct.

Thomas