17:55:51 hyc I'm done with rx_slow_hash: https://github.com/SChernykh/monero/commit/32adb12db68bdb9c41e6cd803bf065f141c7a393 - testing it on one of my nodes now, local node synced 10000 blocks across several RandomX epochs without issues. 17:56:10 testing it with MONERO_RANDOMX_FULL_MEM env 17:57:35 I think it's the 3rd time I'm doing all this logic :D First XMRig, then P2Pool, now monerod :D 19:09:13 lol 19:10:44 this comment is confusing When dataset is used for PoW verification, it's updated in background without stalling other threads (verification is done in light mode then) 19:12:48 When dataset is used for PoW verification, dataset updates don't stall other threads (verification is done in light mode then) 19:13:18 ok. 19:13:39 so when dataset is busy being updated, it doesn't get used. fine. 19:14:00 Removed `SEEDHASH_EPOCH_LAG` and `SEEDHASH_EPOCH_BLOCKS` environment variables 19:14:09 I think the testsuite still uses these 19:14:31 damn 19:14:33 indeed 19:14:37 specifically to set smaller epochs so that boundary crossings can be checked 19:14:44 I was searching for all C/C++ files but forgot *.py 19:57:47 returned them: https://github.com/SChernykh/monero/commit/baa8da512af957c858bc556a127162d89c44ed7a 20:32:53 left a few inline comments 21:33:42 updated to https://github.com/SChernykh/monero/commit/2bcf014a4b7a6a8ed7841fa7964a823c5c0d7d6f 21:34:30 It turns out, SRWLock functions on WIN32 require Windows Vista or newer 21:34:44 does official Monero binaries support Windows 7? 21:35:13 pthread_rwlock_t works on Windows 7, so maybe just leave only pthread_rwlock_t? 21:37:18 I've forgotten what our minimum windows version is 21:37:28 I build on windows7 21:41:40 "Microsoft offered Extended Support for three years which is set to expire on January 14, 2023" 21:41:54 right about time we start using native SRW locks :D 21:43:27 of course it's possible to write a wrapper that checks if kernel32.dll has SRW lock functions and use them, or pthread_rwlock_t as a backup 21:43:54 what % of Windows users run Monero on Windows 7 ? 21:44:38 no idea, most should be on at least 8 by now, 10 is prob common 21:46:07 https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide/ 21:46:09 I've just checked how libuv does it, and they just use SRW lock functions. I guess libuv dropped Windows 7 support already. 21:47:30 should never use pthread APIs on windows, they're just emulated on top of win32 APIs 21:47:46 wait, this says windows 7 supports it: https://stackoverflow.com/questions/13206414/why-slim-reader-writer-exclusive-lock-outperformance-the-shared-one 21:47:51 and in various versions of gcc runtime they were broken 21:48:16 I think Microsoft are just wrong in their own docs 21:48:45 sure, I can change back to #ifdef _WIN32, but then there's an issue with i686 win build 21:49:57 https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-acquiresrwlockshared 21:50:06 yeah the doc says it's in the header file as of win7 21:50:15 changed back: https://github.com/SChernykh/monero/commit/daae9884a5c005957112ecc67567ae0a28c4ddd0 21:50:35 oh, I know why they say Minimum supported client Windows Vista 21:50:47 because they dropped Windows 7 and don't support it anymore, lol 21:51:02 heh 21:51:31 search & replace changed 7 to Vista in one place in docs, but not in another (header file as of win7) 21:51:37 why aren't the rest of the SRW functions coming up undefined? 21:51:46 they all come up as undefined 21:51:51 ah ok 21:52:10 isn't vista older than win7? 21:52:28 https://paste.debian.net/hidden/95753a29/ 21:52:35 Vista came out after win7 21:53:57 linking only fails on i686, not x86-64? 21:54:03 yes 21:54:11 sounds more like mingw is missing the 32bit import library 21:54:28 it's kernel32.dll functions, how can it miss it 21:54:40 or maybe it includes very old kernel32 lib 21:54:51 it still needs a libfoo.a import library 21:55:30 the import library is what tells the linker that it's a DLL reference 21:57:31 https://github.com/meganz/mingw-std-threads/issues/58 21:57:38 vista is older 21:57:45 came right after xp 21:58:34 huh 21:58:39 Mandela effect, lol 21:59:28 no idea what to fix here: https://github.com/monero-project/monero/blob/master/.github/workflows/depends.yml#L97 21:59:47 x86_64-w64-mingw32 builds just fine 22:00:53 it's in CMakeLists.txt 22:01:02 -DWINVER=0x0501 22:01:44 0501, isn't it Windows XP? 22:01:49 yeah 22:02:00 maybe we either delete it entirely, or just bump it up 22:02:00 that explains it 22:02:53 I'll change it to 0x0601 (Windows 7) 22:03:05 or no, I need to find the number for Vista 22:03:34 https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170 22:03:43 0x0600 22:05:07 yeah should be ok 22:05:38 windowsxp 0.4% market share :P 22:07:43 all right, the final one for today https://github.com/SChernykh/monero/commit/ff58dbe625472e423bd71e265f5736f3f148e4c3 22:10:22 ok. for future, you really should use postincrement in hash2hex. it makes a 20% perf difference 22:10:25 https://twitter.com/hyc_symas/status/1600058640970285056 22:11:10 that's with gcc -O2. the optimizer can't fix that for you 22:11:32 that's different code in that tweet 22:11:44 the for loop in hash2hex will just use a register 22:12:10 will it optimize i*2+0 ? 22:12:39 definitely 22:12:44 to some sort of LEA instruction 22:15:20 most likely it will also unroll the loop 2x or 4x, modern compilers are good at this kind of loop of fixed size 22:16:12 also, this function is like 0.1% of CPU time of the minfo that prints this hex hash, lol 22:48:53 i686-w64-mingw32 build fine this time