Hacker News new | past | comments | ask | show | jobs | submit login

Wasn't there some issues around a "custom library" for this? I distinctly remember there being some kind of argument about what is legal and what isn't.

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.




The rules provided aren't as clear as they could be:

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.


To be clear: anyone can contribute a Rust k-nucleotide program that uses a custom hash function, just like those used by other programming languages.

> 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"


The "library" distinction you're drawing here is arbitrary. Or at least, my understanding of it is.

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.


Just like everyone else Rust advocates can contribute programs that use a custom Hash function with a library Hash map.

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/ ).


You didn't answer my question. Does "library" here mean that you are able to use a hashmap other than the one in std::collections, or not?


When someone fully re-implements khash in Rust and publishes the library, that will become a question which merits consideration.

Meanwhile, from the task description: Please don't implement your own custom "hash table" - it will not be accepted.


So, the answer is "no, you are not allowed." But you're open to changing that. Got it.


Can't use a library that doesn't exist.

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".


> If you want an additional Rust hashmap implementation then you need to persuade the Rust community to provide one in std::collections.

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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: