8 ms·

Go vs C++: Ray tracer (part 3)

115 points by kid0m4n 13y ago

buster 13y ago
This has been circulated on the Rust-dev mailinglist: https://mail.mozilla.org/pipermail/rust-dev/2013-September/005735.html https://mail.mozilla.org/pipermail/rust-dev/2013-September/0... Rust did quite well (given that it's not even production ready i'd say it's impressive): https://mail.mozilla.org/pipermail/rust-dev/2013-September/005750.html https://mail.mozilla.org/pipermail/rust-dev/2013-September/0... The only thing they noted was that the Go version "cheated" by precomptuing some values which someone removed to make the algorithms the same.. maybe kid0m4n can comment on this :)
- dbaupp 13y ago
  The Rust code that ML thread is discussing: http://github.com/huonw/card-trace http://github.com/huonw/card-trace
  - kid0m4n 13y ago
    Hey, possible to optimize the code and send over a PR? I would love to rerun the benchmarks with a optimized Rust version and my rust is totally rusty (pun intended :P)
    - dbaupp 13y ago
      I'm sure it's possible. ;) I'm occupied by other things now so won't do it myself, but people are free to work from my code.
      - kid0m4n 13y ago
        Oh the possibilities :D
- kid0m4n 13y ago
  I was looking at the Rust-dev mailing list before going to sleep :) I would argue that it is not cheating "anymore" as both the Go and C++ version are now equal. In fact, I wanna compare how Rust performs in this exact same test with all optimizations applied. Studying those optimizations will be fun itself. I have also explained why optimizations are perfectly fine (IMHO) here: https://github.com/kid0m4n/rays#why-optimize-the-base-algorithm https://github.com/kid0m4n/rays#why-optimize-the-base-algori...
  - buster 13y ago
    Ok, but with different algorithms you are not testing the languages/compilers anymore but the algorithms ;) I understand that now when the C and Go version we can't compare with the rust version anymore uless someone applies the same changes.. anyway, t was a very interesting read on the rust ML and frankly i was surprised to see rust fare so well
    - kid0m4n 13y ago
      True... But, I guess algorithmic advances will happen much less frequently compared to other micro optimizations. And it will keep things interesting across the board.
- devx 13y ago
  I wonder, do the Rust guys have any intention of supporting AMD's HSA or Mantle API in any way? I know Mozilla wants to make Rust take full advantage of multi-core systems, and AMD is doing that, too, so I wonder if there can be some synergy there, or if that's outside of their goals for Rust.
nemothekid 13y ago
go build -gcflags -m After some quick googling I can't find what the "m" flag does. Can anyone shed some light?
- kid0m4n 13y ago
  Author of the article here It helps in finding out details of what the compiler (Xg) thinks of various funcs inlining applicability (is that even a word?)
  - gillianseed 13y ago
    Speaking of gcflags, did you try Go with gcflags=-B to see how it performs without bounds checking. I know this isn't 'the right way' given that Go is supposed to be a safe language but it would be interesting to see how much difference it would make.
    - kid0m4n 13y ago
      Have not tried that... will give it a shot But I guess we are then going away from idiomatic Go
      - gillianseed 13y ago
        I guess, it's an unsupported compiler option (as in it can disappear any new release). I looked at it more as an option for when you want to cram out possible extra performance of release builds.
- nickpresta 13y ago
  go build -gcflags If you run `go help build`, you will see: -gcflags 'arg list' arguments to pass on each 5g, 6g, or 8g compiler invocation. Then you can run: go tool 6g And see: -m print optimization decisions
copx 13y ago
Looking at the github it seems you benchmark GCC 4.8.1 vs. go 1.2rc1. Numbers for Go look promising if one considers that Google's Go implementation does not even have an advanced optimizer yet (in contrast to GCC). >c++ -std=c++11 -O3 -Wall -pthread -ffast-math -mtune=native -march=native -o cpprays cpprays/main.cpp Have you tried -O2? -O3 often generates slower code. >i7 2600 Intel's compiler would probably generate faster code. That's why you can't just say "Go vs C++". You could let Go win this fight by compiling the C++ with Digital Mars. It is also a C++ compiler but it lacks a modern optimizer and the generated code is usually much slower.
- MTGandP 13y ago
  Can you elaborate on why -O3 often generates slower code? I've never heard that before.
  - cpeterso 13y ago
    -O3 inlines functions and unrolls loops more aggressively, so the increased code size might not fit in the CPU cache.
    - kid0m4n 13y ago
      Fair enough... let me do a quick test with -O2 and see how that fares
      - stormbrew 13y ago
        Might want to also give a go at -Os (optimize for small code size). On code that spends its time iterating on the same code over and over again this can be a big win. [edit] Nope, definitely not better. I get O2 being a slight win over O3 and Os being much worse.
        kid0m4n 13y ago
        So it totally disables all loop unrolling, inlining... hmm
