www.digitalmars.com         C & C++   DMDScript  

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

reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 20 2014
next sibling parent reply "MattCoder" <stopthespam mail.com> writes:
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.
Dec 20 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Dec 20 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 20 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Dec 20 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Dec 21 2014
parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
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?
Dec 22 2014
next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Dec 22 2014
next sibling parent reply =?UTF-8?B?IlRow6lv?= Bueno" <munrek gmx.com> writes:
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
Dec 22 2014
next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Dec 22 2014
prev sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Dec 22 2014
prev sibling parent "logicchains" <jonathan.t.barnard gmail.com> writes:
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.
Dec 22 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
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 :(
Dec 22 2014
next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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?
Dec 22 2014
parent reply "Dicebot" <public dicebot.lv> writes:
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.
Dec 22 2014
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Dec 23 2014
prev sibling parent reply "Laeeth Isharc" <laeeth nospamlaeeth.com> writes:
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.
Mar 31 2015
parent reply "Dicebot" <public dicebot.lv> writes:
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
Apr 01 2015
next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Apr 01 2015
prev sibling parent reply "Laeeth Isharc" <laeeth nospamlaeeth.com> writes:
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?
Apr 01 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 1 April 2015 at 20:40:02 UTC, Laeeth Isharc wrote:

 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?


If it is just a PKGBUILD issue - any amount will do. If building 
ldc itself will be necessary.. well, it can be a bit more 
demanding :) I hope for the former.
Apr 01 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 1 April 2015 at 20:59:07 UTC, Dicebot wrote:

 On Wednesday, 1 April 2015 at 20:40:02 UTC, Laeeth Isharc wrote:

 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?


 If it is just a PKGBUILD issue - any amount will do. If 
 building ldc itself will be necessary.. well, it can be a bit 
 more demanding :) I hope for the former.


Mathias Lang has kindly provided me shell access to one 
Raspberry, investigating the issue.
Apr 08 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 9 April 2015 at 04:30:18 UTC, Dicebot wrote:

 On Wednesday, 1 April 2015 at 20:59:07 UTC, Dicebot wrote:

 On Wednesday, 1 April 2015 at 20:40:02 UTC, Laeeth Isharc 
 wrote:

 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?


 If it is just a PKGBUILD issue - any amount will do. If 
 building ldc itself will be necessary.. well, it can be a bit 
 more demanding :) I hope for the former.


 Mathias Lang has kindly provided me shell access to one 
 Raspberry, investigating the issue.


Seems to work for me now with ldc / liblphobos packages 0.15.1-6
Actual issue was so embarassing that I'd better be silent about 
it :P
Apr 09 2015
parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Thursday, 9 April 2015 at 14:03:33 UTC, Dicebot wrote:

 On Thursday, 9 April 2015 at 04:30:18 UTC, Dicebot wrote:

 On Wednesday, 1 April 2015 at 20:59:07 UTC, Dicebot wrote:

 On Wednesday, 1 April 2015 at 20:40:02 UTC, Laeeth Isharc 
 wrote:

 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?


 If it is just a PKGBUILD issue - any amount will do. If 
 building ldc itself will be necessary.. well, it can be a bit 
 more demanding :) I hope for the former.


 Mathias Lang has kindly provided me shell access to one 
 Raspberry, investigating the issue.


 Seems to work for me now with ldc / liblphobos packages 0.15.1-6
 Actual issue was so embarassing that I'd better be silent about 
 it :P


Thanks, v much Dicebot.  (I think you have earned the right to 
own up to making simple errors without embarrassment in case you 
change your mind - it might help someone else to say what it was).


Laeeth.
Apr 11 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 11 April 2015 at 23:04:26 UTC, Laeeth Isharc wrote:

 Thanks, v much Dicebot.  (I think you have earned the right to 
 own up to making simple errors without embarrassment in case 
 you change your mind - it might help someone else to say what 
 it was).


Ha ha, it will hardly help anyone. I have simply forgot to 
increment package version number when doing last fix so it wasn't 
picked up as a replacement to be built.
Apr 12 2015
parent "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Sunday, 12 April 2015 at 18:07:43 UTC, Dicebot wrote:

 On Saturday, 11 April 2015 at 23:04:26 UTC, Laeeth Isharc wrote:

 Thanks, v much Dicebot.  (I think you have earned the right to 
 own up to making simple errors without embarrassment in case 
 you change your mind - it might help someone else to say what 
 it was).


 Ha ha, it will hardly help anyone. I have simply forgot to 
 increment package version number when doing last fix so it 
 wasn't picked up as a replacement to be built.


Aha!  Easy to do...
Apr 12 2015