Basic benchmark

Bill Baxter wbaxter at gmail.com
Mon Dec 15 19:23:14 PST 2008


On Tue, Dec 16, 2008 at 12:00 PM, Denis Koroskin <2korden at gmail.com> wrote:
> On Tue, 16 Dec 2008 05:28:16 +0300, Bill Baxter <wbaxter at gmail.com> wrote:
>
>> On Tue, Dec 16, 2008 at 11:09 AM, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>> Jarrett Billingsley wrote:
>>>>
>>>> On Sat, Dec 13, 2008 at 11:16 AM, Tomas Lindquist Olsen
>>>> <tomas at 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



More information about the Digitalmars-d mailing list