[fbender]

Source?

First Google result for "Rust vs Go speed": 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]

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]

Do those Go programs use explicit SIMD ?

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

[steveklabnik]

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]

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]

It definitely does: 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]

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/compressAv...

I guess it must be a recent addition.

[pcwalton]

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]

> 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.