Re: Are there any benchmark about Bitcoin full node client resource usage?
Firstly it is NOT about parallel transaction verification, instead it postpones script verification by queuing it for a future multi thread processing which is called right before ending the block verification that is done single threaded. This thread joins to the final multi-thread script processing.
The logic behind such a sophisticated scheme apparently has something to do with the complexities produced by transaction packages where we have transactions with fresh inputs that are outputs of other transactions in the same block.
The logic behind such a sophisticated scheme apparently has something to do with the complexities produced by transaction packages where we have transactions with fresh inputs that are outputs of other transactions in the same block.
Stop engaging in abusive technobabbling. There is no interaction with "transaction packages" or anything of the sort there.
Your comments are misleading and non-constructive. My comments are not "abusive" by any measure.
Your claim about transaction packages" not being relevant here is totally false and laughable just like what you are saying below:
Quote
The verification of transactions runs in parallel with everything else. One thread loads transactions from the block into a queue of transactions that need to be validated, other threads pull transactions from the queue and validate them. When the main thread is done loading the queue, it too joins into the validation which has been in progress the whole time. There is nothing particularly fancy about this.
Absolutely false and misleading. The code does not "load" transactions to "queue of transactions" you are deliberately misrepresenting the code for some mysterious purpose that I don't understand.Now let's clean your mess:
In the real world, the real bitcoin core client, does NOT validate transactions in parallel, because in bitcoin there is a possibility for transactions to be chained in a single block, forming a transaction package, hence you can't simply "dispatch" txns of a block between threads waiting for them to join, it is why block verification was implemented single thread.
PR 2060 was an improvement, based on "deferring" the CPU intensive part of the task, i.e. script verification by queuing this part for future parallel processing.
It was good but not a complete scaling solution because the main block validation process remaining single thread, occasionally waits for UTXO checks, so, we don't get linear improvement in terms of block processing times with installing more cpus/cores. Period.
Quote
When blocks contain only a few inputs this limits parallelism, but once blocks have a couple times more inputs than you have cores it achieves full parallelism.
Absolutely false and misleading. I have not checked, but I suppose in 2012 most blocks had ways more than "a couple times more inputs" than an average node's cpu cores. Quote
Of course, there is always room for improvement. But one improves things by actually understanding them, writing code, and testing it. Not by slinging verbal abuse on a forum in a desperate attempt to impress the peanut gallery, so I guess you wouldn't know anything about that. 
Come on This is btctalk, not github, and it is very inappropriate asking people to write code or STFU.
Reading comments like this, I'm realizing more and more that bitcoin is overtaken by junior programmers who do not miss any occasion for bragging with their if-else-then stuff.