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

71–80 of 93 posts

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

#71

Post by bostik »

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…

Bingo.

If and when speed matters, ASIC beats a general-purpose CPU hands down, every time.

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

#72

Post by dlsniper »

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.

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.

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

#73

Post by dlsniper »

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.

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.

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

#74

Post by femto »

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…

Or there is the middle ground of retaining the general purpose nature by making the "dedicated" hardware an FPGA. Potentially the best of both worlds. Xlinx has the Zynq (ARM+FPGA), Intel has bought Altera and is now doing CPUs with FPGAs in the package [2].

[1] http://www.xilinx.com/products/silicon-devices/soc.html

[2] http://www.pcworld.com/article/3055526/intel-starts-baking-s...

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

#75

Post by shurcooL »

fwessels wrote: post #14
anonymous7777 wrote: post #8

ok mentioning Go here is a bit pointless. How did Go help compared to any other language when Arm has hardware instructions for SHA1&2?

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.

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

#76

Post by chewxy »

fwessels wrote: post #39
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?

The Golang assembly does not support all instructions, we've created a tool (see https://github.com/minio/asm2plan9s ) to assist in translating instructions into their opcode equivalents.

Damn. That's neat. I wrote my own python script to translate whatever `as` spits out into BYTE $.... your tool'd have been neat when I wrote this http://blog.chewxy.com/2016/07/25/on-the-memory-alignment-of...

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

#77

Post by fwessels »

chewxy wrote: post #76
fwessels wrote: post #39

Earlier quoted context omitted.

The Golang assembly does not support all instructions, we've created a tool (see https://github.com/minio/asm2plan9s ) to assist in translating instructions into their opcode equivalents.

Damn. That's neat. I wrote my own python script to translate whatever `as` spits out into BYTE $.... your tool'd have been neat when I wrote this http://blog.chewxy.com/2016/07/25/on-the-memory-alignment-of...

Nice blog, and the tool would have helped indeed.

And also, memory allocation is not the most obvious topic in Go/Golang assembly...

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

#78

Post by ridiculous_fish »

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 replaced, but the instruction will live on. The x86 BCD instructions illustrate this.

From what I remember, RISC is less about "simple" instructions, and more about regular instructions which can execute with predictable throughput, ideally one per clock cycle. "Do this particular arithmetic" is in the RISC philosophy, while looping instructions (rep, lswi, etc.) are not.

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

#79

Post by cmrx64 »

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…

I do agree, but I wouldn't include vector instructions in "simple RISC instructions".

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

#80

Post by cmrx64 »

femto wrote: post #74
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…

Or there is the middle ground of retaining the general purpose nature by making the "dedicated" hardware an FPGA. Potentially the best of both worlds. Xlinx has the Zynq (ARM+FPGA), Intel has bought Altera and is now doing CPUs with FPGAs in the package [2]. [1] http://www.xilinx.com/products/silicon-devices/soc.html [2] http://www.pcworld.com/article/3055526/intel-starts-baking-s...

This can work for special-purpose projects, but might become problematic in general: reprogramming the FPGA can be slow (on the order of 10s of milliseconds) and you don't necessarily want to include FPGA state as part of task state in the OS. You also need to be careful about thermal limits and power draw (especially when reconfiguring). I doubt current-generation FPGAs will land in anything smaller than a server for a long time. There, you can have semi-permanent accelerators according to the server's role, and a larger thermal budget.
Post reply on HN