Halving double-hash instruction count

[Sonoftexas]

I haven't followed bitcoin since before ASICs, and I remember when people were trying to squeeze every optimization they could out of the hashing algorithm in the gpu codes.

I didn't know where to put this thread, but my question is about how ASICs are optimized. If I managed to find an extremely good optimization that somehow halved the instruction count needed for a double hash, is that interesting to the ASIC designers? I would think it would save power consumption at least. If not halving, what ratio is interesting? A tenth?

[1714317817]

1714317817

[1714317817]

1714317817

[bob123]

ASIC's (Application-specific integrated circuit's) can only perform one task. But this one task is done extremely efficiently.

You can imagine it like this:
You need to set the power at the correct pins (which basically is the input) and after the electricity has gone trough the hardware you are measuring which bits are set (output; effectively the hash).
The time it needs to calculate a hash is the time the electricity needs to run through the hardware (not exactly, but basically).

Optimization is always good (and desired). But how do you think you have achieved this optimization? Software-wise there isn't much you can do.
You would need to optimize it hardware-wise.

[Sonoftexas]

You need to set the power at the correct pins (which basically is the input) and after the electricity has gone trough the hardware you are measuring which bits are set (output; effectively the hash).
The time it needs to calculate a hash is the time the electricity needs to run through the hardware (not exactly, but basically).

Yeah, so currently a double hash is like 2000+ sequential operations, so there's a maximum frequency you can operate while you wait for the output. If you somehow could use just 1000 gates, you could run it ~twice as fast, right? Or is there some other limitation?

[DDAsics]

CPU like instruction counts have very little to do with designing an ASIC. ASICs are designed using an RTL language. RTL stands for register transfer level, and is totally unrelated to CPU style sequential instructions. Essentially, an ASIC design means setting up a gate pipeline that has a certain delay to produce the first output, but after that short delay the circuit spits out 1 solution every clock cycle.

It is like turning on a hose. There is a delay for the water to move from the faucet to the spout, but once water starts coming out, it comes out in a continuous stream.

Nobody does SHA256 hashing with computer like instructions. It is all fully unrolled pipelines, with as many of them crammed onto a piece of silicon as possible. It is not done as a sequential operation in the way you are thinking of it. What you need to do if you want it to be interesting to ASIC manufacturers is to come up with a way to significantly reduce the number of transistors in a fully pipelined circuit.

[Sonoftexas]

but after that short delay the circuit spits out 1 solution every clock cycle.

Ah, so you're saying that as soon as the signal for one hash leaves a transistor to go the next, the next hash is already incoming to that first transistor? Then the limit on clock speed is only the switching speed of one transistor, and so there's no way to really improve it? Would reducing the number of transistors just reduce the power consumption then?

[mikeywith]

i do not understand why some replies implies that there is nothing much that can be done on the software layer. if what they say is true then how do you explain the effect of overt/covert asicboost? it is certainly far from being "double" the performance, but there are things on the software side that can improve hashing.

[philipma1957]

i do not understand why some replies implies that there is nothing much that can be done on the software layer. if what they say is true then how do you explain the effect of overt/covert asicboost? it is certainly far from being "double" the performance, but there are things on the software side that can improve hashing.

But the chip has patterns burned into it to allow that.

So while the software turns it on and off the switch for boost on/off is built into the chip.

But others know more about this than I do.

[jstefanop]

The math for a single SHA256 hash is already pretty simple linear operation. Transistor counts to perform this has already been optimized at the bare transistor layer with companies like bitmain and Co pouring billions into these optimizations over the last 5 years.

I guess you could stumble across a new mathematical theory that produces that same SHA256 output using a completely different simpler algorithm, but good luck with that .

[tim-bc]

But the chip has patterns burned into it to allow that.

So while the software turns it on and off the switch for boost on/off is built into the chip.

But others know more about this than I do.

Phil is right, the BM1387 chip used in the S9 was designed with asicboost in mind from the beginning (as an option, not as a necessity). The recent firmwares simply provide the software support necessary to actually gain that ~13% power savings.

[NotFuzzyWarm]

Phil is right, the BM1387 chip used in the S9 was designed with asicboost in mind from the beginning (as an option, not as a necessity). The recent firmwares simply provide the software support necessary to actually gain that ~13% power savings.

Correct but AB does that by incrementing the starting value of work sent to the chips 2-4 times and then reusing it - NOT by 'halving the instruction count'. Do a search for the ASICBOOST whitepaper to find out what it does.