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

11–20 of 58 posts

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

#11

Post by pjmlp »

Symmetry wrote: post #6
unoti wrote: post #2

Cool article! One thing that might be important to people if you're looking at these languages besides just speed: Go and C will tend to have radically lower memory usage (often like 10x) than most of the other languages there, such as Scala. This can be very important depending on what your application is. For me, using Go for game world servers was my choice because I can do so much more simulation per dollar of se…

I would bet that C++ and Rust and D and really any language that doesn't have a large runtime and doesn't generally box it's variables would also have less memory usage.

Just to list a few forgotten ones that have faded away that could also fit the bill:

- Modula-2

- Modula-3

- Ada

- Turbo/Apple/Object Pascal

- Delphi

- Oberon, Active Oberon, Oberon-2, Component Pascal

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

#13

Post by [deleted] »

pjmlp wrote: post #11
Symmetry wrote: post #6

Earlier quoted context omitted.

I would bet that C++ and Rust and D and really any language that doesn't have a large runtime and doesn't generally box it's variables would also have less memory usage.

Just to list a few forgotten ones that have faded away that could also fit the bill: - Modula-2 - Modula-3 - Ada - Turbo/Apple/Object Pascal - Delphi - Oberon, Active Oberon, Oberon-2, Component Pascal

[deleted]

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

#14

Post by logicchains »

jgale wrote: post #12

Haskell was excluded from this benchmark because I can't figure it out.

Take the code here: https://github.com/logicchains/levgen-benchmarks/blob/master... and run it. Then, take the same code, change the genRooms function to contain:

  where

    noFit    = genRooms (n-1) (restInts) rsDone

    tr       = Room {rPos=(x,y), rw= w, rh= h}

    x        = rem (U.unsafeHead randInts) levDim

    y        = rem (U.unsafeIndex randInts 1) levDim

    restInts = U.unsafeDrop 4 randInts

    w        = rem (U.unsafeIndex randInts 2) maxWid + minWid

    h        = rem (U.unsafeIndex randInts 3) maxWid + minWid
And change:

let rands = U.unfoldrN 10000000 (Just . next) gen

to:

let rands = U.unfoldrN 20000000 (Just . next) gen

The running time should double. Does it? Or does it increase by orders of magnitude? The latter is what happens to me.

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

#15

Post by pcwalton »

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 in the standard library, although it's pretty rough at this point.

I'd be interested in seeing what the benchmark looks like with Rust 0.8, which has a totally rewritten (and at this point much faster) scheduling and channel implementation.

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

#16

Post by gtani »

logicchains wrote: post #7
unoti wrote: post #2

Cool article! One thing that might be important to people if you're looking at these languages besides just speed: Go and C will tend to have radically lower memory usage (often like 10x) than most of the other languages there, such as Scala. This can be very important depending on what your application is. For me, using Go for game world servers was my choice because I can do so much more simulation per dollar of se…

Although it wouldn't really be relevant for the level generation we're doing unless the memory usage was outrageous, I'm open to including memory usage in the table for comprehensiveness's sake. What would you say is the best way to measure ram usage on Linux; is there something as simple as 'time ./ThisExecutable' is for measuring time?

this is a really good writeup (summing up Private_Dirty, Shared_Dirty for some pid's:

http://tech.brightbox.com/posts/2012-11-28-measuring-shared-...

https://news.ycombinator.com/item?id=4842782

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

#17

Post by logicchains »

mastensg wrote: post #9
logicchains wrote: post #7

Earlier quoted context omitted.

Although it wouldn't really be relevant for the level generation we're doing unless the memory usage was outrageous, I'm open to including memory usage in the table for comprehensiveness's sake. What would you say is the best way to measure ram usage on Linux; is there something as simple as 'time ./ThisExecutable' is for measuring time?

Try the time command (not the shell builtin): $ command time -f 'max resident:\t%M KiB' ls / bin etc initrd.img.old lib32 media proc sbin tmp vmlinuz boot home iso lib64 mnt root srv usr vmlinuz.old dev initrd.img lib lost+found opt run sys var max resident: 968 KiB

Thanks, I've included max resident memory statistics on the benchmark.

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

#18

Post by logicchains »

unoti wrote: post #2

Cool article! One thing that might be important to people if you're looking at these languages besides just speed: Go and C will tend to have radically lower memory usage (often like 10x) than most of the other languages there, such as Scala. This can be very important depending on what your application is. For me, using Go for game world servers was my choice because I can do so much more simulation per dollar of se…

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.

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

#19

Post by dom96 »

logicchains wrote: post #18
unoti wrote: post #2

Cool article! One thing that might be important to people if you're looking at these languages besides just speed: Go and C will tend to have radically lower memory usage (often like 10x) than most of the other languages there, such as Scala. This can be very important depending on what your application is. For me, using Go for game world servers was my choice because I can do so much more simulation per dollar of se…

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.

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

#20

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'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.
Post reply on HN