3 ms·
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
by dbaupp 10y 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.
- bjourne 10y agoYou seriously really can't cite benchmark results when you don't show the source.
- dbaupp 10y agoI'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.
- bjourne 10y agoFeel free to use my email address (easily findable) and mail me the source. Otherwise, no deal.
- dbaupp 10y agoI 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.