halayli 13y ago
vector S(vector o,vector d, unsigned int& seed) {} int T(vector o,vector d,float& t,vector& n) {} not sure why he's copying the vectors here.
- hamidr 13y ago
  Also, he's mostly passing by value.
  - bstamour 13y ago
    Passing by value in C++ can offer speed increases when the function will be copying the object anyways, due to move semantics, constructor eliding, etc.
- Sharlin 13y ago
  Why not? Note that these are not std::vectors. Copying 12 bytes will probably be cheaper than indirect access through a reference.
616c 13y ago
Someone posted something on Nimrod a while back with something totally related [0], and I think it is interesting it keeps getting passed over. I am not a lang expert, but I have become very curious about the multiple alternatives in the systems programming niche, and others. It has been developed at least since 2008 (with 0.6 branch in 2008)[1] and the Go language's first public debut in 2009 (I do not know how stable it was at the time and I gave up after going through the first pages of the whole commit history to get a better answer).[2] At the very least, they were developed in the same time frame, are nominally similar languages, and addressing a lot of the same use cases as Rust I suppose. Yet, unfortunately few bench marks include them. I guess they will always be writing an indie language, but I wish more would check it out. As I continue to learn, maybe I can contribute code to his project. We will see if I ever get that far. [0] http://nimrod-code.org/ http://nimrod-code.org/ [1] http://nimrod-code.org/news.html http://nimrod-code.org/news.html [2] http://en.wikipedia.org/wiki/Go_programming_language http://en.wikipedia.org/wiki/Go_programming_language
- 616c 13y ago
  Well, well, a downvote? I guess struck a nerve by asking why alternative languages, the underlying interest of such a blog post, is upsetting. But I am not sure why given the context. I guess I will stop asking about the differences between Go and Nimrod.
  - AlexanderDhoore 13y ago
    Don't be so oversensitive about the votes your comments get. The best thing you can do on HN is to post and leave for an hour. By then some interesting discussion might have popped up. Don't be bothered by the random downvoters. They are more afraid of you than you are of them.
    - 616c 13y ago
      It's not my first time here. I am well aware hot it works. When I comment I usually prod someone to give me a contrary opinion, and I learn something new from someone for more knowledgeable from me. That is why I keep coming back to HN. But I could have been more direct this time around, mea culpa.
shin_lao 13y ago
I wonder how the C++ version would do with TBB. Also I think it would be more interesting to compare more memory intensive programs, I think C++ would shine even more with all the optimizations opportunities there would have.
- shin_lao 13y ago
  And what about adding the following compile options: -m64 -msse3 -mfpmath=sse?
  - kid0m4n 13y ago
    Adding that to the list of C++ options I am going to try
  - qb45 13y ago
    -m64 and -mfpmath=sse are defaults on x86-64, -msse3 is enabled implicitly by -march=native if the machine supports SSE3.
eliasmacpherson 13y ago
https://kidoman.com/images/go-vs-cpp-after-both-optimized.png https://kidoman.com/images/go-vs-cpp-after-both-optimized.pn... In this picture - am I right in interpreting it at 2048x2048 and 8 cores, that the optimised and tuned go code is nearly three times faster than the multithreaded optimised and tuned C++ code? How come the C++ is the same for 1C and 8C? Is this picture from one of the previous articles? EDIT: (No, I'm wrong, the C++ is single threaded!) It seems it's single threaded - and the last graph isn't showing the current level of C++ single threaded performance - which is ~36 seconds, with go at 21s for 8 threads. Final state of play is go at 18s multithreaded and C++ at 8s multithread and go at 81s single threaded and C++ at 36s single threaded. I read that from the third last graph. It's difficult to understand this ending of the article, as the subtitle is: "Further optimizations and a multi-threaded C++ version" and "Hurray multi-threading" I suggest the order of the article be changed around to have a 'recap on single threaded C++' at the start, and then the new figures - so that it concludes in straightforward manner. This quote from the article is wrong: "C++ is not more than twice as fast than an equivalent Go program at this stage." Correct me if I'm wrong, but in every case that I can see the C++ code will execute twice before the Go code is finished. It is more than twice as fast. By the same logic this "almost" is also wrong: "From taking 58.15 seconds (single threaded), it has now dropped to a extremely impressive 36.36 seconds (again single threaded), making it almost twice as fast as the optimized Go version." 36s < 81s/2
- vanderZwan 13y ago
  "C++ is not more than twice as fast than an equivalent Go program at this stage." I believe that is a simple typo, where 'not' was meant to be a 'now'.
  - eliasmacpherson 13y ago
    Initially I thought that, but I can't explain the 'almost' that follows? also it would be idiomatic to say "now more than twice as fast as" instead of "now more than twice as fast than".
    - 13y ago

