starky performance

[srinathsetty]

The following script seems to be benchmarking sha256 compression rather than a full SHA computation (which requires additional padding such as lengths): https://github.com/celer-network/plonky2-bench/blob/62ebc6ab5c690f7bcd65ffda756e220dfb0b996d/run_starky.sh

Shouldn't it be at least 1024 hashes to hash 64 KB, rather than 512?

[patrickmao93]

The following script seems to be benchmarking sha256 compression rather than a full SHA computation (which requires additional padding such as lengths): https://github.com/celer-network/plonky2-bench/blob/62ebc6ab5c690f7bcd65ffda756e220dfb0b996d/run_starky.sh

Shouldn't it be at least 1024 hashes to hash 64 KB, rather than 512?

You are absolutely right. The original code was written by Sebastian LeDusa from polygon. I asked him the same question and he had no plan on adding paddings for another benchmark. The thing is padding is not particularly expensive and wouldn't change the benchmark result by orders of magnitude. In our blog, we plot the graphs using the # of blocks hashed by Starky matching others. So the actual padding is the only part missing. Considering Starky's performance is way ahead of others, my bet is that with the padding part added it would still be at the top.

[Sladuca]

It should be 1024 invocations for 64K, yes. Each compression function invocation consumes one 512-bit / 64 byte block.