jberman[m]: is there an easy way to test the view tag speedup?

performance_tests?

I rebased onto master and got `monero/external/randomx/src/virtual_memory.cpp:118:2: error: use of undeclared identifier 'pthread_jit_write_protect_np' pthread_jit_write_protect_np(false);`. Anyone know what that's about?

are you building on a mac?

you prob need RandomX pr#226

yes mac

thanks I'll wait for this fix

yea it will be fixed before we tag a release

gitian build uses MacOS SDK 10.11. is that new enough to have this function defined?

guess I'll find out shortly. firing up a gitian build for mac

build finished, no complaints

hyc: 10.11 is ancient, but I'm not sure why it doesn't fail

is __APPLE__ defined when cross compiling?

yes, it has to be

looks like TARGET_OS_OSX doesn't exist in this SDK version, that's why it's working

it's not trying to use that pthread_jit stuff at all

so, gitian builds will keep worknig regardless. I guess that's a relief, even if it makes these last patches moot.

hyc: yea it seems it got added in 10.12 SDK

cool

yep TARGET_OS_OSX is not defined in 10.11

so yeah, gitian builds are fine regardless

even if maybe slower than necessary on newer macos machines

fine, if you don't want to support pthread_jit_write_protect_np

gittian really should use a later 10.x to avoid this sort of thing though

why? sounds like it's using lowest common denominator, and playing it safe

we still have users that use 10.11

don't see any reason to cut support for older macOS versions just to use pthread_jit_write_protect_np

particularly since it isn't making much performance difference on my measurements

did you guys see any big difference in x86-64 benchmarks?

10.12 will still run on 10.11

what do we gain from 10.12? nothing

The defines, to avoid this kind of thing in the first place

it has already been successfully avoided

well, that's moot. Sure for *only* gitian builds, not for building directly from source.

so again, unless any of you are seeing a big performance gain, sounds like a non-issue

it would be easier to use something like this catchorg/Catch2 #2140/files

instead of forcing everyone to upgrade their SDK

but it doesn't matter anyway

that works too

the defines did their job as-is. the _OSX symbol was missing, therefore we didn't try to use that API.

not if someone tried to build on 10.12+

so unless you can point to a missed performance gain, I see no point in pursuing this further

if we're only going to support gitian builds for macos from now on, then yes.

I take it neither of you saw any performance difference then

I don't have an ARM mac to test, sorry

I was asking about x86-64

I didn't see a performance gain on intel

Same

I saw no difference on my M1 mac

<selsta> "jberman: is there an easy way to..." <- I tested it with chain data by modifying `out_can_be_to_acc` to call `derive_view_tag` for every output, then checking if the result is equal to 0x01, and proceeding to derive the output key if so, and short-circuiting if not (I tested with different equalities, got the same results)

I'll share the code on this in a separate commit. was pretty hacky

and the performance tests should give a benchmark idea too (once I fix that UB issue), but chain data seemed to perform better for me

Could somebody review erciccione/monero-site #27? Adds the missing RPC methods up to v0.17.3 including RPC-Pay methods, to the docs on getmonero

jberman[m]: performance tests worked now termbin.com/cgnd