115 points by kid0m4n 13y ago

This has been circulated on the Rust-dev mailinglist: https://mail.mozilla.org/pipermail/rust-dev/2013-September/005735.html https://mail.mozilla.org/pipermail/rust-dev/2013-September/0... Rust did quite well (given that it's not even production ready i'd say it's impressive): https://mail.mozilla.org/pipermail/rust-dev/2013-September/005750.html https://mail.mozilla.org/pipermail/rust-dev/2013-September/0... The only thing they noted was that the Go version "cheated" by precomptuing some values which someone removed to make the algorithms the same.. maybe kid0m4n can comment on this :)

dbaupp 13y ago
The Rust code that ML thread is discussing: http://github.com/huonw/card-trace http://github.com/huonw/card-trace
- kid0m4n 13y ago
  Hey, possible to optimize the code and send over a PR? I would love to rerun the benchmarks with a optimized Rust version and my rust is totally rusty (pun intended :P)
  - dbaupp 13y ago
    I'm sure it's possible. ;) I'm occupied by other things now so won't do it myself, but people are free to work from my code.
    - kid0m4n 13y ago
      Oh the possibilities :D
kid0m4n 13y ago
I was looking at the Rust-dev mailing list before going to sleep :) I would argue that it is not cheating "anymore" as both the Go and C++ version are now equal. In fact, I wanna compare how Rust performs in this exact same test with all optimizations applied. Studying those optimizations will be fun itself. I have also explained why optimizations are perfectly fine (IMHO) here: https://github.com/kid0m4n/rays#why-optimize-the-base-algorithm https://github.com/kid0m4n/rays#why-optimize-the-base-algori...
- buster 13y ago
  Ok, but with different algorithms you are not testing the languages/compilers anymore but the algorithms ;) I understand that now when the C and Go version we can't compare with the rust version anymore uless someone applies the same changes.. anyway, t was a very interesting read on the rust ML and frankly i was surprised to see rust fare so well
  - kid0m4n 13y ago
    True... But, I guess algorithmic advances will happen much less frequently compared to other micro optimizations. And it will keep things interesting across the board.
devx 13y ago
I wonder, do the Rust guys have any intention of supporting AMD's HSA or Mantle API in any way? I know Mozilla wants to make Rust take full advantage of multi-core systems, and AMD is doing that, too, so I wonder if there can be some synergy there, or if that's outside of their goals for Rust.

nemothekid 13y ago

go build -gcflags -m After some quick googling I can't find what the "m" flag does. Can anyone shed some light?

kid0m4n 13y ago
Author of the article here It helps in finding out details of what the compiler (Xg) thinks of various funcs inlining applicability (is that even a word?)
- gillianseed 13y ago
  Speaking of gcflags, did you try Go with gcflags=-B to see how it performs without bounds checking. I know this isn't 'the right way' given that Go is supposed to be a safe language but it would be interesting to see how much difference it would make.
  - kid0m4n 13y ago
    Have not tried that... will give it a shot But I guess we are then going away from idiomatic Go
    - gillianseed 13y ago
      I guess, it's an unsupported compiler option (as in it can disappear any new release). I looked at it more as an option for when you want to cram out possible extra performance of release builds.
nickpresta 13y ago
go build -gcflags If you run `go help build`, you will see: -gcflags 'arg list' arguments to pass on each 5g, 6g, or 8g compiler invocation. Then you can run: go tool 6g And see: -m print optimization decisions

copx 13y ago

Looking at the github it seems you benchmark GCC 4.8.1 vs. go 1.2rc1. Numbers for Go look promising if one considers that Google's Go implementation does not even have an advanced optimizer yet (in contrast to GCC). >c++ -std=c++11 -O3 -Wall -pthread -ffast-math -mtune=native -march=native -o cpprays cpprays/main.cpp Have you tried -O2? -O3 often generates slower code. >i7 2600 Intel's compiler would probably generate faster code. That's why you can't just say "Go vs C++". You could let Go win this fight by compiling the C++ with Digital Mars. It is also a C++ compiler but it lacks a modern optimizer and the generated code is usually much slower.

MTGandP 13y ago
Can you elaborate on why -O3 often generates slower code? I've never heard that before.
- cpeterso 13y ago
  -O3 inlines functions and unrolls loops more aggressively, so the increased code size might not fit in the CPU cache.
  - kid0m4n 13y ago
    Fair enough... let me do a quick test with -O2 and see how that fares
    - stormbrew 13y ago
      Might want to also give a go at -Os (optimize for small code size). On code that spends its time iterating on the same code over and over again this can be a big win. [edit] Nope, definitely not better. I get O2 being a slight win over O3 and Os being much worse.
      - kid0m4n 13y ago
        So it totally disables all loop unrolling, inlining... hmm

