Closed newpavlov closed 6 years ago
I don't think there's any point depending on this within tiny-keccak
. If your implementation is better then the consumers of tiny-keccak
should just depend on your crate instead. The only improvement to the algorithm in this PR is rerolling the outer loop, and I think a better PR would be one that did that and that alone.
In future we plan to add wrappers around assembly from KeccakCodePackage which will be exposed in keccak
through feature gate, so I don't think it will be a good idea to duplicate implementations. Either way it's your call, so you can close this PR if you want.
I've implemented a stand-alone crate
keccak
which currently contains onlyf1600
function. (in future I plan to expand it with other keccak-f variants and keccak-p) The crate is licensed under CC0 terms and it's based on @Vurich's contribution. The main changes are use of custom unrolling macros (i.e. no dependency oncrunchy
) and disabled unrolling of rounds loop. The latter results in a better performance (~15-20% on my machine) and in a significantly smaller function size (~24 times), which proportionally improves compilation times, especially after recent regression in the compiler.