Alright just found something: it's a constant optimization, if I replace
process(14) by process(loop), I do get more similar timings:
DMD
-> time: 159690Ás, y=-1.72651e+11
GDMD
-> time: 115564Ás, y=-1.72651e+11
G++
-> time: 107154Ás, y=-1.72651e+11
I will do serious testing now, with a full library. However if this constant
optimization could be integrated, would be nice ;)

Indeed you're right, it worked :) By adding -inline and -nofloat and using the
14 constant, I obtain the following timings:
DMD
-> time: 144422Ás, y=165632
GDMD
-> time: 5257Ás, y=165632
G++
-> time: 5051Ás, y=165632
DMD sounds still out however.
Thanks ! I'll be back with a real test in few weeks probably with more
questions ;)
g
Henning Hasemann Wrote:

I have no idea of gdc, but with dmd you may want to play around
with flags like -inline and -nofloat and see if and how it
has an effect on the performance.
Henning
--
v4sw7Yhw4ln0pr7Ock2/3ma7uLw5Xm0l6/7DGKi2e6t6ELNSTVXb7AHIMOen5a2Xs5Mr2g5ACPR
hackerkey.com

These last twi timings are so small, I bet there's nothing left in the
resulting binary but the writefln's.. Try passing information to the
program using the command line arguments, for example the mass, force
and the loop-count.
L.

These last twi timings are so small, I bet there's nothing left in the
resulting binary but the writefln's.. Try passing information to the
program using the command line arguments, for example the mass, force
and the loop-count.
L.

Also, from your code in the OP, the result of process() is never used, so the
GCC optimizer might be
optimizing some of that away also.
Regardless, floating point optimizations are currently not a strong point of
the DMC/DMD optimizer.
If those were on par with GCC, then DMD would probably take top honors here in
the Language Shootout:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
There are other frequent visitors to this NG (i.e.: Don Clugston) with a lot of
experience with
writing non-trivial FP code and libraries with D...
Hope you don't mind me mentioning your name Don - If you see this, could you
chime in here with some
common code-level optimizations, etc., that you've found useful?
Good luck with your D testing!
g wrote:

Alright just found something: it's a constant optimization, if I replace
process(14) by process(loop), I do get more similar timings:
DMD
-> time: 159690Ás, y=-1.72651e+11
GDMD
-> time: 115564Ás, y=-1.72651e+11
G++
-> time: 107154Ás, y=-1.72651e+11
I will do serious testing now, with a full library. However if this constant
optimization could be integrated, would be nice ;)

Also, from your code in the OP, the result of process() is never used,
so the GCC optimizer might be optimizing some of that away also.
Regardless, floating point optimizations are currently not a strong
point of the DMC/DMD optimizer. If those were on par with GCC, then DMD
would probably take top honors here in the Language Shootout:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
There are other frequent visitors to this NG (i.e.: Don Clugston) with a
lot of experience with writing non-trivial FP code and libraries with D...
Hope you don't mind me mentioning your name Don - If you see this, could
you chime in here with some common code-level optimizations, etc., that
you've found useful?

The DMD optimiser does not do much floating-point optimisation at all;
it generates very simple x87 code. This forces you to make sure that
your algorithms are optimal. Interestingly, I've found that with many
types of problems, where you converge towards a solution, the bit of
extra precision you get from 80-bit numbers gives you slightly faster
convergence -- which can be more significant than low-level optimisation.
The usual rules apply --
(1) make sure you're using the right algorithm
(2) make sure your code is cache-efficient.
(3) speed only matters inside the innermost loops that are executed
millions of times.
I think that the just-added compile-time function evaluation is going to
be extremely significant; once all the bugs are out of it, we'll be able
to add rule (4): make sure that everything in your innermost loops are
evaluated at compile-time, if possible.
Note that if you're talking about graphics or games programming, the
considerations are quite different to scientific programming; I don't
know much about the former, others here are far more qualified than I am.
-Don.

I have no idea of gdc, but with dmd you may want to play around
with flags like -inline and -nofloat and see if and how it
has an effect on the performance.
Henning
--
v4sw7Yhw4ln0pr7Ock2/3ma7uLw5Xm0l6/7DGKi2e6t6ELNSTVXb7AHIMOen5a2Xs5Mr2g5ACPR
hackerkey.com