01:55:18 <moneromooo> seddd: around ?
01:55:35 <moneromooo> ew. Wrong chen, nvm.
02:09:17 <maybefbi> hyc: ok. people seem to have trouble writing randomx in golang or any other vm because of this one instruction.
02:09:34 <hyc> how sad for them
02:09:42 <maybefbi> :D
02:09:44 <hyc> a lot of GPUs struggle with it too
02:09:59 <hyc> but the point of using cfround is to make life miserable for ASIC builders
02:10:02 <hyc> and it achieves that
02:10:19 <maybefbi> yeah makes sense
02:12:18 <maybefbi> hyc: it also hurts attempts to implement say a full node in wasm
02:12:28 <hyc> yes
02:12:40 <hyc> we already discovered this...
02:12:47 <maybefbi> ok
02:13:25 <hyc> the solution, if you want to do things from a web client, is to call out to a randomx service
02:13:36 <hyc> tevador has already written this too
02:14:18 <hyc> I don't really understand the point of reimplementing librandomx in Golang, particularly since Go isn't a low-level enough language to do it.
02:14:41 <moneromooo> Maybe to be able to claim you created it ? :)
02:14:53 <hyc> lol
02:17:49 <hyc> to get decent performance from a randomX VM you need asm support. the purpose of Go is to isolate inexperienced programmers from the hardware. completely conflicting goals.
02:20:29 <derpy_bridge> <[discord] Arctic#5824>: randomX... in *java*
02:20:44 <derpy_bridge> <[discord] Arctic#5824>: nono, ***PYTHON***
02:29:22 <hyc> if you enjoy implementing floating point math in interpreted languages, knock yourself out...
02:32:06 <maybefbi> hyc: if Intel/AMD/ARM fix their floating point implementations in a processor 100 years from now, won't all old randomx calls become unverifiable?
02:38:44 <hyc> what do you mean fix?
02:39:22 <hyc> what makes you think they're broken?
02:43:37 <maybefbi> if i were the "deep state" "cigarette smoking man" much like how NIST tried to implement kleptographic backdoor in Dual_EC_DRBG, i would influence IEEE to upgrade IEEE 754 ever so subtley just to hurt monero
02:47:25 <selsta> How could that hurt Monero? Just use softfloat or something similar in that unlikely case?
02:48:57 <hyc> lol
02:49:24 <hyc> nobody is going to incompatibly upgrade IEEE-754. Scientists all around the world would revolt.
02:49:47 <hyc> all the supercomputing centers around the country, wher ethe gov't runs their nuclear bomb simulations, would break.
02:52:51 <maybefbi> once people start trading nukes using monero, those neutron transport equations in those computers will be worth breaking
21:38:16 <selsta> the RandomX PR looks now merged
21:38:37 <selsta> is the code safe enough to include in the upcoming release or would it be better master only for a while?
21:39:04 <hyc> I don't think it's urgent for release, master would be fine
21:39:09 <selsta> ok
21:39:59 <tevador> yes, keep it in master for now unless we need to patch the rounding modes
21:40:16 <niocbrrrrrr> wat is in the PR?
21:40:19 <tevador> but I don't think Monero is affected
21:40:46 <tevador> niocbrrrrrr RandomX used to modify the rounding mode of the calling thread
21:41:05 <tevador> which apparently caused some issues on some other blockchain
21:41:15 <niocbrrrrrr> thx
21:41:30 <selsta> tevador: apparently the Loki issue was not because of RandomX
21:41:51 <tevador> is there a write-up somewhere?
21:41:53 <selsta> see https://github.com/monero-project/monero/pull/6534
21:42:06 <selsta> it has also been an issue with monero for a while
21:42:16 <hyc> there's no floating point math in the monero source
21:48:34 <hyc> aside from printing values like hashrate and such
21:58:41 <tevador> btw coming up on 6 months since the fork
22:08:33 <hyc> hashrate still looks normal
22:08:58 <hyc> how's nonce distribution looking?
22:16:07 <tevador> I haven't seen a recent analysis, but I'm sure there are no ASICs for RandomX (apart from those made by AMD)
23:29:34 <sech1> Nonce distribution looks all the same since the fork
23:29:48 <sech1> I tried many different visualization approaches and didn't find any irregularities