I was looking at the bitcoin development subforum yesterday, one guy had done a profiling to find the slow parts of bitcoin core... as other parts were accelerated, sha256 and crc32c were found to consume a lot of cpu... apparently bitcoin core devs are contemplating the use of some sse4 and avx+ variants for both. Might be worth to take a look if you are using the C versions.
You are viewing a single comment's thread from:
thanks for the link. I already use a somewhat optimized SHA256. a lot of the bitcoind used openssl hashing, which just seems wrong, but when they eventually get around to making optimized lib, like secp256k1, it is great stuff
The biggest performance killer I found was the DB and to my mind if the blockchain is immutable data, then why is it in a DB?
I think even scp256k1 would be accelerated with some newer instructions (mulx / adcx) if one goes deeper to the asm level. But they are not very widespread instructions yet in terms of use. The sha256 and crc look that they can be sped up quite a bit. As you progress with iguana and do similar profiling work, you'll have to eliminate the bottlenecks one by one and at that point you may hit issues like that.
As for the DB, I'm not sure exactly how the bitcoin core software works. What I do know, is that it's extremely slow with a mechanical disk. I think I've read gmaxwell say that the db is only for the wallet and not for the blockchain. I haven't analyzed it myself (I'm an extremely rusty coder with C aversion, so...) and that's why I can't say anything with certainty.
As for the immutability, I guess one would say that in theory the blockchain is "eventually consistent"... so there's always room for some divergence...