On 22 December 2014 at 17:01, Iain Buclaw <ibuc...@gdcproject.org> wrote: > On 22 December 2014 at 13:45, via Digitalmars-d > <digitalmars-d@puremagic.com> wrote: >> 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 >>> <digitalmars-d@puremagic.com> 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 > > > Thanks, looks like getLongestPath creates a closure - this causes > memory to be allocated every single time the function is called !!! > > I imagine that LDC can boast smarter heuristics here - I recall David > talking about a memory optimisation that moves the heap allocation to > the stack if it can verify that the closure doesn't escape the > function. > > We are a little behind the times on this - and so is DMD. >
Having another look this evening, I see that the following commit resolves a closure ever being made. https://github.com/logicchains/LPATHBench/commit/e82bc6c2a7ce544d43728e36eb53332eb40a5419 So I would expect that ARM runtime would have improved. Regards Iain.