On Monday, 22 December 2014 at 12:43:19 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 22 December 2014 at 11:45, logicchains via Digitalmars-d
<[email protected]> wrote:
On Sunday, 21 December 2014 at 09:48:24 UTC, Dicebot wrote:
On Saturday, 20 December 2014 at 21:47:24 UTC, Walter Bright
wrote:
I did notice this:
"I updated the ldc D compiler earlier today (incidentally,
as part of
upgrading my system with pacman -Syu), and now it doesn't
compile at all. It
was previously compiling, and ran at around 90% the speed of
C++ on ARM."
Sigh.
I have deployed experimental LDC package exactly to be able
to detect such
issues, otherwise it will never get there. It will be either
fixed within a
week or reverted to old mode.
I installed the new Arch Linux LDC package but it still fails
with the same
error: /usr/lib/libldruntime.so: undefined reference to
`__mulodi4'
I did get GDC to work on ARM, but for some reason the
resulting executable
is horribly slow, around five times slower than what LDC
produced. Are there
any flags other than -O3 that I should be using?
Other than -frelease (to turn off most non-release code
generation), no.
Can you get a profiler on it to see where it's spending most of
it's time?
Thanks
Iain.
With the GDC build, the GC stops the main thread every single
time "getLongestPath" is executed. This does not happen with the
LDC build.
See :
http://unix.cat/d/lpathbench/callgrind.out.GDC
http://unix.cat/d/lpathbench/callgrind.out.LDC
