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

[via Digitalmars-d]

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