and the repo github.com/l1mey112/randomx.js

sech1: re: randomx optimizations: Would it still be fine for example if we use the code with optimizations in both our miner and verification code?

It wasn't verified as thoroughly as the reference repo, but chances are very good that it can be used for everything. But the difference in performance is not that big if MSR and huge pages are applied to both. Less than 10%

*nod*

^ implemented similar tricks they do on github.com/l1mey112/randomx.js/blob/master/src/jit/stubs/semifloat.c

and the purego/wasm interpreter that was using softfloat64 now runs quite faster

no JIT in that mode

-20% per/op

but I also get rid of my own maintained softfloat64 (which was still faster in the case of soft float being needed than compiler soft float support)

making it constant time gave -50% reduction total :)

Tricks as in calculating the error of FP +-/* operations? Yes, that's a well known technique

yeah, to apply rounding

the trick is applying it in constant time

not that bad compared to hardware rounding in interpreter mode paste.debian.net/1414001

ofc as usual calculating both branches and merging them constant time is faster than doing branched code :)