On Tue, 16 Dec 2008 06:23:14 +0300, Bill Baxter <wbax...@gmail.com> wrote:
On Tue, Dec 16, 2008 at 12:00 PM, Denis Koroskin <2kor...@gmail.com>
wrote:
On Tue, 16 Dec 2008 05:28:16 +0300, Bill Baxter <wbax...@gmail.com>
wrote:
On Tue, Dec 16, 2008 at 11:09 AM, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Jarrett Billingsley wrote:
On Sat, Dec 13, 2008 at 11:16 AM, Tomas Lindquist Olsen
<to...@famolsen.dk> wrote:
I tried this out with Tango + DMD 1.033, Tango + LDC r847 and GCC
4.3.2,
my
timings are as follows, best of three:
$ dmd bench.d -O -release -inline
long arith: 55630 ms
nested loop: 5090 ms
$ ldc bench.d -O3 -release -inline
long arith: 13870 ms
nested loop: 120 ms
$ gcc bench.c -O3 -s -fomit-frame-pointer
long arith: 13600 ms
nested loop: 170 ms
My cpu is: Athlon64 X2 3800+
Go LDC!
I hope bearophile will eventually understand that DMD is not good at
optimizing code, and so comparing its output to GCC's is ultimately
meaningless.
I must have missed the memo. How is dmd not good at optimizing code?
Without
knowing many details about it, my understanding is that dmd performs
common
optimization reasonably well and that this particular problem has to
do
with
the long division routine.
It's pretty well proven that for floating point code, DMD tends to
generate code about 50% slower than GCC.
--bb
But other than that it is pretty good.
Yep, it's more than 100x faster than a straightforward Python ports of
similar code, for instance. (I did some benchmarking using a D port
of the Laplace solver here http://www.scipy.org/PerformancePython --
I think bearophile did these comparisons again himself more recently,
too). There I saw DMD about 50% slower than g++. But I've seen
figures in the neighborhood of 50% come up a few times since then in
other float-intensive benchmarks, like the raytracer that someone
ported from c++.
So it is certainly fast. But one of the draws of D is precisely that,
that it is fast. If you're after code that runs as fast as possible,
50% slower than the competition is plenty justification for to go look
elsewhere for your high-performance language. A 50% hit may not
really be relevant at the end of the day, but I know I used to avoid
g++ like the plague because even it's output isn't that fast compared
to MSVC++ or Intel's compiler, even though the difference is maybe
only 10% or so. I was working on interactive fluid simulation, so I
wanted every bit of speed I could get out of the processor. With
interactive stuff, a 10% difference really can matter, I think.
And man, it is so fast!
You mean compile times?
--bb
Yeah.
