5 ms·

Source? First Google result for "Rust vs Go speed": https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=go https://benchmarksgame.alioth.

by fbender 10y ago

Source? First Google result for "Rust vs Go speed": https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=go https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... Rust seems to perform significantly better on some workloads while Go outperforms it marginally in other ones (except reverse-complement where Go is almost 50% faster than Rust). Edit: As for the other points you make – they are often subjective and I've read the opposite to your statement at least as often.

steveklabnik 10y ago
The ones where Go outperforms us currently are the ones with heavy SIMD use; explicit SIMD is still unstable in Rust, so you're at the whims of LLVM generating it. We'll get there...
- igouy 10y ago
  Do those Go programs use explicit SIMD ? http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=rust http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
  - steveklabnik 10y ago
    I assume that they're better about generating it implicitly. That is, it's about why Rust is slow, not about why Go is fast.
    - pcwalton 10y ago
      I don't think Go emits SIMD at all. Their assembler doesn't even support parsing it. I think these are probably just bugs that we need to look at. The benchmarks where we do worse are the string benchmarks; perhaps it's our Unicode correctness that is hurting us, or something like that.
      - burntsushi 10y ago
        It definitely does: https://github.com/golang/go/blob/b851ded09a300033849b60ab47a468087ce557a1/src/runtime/asm_amd64.s#L1394-L1413 https://github.com/golang/go/blob/b851ded09a300033849b60ab47... I should look into those benchmarks if you think there might be string problems. To be frank, I've never looked too closely at anything except for regex-dna.
        pcwalton 10y ago
        Oh, interesting. I was inferring that from the Go code out there that uses machine code directly: https://github.com/minio/blake2b-simd/blob/master/compressAvx2_amd64.s#L181 https://github.com/minio/blake2b-simd/blob/master/compressAv... I guess it must be a recent addition.
        burntsushi 10y ago
        I think it was recent, yeah. I also recall there being problems with their assembler not being able to parse various SIMD instructions in the past. I also recall seeing code like in your link too. Hmm, Go 1.7 introduced support[1] for various AVX instructions (plus at least one SSE 4.2 instruction), some of which are used in blake2b-simd. I can't wait to get SIMD on Rust stable. It's going to be exciting. [1] - https://golang.org/doc/go1.7#tools https://golang.org/doc/go1.7#tools
        pcwalton 10y ago
        Oh, by the way, if you want to investigate the string benchmarks, that would be really awesome--I'm curious to know what's going on there :)
    - igouy 10y ago
      > about why Rust is slow If the Go programs don't use explicit SIMD, then "explicit SIMD is still unstable in Rust" does not explain the difference.

by fbender 10y ago

steveklabnik 10y ago

The ones where Go outperforms us currently are the ones with heavy SIMD use; explicit SIMD is still unstable in Rust, so you're at the whims of LLVM generating it. We'll get there...

igouy 10y ago
Do those Go programs use explicit SIMD ? http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=rust http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
- steveklabnik 10y ago
  I assume that they're better about generating it implicitly. That is, it's about why Rust is slow, not about why Go is fast.
  - pcwalton 10y ago
    I don't think Go emits SIMD at all. Their assembler doesn't even support parsing it. I think these are probably just bugs that we need to look at. The benchmarks where we do worse are the string benchmarks; perhaps it's our Unicode correctness that is hurting us, or something like that.
    - burntsushi 10y ago
      It definitely does: https://github.com/golang/go/blob/b851ded09a300033849b60ab47a468087ce557a1/src/runtime/asm_amd64.s#L1394-L1413 https://github.com/golang/go/blob/b851ded09a300033849b60ab47... I should look into those benchmarks if you think there might be string problems. To be frank, I've never looked too closely at anything except for regex-dna.
      - pcwalton 10y ago
        Oh, interesting. I was inferring that from the Go code out there that uses machine code directly: https://github.com/minio/blake2b-simd/blob/master/compressAvx2_amd64.s#L181 https://github.com/minio/blake2b-simd/blob/master/compressAv... I guess it must be a recent addition.
        burntsushi 10y ago
        I think it was recent, yeah. I also recall there being problems with their assembler not being able to parse various SIMD instructions in the past. I also recall seeing code like in your link too. Hmm, Go 1.7 introduced support[1] for various AVX instructions (plus at least one SSE 4.2 instruction), some of which are used in blake2b-simd. I can't wait to get SIMD on Rust stable. It's going to be exciting. [1] - https://golang.org/doc/go1.7#tools https://golang.org/doc/go1.7#tools
      - pcwalton 10y ago
        Oh, by the way, if you want to investigate the string benchmarks, that would be really awesome--I'm curious to know what's going on there :)
  - igouy 10y ago
    > about why Rust is slow If the Go programs don't use explicit SIMD, then "explicit SIMD is still unstable in Rust" does not explain the difference.