Rust can do custom hashes as well, to be clear. There's been some arguments over what hashes are allowed in the game in the past.
That is, I think I'm thinking of this:
> k-nucleotide will explicitly require built-in / library HashMap.
https://alioth.debian.org/tracker/?func=detail&group_id=1008...
Since C doesn't have a standard library hashmap, you can write an entirely custom one just for the benchmark. But since Rust has a built-in hashmap in the standard library, you cannot. Even though you could write Rust code that's the same as the custom C hashmap.
http://benchmarksgame.alioth.debian.org/u64q/knucleotide-des...
But they say 'don't write a custom hash table', not 'don't write a custom hash function'. Maybe the problem is that the data in this benchmark is just not a good way to exercise the hash tables in a given language the way the benchmark intended. That probably means the benchmark should be modified; the complaint that some implementations use 'laughably bad' hash functions that seem to be measurably decent hash functions for the data at hand seems really strange.
> Since C doesn't have a standard library hashmap, you can write an entirely custom one just for the benchmark.
NOT TRUE!
#315195 states the opposite!
"k-nucleotide will explicitly require built-in / library HashMap"
Am I allowed to use a custom HashMap for the game, or am I required to use the one in std::collections? My understanding is that it's the latter, and so that penalizes Rust or any other language that includes a map in their standard library.
In fact, the current Rust k-nucleotide DOES use a custom Hash function with a library Hash map.
No one is allowed to -- in your words -- "write an entirely custom [hashmap] just for the benchmark".
(This was all discussed to death, in early December on https://www.reddit.com/r/rust/ ).
Meanwhile, from the task description: Please don't implement your own custom "hash table" - it will not be accepted.
If you want an additional Rust hashmap implementation then you need to persuade the Rust community to provide one in std::collections.
No one is allowed to -- in your words -- "write an entirely custom [hashmap] just for the benchmark".
Again, this means that for Rust, it _has_ to be in the standard library. But C doesn't have one in the standard library. So C gets to write their own, and Rust doesn't.
I still can't get all the moral over this.
The best thing here for Rust would be to achieve the best performance on this game and nothing else.
To me this game is important and winning on it is more yet. So, if Rust don't have better result by "morals" this is so wrong that hurts. But each time I read these responses I ask myself if there is not a real problem there.
I like Rust, but performance is decisive. It is really sad to see that Rust keeps going down on this game and that makes me question myself when trying to invest time on Rust.
If, on the other hand, you're just treating the benchmarks as a fun competition akin to code golf, then by all means, hacks ahoy!
I don't know the background of these people, but they couldn't be more wrong. So that looks like "morals" or just they don't ever saw real C code out there.
For example https://github.com/haipome/fnv/blob/master/fnv.c
That's absurd. The benchmarks game doesn't measure real-world performance in any sense whatsoever. And many of the implementations are written in ways that you'd never ever put into production code (for example, the laughably bad hashing functions that are mentioned elsewhere in this thread). From what I understand, the Rust implementations tend to not get up to those shenanigans, which makes them appear worse than the implementations from other languages that do.
It's not the goal of a programming language to be the top on a silly benchmarks game. The goal is to be an excellent language for real-world use.