Since people were so angry I used The Benchmark Game as a source for benchmarks here (https://github.com/logicchains/LPATHBench/blob/master/writeu...) is another micro benchmark showing gcc & clang handily beating rustc. Though the timings are 1+1/2 year old. Their relative performances might have changed significantly.
Also, given how prone microbenchmarks are to depending on hand-optimization over the compiler quality, benchmarks should have been contributed to by the community -- I don't think anyone in rust has heard about this one.
Oh also, Rust is as fast as C/C++ there. It's just not faster than C++Cached, _which is a different algorithm_. That's the problem with microbenchmarks, you end up measuring differences in the algorithm used.
No. In the first table Rust has 1874 and C++/clang 1722. The latter number is lower. C++ with clang beats Rust.
In the second table all C and C++ versions beats Rust. 618, 749, 755 and 735 vs 877. That is a very big difference.
You can also run the fucking benchmarks yourself and see for yourself. I have linked to lots of benchmarks showing C spanking Rust. None has shown any fair benchmarks were Rust is as fast as C.
That's a ... very small difference. And again, probably due to implementation differences. I'm not claiming C doesn't beat Rust, I'm just saying by very little -- Rust is practically just as fast, within the margin of error that microbenchmarks have. You have been belting out claims that Rust is 2x slower -- clearly false. Rust may be 5% slower -- which ... doesn't really matter.
Look at wycats' talk on fast_blank. That's a real world example that's faster than C. Rust used to be faster than c on the regex benchmark at one point, as burntsushi pointed out.
> That's a ... very small difference. And again, probably due to implementation differences.
735 / 618 = 1.19 So Rust is at least 19% slower than C even without involving SIMD intrinsics. You wrote "your rust code shouldn't have any more overhead" but in all the benchmarks it has!
> You have been belting out claims that Rust is 2x slower -- clearly false.
Clearly not, since it is on all the SIMD-using benchmarks.
> Look at wycats' talk on fast_blank. That's a real world example that's faster than C. Rust used to be faster than c on the regex benchmark at one point, as burntsushi pointed out.
Because it is comparing different regex engines, not language performance. I said you should apply "common sense" to The Benchmark Game's numbers.
Here's the thing, you guys can easily prove me wrong. Prove that Rust has zero cost abstractions by taking any small C benchmark, transliterate it to Rust code and profile it. If it is as fast, I'm proven wrong. If it is slower you are proven wrong.
Rust can use simd too. It doesn't in those benchmarks. Please apply the common sense you keep harping about. Claiming rust is 2x slower because of that benchmark is a falsehood.
Re:regex: my point exactly. Most microbenchmarks are prone to slight differences in the implementation causing issues (and you can rarely translate code exactly, especially to something like rust which often requires a different structure of code from C. Same for any two other langauges). 19% is well within this error box.
The fast_blank thing is this example. fast_blank is a carefully hand optimized C extension whose main purpose is being super fast. A mostly naive Rust one-liner beat it (not by much iirc, perhaps 10%, but thats within the error box im talking about). It didn't use parallelism or anything fancy. They weren't even trying to beat C. I provided this proof already.
I could try fixing that benchmark you linked to -- the rust version looks like it could be optimized further. Not sure if its worth it, really. I don't put much stock in microbenchmarks for anything other than order of magnitude comparisons.
No it can't. Either accept that the nightly build of Rust is not the Rust we are talking about or stop discussing with me.
> Re:regex: my point exactly.
The problem with regex libraries are that they are to big so therefore doesn't reveal so much about inherent language performance.
> Most microbenchmarks are prone to slight differences in the implementation causing issues (and you can rarely translate code exactly, especially to something like rust which often requires a different structure of code from C. Same for any two other langauges).
Yes, obviously the implementation defines performance. That's what I wrote in the other thread part: "this discussion is about Rust vs C. Or rather clang 3.6.2/gcc 5.2.1 vs Rust 1.9.0 since language performance is very implementation dependent"
And fwiw, you can easily transliterate C code to C++ or to asm.
> 19% is well within this error box.
What error box? 19% is a huge difference.
> The fast_blank thing is this example. fast_blank is a carefully hand optimized C extension whose main purpose is being super fast.
Also, given how prone microbenchmarks are to depending on hand-optimization over the compiler quality, benchmarks should have been contributed to by the community -- I don't think anyone in rust has heard about this one.
Oh also, Rust is as fast as C/C++ there. It's just not faster than C++Cached, _which is a different algorithm_. That's the problem with microbenchmarks, you end up measuring differences in the algorithm used.