Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.minio.io

Post reply on HN
Print view View original

81–90 of 93 posts

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

#81

Post by cmrx64 »

sjolsen wrote: post #63
halomru wrote: post #56

Earlier quoted context omitted.

>there are no algorithm changes (otherwise the results would be different Insertionsort, Mergesort and Timsort are three wildly different algorithms with different speeds, but on every possible input they produce the exact same result

Strictly speaking, it's possible for different sorting algorithms to produce different results if you sort using a weak order rather than a total order.

Or an unstable sort (which none of grandparent's examples are, but aren't uncommon in naive implementations)

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

#82

Post by cmrx64 »

userbinator wrote: post #67

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…

I think RISC-V is showing that RISC ISAs can still compete in this space: https://arxiv.org/pdf/1607.02318v1.pdf. RISC-V has extensibility of the ISA as a core feature, allowing for special-purpose accelerators and coprocessors as needed.

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

#84

Post by Cthulhu_ »

pcwalton wrote: post #66
giovannibajo1 wrote: post #22

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.

Only if the compiler is aware of and can translate code into e.g. ARM-specific sha instructions. If not, then the developer is still smarter than the compiler and should use assembly to use those specific instructions.

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

#86

Post by userbinator »

ridiculous_fish wrote: post #78
userbinator wrote: post #67

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…

> CISC-style dedicated instructions and hardware which utilises them will always be more efficient than a pure software implementation using just "simple RISC instructions" For a counterexample, see the x86 string instructions. "Hardware" implementations like `repne scasb` are routinely outperformed by software implementations using SSE2. Another problem is that these instructions don't die. SHA will some day be repl…

For a counterexample, see the x86 string instructions. "Hardware" implementations like `repne scasb` are routinely outperformed by software implementations using SSE2.

That's only because SCAS (and CMPS) has not (yet) received quite the same amount of attention as MOVS and STOS. For a counterexample to your counterexample, look up "enhanced REP MOVSB". REP MOVS/STOS can operation on cacheline-sized blocks since at least the P6, when it was introduced as the "fast strings" feature, and its performance has been steadily improved over the processor generations.

Another problem is that these instructions don't die. SHA will some day be replaced, but the instruction will live on. The x86 BCD instructions illustrate this.

Replaced for secure crypto, yes, but there are plenty of other applications like (nonmalicious) data corruption detection where a reasonably fast yet far more collision-resistant algorithm than regular CRC is very useful.

On the topic of BCD instructions, there's this: https://news.ycombinator.com/item?id=8477254

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

#87

Post by pjmlp »

userbinator wrote: post #67

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…

Also in sync with the micro-coded CPUs of Burroughs, Xerox PARC, ETHZ, Genera and so on, even if they eventually lost to more general purpose CISC instructions.

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

#88

Post by pjmlp »

dlsniper wrote: post #72
pcwalton wrote: post #66

Earlier quoted context omitted.

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

Is this a general thing or a Go specific one? This generic statement seems to be false given how many optimizations that actually need assembly exist in Go and not only.

It is a general thing and quite common.

Either you keep adding intrisics to the compiler, or outsource it to an external Assembler.

Even managed languages have bytecode Assemblers available.

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

#89

Post by pjmlp »

shurcooL wrote: post #75
fwessels wrote: post #14

Earlier quoted context omitted.

Go didn't help specifically, it is just that this package makes support for the ARM SHA instructions available for Golang.

Also Go has support for using assembly in a package natively, not all languages/build tools support that as easily.

It is pretty common in imperative compiled languages.

Back when compilers were sold, the professional version always had an assembler in the box.

In MS-DOS even BASIC compilers like Turbo Basic could use inline Assembly.

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

#90

Post by pjmlp »

nickcw wrote: post #27
serge2k wrote: post #26

> WORD $0x4cdf2025 // ld1 {v5.16b-v8.16b}, [x1], #64 Why is the code written as words like this instead of just the assembly instructions?

Because the Go assembler doesn't have those instructions built in most likely. That sort of thing is quite common in Go assembler. The assemblers are a little primitive and they force the assembly language for each processor into a common pattern, so when you are writing ARM assembler for instance, everything is backwards. I imagine having rationalised the assemblers between processors somewhat it makes the core deve…

Backwards from AT&T point of view, right?

Because for me it feels very natural, given the Z80 and Intel Assembly.

Post reply on HN