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

[burntsushi]

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

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