ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.

[Iain Buclaw via Digitalmars-d]

On 22 December 2014 at 13:45, via Digitalmars-d
<digitalmars-d at 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 at 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.

Regards
Iain.