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.

Regards
Iain.

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

On Monday, 22 December 2014 at 11:45:55 UTC, logicchains wrote:
> 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?

Argh, sorry, now this is my personal failure - have applied the workaround only to i686 and forgot about arm CARCH (it works on x86_64 without workarounds). Pushed update again.

Unfortunately I don't have any ARM device myself to test and this process is very sub-optimal :(

On 23 Dec 2014 07:15, "Dicebot via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Monday, 22 December 2014 at 11:45:55 UTC, logicchains wrote:
>>
>> 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?
>
>
> Argh, sorry, now this is my personal failure - have applied the
workaround only to i686 and forgot about arm CARCH (it works on x86_64 without workarounds). Pushed update again.
>
> Unfortunately I don't have any ARM device myself to test and this process
is very sub-optimal :(

Maybe you could set up a qemu-arm chroot?

On Tuesday, 23 December 2014 at 07:21:20 UTC, Iain Buclaw via Digitalmars-d wrote:
> Maybe you could set up a qemu-arm chroot?

Probably I should. Didn't bother originally because ARM support is not part of Arch Linux upstream - it is separate project with own packaging infrastructure, they simply reuse existing package specs when possible.

Actually having D ARM users makes perspective a bit different.

On 23 December 2014 at 07:28, Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Tuesday, 23 December 2014 at 07:21:20 UTC, Iain Buclaw via Digitalmars-d wrote:
>>
>> Maybe you could set up a qemu-arm chroot?
>
>
> Probably I should. Didn't bother originally because ARM support is not part of Arch Linux upstream - it is separate project with own packaging infrastructure, they simply reuse existing package specs when possible.
>
> Actually having D ARM users makes perspective a bit different.

Yeah.  I've also got a MIPS and RS/6000 box at home, when I get the funds to move to a biggest place, I'll be happy to get port-boxes set-up for any party interested (ie: druntime porters with ldc/gdc)

Iain.

On Tuesday, 23 December 2014 at 07:11:02 UTC, Dicebot wrote:
> On Monday, 22 December 2014 at 11:45:55 UTC, logicchains wrote:
>> 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?
>
> Argh, sorry, now this is my personal failure - have applied the workaround only to i686 and forgot about arm CARCH (it works on x86_64 without workarounds). Pushed update again.
>
> Unfortunately I don't have any ARM device myself to test and this process is very sub-optimal :(

fwiw - very much appreciate your volunteer effort and that you probably have better things to do.  but in case you weren't aware and did have time to look: I get the same linker error for _mulodi4.  gdc works.  (Arch ARM).


Laeeth.

On Tuesday, 31 March 2015 at 21:49:00 UTC, Laeeth Isharc wrote:
> fwiw - very much appreciate your volunteer effort and that you probably have better things to do.  but in case you weren't aware and did have time to look: I get the same linker error for _mulodi4.  gdc works.  (Arch ARM).
>
>
> Laeeth.

I weren't aware. And, sadly, I wasn't able to set up a virtual environment with ARM that actually works :( Any chance you could give me ssh sandbox access to some ARM machine for debugging session? If yes, please write me via public@dicebot.lv

On 1 April 2015 at 21:39, Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Tuesday, 31 March 2015 at 21:49:00 UTC, Laeeth Isharc wrote:
>>
>> fwiw - very much appreciate your volunteer effort and that you probably have better things to do.  but in case you weren't aware and did have time to look: I get the same linker error for _mulodi4.  gdc works.  (Arch ARM).
>>
>>
>> Laeeth.
>
>
> I weren't aware. And, sadly, I wasn't able to set up a virtual environment with ARM that actually works :( Any chance you could give me ssh sandbox access to some ARM machine for debugging session? If yes, please write me via public@dicebot.lv

I have a couple of ARM devices that can be used for such purposes. You'll need to wait a month though...

Iain.

On Wednesday, 1 April 2015 at 19:39:07 UTC, Dicebot wrote:
> On Tuesday, 31 March 2015 at 21:49:00 UTC, Laeeth Isharc wrote:
>> fwiw - very much appreciate your volunteer effort and that you probably have better things to do.  but in case you weren't aware and did have time to look: I get the same linker error for _mulodi4.  gdc works.  (Arch ARM).
>>
>>
>> Laeeth.
>
> I weren't aware. And, sadly, I wasn't able to set up a virtual environment with ARM that actually works :( Any chance you could give me ssh sandbox access to some ARM machine for debugging session? If yes, please write me via public@dicebot.lv

Experimenting on my oneplusone phone running arch (geekbench3 2.9k) and will be back in range in a week.  How much RAM do you think you need?