Hacker News new | ask | show | jobs
by dbaupp 3660 days ago
That comparison is misleading for exactly the reasons others have said: the algorithms differ, as can be easily seen in their very different data structures.

A naive, line-by-line port of your fast variant to safe Rust (which I unfortunately am not allowed to share, but didn't require much thinking nor much time), without bothering with prefetching, gives me numbers more like:

  Rust-fast: 533
  C-fast: 685
I'm using --release for Rust (so no CPU-specific optimisation), and the same invocation as you for C. Everything except my editor is closed when benchmarking, and I'm on a Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz.
1 comments

You seriously really can't cite benchmark results when you don't show the source.
I'm really really sorry (I want to keep my job), but seriously, the code I benchmarked was a trivial reimplementation of your code. The get_max_cost_small2 function that is benchmarked is so small and simple that someone else doing it is likely to end up with something identical!

I'm not trying to act in bad faith: as a member of the Rust core team, that would be braindead and stupid on my part.

Feel free to use my email address (easily findable) and mail me the source. Otherwise, no deal.
I literally cannot share the source, I wish I could but the reality is my job does not let me. You're being unreasonable given how ridiculously simple the benchmarked section of the code is: it would not take long for even a Rust beginner to reimplement something equivalent, especially since it doesn't touch on any of the "hard" parts of Rust (no need for explicit lifetimes etc.).

As I said before, I have nothing to gain and everything to lose by lying to you.