10:50:26 <sech1> https://www.youtube.com/watch?v=gmAgvHaw9w4
10:51:29 <sech1> and the repo https://github.com/l1mey112/randomx.js
10:54:42 <parazyd> 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?
10:57:59 <sech1> 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%
11:25:02 <parazyd> *nod*
15:02:13 <DataHoarder> ^ implemented similar tricks they do on https://github.com/l1mey112/randomx.js/blob/master/src/jit/stubs/semifloat.c
15:03:00 <DataHoarder> and the purego/wasm interpreter that was using softfloat64 now runs quite faster 
15:03:03 <DataHoarder> no JIT in that mode
15:03:45 <DataHoarder> -20% per/op
15:11:01 <DataHoarder> 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)
15:26:36 <DataHoarder> making it constant time gave -50% reduction total :)
15:27:49 <sech1> Tricks as in calculating the error of FP +-/* operations? Yes, that's a well known technique
15:32:43 <DataHoarder> yeah, to apply rounding
15:36:02 <DataHoarder> the trick is applying it in constant time
16:18:50 <DataHoarder> not that bad compared to hardware rounding in interpreter mode https://paste.debian.net/1414001/
16:20:10 <DataHoarder> ofc as usual calculating both branches and merging them constant time is faster than doing branched code :)