disclaimer: I am one of the co-authors pf the code as well as founder

Thank for for the feedback, that is nice to hear. And as for the business question, we plan on launching a Sneller Cloud offering. (Sneller founder here)

Sneller founder here: we do not have any non-AVX code so we cannot compare directly against that. But generally speaking our code always works on 16 lanes in parallel per core, so that gives a huge speed-up.

Albeit not using gas, you may want to check out https://github.com/SnellerInc/sneller -- it has about ~250 primitives written in AVX-512. (Sneller founder)

We have added both a cost and power consumption comparison to the blog post (including AMD EPYC as well), here is a snippet:

| Instance type | m6g.16xlarge | c5.18xlarge | c5.24xlarge | c5a.24xlarge |

| Architecture | Graviton2 | Skylake | Cascade lake | AMD EPYC |

| CPU(s) | 64 | 72 | 96 | 96 |

| RAM (GiB) | 256 | 144 | 192 | 192 |

| $/hour | $2.464 | $3.06 | $4.08 | $3.696 |

| Power usage (W) | ~115 | ~240 | ~240 | ~280 |

As per last week's announcement from AWS about the availability of AMD EPYC cpus, we have repeated the “single socket” test for the EPYC cpu as well.

The updated chart is included in the post or you can find it here: https://blog.min.io/content/images/2020/06/single-socket-per...

It clearly performs and scales a lot better than the Intel CPUs (no doubt also benefiting from the increased memory bandwidth) and at high core counts is very close to the Graviton2.

Furthermore, I agree that the “investment costs” for Amazon are almost minute, they might have already earned it back.

Check out the graph at https://github.com/fwessels/HashCompare that compares different hashing techniques.

And also we've done some predictions for collisions, see: https://github.com/fwessels/HashCompare/issues/1#issuecommen...

Yes, you can, but just naming the return variable takes care of this.

No, it is not an IR code such as in Java or .Net. At compile time it is translated into opcodes for the corresponding architecture that you are compiling for.

I disagree. I think saying that it's the lowered intermediate representation in the Go compiler pipeline is a really good description. It's equivalent to the LIR in Java's C2 compiler. I'm not sure what the equivalent is in .net.

Fundamentally, it's a representation and it's intermediate isn't it?

No, not really. Go's assembly might be considered somewhat higher level than regular assembly code, but it's certainly architecture specific. The examples highlighted use x86 SIMD instructions unavailable on other architectures.

Freedoms taken by the go assemblers also seem to be decreasing as the compiler becomes smarter. E.g. instruction reordering is no longer performed (https://github.com/golang/go/issues/15837).

You can read about the assemblers here: https://golang.org/doc/asm

Yes I know it's architecture specific. Many lowered IRs are. The equivalent I gave, Java's C2 IR, is also architecture specific, which is why I used it.

That is a good question but have never tried it. However, there is nothing "special" about the assembly as ported by c2goasm, so it should equally well as any other (hand-crafted) assembly.