Thread overview | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
December 20, 2014 ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more. | ||||
---|---|---|---|---|
| ||||
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. |
December 20, 2014 Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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. |
December 20, 2014 Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more. | ||||
---|---|---|---|---|
| ||||
Posted in reply to MattCoder | 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 |
December 20, 2014 Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more. | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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.
|
December 20, 2014 Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
December 21, 2014 Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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.
|
December 22, 2014 Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | 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?
|
December 22, 2014 Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more. | ||||
---|---|---|---|---|
| ||||
Posted in reply to logicchains | 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.
|
December 22, 2014 Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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 |
December 22, 2014 Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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.
|
Copyright © 1999-2021 by the D Language Foundation