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

New Rust hash table leads Benchmarks Game

benchmarksgame.alioth.debian.org

Post reply on HN
Print view View original

131–140 of 156 posts

Re: New Rust hash table leads Benchmarks Game

#131

Post by flukus »

rbehrends wrote: post #127
flukus wrote: post #112

Earlier quoted context omitted.

> For non-GCed languages, you are allowed to use a memory pool of your choice (the C version uses the Apache Portable Runtime library), for GCed languages you are required to use the standard GC with the default settings (no adjustment of GC parameters permitted). This is apples and oranges. Doesn't that match with how a library would be used in the real world? A c library can create it's own memory pool but a GC one…

If I were to run a performance-critical application, I'd definitely tune the GC accordingly. It's why the JVM offers several garbage collectors in the first place, for example. Also, GCed languages aren't prevented from using memory pools, but often they are not part of their common libraries, because there's less need for them.

> If I were to run a performance-critical application, I'd definitely tune the GC accordingly.

But you have to tune it for the performance of the whole application (AFAIK), you can't tune it for an individual algorithm like you can with c. It's a one size fits all approach.

Re: New Rust hash table leads Benchmarks Game

#132

Post by mbrubeck »

acqq wrote: post #128
mbrubeck wrote: post #58

In other Rust/benchmarksgame news, I just submitted a simple fix to the Rust program for "reverse-complement" that makes it faster than the fastest C++ program, on my computer. The old version was spending 2/3 of its time just reading the input into memory, because it wasn't allocating a large enough buffer up front. https://github.com/TeXitoi/benchmarksgame-rs/pull/44 I'm also working on some additional changes that…

Thanks! I like Rust for what it does in advancing the state of the art of the languages, but I also like how this example demonstrates how hard it is to avoid "unsafe" constructs and remain competitive. https://github.com/TeXitoi/benchmarksgame-rs/blob/master/src...

For what it's worth, this alternate implementation has only one line of unsafe code (a call to the libc "memchr" function) and is only 9% slower than the fastest unsafe version:

https://github.com/mbrubeck/benchmarksgame-rs/blob/reverse_c...

It's very easy to write extremely fast safe Rust code. (The safe Rust version above is faster than the fastest C++ submission, on my computer.) Using "unsafe" for optimization is usually only helpful to get a few extra percent speedup in an inner loop. If this were production code rather than the benchmarks game, I'd probably ship the safe version.

Re: New Rust hash table leads Benchmarks Game

#133

Post by [deleted] »

acqq wrote: post #128
mbrubeck wrote: post #58

In other Rust/benchmarksgame news, I just submitted a simple fix to the Rust program for "reverse-complement" that makes it faster than the fastest C++ program, on my computer. The old version was spending 2/3 of its time just reading the input into memory, because it wasn't allocating a large enough buffer up front. https://github.com/TeXitoi/benchmarksgame-rs/pull/44 I'm also working on some additional changes that…

Thanks! I like Rust for what it does in advancing the state of the art of the languages, but I also like how this example demonstrates how hard it is to avoid "unsafe" constructs and remain competitive. https://github.com/TeXitoi/benchmarksgame-rs/blob/master/src...

[deleted]

Re: New Rust hash table leads Benchmarks Game

#134

Post by rbehrends »

igouy wrote: post #116
rbehrends wrote: post #108

Earlier quoted context omitted.

I have some experience with codegolfing for speed and in my experience, these benchmarks do not reflect the reality of such problems, either. If you really want to tweak code for speed, you'll use a mix of algorithmic improvements (that's where the biggest gains are) tailored to your language and compiler/hardware, possibly using FFI/assembly if you absolutely need it. But the benchmark game explicitly disallows algo…

> Except through the backdoor, where language implementors can sometimes tweak libraries to circumvent restrictions. Which programming language implementations are doing that to your knowledge? "… Kernels … Toy programs … Synthetic benchmarks … discredited today, usually because the compiler writer and architect can conspire to make the computer appear faster on these stand-in programs than on real applications." htt…

> Which programming language implementations are doing that to your knowledge?

