3 ms·
I'm curious how much of the authors Go speedup was Go's typically faster single threaded execution or if it was from using Go's easy multi-threading primitives.
by voidlogic 12y ago
I'm curious how much of the authors Go speedup was Go's typically faster single threaded execution or if it was from using Go's easy multi-threading primitives. Of course I imagine it was some ratio of both, but I'm curious about it.
- infimum 12y agoI recently had a similar project [0] and wrote the first version in Java. In some cases it took almost an hour to render a simple 6 bit per color channel image. After that I rewrote it in Go and got it down to ~120s. I think this is mainly due to the fact that the Java version lays way to heavy on OO and does a lot of dynamic memory stuff and the rewritten Go version uses simply 2 (or 3) large arrays. I think in our case it wasn't a raw performance thing but rather the fact that go's proximity to C made us code smarter (= [0]https://github.com/31415us/olga https://github.com/31415us/olga basically a straight up copy/reimplementation of joco's [1] response to [2] [1]http://joco.name/2014/03/02/all-rgb-colors-in-one-image/ http://joco.name/2014/03/02/all-rgb-colors-in-one-image/ [2]http://codegolf.stackexchange.com/questions/22144/images-with-all-colors http://codegolf.stackexchange.com/questions/22144/images-wit...
- voidlogic 12y agoThat is true, while it often using more memory the same code in Java is usually faster than the same code in Go. The thing is- as you aptly pointed out, the idiomatic Go solution is not the same code and is often lighter and faster.