Live data from Hacker News

New Rust hash table leads Benchmarks Game

benchmarksgame.alioth.debian.org

51–60 of 156 posts

Re: New Rust hash table leads Benchmarks Game

#51
post #41

Earlier quoted context omitted.

I am saying this as someone who loved C for my entire life, when I was in college I did implement most of the assignments in C when prof said python is okay, but I did in C because I loved it and I thought I would learn more by doing them in C. So no hard feeling involved. There is no reputation to defend. You mean security problems everywhere ? do you mean old, broken, nasty build systems ? Do you mean not having si…

Right. The only thing C had going for it was that it was the fastest non-assembly language. I'm biased, I want all C development halted and moved over to Rust. If C is no longer the fastest , for some definition of that, then no one should be defending it at this point. Honestly, I want the LLVM optimized C version specifically so that this last argument for C in any context will be taken off the table. I'm sure ther…

I am asking this genuinely, I always thought and heard LLVM optimizer is inferior to GCC's. Am I wrong ? is there any scientific benchmark for this ?

Re: New Rust hash table leads Benchmarks Game

#52
post #23

It seems to me that there are a lot of apples-to-oranges comparisons here? Some implementations are using the language's standard library hashtable implementation while others are using 3rd party version (with different algorithms and data structures across all of them), some are using multiple threads while others are single threaded etc. As a result, I wouldn't read too much into the rankings you see here.

> It seems to me that there are a lot of apples-to-oranges comparisons here? So, the usual. :) I stopped taking into account the benchmarks game completely after I saw apples-to-potatoes comparisons a few years back.

http://benchmarksgame.alioth.debian.org/dont-jump-to-conclus...

Long ago the Ada program contributors told me -- It's only the same program if the same assembler is generated ;-)

Re: New Rust hash table leads Benchmarks Game

#53
post #41

Earlier quoted context omitted.

I am saying this as someone who loved C for my entire life, when I was in college I did implement most of the assignments in C when prof said python is okay, but I did in C because I loved it and I thought I would learn more by doing them in C. So no hard feeling involved. There is no reputation to defend. You mean security problems everywhere ? do you mean old, broken, nasty build systems ? Do you mean not having si…

Right. The only thing C had going for it was that it was the fastest non-assembly language. I'm biased, I want all C development halted and moved over to Rust. If C is no longer the fastest , for some definition of that, then no one should be defending it at this point. Honestly, I want the LLVM optimized C version specifically so that this last argument for C in any context will be taken off the table. I'm sure ther…

>Right. The only thing C had going for it was that it was the fastest non-assembly language.

Not really. C has lots of existing code, lots of developers who know it, and for many platforms it is the only language for which you'll find a compiler. As a language it is a trainwreck, but it does have a sizeable moat.

Re: New Rust hash table leads Benchmarks Game

#54
post #51

Earlier quoted context omitted.

Right. The only thing C had going for it was that it was the fastest non-assembly language. I'm biased, I want all C development halted and moved over to Rust. If C is no longer the fastest , for some definition of that, then no one should be defending it at this point. Honestly, I want the LLVM optimized C version specifically so that this last argument for C in any context will be taken off the table. I'm sure ther…

I am asking this genuinely, I always thought and heard LLVM optimizer is inferior to GCC's. Am I wrong ? is there any scientific benchmark for this ?

I think they make different choices in different situations. My understanding has been that they are generally the same, with one doing much better in different situations.

But I have nothing to back this up. Wouldn't it be cool if the benchmark game provided a datapoint on this?

Re: New Rust hash table leads Benchmarks Game

#55

Earlier quoted context omitted.

Is there any reason why we can't have a "C clang"? Or has just nobody bothered yet?

Circa 2011 the maintainer of the benchmark game decided to mostly only allow one implementation of each language[0] following pypy developers trying to get program alternatives which weren't pypy-pessimal. [0] some languages get a bye for some reason e.g. MRI and JRuby, but no pypy, and which implementation is blessed is also arbitrary e.g. javascript is v8 but lua is lua.

> javascript is v8

Kind-of: Node.js actually.

Re: New Rust hash table leads Benchmarks Game

#56
post #10

It is new Rust hash table from external crate.

The default hash table has better security against malicious input by using a slower hashing algorithm. Its the right default, but if you really want performance and to compete with C/C++, you have to use an algorithm that makes different tradeoffs, or you would be comparing apples to oranges.

Do the hash tables in use by the C/C++ entries use low-security hash functions? Seems like that needs evidence.

Re: New Rust hash table leads Benchmarks Game

#57
Is there something fishy going on with the NaiveHashMap here? What's happening?

  impl Hasher for NaiveHasher {
      fn finish(&self) -> u64 {
          self.0
      }
      fn write(&mut self, _: &[u8]) {
          unimplemented!()
      }
      fn write_u64(&mut self, i: u64) {
          self.0 = i ^ i >> 7;
      }
  }

Re: New Rust hash table leads Benchmarks Game

#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 make it even faster than the C version (again, on my computer) by improving how it divides work across CPUs:

https://github.com/TeXitoi/benchmarksgame-rs/pull/46

These improved Rust programs have not yet been added to the benchmarksgame site. Previous entries are ranked at:

http://benchmarksgame.alioth.debian.org/u64q/performance.php...

Minor improvements to the Rust programs for "mandelbrot" and "binary-trees" are also awaiting review!

Re: New Rust hash table leads Benchmarks Game

#59

Is there something fishy going on with the NaiveHashMap here? What's happening? impl Hasher for NaiveHasher { fn finish(&self) -> u64 { self.0 } fn write(&mut self, _: &[u8]) { unimplemented!() } fn write_u64(&mut self, i: u64) { self.0 = i ^ i >> 7; } }

Looks like it only handles u64's being hashed and panics on all other input. That must be because it is known it will be used exactly with `.write_u64`. Not having to implement the general byte buffer hashing is a big benefit, removes the whole partial state tracking of the hasher, which the compiler probably would not optimize out (we don't know until we try though).

Re: New Rust hash table leads Benchmarks Game

#60

The rust version is using multiple cpus using a pool concept (which looks a lot like the multiprocessing module from python so kudos there). But the C version is single threaded from what I can tell. So rust is safe but threaded to be faster than single threaded C which isn't that much slower. Hmm...

That's not true. If you look at the comparisons, the cpu time taken by C is actually more than rust, and the cpu load looks about even. Note the C version uses: #pragma omp parallel sections

Ahh dang I didn't know you could do compiler run parallelism.
Post reply on HN