My point here is not that this is being done (I'm generally assuming that language implementors have better things to do than to pollute their standard libraries for a benchmark game); I was making a different point, namely the inability to do algorithmic improvement, and mentioned that possibility for the sake of completeness.

Re: New Rust hash table leads Benchmarks Game

#135

Post by rbehrends »

flukus wrote: post #131
rbehrends wrote: post #127

Earlier quoted context omitted.

If I were to run a performance-critical application, I'd definitely tune the GC accordingly. It's why the JVM offers several garbage collectors in the first place, for example. Also, GCed languages aren't prevented from using memory pools, but often they are not part of their common libraries, because there's less need for them.

> If I were to run a performance-critical application, I'd definitely tune the GC accordingly. But you have to tune it for the performance of the whole application (AFAIK), you can't tune it for an individual algorithm like you can with c. It's a one size fits all approach.

1. That goes towards the other point that I made [1] about how microbenchmarks have only limited relevance for the performance of large applications (the performance of memory pools can also change as a result; as an extreme case, multiple large memory pools can lead to swapping).

2. Many GCs allow you to tune performance for individual computations. For example, Erlang allows you to basically start a new lightweight process with a heap large enough so that collection isn't needed and to throw it away at the end; OCaml's GC parameters can be changed while the program is running.

[1] https://news.ycombinator.com/item?id=13747876

Re: New Rust hash table leads Benchmarks Game

#136

Post by kibwen »

saurik wrote: post #130
igouy wrote: post #125

Earlier quoted context omitted.

Java #6 => HashMap http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... Java #3 => HashMap http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... Java #5 => HashMap http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... Java #4 => HashMap http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...

Those are different implementations; I know those exist, and which is why I had specifically said there were multiple implementations and pointed at the "faster one", which is obviously the one most people are going to be paying attention to, and which is the one that is also most relevant as we could and probably should expect the implementations for other languages to use some crazy one-off library: it demonstrates…

> What's up?

igouy is the maintainer of the benchmarks game.

Re: New Rust hash table leads Benchmarks Game

#137

Post by kibwen »

mbrubeck wrote: post #132
acqq wrote: post #128

Earlier quoted context omitted.

Thanks! I like Rust for what it does in advancing the state of the art of the languages, but I also like how this example demonstrates how hard it is to avoid "unsafe" constructs and remain competitive. https://github.com/TeXitoi/benchmarksgame-rs/blob/master/src...

For what it's worth, this alternate implementation has only one line of unsafe code (a call to the libc "memchr" function) and is only 9% slower than the fastest unsafe version: https://github.com/mbrubeck/benchmarksgame-rs/blob/reverse_c... It's very easy to write extremely fast safe Rust code. (The safe Rust version above is faster than the fastest C++ submission, on my computer.) Using "unsafe" for optimization is…

> one line of unsafe code (a call to the libc "memchr" function)

Is burntsushi's Rust implementation of memchr notably slower than libc's?

Re: New Rust hash table leads Benchmarks Game

#138

Post by mbrubeck »

kibwen wrote: post #137
mbrubeck wrote: post #132

Earlier quoted context omitted.

For what it's worth, this alternate implementation has only one line of unsafe code (a call to the libc "memchr" function) and is only 9% slower than the fastest unsafe version: https://github.com/mbrubeck/benchmarksgame-rs/blob/reverse_c... It's very easy to write extremely fast safe Rust code. (The safe Rust version above is faster than the fastest C++ submission, on my computer.) Using "unsafe" for optimization is…

> one line of unsafe code (a call to the libc "memchr" function) Is burntsushi's Rust implementation of memchr notably slower than libc's?

> Is burntsushi's Rust implementation of memchr notably slower than libc's?

Not as far as I know. A lot of this benchmarksgame code has evolved slowly over time and hasn't been cleaned up yet to use "modern" crates and language features.

Re: New Rust hash table leads Benchmarks Game

#139

Post by acqq »

mbrubeck wrote: post #132
acqq wrote: post #128

Earlier quoted context omitted.

Thanks! I like Rust for what it does in advancing the state of the art of the languages, but I also like how this example demonstrates how hard it is to avoid "unsafe" constructs and remain competitive. https://github.com/TeXitoi/benchmarksgame-rs/blob/master/src...

For what it's worth, this alternate implementation has only one line of unsafe code (a call to the libc "memchr" function) and is only 9% slower than the fastest unsafe version: https://github.com/mbrubeck/benchmarksgame-rs/blob/reverse_c... It's very easy to write extremely fast safe Rust code. (The safe Rust version above is faster than the fastest C++ submission, on my computer.) Using "unsafe" for optimization is…

Wonderful, thank you! Producing the safe versions which are that efficient is really the best argument for Rust that I can imagine.

Re: New Rust hash table leads Benchmarks Game

#140

Post by [deleted] »

kibwen wrote: post #137
mbrubeck wrote: post #132

Earlier quoted context omitted.

For what it's worth, this alternate implementation has only one line of unsafe code (a call to the libc "memchr" function) and is only 9% slower than the fastest unsafe version: https://github.com/mbrubeck/benchmarksgame-rs/blob/reverse_c... It's very easy to write extremely fast safe Rust code. (The safe Rust version above is faster than the fastest C++ submission, on my computer.) Using "unsafe" for optimization is…

> one line of unsafe code (a call to the libc "memchr" function) Is burntsushi's Rust implementation of memchr notably slower than libc's?

[deleted]
Post reply on HN