trie: parallel commit (alternative version)

[holiman]

Alternative to #30461

I've attempted to do it differently.

• Get rid of the wrapped node struct
• On top level, spin out new committers, one per goroutine. Each committer has it's own internal nodeset. After finishing it's work, each goroutine merges it's own nodeset with the parent nodeset.

With this approach, I get

BenchmarkCommit/commit-5000nodes-single-8                    129           9849412 ns/op         4620280 B/op      55223 allocs/op
BenchmarkCommit/commit-5000nodes-parallel-8                  313           3974443 ns/op         5592933 B/op      55789 allocs/op

So the 9ms -> 10ms for single-thread, and 4ms for multi-threaded approach. The mem usage is only marginally higher than current master.

[holiman]

Running this on 07 vs master on 08 now

[holiman]

Here's the same:ish chart as @rjl493456442 provided for #30461

The previous one

It's a bit odd -- the previous PR did showed a clear difference, but this PR does not. I have no idea why that is.

[holiman]

I will now switch it a bit, so that:

07 switches from this PR to running #30461 (rebased on master)
08 switches from master to running this PR

[holiman]

I will now switch it a bit, so that:

07 switches from this PR to running #30461 (rebased on master) 08 switches from master to running this PR

So, apparently, this made a difference. I don't know why, but now it does show a difference. The only meaningful change I can think of, is that I now set back the minumum mutations from 400 to 100. For account commit, a block's worth of changes should easily surpass 400, but I don't have any better theory. I have double-checked that the commit-hash of the code that was running on 07 was indeed this PR.

So, new charts:

On the left: master then this PR, going from ~5 to ~2ms
On the right: this PR then #30461, going from ~5 to ~3ms

So, now it's showing what I had expected from the start. Here's a zoom in on the last 30 minutes, again this PR on the left, ancestor PR on the right: