Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Parallel Roguelike Lev-Gen Benchmarks: Rust, Go, D, Scala and Nimrod

togototo.wordpress.com

Post reply on HN
Print view View original

21–30 of 58 posts

Re: Parallel Roguelike Lev-Gen Benchmarks: Rust, Go, D, Scala and Nimrod

#21

Post by logicchains »

dom96 wrote: post #19
logicchains wrote: post #18

Earlier quoted context omitted.

The benchmark now includes maximum resident memory usage. Go does indeed perform quite well (at least with 6g), using around 30MiB, compared to around 25/26MiB for the non-garbage-collected languages. Scala is memory-heavy, as expected, and Rust seems to use a surprising amount of memory for some reason.

Don't forget about Nimrod which performs extremely well for a garbage collected language. And D which does too.

True. I didn't actually realise the Nimrod implementation was garbage collected, I just assumed for some reason it managed memory in a hidden manual way like the C++ implementation. Note that garbage collection may not actually occur in this benchmark; for the single threaded benchmark at least, the Go runtime didn't make a single call to the GC, so D and Nimrod might be similar.

Re: Parallel Roguelike Lev-Gen Benchmarks: Rust, Go, D, Scala and Nimrod

#24

Post by pcwalton »

logicchains wrote: post #20
pcwalton wrote: post #15

Really nice article. > I think there may be a more concise way to parallelise parts of the problem in Rust, using something like (from the Rust docs): > > let result = ports.iter().fold(0, |accum, port| accum + port.recv() ); We plan to have convenient fork/join style parallelism constructs, so that you don't have to build it yourself using message passing or unsafe code. There is a prototype in the `par.rs` module i…

I'd like to test it with the new Rust-coded runtime, especially if it's faster, but I won't have time to build it for a couple of days. I actually avoided building it earlier because I thought the new scheduler was slower and needed time to mature (I think I read that it doesn't yet swap tasks between threads, or something along those lines?), but I must have misread.

It's been maturing fast and most of those problems have been fixed, although I wouldn't be surprised if you continue to see problems (and if you do filing issues would be much appreciated) :)

Re: Parallel Roguelike Lev-Gen Benchmarks: Rust, Go, D, Scala and Nimrod

#26

Post by logicchains »

james4k wrote: post #23

Why are you parallelizing these in such different ways? For example, in Go you start 800 goroutines, but in others you start just 4 threads/tasks as worker pool. I would imagine indeed these would give quite different results.

It's done differently in Go because someone else wrote it, and I found it to be faster than the version I wrote using a worker pool of 4 tasks. If you look closely you'll see it doesn't actually ever run more than 4 goroutines simultaneously.

Re: Parallel Roguelike Lev-Gen Benchmarks: Rust, Go, D, Scala and Nimrod

#27

Post by james4k »

logicchains wrote: post #26
james4k wrote: post #23

Why are you parallelizing these in such different ways? For example, in Go you start 800 goroutines, but in others you start just 4 threads/tasks as worker pool. I would imagine indeed these would give quite different results.

It's done differently in Go because someone else wrote it, and I found it to be faster than the version I wrote using a worker pool of 4 tasks. If you look closely you'll see it doesn't actually ever run more than 4 goroutines simultaneously.

I noticed that, but you're still allocating for 800 goroutines in the end. I guess in the scope of the benchmark, that is still relatively cheap. It just was a red flag for me.

Re: Parallel Roguelike Lev-Gen Benchmarks: Rust, Go, D, Scala and Nimrod

#28

Post by logicchains »

kid0m4n wrote: post #25

Have sent in a pull request: https://github.com/logicchains/Levgen-Parallel-Benchmarks/pu... Go performance improves from ~470 ms to ~360 ms on my Quad core MBP 15 (Late 2011)

Thanks, that makes it faster than Scala.

Re: Parallel Roguelike Lev-Gen Benchmarks: Rust, Go, D, Scala and Nimrod

#29

Post by gillianseed »

logicchains wrote: post #20
pcwalton wrote: post #15

Really nice article. > I think there may be a more concise way to parallelise parts of the problem in Rust, using something like (from the Rust docs): > > let result = ports.iter().fold(0, |accum, port| accum + port.recv() ); We plan to have convenient fork/join style parallelism constructs, so that you don't have to build it yourself using message passing or unsafe code. There is a prototype in the `par.rs` module i…

I'd like to test it with the new Rust-coded runtime, especially if it's faster, but I won't have time to build it for a couple of days. I actually avoided building it earlier because I thought the new scheduler was slower and needed time to mature (I think I read that it doesn't yet swap tasks between threads, or something along those lines?), but I must have misread.

Yes this was a interesting benchmark, nice work. One question though, why are you using an old version of GCC (4.7)?

4.8 has been out for quite some time, I did a quick comparison using your benchmark between gcc 4.8.1 and clang 3.3 on my system and clang still won but the difference was ~3.5% on my machine.

Re: Parallel Roguelike Lev-Gen Benchmarks: Rust, Go, D, Scala and Nimrod

#30

Post by logicchains »

james4k wrote: post #27
logicchains wrote: post #26

Earlier quoted context omitted.

It's done differently in Go because someone else wrote it, and I found it to be faster than the version I wrote using a worker pool of 4 tasks. If you look closely you'll see it doesn't actually ever run more than 4 goroutines simultaneously.

I noticed that, but you're still allocating for 800 goroutines in the end. I guess in the scope of the benchmark, that is still relatively cheap. It just was a red flag for me.

No worries. A commenter here submitted a faster version, so it uses that now instead anyway.
Post reply on HN