halayli 13y ago

vector S(vector o,vector d, unsigned int& seed) {} int T(vector o,vector d,float& t,vector& n) {} not sure why he's copying the vectors here.

hamidr 13y ago
Also, he's mostly passing by value.
- bstamour 13y ago
  Passing by value in C++ can offer speed increases when the function will be copying the object anyways, due to move semantics, constructor eliding, etc.
Sharlin 13y ago
Why not? Note that these are not std::vectors. Copying 12 bytes will probably be cheaper than indirect access through a reference.

616c 13y ago

Someone posted something on Nimrod a while back with something totally related [0], and I think it is interesting it keeps getting passed over. I am not a lang expert, but I have become very curious about the multiple alternatives in the systems programming niche, and others. It has been developed at least since 2008 (with 0.6 branch in 2008)[1] and the Go language's first public debut in 2009 (I do not know how stable it was at the time and I gave up after going through the first pages of the whole commit history to get a better answer).[2] At the very least, they were developed in the same time frame, are nominally similar languages, and addressing a lot of the same use cases as Rust I suppose. Yet, unfortunately few bench marks include them. I guess they will always be writing an indie language, but I wish more would check it out. As I continue to learn, maybe I can contribute code to his project. We will see if I ever get that far. [0] http://nimrod-code.org/ http://nimrod-code.org/ [1] http://nimrod-code.org/news.html http://nimrod-code.org/news.html [2] http://en.wikipedia.org/wiki/Go_programming_language http://en.wikipedia.org/wiki/Go_programming_language

616c 13y ago
Well, well, a downvote? I guess struck a nerve by asking why alternative languages, the underlying interest of such a blog post, is upsetting. But I am not sure why given the context. I guess I will stop asking about the differences between Go and Nimrod.
- AlexanderDhoore 13y ago
  Don't be so oversensitive about the votes your comments get. The best thing you can do on HN is to post and leave for an hour. By then some interesting discussion might have popped up. Don't be bothered by the random downvoters. They are more afraid of you than you are of them.
  - 616c 13y ago
    It's not my first time here. I am well aware hot it works. When I comment I usually prod someone to give me a contrary opinion, and I learn something new from someone for more knowledgeable from me. That is why I keep coming back to HN. But I could have been more direct this time around, mea culpa.

shin_lao 13y ago

I wonder how the C++ version would do with TBB. Also I think it would be more interesting to compare more memory intensive programs, I think C++ would shine even more with all the optimizations opportunities there would have.

shin_lao 13y ago
And what about adding the following compile options: -m64 -msse3 -mfpmath=sse?
- kid0m4n 13y ago
  Adding that to the list of C++ options I am going to try
- qb45 13y ago
  -m64 and -mfpmath=sse are defaults on x86-64, -msse3 is enabled implicitly by -march=native if the machine supports SSE3.

eliasmacpherson 13y ago

https://kidoman.com/images/go-vs-cpp-after-both-optimized.png https://kidoman.com/images/go-vs-cpp-after-both-optimized.pn... In this picture - am I right in interpreting it at 2048x2048 and 8 cores, that the optimised and tuned go code is nearly three times faster than the multithreaded optimised and tuned C++ code? How come the C++ is the same for 1C and 8C? Is this picture from one of the previous articles? EDIT: (No, I'm wrong, the C++ is single threaded!) It seems it's single threaded - and the last graph isn't showing the current level of C++ single threaded performance - which is ~36 seconds, with go at 21s for 8 threads. Final state of play is go at 18s multithreaded and C++ at 8s multithread and go at 81s single threaded and C++ at 36s single threaded. I read that from the third last graph. It's difficult to understand this ending of the article, as the subtitle is: "Further optimizations and a multi-threaded C++ version" and "Hurray multi-threading" I suggest the order of the article be changed around to have a 'recap on single threaded C++' at the start, and then the new figures - so that it concludes in straightforward manner. This quote from the article is wrong: "C++ is not more than twice as fast than an equivalent Go program at this stage." Correct me if I'm wrong, but in every case that I can see the C++ code will execute twice before the Go code is finished. It is more than twice as fast. By the same logic this "almost" is also wrong: "From taking 58.15 seconds (single threaded), it has now dropped to a extremely impressive 36.36 seconds (again single threaded), making it almost twice as fast as the optimized Go version." 36s < 81s/2

vanderZwan 13y ago
"C++ is not more than twice as fast than an equivalent Go program at this stage." I believe that is a simple typo, where 'not' was meant to be a 'now'.
- eliasmacpherson 13y ago
  Initially I thought that, but I can't explain the 'almost' that follows? also it would be idiomatic to say "now more than twice as fast as" instead of "now more than twice as fast than".
  - 13y ago