4 ms·

Is rust actually faster than go? I had no idea.

b4ux1t3 9y ago
You can tweak Go to make it as fast or faster, but, out of the box, the runtime is a bit slower. Building is faster, though, so that's nice.
- ice109 9y ago
  what are the things that you can tweak?
  - nemo1618 9y ago
    Most Go programs can benefit a lot from smarter memory management, which puts less strain on the GC and allows for certain optimizations. Things like refactoring your function to write into a pre-allocated buffer instead of returning a newly-allocated object. Or using a concrete type like `*os.File` instead of `io.Writer` so that the compiler can eliminate a heap allocation. You can also eliminate some slice bounds-checking by "asserting" the size of the slice outside the hot path; see http://www.tapirgames.com/blog/go-1.7-bce http://www.tapirgames.com/blog/go-1.7-bce Go also has a great profiler for discovering exactly which functions/statements are causing slowdown or allocating excessive memory. At the end of the day, though, I don't think most Go programs can be optimized to run as fast as their Rust equivalents (without dropping into asm, at least). There's just too much overhead that you aren't allowed to disable.
    - b4ux1t3 9y ago
      > At the end of the day, though, I don't think most Go programs can be optimized to run as fast as their Rust equivalents (without dropping into asm, at least) To be clear, I meant programs that don't rely on things like concurrency or networking. For example, I think editing binary blobs (like images) would be just as fast as Rust, if I remember some of the research I did correctly. I don't have any sources on that, and it was a while back, so it's kinda irrelevant, I guess.
random023987 9y ago
Rust has an explicit goal of zero-cost abstractions, while Go will allow more expensive abstractions in the service of simplicity.
- ori_b 9y ago
  For the kind of numerical code here, it's not going to be significantly faster.
  - bascule 9y ago
    curve25519-dalek is 3X faster than the equivalent Go code (i.e. in the stdlib, authored by agl). This is for a few reasons: Rust has support for 128-bit integers (i.e. u128) which allows for faster arithmetic when operating on what are effectively multi-u128 bignums in an elliptic curve library. LLVM is generally more sophisticated about optimizations. It wasn't until recently that go had an SSA-based compiler, so its optimizer isn't nearly as sophisticated as LLVM's, which has been developed for many years now.
    - pjmlp 9y ago
      There is also gccgo, taking advantage of GCC's backend. There is some ongoing work into an LLVM based compiler for Go, and LLVM now has Go as official supported bindings.
    - tptacek 9y ago
      Go can and should fix the integer problem here. George Tankersley had a whole talk at Crypto Village this year about what a nightmare it is to write competitively fast curve code in Go.
  - fnord123 9y ago
    My information may be out of date, but last time I poked through the Go compiler, it did no vectorization or anything equivalent to march=native. So there's plenty of opportunity for Rust to be faster.
- kmicklas 9y ago
digikata 9y ago
As always, general benchmarks only give you limited insights, but this might be interesting: Rust vs Go http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=go http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Rust vs C http://benchmarksgame.alioth.debian.org/u64q/rust.html http://benchmarksgame.alioth.debian.org/u64q/rust.html

You can tweak Go to make it as fast or faster, but, out of the box, the runtime is a bit slower. Building is faster, though, so that's nice.

ice109 9y ago
what are the things that you can tweak?
- nemo1618 9y ago
  Most Go programs can benefit a lot from smarter memory management, which puts less strain on the GC and allows for certain optimizations. Things like refactoring your function to write into a pre-allocated buffer instead of returning a newly-allocated object. Or using a concrete type like `*os.File` instead of `io.Writer` so that the compiler can eliminate a heap allocation. You can also eliminate some slice bounds-checking by "asserting" the size of the slice outside the hot path; see http://www.tapirgames.com/blog/go-1.7-bce http://www.tapirgames.com/blog/go-1.7-bce Go also has a great profiler for discovering exactly which functions/statements are causing slowdown or allocating excessive memory. At the end of the day, though, I don't think most Go programs can be optimized to run as fast as their Rust equivalents (without dropping into asm, at least). There's just too much overhead that you aren't allowed to disable.
  - b4ux1t3 9y ago
    > At the end of the day, though, I don't think most Go programs can be optimized to run as fast as their Rust equivalents (without dropping into asm, at least) To be clear, I meant programs that don't rely on things like concurrency or networking. For example, I think editing binary blobs (like images) would be just as fast as Rust, if I remember some of the research I did correctly. I don't have any sources on that, and it was a while back, so it's kinda irrelevant, I guess.

random023987 9y ago

Rust has an explicit goal of zero-cost abstractions, while Go will allow more expensive abstractions in the service of simplicity.

ori_b 9y ago
For the kind of numerical code here, it's not going to be significantly faster.
- bascule 9y ago
  curve25519-dalek is 3X faster than the equivalent Go code (i.e. in the stdlib, authored by agl). This is for a few reasons: Rust has support for 128-bit integers (i.e. u128) which allows for faster arithmetic when operating on what are effectively multi-u128 bignums in an elliptic curve library. LLVM is generally more sophisticated about optimizations. It wasn't until recently that go had an SSA-based compiler, so its optimizer isn't nearly as sophisticated as LLVM's, which has been developed for many years now.
  - pjmlp 9y ago
    There is also gccgo, taking advantage of GCC's backend. There is some ongoing work into an LLVM based compiler for Go, and LLVM now has Go as official supported bindings.
  - tptacek 9y ago
    Go can and should fix the integer problem here. George Tankersley had a whole talk at Crypto Village this year about what a nightmare it is to write competitively fast curve code in Go.
- fnord123 9y ago
  My information may be out of date, but last time I poked through the Go compiler, it did no vectorization or anything equivalent to march=native. So there's plenty of opportunity for Rust to be faster.
kmicklas 9y ago

digikata 9y ago

As always, general benchmarks only give you limited insights, but this might be interesting: Rust vs Go http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=go http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Rust vs C http://benchmarksgame.alioth.debian.org/u64q/rust.html http://benchmarksgame.alioth.debian.org/u64q/rust.html