Live data from Hacker News

Show HN: Accelerating SHA256 by 100x in Golang on ARM

blog.minio.io

91–93 of 93 posts

Re: Show HN: Accelerating SHA256 by 100x in Golang on ARM

#91

Earlier quoted context omitted.

That's wishful thinking. GCC isn't able to do that with C language, a 20 years old compiler with a 40 years language. How would a compiler know that you can use a SHA2 instruction? Yes, there are intrinsics but then what about specialized vectorized instructions which don't match any primitive types or operations in the language (like, you can't express "add with carry" in C or Go)? And how can you explain a compiler…

"That's wishful thinking. GCC isn't able to do that with C language, a 20 years old compiler with a 40 years language. How would a compiler know that you can use a SHA2 instruction?" Well, actually, they could, it's just not worth pattern matching because it occurs so infrequently. "but history has shown that things like autovectorization are too fragile and can't be relied upon." Errr, i'd say the opposite. History…

Can you show me an opensource library implementing performance-sensitive computations in any field (graphics, numerics, crypto, etc.) which relies on autovectorization to obtain the performance characteristics that clients rely upon?

The large majority of performance-sensitive libraries I know of rely on carefully written native code (C, C++), with a mixture of assembly and/or intrinsics. This, to me, is a failure to concretize autovectorization from textbooks into an industry-accepted solution.

Re: Show HN: Accelerating SHA256 by 100x in Golang on ARM

#92

Earlier quoted context omitted.

Most of it is written to take advantage of special hardware instructions in CPUs. If you take OpenSSL (a C library), it's got many assembly code paths as well. I'm not sure why this should be a problem, it just shows attention to performance in my opinion.

Opaque assembly blocks that the compiler doesn't understand the effects of are actually suboptimal for performance.

Rarely true for low level crypto code.

Re: Show HN: Accelerating SHA256 by 100x in Golang on ARM

#93

This is the sort of thing that shows why the whole "pure RISC philosophy" of implementing only the simplest instructions is ultimately a pretty dead-end in processor design. CISC-style dedicated instructions and hardware which utilises them will always be more efficient than a pure software implementation using just "simple RISC instructions", because hardware can easily express specialised computations like the extr…

This article is referring specifically to ARM64 assembly which is actually quite a bit more RISC-y than previous versions of the ARM ISA. In favor of simplicity, many of the more complex ARMv7 instructions (such as the block loads/stores) were removed in ARMv8. I'd still agree that ARM is not very RISC anymore, but the ongoing move to ARM64 takes it quite a bit back in that direction.
Post reply on HN