02:07:03 do we want to merge 226 + 227 and tag v1.1.11? 02:11:08 heh I was wondering why the benchmark still said 1.1.8 when I ran it 02:15:02 that sort of thing ought to be automated with git somehow. oh well 03:57:25 I don't see anything wrong with merging those 2 03:57:39 just a bit of a shame going thru all that for no actual gains 03:58:19 sech1: did anyone using xmrig ever see a perf difference using that pthread_jit API? 04:00:01 https://developer.apple.com/documentation/apple-silicon/porting-just-in-time-compilers-to-apple-silicon 04:04:11 at least Apple recommends to use pthread_jit_write_protect_np, will check on my ARM Mac if it makes a difference 04:08:21 I guess the main difference between this and the mprotect call is that this is supposed to only affect the current thread, while mprotect affects an entire process 04:08:35 not a difference we actually care about\ 04:10:54 and the code isn't calling sys_icache_invalidate 04:19:45 we use gcc's __builtin__clear_cache instead 04:22:23 yeah. I wonder why wow has https://git.wownero.com/wownero/RandomX/commit/4d940e9e331487413199361407caee4376d9d804 instead. 04:23:48 don't remember the details, but I remember looking into all this 04:24:04 https://github.com/tevador/RandomX/pull/197 04:24:08 it was closed 04:26:45 heh, linked ticket discussion https://github.com/xmrig/xmrig/issues/2060#issuecomment-767365078 04:28:55 that pretty much sums up what we're seeing 04:29:50 no perf gain... right now anyway 04:30:33 hm, I never saw this before https://github.com/xmrig/xmrig/issues/2060#issuecomment-790647208 04:30:57 using the mach APIs directly instead of posix mmap, to get larger page support 04:36:22 https://bugs.openjdk.java.net/browse/JDK-8233062?focusedCommentId=14343195 04:36:29 doesn't sound too promising 04:37:56 ugh 04:38:23 >Conveniently, for anonymous mmap memory, these superpage flags that would normally go to the mach_vm_map API, can also be passed into the file descriptor argument of mmap 04:38:29 fragmentation is an issue on linux too, but usually if you reserve at boot time you're good to go 04:39:06 talk about a hack: Conveniently, for anonymous mmap memory, these superpage flags that would normally go to the mach_vm_map API, can also be passed into the file descriptor argument of mmap. 04:50:32 huh, the flags that can be used are defined in /usr/include/mach/vm_statistics.h 04:50:54 yeah, odd place for them 04:50:57 superpages are allowed to be used in user-space 04:53:03 yeah odd juming through hoops to get to the doc on these flags 04:54:04 this guy claimed xmrig already got it working https://github.com/tevador/RandomX/issues/196#issuecomment-845397466 04:54:15 but I don't see it in the xmrig source or git logs 04:54:26 I see 2MB superpages for intel 04:54:36 unless they redefined the flag for arm 04:56:15 nope 6b21a51a2fb4aa8c476ed364db8808a25e1bf517 13:18:44 300 MH wooo 18:11:55 I just received an offer for an ARM tvbox with Cortex A35 cores. the lowest power 64bit ARM cores\ 18:12:11 has anyone benchmarked these, compared to A53 or A55? 18:12:49 Amlogic S905W2, 4GB RAM $26.50 18:13:43 A55 18:14:40 hmm, however 18:14:45 I only landed 104H/s 18:15:00 others seem to have 530h/s :| which I wouldn't mind getting myself :P 18:23:32 https://xmrig.com/benchmark?vendor=other I trust that A55 is part of another processor 18:26:32 need to compare single-thread results since you have no idea how many cores were used 18:27:29 interesting that A55 beats A57 18:27:42 clock rates must be too different 18:47:39 went through to try out the tvbox in the bedroom 18:48:39 unless sech1 loaded in some amazing armv8 improvements to 6.15.3 from 6.15.2 I'm assuming thats a processor with A55 cores available 18:48:58 best I could get from single threads was 30h/s 18:50:28 this benchmark table kinda sucks since it doesn't list clockrate with CPU name 18:50:48 in the obvious case that 6.15.3 does not automagically make an A55 code run faster, I'm still compiling the newer version :P 19:06:36 gingeropolous: this says p2pool is #4, not #3 https://miningpoolstats.stream/monero 19:07:41 nanopool hr fluctuaes as they have 1 huge miner that mines for about 10-12hrs a day 19:07:58 ah 19:07:59 *fluctuates 19:08:09 also, what's this other p2pool.io at #19? 19:08:58 it's a pool someone set up for small miners, those that like getting shares even though the bottom line is the same 19:09:16 #p2pool-mini 19:09:25 ah 19:10:02 a bunch of pools with only 1 miner. solo mining thru a pool server :P 19:58:56 would be dope to find a way to get the different p2pools to communicate with each other using their faster p2pool protocol for informing each other of new blocks 20:28:59 you can just connect two p2pool instances to your monerod 20:29:04 it will receive blocks from both 20:33:12 nice