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

51–58 of 58 posts

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

#51

Post by gillianseed »

logicchains wrote: post #46
gillianseed wrote: post #29

Earlier quoted context omitted.

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.

I was using LLVM 3.2 because Rust and LLVM-D use that, so I thought it was fair. GCC 4.7 followed from this because I assumed it was of the same generation as LLVM 3.2, and that 4.8.1 was newer so less fair to compare to LLVM 3.2.

I see, personally I would prefer using the latest release available for each language as this more likely mirrors 'real world' scenarios.

But that's preferences for you, everyone has them :)

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

#52

Post by logicchains »

gillianseed wrote: post #51
logicchains wrote: post #46

Earlier quoted context omitted.

I was using LLVM 3.2 because Rust and LLVM-D use that, so I thought it was fair. GCC 4.7 followed from this because I assumed it was of the same generation as LLVM 3.2, and that 4.8.1 was newer so less fair to compare to LLVM 3.2.

I see, personally I would prefer using the latest release available for each language as this more likely mirrors 'real world' scenarios. But that's preferences for you, everyone has them :)

You're right that it probably makes for a better benchmark, and I tried to use recent versions for the other languages, I just didn't bother for C and C++ as I assumed they'd already be the fastest in class so there was no need to test on the latest compilers.

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

#53

Post by gillianseed »

logicchains wrote: post #52
gillianseed wrote: post #51

Earlier quoted context omitted.

I see, personally I would prefer using the latest release available for each language as this more likely mirrors 'real world' scenarios. But that's preferences for you, everyone has them :)

You're right that it probably makes for a better benchmark, and I tried to use recent versions for the other languages, I just didn't bother for C and C++ as I assumed they'd already be the fastest in class so there was no need to test on the latest compilers.

Well my main interest in this benchmark was actually that of Rust and Go as those are the languages tested that I'm personally most interested in (nice seeing them performing quite well), I just found the use of older compiler versions as an odd thing (though you explained your rationale).

Any chance you would consider putting the compiler version used (for all compilers, not just c/c++) next to the compiler in the column for better disclosure?

Good luck on your game!

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

#54

Post by logicchains »

gillianseed wrote: post #53
logicchains wrote: post #52

Earlier quoted context omitted.

You're right that it probably makes for a better benchmark, and I tried to use recent versions for the other languages, I just didn't bother for C and C++ as I assumed they'd already be the fastest in class so there was no need to test on the latest compilers.

Well my main interest in this benchmark was actually that of Rust and Go as those are the languages tested that I'm personally most interested in (nice seeing them performing quite well), I just found the use of older compiler versions as an odd thing (though you explained your rationale). Any chance you would consider putting the compiler version used (for all compilers, not just c/c++) next to the compiler in the c…

Thanks! And sure, I'll put the compiler versions up sometime next week, along with the compile times.

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

#55

Post by levosmetalo »

AlisdairO wrote: post #49
Aloisius wrote: post #31

Earlier quoted context omitted.

If it was just the 20-30 MB JVM tax, I might be with you. But in applications that allocate and deallocate a lot of memory, the GC of every JVM implementation I've used also hoards memory from the system (well there are a few implementations that give it back, but they cause app performance to nosedive). If you're building a piece of software that needs to co-exist with other memory intensive processes, the JVM's pol…

This is a big issue for me too. IIRC the next version of the JVM will allow you to specify a target memory usage as well as a max, which will encourage it to GC more after memory spikes. You should be able to return some of this to the system without too much penalty (as long as the spikes aren't too frequent...).

No need to wait for the "next gen" GC. Right now you can specify min percentage of free space in a heap that triggers giving back memory to the OS. Yes, you need to specify a few more GC parameters, but it's certainly doable to force JVM to behave this way.

I used this approach in the past to keep memory usage lean. I had some spikes in application that required a lot of memory, so had to keep Xmx high, but configured the app to trigger deallocation to the OS when there's more that 20% of free memory. Worked like a charm even on and old ere 1.5 Sun JVM.

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

#56

Post by AlisdairO »

levosmetalo wrote: post #55
AlisdairO wrote: post #49

Earlier quoted context omitted.

This is a big issue for me too. IIRC the next version of the JVM will allow you to specify a target memory usage as well as a max, which will encourage it to GC more after memory spikes. You should be able to return some of this to the system without too much penalty (as long as the spikes aren't too frequent...).

No need to wait for the "next gen" GC. Right now you can specify min percentage of free space in a heap that triggers giving back memory to the OS. Yes, you need to specify a few more GC parameters, but it's certainly doable to force JVM to behave this way. I used this approach in the past to keep memory usage lean. I had some spikes in application that required a lot of memory, so had to keep Xmx high, but configure…

That mostly works, but you do still run into the issue of the memory hanging around until collection - so if your JVM doesn't choose to collect (because it has a high Xmx set), it keeps a bunch of ram.

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

#57

Post by logicchains »

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 tested it with the new runtime, but it only ran at around 87% of the speed of the original. I also needed to add a task::deschedule() call to make the scheduler behave.

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

#58

Post by vanderZwan »

logicchains wrote: post #45
vanderZwan wrote: post #37

Although it's nice to see which compiler performs best, I'm really curious as to why one compiler outperforms another for the same language. What's gcc's achilles heel for example? (it seems to consistently do worse for every language it's use for)

GCC outputs a jmp in the assembly for GenRands rather than a cmov. This involves branching, leading to branch misses, which waste time.

Thank you for clearing that up. You probably won't see this after 11 days, but I have to try: is that a missed optimisation or a deliberate design decision?
Post reply on HN