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

151–156 of 156 posts

Re: New Rust hash table leads Benchmarks Game

#151

Post by igouy »

stcredzero wrote: post #84
matt_wulfeck wrote: post #80

Earlier quoted context omitted.

Probably because people are intelligent enough not to compare speeds inside of a vacuum. When someone denigrates a language as "java-like" they're really just comparing it anecdotally to the sum of all Java projects they've worked with. Rarely is the project a single-purpose, optimized pet-project.

Smalltalk was long castigated for being a "slow, poky interpreted language" long, long after it stopped being that in fact. In all of my time as a consultant for the language vendor, never did I ever come across the VM actually being too slow. In something like 90% of the cases, it was due to IO. Before I left the Smalltalk part of my career behind, someone had the occasion to compare the parser-compiler of one Small…

If only someone was interested in contributing Smalltalk programs written with MatriX to use quad-core --

http://benchmarksgame.alioth.debian.org/u64q/smalltalk.html

Re: New Rust hash table leads Benchmarks Game

#152

Post by igouy »

rbehrends wrote: post #147
igouy wrote: post #146

Earlier quoted context omitted.

There's been a good deal of play, flex and slop in the interpretation of "use the same algorithm" for some of those tasks. I think your point is more that "Don't optimize away the work." is antithetical to what we do.

All of the benchmark game problems either prescribe using a fixed algorithm or have an obvious optimal asymptotic complexity. The remaining challenge is generally to reduce the constant factor as much as possible. This is just not what a lot of computationally expensive problems look like in practice. As a simple example, any practical solution for an NP-hard problem will be full of tradeoffs; often you just want som…

You're pushing hard on a wide-open door :-)

Re: New Rust hash table leads Benchmarks Game

#153

Post by emn13 »

sqeaky wrote: post #149
emn13 wrote: post #85

Earlier quoted context omitted.

Yeah. But in this kind of tuned benchmark, I doubt clang will do any better across the board - especially not considering the fact that the current programs are likely to be at least somewhat tuned specifically for gcc.

Clang does well enough to be the default compiler for Apple and Google. It can't be that far behind.

Oh yeah, I have no reason to believe it's worse; it's just that I also doubt it's going to help much either.

But... trial and error and all ;-).

Re: New Rust hash table leads Benchmarks Game

#154

Post by igouy »

saurik wrote: post #114

> Some language implementations have hash tables built-in; some provide a hash table as part of a collections library; some use a third-party hash table library. (For example, use either khash or CK_HT for C language k-nucleotide programs.) The hash table algorithm implemented is likely to be different in different libraries. > Please don't implement your own custom "hash table" - it will not be accepted. > The work…

Whatever the motivation for your comments, they did remind me that I'd intended to have background information URLs on other pages (not just the home page).

So thanks for that!

Re: New Rust hash table leads Benchmarks Game

#155

Post by [deleted] »

acqq wrote: post #139
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…

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

[deleted]

Re: New Rust hash table leads Benchmarks Game

#156

Post by mbrubeck »

mbrubeck wrote: post #143
acqq wrote: post #139

Earlier quoted context omitted.

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

As an update, this pull request now removes most of the unsafe code: https://github.com/TeXitoi/benchmarksgame-rs/pull/46

Further update: I now have a Rust program that is 100% safe code and is also faster than any of the unsafe programs (including the C and C++ entries):

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

Post reply on HN