https://www.reddit.com/r/programming/comments/2pvf68/armv7_vs_x8664_pathfinding_benchmark_of_c_d_go/

Please take a look at this and ensure that the benchmark code is using D correctly.

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.

On Saturday, 20 December 2014 at 21:47:24 UTC, Walter Bright wrote:
> https://www.reddit.com/r/programming/comments/2pvf68/armv7_vs_x8664_pathfinding_benchmark_of_c_d_go/
>
> Please take a look at this and ensure that the benchmark code is using D correctly...

There is already a topic about this:
http://forum.dlang.org/thread/agevpeanzbpbtcjgxaxn@forum.dlang.org

Matheus.

MattCoder:

> There is already a topic about this:
> http://forum.dlang.org/thread/agevpeanzbpbtcjgxaxn@forum.dlang.org
>
> Matheus.

And perhaps even a bug report of mine:

http://forum.dlang.org/thread/zpjjzbkwlisjemoxutms@forum.dlang.org?page=5#post-izyhysusezbidhqdncan:40forum.dlang.org

Bye,
bearophile

On 12/20/2014 2:39 PM, bearophile wrote:
> MattCoder:
>
>> There is already a topic about this:
>> http://forum.dlang.org/thread/agevpeanzbpbtcjgxaxn@forum.dlang.org
>>
>> Matheus.
>
> And perhaps even a bug report of mine:
>
> http://forum.dlang.org/thread/zpjjzbkwlisjemoxutms@forum.dlang.org?page=5#post-izyhysusezbidhqdncan:40forum.dlang.org


Bug reports go into bugzilla. Reporting them in the n.g. means they'll likely get ignored. Of course, once in bugzilla, it's fine to make posts about it.

Walter Bright:

> Bug reports go into bugzilla. Reporting them in the n.g. means they'll likely get ignored.

I'll take care of not letting it get ignored :-)

Bye,
bearophile

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.

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?

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.

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

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.

I ran callgrind on it, 75% of the runtime is spent in _D2gc2gc2GC6malloc, and 5% in reduce.