www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Code optimization

reply Tiago Gasiba <tiago.gasiba gmail.com> writes:
Hi *,

  How good is the DMD compiler code optimization?
  As a researcher, I write programs mainly to do simulations.
  Normally the software does not have any GUI and should run "damm fast".
  It is not unusual that some simulations take as much as 2 or 3 weeks to
finish.
  Therefore, if a compiler can save only 10% of running time, this is very much
wellcome - independent of how big the output file is (i.e. optimize for speed,
not for space).
  Recently, while playing with DMD, I wrote a program to simulate LDPC codes
(encoding/decoding).
  To try out the code, I ran a very simple simulation which took me about 2min
to finish.
  Then, I have compiled the same program with "dmd -O" and, surprise! No
reduction in exectution time at all!
  How good is the D code generation optimization? How does it compare to GCC?
How should a program be written in order to make it fast?
  Let me refrase it - what should we avoid while writting a D program in order
to make it run fast?
  I have two good things to mention:
    1) the code written in D is much more straight-forward and much more
understandable than the C version
    2) the execution time was only slightly higher than the one obtained for
the GCC version of the program.
  Now the bad news:
    1) this comparison is not fair, since I have used smarter programming for D
than for C... maybe I'll try the same "trick" in C and it will be even faster...

  How mature is D code optimization compared to GCC? What should we expect in
the (near) future? Remember that GCC is already in version 4.x, while D is 0.x!
  Last but not the least, how do I profile my code to make it faster?

Thanks,
Tiago

-- 
Tiago Gasiba (MSc.) - http://www.gasiba.de
Everything should be made as simple as possible, but not simpler.
Oct 24 2005
next sibling parent reply zwang <nehzgnaw gmail.com> writes:
Tiago Gasiba wrote:
<snip>
   Last but not the least, how do I profile my code to make it faster?

dmd -profile
Oct 24 2005
parent Tiago Gasiba <tiago.gasiba gmail.com> writes:
zwang schrieb:

 Tiago Gasiba wrote:
 <snip>
   Last but not the least, how do I profile my code to make it faster?

dmd -profile

Shame on me! :( That's nice... I've made my code at least 3x faster :) Now... is there a nice GUI for the "trace.log" or do I have to write it myself? ;) Dumm question, I know... Thanks, Tiago -- Tiago Gasiba (M.Sc.) - http://www.gasiba.de Everything should be made as simple as possible, but not simpler.
Oct 24 2005
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Tiago Gasiba wrote:

   Then, I have compiled the same program with "dmd -O" and, surprise! No
reduction in exectution time at all!

hmm .. try "dmd -release -O" don't know if that'll make a difference! but it's just something to try.
Oct 24 2005
parent reply Tiago Gasiba <tiago.gasiba gmail.com> writes:
Hasan Aljudy schrieb:

 Tiago Gasiba wrote:
 
   Then, I have compiled the same program with "dmd -O" and, surprise! No
   reduction in exectution time at all!

hmm .. try "dmd -release -O" don't know if that'll make a difference! but it's just something to try.

