13:51:14 hey, can someone with an Intel Mac verify this? https://github.com/tevador/RandomX/issues/216#issuecomment-886029727 20:25:04 ok selsta verified for me. sech1, when you get a chance, mebbe approve/merge the last 2 PRs 20:27:13 hyc #217 and #222? 20:27:23 yep 20:28:10 I had an outstanding question on #222 tho 20:28:35 if you can answer, that'd be good 20:30:46 I have no idea, I didn't even know about this double column thing before today 20:31:24 have you built DLL with msvc recently? 20:32:07 I never build this DLL actually 20:32:24 oh, I thought you said you ran into this problem before on windows 20:32:48 It was in debug MSVC build, with static randomx lib 20:33:24 huh. interesting. I thought this was only a problem for shared libs, but oh well. 20:33:33 I don't think #222 will change debug MSVC behavior 20:34:15 you don't think it will fix anything? 20:34:24 because it's about external calls, not internal jumps within the same asm file 20:34:37 no, it definitely fixes some issues with linker 20:34:56 MSVC just does its own shenanigans in debug build 20:35:02 ah 20:35:05 like placing jmp trampoline for every function 20:46:37 MSVC debug build still crashes 20:52:25 have you got a trace of exactly where it crashes? 20:53:16 wondering if it's related to the line I commented about, or completely different location 20:53:50 I think it's an unrelated issue 20:58:00 in debug MSVC build? It crashes because pointer to functions were not pointing to the actual ASM code, so all size and ptr diff calculations were wrong 20:58:37 crashes here: https://github.com/tevador/RandomX/blob/master/src/jit_compiler_x86.cpp#L223 20:58:46 I have a workaround for this: https://github.com/SChernykh/RandomX/commit/1adc7d8efd2943c0996f55821b7d3ba94795135f#diff-3d4646054ab2a831c4228adf316a676bbffaa2e65b19f6ceeb1cdf068484eff4R98 20:58:49 because epilogueSize is negative 20:59:56 can you PR it? 21:01:09 my branch is quite divergent from mainline, I'll make a separate PR tomorrow 21:01:58 cool. then 222 can go in as-is and your PR will take care of the rest 21:02:41 everything has been merged 21:03:43 ah just got the last email from github. cool 21:04:28 or maybe I'll PR today, it shouldn't take much time 21:12:36 soon it will be 2 years since RandomX activation on mainnet and I'm still waiting for shelby3's ASIC 21:13:00 lol 21:13:18 or linzhi's 21:14:20 linzhi must be bankrupt by now, their ASICs have bricked themselves by being too late, DAG won't fit anymore 21:15:27 ^I mean their ethereum stuff 21:15:42 https://github.com/tevador/RandomX/pull/225 21:19:26 btw any info on how wownero's pool blocking strategy has been going? 21:19:40 works so far 21:19:58 I've been mining it solo for quite a while, but then switched all my servers to p2pool 21:21:03 the next step should be bundling p2pool with monerod 21:21:48 I'd like to see it integrated. otherwise wasting a lot of RAM on caches & datasets 21:22:16 1 GH/s of braindead miners still on minexmr 21:23:27 huh. I got 17 payouts today 21:23:42 previous was oct 27, nothing in between 21:28:15 hyc integrated how? It's completely different codebases, monerod doesn't use libuv. Maybe monerod can share RandomX caches via file mapping 21:28:59 just some mechanism so they can share randomx memory, yeah 21:29:31 it's better to have on monerod side via some RPC that tell the name of file mapping 21:29:46 or just some well known name 21:30:15 p2pool only needs to verify hashes right? why not just forward to monerod for verification 21:30:46 that's slower 21:30:51 maybe for "super-light" mode 21:31:05 But monerod doesn't have such RPC yet 21:31:58 in theory, RandomX could be moved completely out of monerod, something like https://github.com/tevador/randomx-service 21:32:13 yes, \i suggestted this a few days ago 21:32:30 without RandomX stuff, p2pool uses less than 100 MB of memory 21:32:55 and that's including 12 hours worth of sidechain blocks 21:34:08 suppose we do a randomx-service using unix domain sockets 21:37:02 even with localhost TCP, the overhead will be negligible compared to the ~1 ms it takes to calculate the hash 21:37:16 usually 2 ms when it's not in batch mode 21:37:21 because cache is cold 21:37:50 also, monerod uses only light mode normally 21:38:58 a single randomx-service that does mining plus p2pool + monerod verification would be slick 21:41:14 one more thing to set up? 21:41:21 probably better to keep it inside monerod 21:42:40 or monerod could get a RPC method for calculating hashes 21:43:49 yeah, that could work. all the necessary parts are already present 21:44:15 that would be limited to the current 2 RandomX caches though, but p2pool doesn't need more 21:48:17 so there's 2 actions, right? one is to validate if an incoming share was computed correctly\ 21:48:44 the other is to submit a block to monerod if the incoming hash solves the mainchain difficulty 21:49:05 in the latter case, you can just send it to monerod without trying to validate it 21:51:49 I already send it before PoW validation 21:51:59 but PoW validation is done on p2pool side later anyway 23:39:43 can prob get a new monerod rpc ready before v0.18 release