On Saturday, 22 December 2012 at 12:15:38 UTC, Russel Winder
wrote:
Interesting (or not)
side observation: LDC generally creates faster executables than
DMD,
except in one or two cases that I have.
If you ever have time to do some quick profiling, could you
please try to figure out why the LDC-generated executable is
slower – or if the code you are working on is open source, put
some instructions together on how to run the benchmark(s)? The
LLVM backend really shouldn't produce slower code than DMD in
just about any situation, so most likely we are doing something
stupid in LDC.
I'm really interested in this, because apart from target platform
support (druntime/ARM is still not there yet, though) and some
very few DMD-specific bugs such as the one you seem to hit, there
is little reason to use LDC other than for the its code
generation.
Oh, and if you get around to doing this before the next LDC
release, could you please try it on a Git master build, and if
you are on a 32 bit system, ideally use LLVM 3.2+? We had to
disable optimizations on earlier LLVM versions for x86 builds of
druntime due to a LLVM codegen bug only fixed in 3.2, and the
GC-to-stack-promotion pass now activated in master should catch a
few cases where we do stupid things like allocating array
manifest constants on every entry into function, even if they
were only used for meta-programming.
There is still a single known issue which can drastically affect
GC performance, though:
https://github.com/ldc-developers/ldc/issues/233. There is an
easy fix, but it completely breaks shared libraries (but given
that those don't work reliably anyway, I think I'll just go with
it for the time being…)
David