Simulation time results: compilation method: dmd -O -release real 1m15.055s user 1m11.948s sys 0m0.136s compilation method: dmd -O real 1m26.488s user 1m24.425s sys 0m0.076s compilation method: dmd real 1m25.107s user 1m23.949s sys 0m0.060s Apparently, the -release flag does "something", i.e. it lowered the execution time by 10sec. It might have just been "luck" and the CPU was less busy when I ran the first simulation. Nevertheless, compiling the code with or without optimization had no impact on the performance! :( Best, Tiago -- Tiago Gasiba (MSc.) - http://www.gasiba.de Everything should be made as simple as possible, but not simpler.
Oct 24 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <djio77$s95$1 digitaldaemon.com>, Tiago Gasiba says...
Apparently, the -release flag does "something", i.e. it lowered the execution
time by 10sec.
It might have just been "luck" and the CPU was less busy when I ran the first
simulation.
Nevertheless, compiling the code with or without optimization had no impact on
the performance! :(

-release removes any in/out contract checking in the code, asserts, and bounds checking for arrays. Try -release with and without "-O -inline" added to see the effects of the DM optimizer. Sean
Oct 24 2005
parent Tiago Gasiba <tiago.gasiba gmail.com> writes:
Sean Kelly schrieb:

 In article <djio77$s95$1 digitaldaemon.com>, Tiago Gasiba says...
Apparently, the -release flag does "something", i.e. it lowered the
execution time by 10sec. It might have just been "luck" and the CPU was
less busy when I ran the first simulation. Nevertheless, compiling the
code with or without optimization had no impact on the performance! :(

-release removes any in/out contract checking in the code, asserts, and bounds checking for arrays. Try -release with and without "-O -inline" added to see the effects of the DM optimizer. Sean

Results for dmd -release -O -inline: real 1m14.794s user 1m12.113s sys 0m0.224s Results for dmd -release: real 1m18.049s user 1m15.149s sys 0m0.180s Didnt make much difference... :( Tiago -- Tiago Gasiba (MSc.) - http://www.gasiba.de Everything should be made as simple as possible, but not simpler.
Oct 24 2005
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <djio77$s95$1 digitaldaemon.com>, Tiago Gasiba says...
Hasan Aljudy schrieb:

 Tiago Gasiba wrote:
 
   Then, I have compiled the same program with "dmd -O" and, surprise! No
   reduction in exectution time at all!

hmm .. try "dmd -release -O" don't know if that'll make a difference! but it's just something to try.

Simulation time results: compilation method: dmd -O -release real 1m15.055s user 1m11.948s sys 0m0.136s compilation method: dmd -O real 1m26.488s user 1m24.425s sys 0m0.076s compilation method: dmd real 1m25.107s user 1m23.949s sys 0m0.060s Apparently, the -release flag does "something", i.e. it lowered the execution time by 10sec. It might have just been "luck" and the CPU was less busy when I ran the first simulation. Nevertheless, compiling the code with or without optimization had no impact on the performance! :( Best, Tiago

Now try 'dmd -O -release -inline' and see if that makes a difference. If you are making a lot of functions calls, the optimizations may not make much of a difference unless frequently called functions are also inlined because of the call overhead. If your code is integer intensive, -O will generally make a difference for tight loops. If it is fp intensive -O will generally /not/ make a big difference right now. In general, DMD does well vs. GCC and other compilers, but of course your milage may vary <g>: http://shootout.alioth.debian.org/benchmark.php?test=all&lang=all&sort=fullcpu The bottleneck right now is primarily in the allocator and GC if you plan to de/allocate a lot of objects in a tight loop. There are a number of ways to use D's flexibility to work around that though: http://digitalmars.com/d/memory.html
-- 
Tiago Gasiba (MSc.) - http://www.gasiba.de
Everything should be made as simple as possible, but not simpler.

Oct 24 2005
parent reply Tiago Gasiba <tiago.gasiba gmail.com> writes:
Dave schrieb:

 
 If your code is integer intensive, -O will generally make a difference for
 tight loops. If it is fp intensive -O will generally /not/ make a big
 difference right now.

Yeap! Its highly FP intensive. In fact, I'm spending all the time just doing FP operations. I can say, however, that the results I obtain with D are very good, but I got somehow surprized why the -O was not producing any speedup. BTW, I removed all the function calls "by hand" long time back :) When you mean "right now" what does that mean? Is there a plan to work this out?
 
 In general, DMD does well vs. GCC and other compilers, but of course your
 milage may vary <g>:
 
 http://shootout.alioth.debian.org/benchmark.php?test=all&lang=all&sort=fullcpu

I have seen this some time back and was wandering how much effort was being put into the code optimization. I also know this is a though topic to deal with...
 The bottleneck right now is primarily in the allocator and GC if you plan
 to de/allocate a lot of objects in a tight loop. There are a number of
 ways to use D's flexibility to work around that though:
 
 http://digitalmars.com/d/memory.html

I'll take a look at this... might be interesting to know some "black magic" here :) Last but not the least, I would like to refer that the "user" can not expect the "compiler" to speedup dumm/sloppy/poorly written code. I'm trying my best to write something fast but that does not mean that I'm not interested in knowing how much can the compiler help me. I would like to congratulate you guys because DMD does (already) a very good job. Thanks, Tiago -- Tiago Gasiba (MSc.) - http://www.gasiba.de Everything should be made as simple as possible, but not simpler.
Oct 24 2005
next sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Tiago Gasiba wrote:
 Yeap! Its highly FP intensive. In fact, I'm spending all the time just doing
FP operations.
 I can say, however, that the results I obtain with D are very good, but I got
somehow surprized why the -O was not producing any speedup.
 BTW, I removed all the function calls "by hand" long time back :)
 When you mean "right now" what does that mean? Is there a plan to work this
out?

The language and compiler are evolving quite rapidly. Maybe Walter should work more on SSE & 3dNow support in the future?
Oct 24 2005
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
In article <djj1kf$137l$1 digitaldaemon.com>, Tiago Gasiba says...
Dave schrieb:

 
 If your code is integer intensive, -O will generally make a difference for
 tight loops. If it is fp intensive -O will generally /not/ make a big
 difference right now.

Yeap! Its highly FP intensive. In fact, I'm spending all the time just doing FP operations. I can say, however, that the results I obtain with D are very good, but I got somehow surprized why the -O was not producing any speedup. BTW, I removed all the function calls "by hand" long time back :) When you mean "right now" what does that mean? Is there a plan to work this

By "right now" I'm making an assumption that it will be one of those things that will get attention over time, especially w.r.t. running on x86-64 and things like vectorization and such (there are some plans to add "array operations" to the language for example).
 
 In general, DMD does well vs. GCC and other compilers, but of course your
 milage may vary <g>:
 
 http://shootout.alioth.debian.org/benchmark.php?test=all&lang=all&sort=fullcpu

I have seen this some time back and was wandering how much effort was being put into the code optimization. I also know this is a though topic to deal with...

I think there has been a good amount of attention to performance in the language design and of the reference compiler frontend to take advantage of the language. One of the stated goals of D is high-performance, but it is still young yet so I'm pretty sure things will just continue to get better. Also, the DMD compiler is using a C/++ backend. IIRC, Walter Bright (the creator of D and DMD) has made comments in the past to the effect of a backend specilized for D would make a favorable difference in at least some areas where D is 'superior' to C/++. I'm guessing things like foreach loops, virtual functions and D arrays for a few.
 The bottleneck right now is primarily in the allocator and GC if you plan
 to de/allocate a lot of objects in a tight loop. There are a number of
 ways to use D's flexibility to work around that though:
 
 http://digitalmars.com/d/memory.html

I'll take a look at this... might be interesting to know some "black magic" here :) Last but not the least, I would like to refer that the "user" can not expect the "compiler" to speedup dumm/sloppy/poorly written code. I'm trying my best to write something fast but that does not mean that I'm not interested in knowing how much can the compiler help me. I would like to congratulate you guys because DMD does (already) a very good job. Thanks, Tiago -- Tiago Gasiba (MSc.) - http://www.gasiba.de Everything should be made as simple as possible, but not simpler.

Oct 24 2005
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Tiago Gasiba" <tiago.gasiba gmail.com> wrote in message
news:djj1kf$137l$1 digitaldaemon.com...
 Yeap! Its highly FP intensive. In fact, I'm spending all the time just

 I can say, however, that the results I obtain with D are very good, but I

One problem with FP code is that DMD uses the x87 FPU instructions. Intel has 'backburnered' them, and has not spent the effort improving their performance like they've done for their replacement FPU instructions. This marginalization of x87 opcodes has continued with the AMD 64. The wretched part of all this is Intel has not supported 80 bit reals in the newer instructions. Thus, if code is generated for the newer opcodes, then accuracy suffers.
Oct 24 2005
next sibling parent reply Daniel Horn <hellcatv hotmail.com> writes:
Walter Bright wrote:
 "Tiago Gasiba" <tiago.gasiba gmail.com> wrote in message
 One problem with FP code is that DMD uses the x87 FPU instructions. Intel
 has 'backburnered' them, and has not spent the effort improving their
 performance like they've done for their replacement FPU instructions. This
 marginalization of x87 opcodes has continued with the AMD 64.
 
 The wretched part of all this is Intel has not supported 80 bit reals in the
 newer instructions. Thus, if code is generated for the newer opcodes, then
 accuracy suffers.

double a=.01289122343252353; double b=.01259212262636233; bool x= (a*b<a*b); if one of a or be spill over then x could indeed be true! I've seen it before and had a simple 5 line code that produced such a problem due to the 80 bit arithmetic---it worked fine on the macintosh where all floats are 64 bit
Oct 25 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Daniel Horn" <hellcatv hotmail.com> wrote in message
news:djm5ia$166v$1 digitaldaemon.com...
 Walter Bright wrote:
 "Tiago Gasiba" <tiago.gasiba gmail.com> wrote in message
 One problem with FP code is that DMD uses the x87 FPU instructions.


 has 'backburnered' them, and has not spent the effort improving their
 performance like they've done for their replacement FPU instructions.


 marginalization of x87 opcodes has continued with the AMD 64.

 The wretched part of all this is Intel has not supported 80 bit reals in


 newer instructions. Thus, if code is generated for the newer opcodes,


 accuracy suffers.

double a=.01289122343252353; double b=.01259212262636233; bool x= (a*b<a*b); if one of a or be spill over then x could indeed be true! I've seen it before and had a simple 5 line code that produced such a problem due to the 80 bit arithmetic---it worked fine on the macintosh where all floats are 64 bit

A couple years back I upgraded the back end so that FPU spills were done to a full 80 bits, so this should not be an issue any longer (for D, anyway).
Oct 25 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
In article <djjeu4$1g0k$3 digitaldaemon.com>, Walter Bright says...
One problem with FP code is that DMD uses the x87 FPU instructions. Intel
has 'backburnered' them, and has not spent the effort improving their
performance like they've done for their replacement FPU instructions. This
marginalization of x87 opcodes has continued with the AMD 64.

The wretched part of all this is Intel has not supported 80 bit reals in the
newer instructions. Thus, if code is generated for the newer opcodes, then
accuracy suffers.

I just ran across a link to this article in comp.arch: http://www.infoworld.com/article/05/10/26/44OPcurve_1.html?source=rss&url=http://www.infoworld.com/article/05/10/26/44OPcurve_1.html Apparently, AMD is going to begin to offer its own extensions to the x86 instruction set with its next batch of CPUs. They haven't said what they'll be yet, but there's speculation that AMD may resurrect and extend its old floating point instruction set. Portability issues aside, it would be exciting if a PC hardware manufacturer began to take a bit more interest in fancy mathematics. And coupled with the 32-way Opteron hardware due out in the near future, AMD could become the affordable way to move into high-end computing. And at the moment, D seems uniquely suited for this type of programming (compared to other non-specialized programming languages). Sean
Oct 26 2005
prev sibling next sibling parent James Dunne <james.jdunne gmail.com> writes:
Tiago Gasiba wrote:
 Hi *,
 
   How good is the DMD compiler code optimization?
   As a researcher, I write programs mainly to do simulations.
   Normally the software does not have any GUI and should run "damm fast".
   It is not unusual that some simulations take as much as 2 or 3 weeks to
finish.
   Therefore, if a compiler can save only 10% of running time, this is very
much wellcome - independent of how big the output file is (i.e. optimize for
speed, not for space).
   Recently, while playing with DMD, I wrote a program to simulate LDPC codes
(encoding/decoding).
   To try out the code, I ran a very simple simulation which took me about 2min
to finish.
   Then, I have compiled the same program with "dmd -O" and, surprise! No
reduction in exectution time at all!
   How good is the D code generation optimization? How does it compare to GCC?
How should a program be written in order to make it fast?
   Let me refrase it - what should we avoid while writting a D program in order
to make it run fast?
   I have two good things to mention:
     1) the code written in D is much more straight-forward and much more
understandable than the C version
     2) the execution time was only slightly higher than the one obtained for
the GCC version of the program.
   Now the bad news:
     1) this comparison is not fair, since I have used smarter programming for
D than for C... maybe I'll try the same "trick" in C and it will be even
faster...
 
   How mature is D code optimization compared to GCC? What should we expect in
the (near) future? Remember that GCC is already in version 4.x, while D is 0.x!
   Last but not the least, how do I profile my code to make it faster?
 
 Thanks,
 Tiago
 

Tiago, Since you seem to be basing your benchmarks on GCC (the backend specifically), why not try out GDC? It's a D front end compiler attached to the GCC backend system. I'm not sure of the state of the front end's optimizations in that port, but noting that it has the GCC backend might be of interest to you. Check it out, it's on the "D Links" page. You might have to do a bit of GCC compiling on your system to get a working GDC. cygwin seems to already have a GDC package available for installation if you're running on Windows and don't feel like compiling GCC. -- Regards, James Dunne
Oct 24 2005
prev sibling next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Tiago Gasiba" <tiago.gasiba gmail.com> wrote in message
news:dji47s$bf9$1 digitaldaemon.com...
   How good is the DMD compiler code optimization?

Pretty good. It'll do advanced data flow analysis, assign multiple variables to the same register, instruction scheduling, etc.
   As a researcher, I write programs mainly to do simulations.
   Normally the software does not have any GUI and should run "damm fast".
   It is not unusual that some simulations take as much as 2 or 3 weeks to

   Therefore, if a compiler can save only 10% of running time, this is very

speed, not for space).
   Recently, while playing with DMD, I wrote a program to simulate LDPC

   To try out the code, I ran a very simple simulation which took me about

   Then, I have compiled the same program with "dmd -O" and, surprise! No

To get fastest output, use the switches -O -inline -release.
   How good is the D code generation optimization? How does it compare to

   Let me refrase it - what should we avoid while writting a D program in

   I have two good things to mention:
     1) the code written in D is much more straight-forward and much more

     2) the execution time was only slightly higher than the one obtained

   Now the bad news:
     1) this comparison is not fair, since I have used smarter programming

faster...
   How mature is D code optimization compared to GCC? What should we expect

is 0.x!
   Last but not the least, how do I profile my code to make it faster?

DMD has a builtin profiler. See www.digitalmars.com/techtips/timing_code.html
Oct 24 2005
prev sibling parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
One interresting effect is that the use of true arrays instead
of pointers can cause significant performance improvements.
(observed while testing some sorting code)

If the FPU code is a bottel neck, not too big and you can live
with "double" precision you might try to use inline assembler
and SSE instructions.

Thomas
Oct 28 2005