Jump to page: 1 24  
Page
Thread overview
Performance dmd vs ldc2
Jul 24, 2013
Chris
Jul 24, 2013
bearophile
Jul 24, 2013
Chris
Jul 24, 2013
bearophile
Jul 24, 2013
Chris
Jul 24, 2013
John Colvin
Jul 24, 2013
Chris
Jul 24, 2013
Kai Nacke
Jul 24, 2013
David Nadlinger
Jul 24, 2013
David Nadlinger
Jul 25, 2013
Chris
Jul 26, 2013
Kagamin
Jul 29, 2013
Chris
Jul 30, 2013
Temtaime
Jul 30, 2013
Chris
Jul 30, 2013
Kagamin
Jul 30, 2013
John Colvin
Jul 31, 2013
Chris
Jul 31, 2013
John Colvin
Jul 31, 2013
Chris
Jul 31, 2013
John Colvin
Jul 31, 2013
Chris
Jul 31, 2013
Chris
Jul 31, 2013
Kagamin
Jul 31, 2013
Kagamin
Aug 01, 2013
Chris
Jul 30, 2013
John Colvin
Jul 30, 2013
Temtaime
Jul 30, 2013
John Colvin
Jul 24, 2013
David Nadlinger
Jul 24, 2013
Dicebot
July 24, 2013
I recompiled a medium sized project with ldc2 (for the first time ever). I was surprised at how fast the program started afterwards. My program reads in a few rule files it needs to operate (including XML parsing). With dmd 2.063 the program takes 4 seconds to load, with ldc2 it is there immediately.

Although I have not done any serious (i.e. exact) benchmarking here are the first obvious results:

Build time
dmd 2.063 : ~ 1 sec (probably less)
ldc2 : 14 secs

File size of executable
dmd 2.063 : 2.8 MB
ldc2 : 3.2 MB

Startup time
dmd 2.063 : 4 secs
ldc2 : next to zero secs (true!)

The program uses external C libraries (portaudio and libsndfile among others). However, the performance gain when using ldc2 is in the reading and parsing part of the program, which is pure D code.

By the way, the program compiled with ldc2 without error at the first attempt. No complaints, no questions asked :-)

PS Naive question: What's the difference between ldc2 and ldmd2?
July 24, 2013
Chris:

> Although I have not done any serious (i.e. exact) benchmarking here are the first obvious results:

In the last weeks Walter has written several patches for the back-end of DMD, to better optimize programs, but I didn't see benchmarks to justify those changes.


> PS Naive question: What's the difference between ldc2 and ldmd2?

ldmd2 is just a wrapper that calls ldc2. It gives a similar interface to dmd. But it lacks profiler, linker options like -L/STACK:1000000 and more.

(How do you increase stack space on Windows with ldc2?)

Bye,
bearophile
July 24, 2013
On Wednesday, 24 July 2013 at 11:42:59 UTC, bearophile wrote:
> Chris:
>
>> Although I have not done any serious (i.e. exact) benchmarking here are the first obvious results:
>
> In the last weeks Walter has written several patches for the back-end of DMD, to better optimize programs, but I didn't see benchmarks to justify those changes.
>
>
>> PS Naive question: What's the difference between ldc2 and ldmd2?
>
> ldmd2 is just a wrapper that calls ldc2. It gives a similar interface to dmd. But it lacks profiler, linker options like -L/STACK:1000000 and more.
>
> (How do you increase stack space on Windows with ldc2?)
>
> Bye,
> bearophile

ldmd2 compiles the code much faster than ldc2 (~4 secs vs 14 secs). The program runs just as fast (as far as I can see at the moment).
July 24, 2013
Chris:

> ldmd2 compiles the code much faster than ldc2 (~4 secs vs 14 secs). The program runs just as fast (as far as I can see at the moment).

The ldmd2 binary is tiny, it's not a compiler, it's just a wrapper. If the compilation time is different then they are can calling the compiler with different compilation switches.

