6 ms·

Or it is faster than C (http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=mandelbrot http://benchmarksgame.alioth.debian.org/u64q/performance.ph

Or it is faster than C (http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=mandelbrot http://benchmarksgame.alioth.debian.org/u64q/performance.php...). Depends which link you click on.

bjourne 10y ago
From the looks of it, that Rust program spawns 20 threads and does the computations in parallel. The C program does it all in one thread and doesn't even utilize sse intrinsics. I know full well that The Computer Language Benchmarks Game isn't a perfect source for programming language speed arguments, but what you can you do.
- tatterdemalion 10y ago
  You're right - for microbenchmarks, the difference between Rust and C is going to be in how the solution is implemented, because the languages have such similar performance characteristics. This is why your original comment that Rust is not as performant as C is quite silly. You look rather hypocritical turning around and pointing it out when someone links to a microbenchmark on which Rust outperforms C.
- frankmcsherry 10y ago
  Yeah, given that the CPU load for the C lines are listed as 100% 95% 95% 95% on a quadcore, I'm going to say "not one thread". Edit: to be helpful, rather than just obnoxious, (<3) the C version uses open mp pragmas, so it looks single-threaded.
- kbenson 10y ago
  Well, if you are familiar enough with the languages in question, you can look for what appear to be submissions that appear to use mostly idiomatic expressions of the language. Alternatively, if you are more interested in maximum possible performance, you can confirm both are making use of advanced techniques for quicker execution, but that's probably much harder to judge.
- Manishearth 10y ago
  So it's okay to claim Rust is slower than C by cherry picking SIMD benchmarks (rust can do simd btw, just not on stable), but not okay to claim c is slower than rust by cherry picking a parallelization benchmark? If you don't think that benchmark is fair, submit a parallel solution in C. The benchmarks game is far from being even a useful source. It gives order of magnitude answers, and that's pretty much it. Using it (cherry-picked!) to back up a claim that Rust is 2x slower than C is disingenuous. "but what can you do" -- don't make absolute arguments about something using imprecise data. Actual rust in real world programs may actually end up being faster than C (see Yehuda Katz's talk on fast_blank in rust). C often needs to be hand-optimized. Rust, with its zero cost abstractions, often doesn't need to be; a naive program in rust would probably be faster than the same in C. Remember that fundamentally rust compiles the same way c does, and your rust code shouldn't have any more overhead. (except drop flags -- a minor cost -- which are something you might hand-implement in c anyway). We also use llvm, so we get mostly the same compiler optimizations.
  - bjourne 10y ago
    I wrote "what can you do" because you are supposed to use some modicum of common sense when reading the numbers on The Benchmark Game. E.g in one of the benchmarks PHP beats both C and Rust, so you need to apply common sense to understand that that result is an outlier. I didn't cherry-pick; in 5/10 benchmarks, C is twice as fast as Rust. > rust code shouldn't have any more overhead. But it appears that it have. > We also use llvm, so we get mostly the same compiler optimizations. That is not a guarantee for efficient code. For example, in my testing, g++ is over 50% faster than clang++ in certain template-heavy scenarios.
    - Rusky 10y ago
      No, it does not appear that Rust has any overhead over C, except in cases that use SIMD. That is not a generally applicable result.
    - nemothekid 10y ago
      >I didn't cherry-pick; in 5/10 benchmarks, C is twice as fast as Rust. Making the claim that C is twice as fast as Rust because of 5/10 benchmarks in the "benchmark game" shows an incredible lack of common sense to me. In 5/10 benchmarks, the benchmark games claims Go has equal if not better performance than Rust. Am I supposed to believe now, that a managed, garbage collected, 6-year-old compiler, language is as fast as as language without a runtime running on LLVM? Don't back up your claim with flawed benchmarks.
- dikaiosune 10y ago
  Both examples are cherry-picked, is the point. Neither is particularly helpful in representing the whole story. That said, Rust makes it ridiculously easy to use parallelism if a task can support it, which is a strong advantage in its favor.
- xyience 10y ago
  > but what you can you do. Not make sweeping generalizations based on one benchmark you didn't write?

Or it is faster than C (http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=mandelbrot http://benchmarksgame.alioth.debian.org/u64q/performance.php...). Depends which link you click on.

bjourne 10y ago

From the looks of it, that Rust program spawns 20 threads and does the computations in parallel. The C program does it all in one thread and doesn't even utilize sse intrinsics. I know full well that The Computer Language Benchmarks Game isn't a perfect source for programming language speed arguments, but what you can you do.

tatterdemalion 10y ago
You're right - for microbenchmarks, the difference between Rust and C is going to be in how the solution is implemented, because the languages have such similar performance characteristics. This is why your original comment that Rust is not as performant as C is quite silly. You look rather hypocritical turning around and pointing it out when someone links to a microbenchmark on which Rust outperforms C.
frankmcsherry 10y ago
Yeah, given that the CPU load for the C lines are listed as 100% 95% 95% 95% on a quadcore, I'm going to say "not one thread". Edit: to be helpful, rather than just obnoxious, (<3) the C version uses open mp pragmas, so it looks single-threaded.
kbenson 10y ago
Well, if you are familiar enough with the languages in question, you can look for what appear to be submissions that appear to use mostly idiomatic expressions of the language. Alternatively, if you are more interested in maximum possible performance, you can confirm both are making use of advanced techniques for quicker execution, but that's probably much harder to judge.
Manishearth 10y ago
So it's okay to claim Rust is slower than C by cherry picking SIMD benchmarks (rust can do simd btw, just not on stable), but not okay to claim c is slower than rust by cherry picking a parallelization benchmark? If you don't think that benchmark is fair, submit a parallel solution in C. The benchmarks game is far from being even a useful source. It gives order of magnitude answers, and that's pretty much it. Using it (cherry-picked!) to back up a claim that Rust is 2x slower than C is disingenuous. "but what can you do" -- don't make absolute arguments about something using imprecise data. Actual rust in real world programs may actually end up being faster than C (see Yehuda Katz's talk on fast_blank in rust). C often needs to be hand-optimized. Rust, with its zero cost abstractions, often doesn't need to be; a naive program in rust would probably be faster than the same in C. Remember that fundamentally rust compiles the same way c does, and your rust code shouldn't have any more overhead. (except drop flags -- a minor cost -- which are something you might hand-implement in c anyway). We also use llvm, so we get mostly the same compiler optimizations.
- bjourne 10y ago
  I wrote "what can you do" because you are supposed to use some modicum of common sense when reading the numbers on The Benchmark Game. E.g in one of the benchmarks PHP beats both C and Rust, so you need to apply common sense to understand that that result is an outlier. I didn't cherry-pick; in 5/10 benchmarks, C is twice as fast as Rust. > rust code shouldn't have any more overhead. But it appears that it have. > We also use llvm, so we get mostly the same compiler optimizations. That is not a guarantee for efficient code. For example, in my testing, g++ is over 50% faster than clang++ in certain template-heavy scenarios.
  - Rusky 10y ago
    No, it does not appear that Rust has any overhead over C, except in cases that use SIMD. That is not a generally applicable result.
  - nemothekid 10y ago
    >I didn't cherry-pick; in 5/10 benchmarks, C is twice as fast as Rust. Making the claim that C is twice as fast as Rust because of 5/10 benchmarks in the "benchmark game" shows an incredible lack of common sense to me. In 5/10 benchmarks, the benchmark games claims Go has equal if not better performance than Rust. Am I supposed to believe now, that a managed, garbage collected, 6-year-old compiler, language is as fast as as language without a runtime running on LLVM? Don't back up your claim with flawed benchmarks.
dikaiosune 10y ago
Both examples are cherry-picked, is the point. Neither is particularly helpful in representing the whole story. That said, Rust makes it ridiculously easy to use parallelism if a task can support it, which is a strong advantage in its favor.
xyience 10y ago
> but what you can you do. Not make sweeping generalizations based on one benchmark you didn't write?