Dear All,

I have good preliminary news. DMD 0.73 seems to generate faster code than GCC 3.3! This is good. But why? You can download my test program from

http://www.inf.bme.hu/~pts/d_is_fast.zip

Watch the `user' times:

$ dmd -O -version=linux_libc zcatd.d
gcc zcatd.o -o zcatd -lphobos -lpthread -lm -Xlinker -L../../bin/../lib
$ gcc-3.3 -mcpu=pentium-mmx -s -O3 -DCFG_LANG_ANSIC=1 -ansi -pedantic -W
-Wall zcatc.c -o zcatc
$ time ./zcatd <t.gz >t

real    0m2.825s
user    0m2.390s
sys     0m0.300s
$ zcat t.gz | cmp t -
$ time ./zcatc <t.gz >t

real    0m4.526s
user    0m4.080s
sys     0m0.230s
$ zcat t.gz | cmp t -
$

pts

In article <bksfgi$165o$1@digitaldaemon.com>, pts+d@math.bme.hu says...
>
>Dear All,
>
>I have good preliminary news. DMD 0.73 seems to generate faster code than GCC 3.3! This is good. But why?

from http://www.digitalmars.com/d/overview.html
"
Include files. A major cause of slow compiles as each compilation unit must
reparse enormous quantities of header files. Include files should be done as
importing a symbol table.
"

DUI has 43000 lines and takes 1 or 2 seconds to compile with DMD.
gtkmm has 95000 lines and takes (not clocked) about half an hour to
compile with gcc.
Obviouly the comparison can't be done like this
but looks like DMD is about 900 times faster!
(I compile DUI in one go and gtkmm is compiled file by file,
but the fact that dmd can compile a big bunch of files
and gcc doesn't dare to do it is relevant.
Now that I'm writting this: DUI is compiled in 3 or 4 runs of dmd
so it should takes  3 or 4 times 1 or 2 seconds, so 900 times might
be more like 300 times, bummer,
from 5 minuts to 1 second... can't you do better Walter? ;)

Utilities that try to check which programs need to compile need to be very fast or they risk increasing the code generation time.

(when we start releasing open source applications/utilities) people not used to dmd will think the compilation failed!

Ant

That is good news, but beating GCC's code generation is not saying much.  ;)

Also GCC goes all the way up to -O6, and you only used -O3.  That may not make much difference.

You shouldn't trust benchmarks like this.  Tweaking the options a bit could tilt the results either way.  The order you run the programs in is important too unless you flush the disk cache and memory cache between runs, the second program can benefit from the run of the first bringing stuff into the caches.

Sean

<pts+d@math.bme.hu> wrote in message news:bksfgi$165o$1@digitaldaemon.com...
> Dear All,
>
> I have good preliminary news. DMD 0.73 seems to generate faster code than
GCC
> 3.3! This is good. But why? You can download my test program from
>
> http://www.inf.bme.hu/~pts/d_is_fast.zip
>
> Watch the `user' times:
>
> $ dmd -O -version=linux_libc zcatd.d
> gcc zcatd.o -o zcatd -lphobos -lpthread -lm -Xlinker -L../../bin/../lib
> $ gcc-3.3 -mcpu=pentium-mmx -s -O3 -DCFG_LANG_ANSIC=1 -ansi -pedantic -W
> -Wall zcatc.c -o zcatc
> $ time ./zcatd <t.gz >t
>
> real    0m2.825s
> user    0m2.390s
> sys     0m0.300s
> $ zcat t.gz | cmp t -
> $ time ./zcatc <t.gz >t
>
> real    0m4.526s
> user    0m4.080s
> sys     0m0.230s
> $ zcat t.gz | cmp t -
> $
>
> pts

In article <bkshtj$19kj$1@digitaldaemon.com>, Ant says...
>
>In article <bksfgi$165o$1@digitaldaemon.com>, pts+d@math.bme.hu says...
>>
>>Dear All,
>>
>>I have good preliminary news. DMD 0.73 seems to generate faster code than GCC

>from 5 minuts to 1 second

oh, you say "faster code", not "code faster"... :P

Any way, I wanted to say that a couple of weeks ago,
when Walter released the wc on the Alice text comparison with C.

Ant

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bksji1$1c3j$1@digitaldaemon.com...
> That is good news, but beating GCC's code generation is not saying much.
;)
> Also GCC goes all the way up to -O6, and you only used -O3.  That may not make much difference.

<g> Responses I get for D code running faster than the equivalent C++ code are:

1) Did I try Brand X C++ compiler, which presumably optimizes better?
2) That isn't the proper/modern/whatever way to write code in C++.
3) Theoretically, a better C++ optimizer would make it faster.
4) Performance is not so important.

> You shouldn't trust benchmarks like this.  Tweaking the options a bit
could
> tilt the results either way.  The order you run the programs in is
important
> too unless you flush the disk cache and memory cache between runs, the second program can benefit from the run of the first bringing stuff into
the
> caches.

Of course you're right, it pays to be careful in interpreting benchmark results so that what you think you are measuring is what is actually being measured (for example, I've seen benchmarks that purported to measure CPU speed that in actuality were totally dominated by file I/O speed). As they say, there are lies, d**n lies, and benchmarks. Nevertheless, benchmarks do give useful information in comparing languages and compilers.

And the more benchmarks are written, the more it becomes inescapable that D is as well or better suited to writing high performance applications than C++.

Sean L. Palmer wrote:
> Also GCC goes all the way up to -O6, and you only used -O3.  That may not
> make much difference.

Not any longer, O3 is currently the top, and all above are equivalent, if you trust the manual. However, it doesn't turn on *all* optimisations, separate command-line parameters are requiered for some of them.

-eye