Anders F Björklund schrieb:
> 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);
>  >}

Thanks, fixed it.

Thomas

Dave schrieb:
> >The D port is "quick 'n' dirty hack" because it neither uses static/const attributes nor D's own 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. Come on 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?

Could you please send me a diff of your finalized version?

Thomas

> > >>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.

Http access to DStress and the benchmark sources is up and running.

http://svn.kuehne.cn/dstress
svn://svn.kuehne.cn/dstress

Thomas

"Thomas Kuehne" <thomas-dloop@kuehne.cn> wrote in message news:cmjgps$2t9i$1@digitaldaemon.com...
> Http access to DStress and the benchmark sources is up and running.
>
> http://svn.kuehne.cn/dstress
> svn://svn.kuehne.cn/dstress

Thanks. The reason the HAVE_COMPLEX D benchmark is so slow is that class Complex, in D, is created on the heap, whereas it is used as strictly a value object. The first solution is to make it a struct instead of a class, which will make it a value object. Even better, just replace class Complex with cdouble, which is D's complex double native type.

In article <cmh819$2ij6$1@digitaldaemon.com>, Thomas Kuehne says...
>
>Dave schrieb:
>> >The D port is "quick 'n' dirty hack" because it neither uses static/const attributes nor D's own 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. Come on 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?
>
>Could you please send me a diff of your finalized version?
>
>Thomas
>
>

Ok - here that is:

322c322
< final class MaxBenchmark : Benchmark {
---
> class MaxBenchmark : Benchmark {
380c380
< final class MatrixBenchmark: public Benchmark {
---
> class MatrixBenchmark: public Benchmark {
405c405
<       final class Matrix {
---
>       class Matrix {
480c480
< final class IteratorBenchmark: public Benchmark {
---
> class IteratorBenchmark: public Benchmark {
498c498
<       final class Iterator {
---
>       class Iterator {
566c566
< final class ComplexBenchmark: public Benchmark {
---
> class ComplexBenchmark: public Benchmark {
585c585
<       final class Complex {
---
>       class Complex {

- Dave

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
>
>> 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

In the NG archives there has been talk about the compiler being able to 'auto-finalize' classes and methods because of how the D language has been designed.

Once that is done a lot of the abstraction penalty should disappear w/o the programmer being concerned with using language constructs to accomplish that.

- Dave

In article <cmjtmn$c0f$1@digitaldaemon.com>, Walter says...
>
>"Thomas Kuehne" <thomas-dloop@kuehne.cn> wrote in message news:cmjgps$2t9i$1@digitaldaemon.com...
>> Http access to DStress and the benchmark sources is up and running.
>>
>> http://svn.kuehne.cn/dstress
>> svn://svn.kuehne.cn/dstress
>
>Thanks. The reason the HAVE_COMPLEX D benchmark is so slow is that class Complex, in D, is created on the heap, whereas it is used as strictly a


Sometime ago, there's a post about "Dropping the distinction between objects and references may hinder performance", do you think this issue will be addressed in the future?

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11960


>value object. The first solution is to make it a struct instead of a class, which will make it a value object. Even better, just replace class Complex with cdouble, which is D's complex double native type.

<no@where.com> wrote in message news:cmolmi$107v$1@digitaldaemon.com...
> In article <cmjtmn$c0f$1@digitaldaemon.com>, Walter says...
> >
> >"Thomas Kuehne" <thomas-dloop@kuehne.cn> wrote in message news:cmjgps$2t9i$1@digitaldaemon.com...
> >> Http access to DStress and the benchmark sources is up and running.
> >>
> >> http://svn.kuehne.cn/dstress
> >> svn://svn.kuehne.cn/dstress
> >
> >Thanks. The reason the HAVE_COMPLEX D benchmark is so slow is that class Complex, in D, is created on the heap, whereas it is used as strictly a
>
>
> Sometime ago, there's a post about "Dropping the distinction between
objects and
> references may hinder performance", do you think this issue will be
addressed in
> the future?
>
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11960

I understand the issue with it, but I want to run with what we've got for a while.

no@where.com schrieb:

> Sometime ago, there's a post about "Dropping the distinction between objects and
> references may hinder performance", do you think this issue will be addressed in
> the future?
> 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11960

The suggestion from this message cannot work without breaking polymorphy. Reason: every object can be substituted by an instance of a derived object, which may be larger than the original one. Thus it is unclear how much space should be left within the container to accomodate the object. Thus, it *has* to be allocated dynamically.

Suggested solution: allow structs to inherit from classes - the resulting struct is reliable, that is it cannot be substituted by anything else. We attempt to write a complete, detailed proposal, with reasoning and details for suggested implementations, as soon as Walter calls out to design D 2.0. Until then, it is not realistic to expect such features.

-eye

After roughly 2 years( http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=12277 )
I've generated new test results for OOPack:
http://dstress.kuehne.cn/benchmark/oopack/oopack-results.pdf

extract:

dmd-0.169 -O -release -inline
                         Seconds       Mflops
Test       Iterations     C    OOP     C    OOP  Ratio
- ----       ----------  -----------  -----------  -----
Iterator       400000  3.280 4.520  243.902 176.991  1.378
Complex        200000  2.020 158.09 792.079 10.121  78.262
Matrix           3000  3.270 4.560  229.358 164.474  1.394
Max           1000000  3.760 3.990  265.957 250.627  1.061

gdc-0.19(gcc-3.4.6) -c -O3 -frelease -finline-functions -m32
                         Seconds       Mflops
Test       Iterations     C    OOP     C    OOP  Ratio
- ----       ----------  -----------  -----------  -----
Iterator       400000  1.090 4.260  733.945 187.793  3.908
Complex        200000  1.360 241.1 1176.471  6.636 177.279
Matrix           3000  1.140 3.530  657.895 212.465  3.096
Max           1000000  4.100 4.100  243.902 243.902  1.000

g++-4.1.1 -O3 -m32
                         Seconds       Mflops
Test       Iterations     C    OOP     C    OOP  Ratio
- ----       ----------  -----------  -----------  -----
Iterator       400000    1.1   1.1  733.9 740.7    1.0
Complex        200000    1.1   1.1  1428.6 1403.5  1.0
Matrix           3000    1.1   1.1  663.7 663.7    1.0
Max           1000000    3.0   3.1  327.9 326.8    1.0


While the gaps between GCC, GDC and DMD have narrowed, "Complex" still poses a serious problem for GDC and DMD.

The C version of "Iterator" seems to be surprisingly hard for DMD: DMD / GDC / GCC = 243.902 / 733.945 / 733.9 Mflops

It would be interesting to see how DM, DMD and GDC compete on a MSWindows system.

Thomas