LDC and associative arrays

[joseph....@gmail.com]

Hello all,

I'm having an odd experience with a new project, which is that LDC is producing (by some margin) the slowest-running executables. My normal experience has been that GDC produces the fastest, LDC comes in a close second and DMD-compiled executables run about half the speed of those compiled with GDC.

In this case, it's the LDC-compiled version that runs at half the speed of GDC-compiled, and DMD-compiled comes in the middle, with running speed moderately slower than GDC-compiled.

The only thing I can think of that makes this code different from others I've written in the past is that it makes extensive use of associative arrays. Is there any reason why this might be particularly problematic with LDC?

Thanks and best wishes,

-- Joe

[David Nadlinger]

Hi,

On Sat, Nov 3, 2012 at 6:43 AM, <joseph....@gmail.com> wrote:

The only thing I can think of that makes this code different from others I've written in the past is that it makes extensive use of associative arrays.  Is there any reason why this might be particularly problematic with LDC?

the only really good answer to this question is profiling.

However, one guess would be that the LDC build system currently creates a debug build of druntime and Phobos by default. This is probably enough to create a significant slowdown in many applications, and AA-heavy code will probably call quite a few druntime functions.

This definitely needs to be changed, but I guess the best solution would be to reactivate the -defaultlib/-debuglib mechanism and build two copies of Phobos/druntime as part of the standard build process.

To test whether this is really the cause for the slowdown, you can just modify the D_FLAGS variable in CMake accordingly, e.g. set it to -d;-O3;-release.

David

[David Nadlinger]

Oh, and another possible issue would be that LDC currently heap-allocates array literals for enums on each function entry in some cases where even DMD doesn't do it.

Re-enabling the gc2stack pass with its unused allocation detection would fix this problem as a nice side-effect, but unfortunately it seems to uncover a problem somewhere in the function type handling code (see https://github.com/ldc-developers/ldc/pull/206).

David

[Joseph Rushton Wakeling]

On 11/03/2012 11:44 AM, David Nadlinger wrote:
> the only really good answer to this question is profiling.

Sure. I was wondering if there was a known issue (as e.g. floating point is or
was a known issue with DMD).

> However, one guess would be that the LDC build system currently creates a debug
> build of druntime and Phobos by default. This is probably enough to create a
> significant slowdown in many applications, and AA-heavy code will probably call
> quite a few druntime functions.

Hmmm, possible, but other code of mine (just using regular arrays) doesn't show
any comparable slowdown, in fact the LDC-compiled version is very competitive
with GDC. That's why I wondered if it was something specific to AA.

> To test whether this is really the cause for the slowdown, you can just modify
> the D_FLAGS variable in CMake accordingly, e.g. set it to -d;-O3;-release.

I'll give it a go and get back to you. :-)

[Joseph Rushton Wakeling]

On 11/03/2012 11:44 AM, David Nadlinger wrote:

> However, one guess would be that the LDC build system currently creates a debug
> build of druntime and Phobos by default. This is probably enough to create a
> significant slowdown in many applications, and AA-heavy code will probably call
> quite a few druntime functions.
>
> This definitely needs to be changed, but I guess the best solution would be to
> reactivate the -defaultlib/-debuglib mechanism and build two copies of
> Phobos/druntime as part of the standard build process.
>
> To test whether this is really the cause for the slowdown, you can just modify
> the D_FLAGS variable in CMake accordingly, e.g. set it to -d;-O3;-release.

Done so -- the code speeds up significantly as a result. It's now about on a
par or maybe slightly faster than DMD-compiled code, and much closer to the
GDC-compiled program speed. Thanks for the thought!

Can I suggest adding a "release" option to the LDC build config? Something that
would allow you to do e.g. cmake -release or make -release depending on which is
more convenient, and have appropriate CFLAGS, CXXFLAGS and D_FLAGS chosen.

[David Nadlinger]

On Sun, Nov 4, 2012 at 9:39 PM, Joseph Rushton Wakeling
<joseph....@gmail.com> wrote:
> Can I suggest adding a "release" option to the LDC build config? Something
> that would allow you to do e.g. cmake -release or make -release depending on
> which is more convenient, and have appropriate CFLAGS, CXXFLAGS and D_FLAGS
> chosen.

I think this is the wrong approach. Whether you want a debug or
release build of druntime/Phobos is not decided at LDC build time, but
rather when you use LDC to build your applications (most of the time,
a release build is probably fine).

The default should be switched to -O3 -release, and a second set of
libraries should be built with -g and a -debug suffix (e.g.
libdruntime-ldc-debug.a) for use with -debuglib. Anyone wants to grab
this task? I'm unfortunately swamped at the moment.

David