Use non-locking operations for nodes count and tbHits

[anematode]

As usual... non-functional speedup.

Failed yellow on Fishtest:

LLR: -2.95 (-2.94,2.94) <0.00,2.00>
Total: 219616 W: 57165 L: 57105 D: 105346
Ptnml(0-2): 732, 24277, 59720, 24357, 722 

vondele and I chatted on the Discord and agreed that this is probably still a good change even if it doesn't gain on fishtest, given that it gains on at least some systems, and it would be insane for it to regress anywhere. That being said, it might be a good idea to get more benchmarks to understand the impact of this change....

Background/explanation

fetch_add and friends must produce a locking instruction because they guarantee consistency in the presence of multiple writers. Because only one thread ever writes to nodes and tbHits, we may use relaxed load and store to emit regular loads and stores (on both x86-64 and arm64), while avoiding formal 👻 UB 👻 and miscounting nodes.

Credit must go to Arseniy Surkov of Reckless (@codedeliveryservice) for uncovering this performance gotcha.

(I'm honestly shocked that this patch works—I guess uncontended atomics are much more expensive than I thought!)

Other data

Benchmark results from vondele's many-core machine:

==== master ====
1 Nodes/second : 294269736
2 Nodes/second : 295217629
Average (over 2):  294743682
==== goose ====
1 Nodes/second : 299003603
2 Nodes/second : 298111320
Average (over 2):  298557461

indicating it scales fine. Interestingly I get only a minuscule speedup on my Zen 5 machine (+0.1%, P>0.99). I can't imagine a case where it'd ever regress though, and fishtest doesn't lie.

[ddobbelaere]

Why does only one thread update those counters? What's the point for using atomics anyway then, to just read them in another thread? Sorry for the potentially stupid question.

[vondele]

because two different threads read them... they have to be treated as atomics.

[ddobbelaere]

I see, they are local counters of the worker thread itself (and not global ones) which are accumulated elsewhere. Makes perfect sense, sorry for the noise.

[vondele]

will need rebase

[vondele]

will need rebase

@anematode FYI