13 ms·

>On similar note, why Rust over Go? I was going to say that rust has performance advantages over Go (due to GC), but look at benchmarks: http://benchmarksgame

>On similar note, why Rust over Go? I was going to say that rust has performance advantages over Go (due to GC), but look at benchmarks: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=rust http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Go wins some and looses some, but it's all in the ballpark (except Binary trees [1] which it loses even to Java(!)). It's true that rust is a new language, but so is Go. [1]: I assume it's because it's a test of GC, but Go loses to Java (which, like Go, is a GC language)

merb 10y ago
yeah of course, doing simple programs and checking their time is a good benchmark... oh wait.. also real world performance in bigger programs is mostly different, especially when you deal with big heaps. Btw. this site is extremly bad for benchmarks since it also measure's the startup time of the runtime in java/go/rust.
- igouy 10y ago
  > startup time http://benchmarksgame.alioth.debian.org/sometimes-people-just-make-up-stuff.html#jvm-startup-time http://benchmarksgame.alioth.debian.org/sometimes-people-jus...
- FreeFull 10y ago
  Rust doesn't have any significant runtime startup cost, but it certainly is an issue for Java (and presumably Go as well).
  - igouy 10y ago
    It is an issue for Java programs that complete in a few tenths of a second. So these do more work than a few tenths of a second.
mmstick 10y ago
This is only because the Rust implementations are using particularly slow code paths, either because SIMD/AVX optimizations requires a nightly compiler, some optimizations would require unsafe code, or that other languages are using particularly hacky code that would never fly in real world software. For example, many of the Java/C/C++ benchmarks are using custom optimizations that should be illegal for the benchmarking. Case in point, some are featuring custom hash maps that feature hashing algorithms that, while fast, would never be useful as they provide no protection against collisions. You'll see a hashing algorithm in a C preprocessor, for example, that just fakes having an actual algorithm whereas Rust examples are sticking to the tried and tested production-grade algorithms shipping in the standard library.
- pvg 10y ago
  Which ones do you have in mind? Preprocessor sounds a little cheaty but picking a hash function that's a better fit for the data is a pretty basic, practical sort of optimization.
  - simcop2387 10y ago
    I think he's talking about the C code here, right at the top http://benchmarksgame.alioth.debian.org/u64q/program.php?test=knucleotide&lang=gcc&id=1 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
    - pvg 10y ago
      If that's the one it's a custom hash function which is then inlined as a macro. That still seems like a pretty vanilla C optimization that one might write in real C code.
      - eridius 10y ago
        The problem isn't that it's a macro. It's that it's a horrifically bad hash function. It's blazing fast, but completely unsuitable for use in any real code.
Animats 10y ago
The binary trees benchmark forks off a large number of threads. Those are OS threads in Rust, and that is probably an inefficient way to compute something if you have more threads than CPUs.
duneroadrunner 10y ago
While you're checking out the performance of Rust and Go benchmark implementations, you can also check out some SaferCPlusPlus benchmarks[1] (and kind of compare them with other languages (transitively via the C++ benchmaks)). I've already suggested that these days a "memory safe" implementation category for the benchmarks would be of interest. But apparently not to the current maintainer of the benchmarks. Anyone else out there got nothing better to do than maintain a benchmark site for memory safe implementations? :) [1] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksGame https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...
hamilyon2 10y ago
This site explicitly mentions that results of benchmarks mean almost nothing. Google published results that tell that golang is slower than java in real applications
- igouy 10y ago
  > This site explicitly mentions that results of benchmarks mean almost nothing. Quote?

merb 10y ago

yeah of course, doing simple programs and checking their time is a good benchmark... oh wait.. also real world performance in bigger programs is mostly different, especially when you deal with big heaps. Btw. this site is extremly bad for benchmarks since it also measure's the startup time of the runtime in java/go/rust.

igouy 10y ago
> startup time http://benchmarksgame.alioth.debian.org/sometimes-people-just-make-up-stuff.html#jvm-startup-time http://benchmarksgame.alioth.debian.org/sometimes-people-jus...
FreeFull 10y ago
Rust doesn't have any significant runtime startup cost, but it certainly is an issue for Java (and presumably Go as well).
- igouy 10y ago
  It is an issue for Java programs that complete in a few tenths of a second. So these do more work than a few tenths of a second.

mmstick 10y ago

This is only because the Rust implementations are using particularly slow code paths, either because SIMD/AVX optimizations requires a nightly compiler, some optimizations would require unsafe code, or that other languages are using particularly hacky code that would never fly in real world software. For example, many of the Java/C/C++ benchmarks are using custom optimizations that should be illegal for the benchmarking. Case in point, some are featuring custom hash maps that feature hashing algorithms that, while fast, would never be useful as they provide no protection against collisions. You'll see a hashing algorithm in a C preprocessor, for example, that just fakes having an actual algorithm whereas Rust examples are sticking to the tried and tested production-grade algorithms shipping in the standard library.

pvg 10y ago
Which ones do you have in mind? Preprocessor sounds a little cheaty but picking a hash function that's a better fit for the data is a pretty basic, practical sort of optimization.
- simcop2387 10y ago
  I think he's talking about the C code here, right at the top http://benchmarksgame.alioth.debian.org/u64q/program.php?test=knucleotide&lang=gcc&id=1 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
  - pvg 10y ago
    If that's the one it's a custom hash function which is then inlined as a macro. That still seems like a pretty vanilla C optimization that one might write in real C code.
    - eridius 10y ago
      The problem isn't that it's a macro. It's that it's a horrifically bad hash function. It's blazing fast, but completely unsuitable for use in any real code.

Animats 10y ago

The binary trees benchmark forks off a large number of threads. Those are OS threads in Rust, and that is probably an inefficient way to compute something if you have more threads than CPUs.

duneroadrunner 10y ago

While you're checking out the performance of Rust and Go benchmark implementations, you can also check out some SaferCPlusPlus benchmarks[1] (and kind of compare them with other languages (transitively via the C++ benchmaks)). I've already suggested that these days a "memory safe" implementation category for the benchmarks would be of interest. But apparently not to the current maintainer of the benchmarks. Anyone else out there got nothing better to do than maintain a benchmark site for memory safe implementations? :) [1] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksGame https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

hamilyon2 10y ago

This site explicitly mentions that results of benchmarks mean almost nothing. Google published results that tell that golang is slower than java in real applications

igouy 10y ago
> This site explicitly mentions that results of benchmarks mean almost nothing. Quote?