Bye,
bearophile
July 24, 2013
On Wednesday, 24 July 2013 at 12:11:50 UTC, bearophile wrote:
> Chris:
>
>> ldmd2 compiles the code much faster than ldc2 (~4 secs vs 14 secs). The program runs just as fast (as far as I can see at the moment).
>
> The ldmd2 binary is tiny, it's not a compiler, it's just a wrapper. If the compilation time is different then they are can calling the compiler with different compilation switches.
>
> Bye,
> bearophile

Thanks for clarifying that. I am still impressed with the performance. Although I'm sure I could squeeze a bit more out of dmd. As of now I'm only using the garden-variety (i.e. dmd -release [files]). I didn't use any switches with ldc2, though.
July 24, 2013
On Wednesday, 24 July 2013 at 10:05:17 UTC, Chris wrote:
> ...

That is somewhat expected result. dmd is reference implementation, but I would never use is for release production code personally.

July 24, 2013
On Wednesday, 24 July 2013 at 12:49:50 UTC, Chris wrote:
> On Wednesday, 24 July 2013 at 12:11:50 UTC, bearophile wrote:
>> Chris:
>>
>>> ldmd2 compiles the code much faster than ldc2 (~4 secs vs 14 secs). The program runs just as fast (as far as I can see at the moment).
>>
>> The ldmd2 binary is tiny, it's not a compiler, it's just a wrapper. If the compilation time is different then they are can calling the compiler with different compilation switches.
>>
>> Bye,
>> bearophile
>
> Thanks for clarifying that. I am still impressed with the performance. Although I'm sure I could squeeze a bit more out of dmd. As of now I'm only using the garden-variety (i.e. dmd -release [files]). I didn't use any switches with ldc2, though.

try dmd -release -noboundscheck -O -inline [files]
and the same for ldmd
July 24, 2013
On Wednesday, 24 July 2013 at 13:12:46 UTC, John Colvin wrote:
> On Wednesday, 24 July 2013 at 12:49:50 UTC, Chris wrote:
>> On Wednesday, 24 July 2013 at 12:11:50 UTC, bearophile wrote:
>>> Chris:
>>>
>>>> ldmd2 compiles the code much faster than ldc2 (~4 secs vs 14 secs). The program runs just as fast (as far as I can see at the moment).
>>>
>>> The ldmd2 binary is tiny, it's not a compiler, it's just a wrapper. If the compilation time is different then they are can calling the compiler with different compilation switches.
>>>
>>> Bye,
>>> bearophile
>>
>> Thanks for clarifying that. I am still impressed with the performance. Although I'm sure I could squeeze a bit more out of dmd. As of now I'm only using the garden-variety (i.e. dmd -release [files]). I didn't use any switches with ldc2, though.
>
> try dmd -release -noboundscheck -O -inline [files]
> and the same for ldmd

Just tried it. dmd takes a bit longer to compile. Little or no performance gain in executable. Executable with ldmd2 still lightning fast in comparison.

I expected a slight gain in performance with ldc2, but nowhere near as big a gain as I actually got. Here's a new fan! However, the rest of the code (except for the loading bit) seems to work as fast with dmd as with ldc2.

What's the story with LDC for Windows?
July 24, 2013
On 24 Jul 2013, at 14:49, Chris wrote:
> Thanks for clarifying that. I am still impressed with the performance. Although I'm sure I could squeeze a bit
> more out of dmd. As of now I'm only using the garden-variety (i.e. dmd -release [files]). I didn't use any
> switches with ldc2, though.

That's surprising. In quite a few instances, LDC's codegen is even worse than DMD's without any optimization flags (removing silly redundancies from the emitted IR is a thing that should be tackled in the future).

David
July 24, 2013
On 24 Jul 2013, at 14:11, bearophile wrote:
> Chris:
>
>> ldmd2 compiles the code much faster than ldc2 (~4 secs vs 14 secs). The program runs just as fast (as far as I can see at the moment).
> The ldmd2 binary is tiny, it's not a compiler, it's just a wrapper. If the compilation time is different then
> they are can calling the compiler with different compilation switches.

ldmd uses the "-singleobj" flag by default (for DMD compatibility), which causes the code emitted for the n different D modules to be linked together into 1 LLVM module on the LLVM IR level, instead of emitting n LLVM modules as n object files and linking them with the system linker. This could be a factor, but the large difference is strange.

David
« First   ‹ Prev
1 2 3 4