do we want to merge 226 + 227 and tag v1.1.11?

heh I was wondering why the benchmark still said 1.1.8 when I ran it

that sort of thing ought to be automated with git somehow. oh well

I don't see anything wrong with merging those 2

just a bit of a shame going thru all that for no actual gains

sech1: did anyone using xmrig ever see a perf difference using that pthread_jit API?

at least Apple recommends to use pthread_jit_write_protect_np, will check on my ARM Mac if it makes a difference

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

not a difference we actually care about\

and the code isn't calling sys_icache_invalidate

we use gcc's __builtin__clear_cache instead

yeah. I wonder why wow has git.wownero.com/wownero/RandomX/com…e9e331487413199361407caee4376d9d804 instead.

don't remember the details, but I remember looking into all this

it was closed

heh, linked ticket discussion xmrig/xmrig #2060#issuecomment-767365078

that pretty much sums up what we're seeing

no perf gain... right now anyway

hm, I never saw this before xmrig/xmrig #2060#issuecomment-790647208

using the mach APIs directly instead of posix mmap, to get larger page support

doesn't sound too promising

ugh

>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

fragmentation is an issue on linux too, but usually if you reserve at boot time you're good to go

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.

huh, the flags that can be used are defined in /usr/include/mach/vm_statistics.h

yeah, odd place for them

superpages are allowed to be used in user-space

yeah odd juming through hoops to get to the doc on these flags

this guy claimed xmrig already got it working tevador/RandomX #196#issuecomment-845397466

but I don't see it in the xmrig source or git logs

I see 2MB superpages for intel

unless they redefined the flag for arm

nope 6b21a51a2fb4aa8c476ed364db8808a25e1bf517

300 MH wooo

I just received an offer for an ARM tvbox with Cortex A35 cores. the lowest power 64bit ARM cores\

has anyone benchmarked these, compared to A53 or A55?

Amlogic S905W2, 4GB RAM $26.50

A55

hmm, however

I only landed 104H/s

others seem to have 530h/s :| which I wouldn't mind getting myself :P

xmrig.com/benchmark?vendor=other I trust that A55 is part of another processor

need to compare single-thread results since you have no idea how many cores were used

interesting that A55 beats A57

clock rates must be too different

went through to try out the tvbox in the bedroom

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

best I could get from single threads was 30h/s

this benchmark table kinda sucks since it doesn't list clockrate with CPU name

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

gingeropolous: this says p2pool is #4, not #3 miningpoolstats.stream/monero

nanopool hr fluctuaes as they have 1 huge miner that mines for about 10-12hrs a day

ah

*fluctuates

also, what's this other p2pool.io at #19?

it's a pool someone set up for small miners, those that like getting shares even though the bottom line is the same

#p2pool-mini

ah

a bunch of pools with only 1 miner. solo mining thru a pool server :P

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

you can just connect two p2pool instances to your monerod

it will receive blocks from both

nice