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

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Mon Dec 22 14:50:11 PST 2014


On 22 December 2014 at 17:01, Iain Buclaw <ibuclaw at gdcproject.org> wrote:
> 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.
>

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.


More information about the Digitalmars-d mailing list