why xmrig 5.5.1 is crashing on x32 ?

how to feeexeeet

Is it safe to use std::atomic<uint32>::fetch_add(1) in real miner?

it's present in randomx-benchmark

it is safe, but there are better ways to distribute nonces

you can make many non-overlapping sequences

I've just get duplicate value from fetch_add(1) within the same thread. That's why asked here

indeed, simpler to just divide nonce space by number of threads, and not worry about it

It's iterating by N nonces within nonce space and assign i-th part to each thread. I'm trying to decrease delay of switching from previous job. It's up to N / (worker speed) now.

If that problem with atomic is real then I can't use them even for job notification.

Maybe it has happened due loading randomx library from memory buffer.

Can't reproduce it in c++ binary without sophisticated loading.

What efficient way will you use for new job notification except atomic and decreased threads's step within nonce space?

some structure under mutex?

again duplicate but in two different threads, something doesn't work

atomic should just work

returning same value twice is weird

if this is all required for fetch_add: "lock xadd QWORD PTR [rax],rdx" then it should really work even in jit with arbitrary memory address

Yo

cohcho: yes, just note that this instruction can take 20-50 CPU cycles

tevador is there a paper on RandomX?

i.e how it works?

there are extensive docs on github

cool, in the same repo?

ooh found it

this looks good too: github.com/tevador/RandomX/blob/master/doc/design.md

(y)

yes, there are two docs: the formal specs and the design comments

thanks didn't know if it was all code or not and if there was a separate paper

everything is in the github repo, including the audit reports

Cool thanks. I did not know you hung out in this chat. I'll probably be back with questions,

ok, this is the right channel for questions

Sweet