Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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...
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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 pub...@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.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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 pub...@dicebot.lv
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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 pub...@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?
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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?
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
On 22 December 2014 at 17:01, Iain Buclaw ibuc...@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.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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 :(
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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?
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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/agevpeanzbpbtcjgx...@forum.dlang.org Matheus.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
MattCoder: There is already a topic about this: http://forum.dlang.org/thread/agevpeanzbpbtcjgx...@forum.dlang.org Matheus. And perhaps even a bug report of mine: http://forum.dlang.org/thread/zpjjzbkwlisjemoxu...@forum.dlang.org?page=5#post-izyhysusezbidhqdncan:40forum.dlang.org Bye, bearophile
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
On 12/20/2014 2:39 PM, bearophile wrote: MattCoder: There is already a topic about this: http://forum.dlang.org/thread/agevpeanzbpbtcjgx...@forum.dlang.org Matheus. And perhaps even a bug report of mine: http://forum.dlang.org/thread/zpjjzbkwlisjemoxu...@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.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
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