I think the whole dialog here is more like “how can we tune parameters to align better with new incoming CPU architecture”

for example tuning towards newer AMD architectures, afaik similar to what was done years ago for initial RandomX

performance of each section has changed relatively to each other over the past few years

<j​effro256:monero.social> If it's possible to answer this generally, will the additional AES instructions tip the scale in favor of AMD chips or Intel chips? AMD chips generally dominate in multi-threaded RandomX mining over Intel chips, and I wouldn't want to entrench that further.

the additional AES instructions will fill in the "free space" that exists on both Intel and AMD CPUs now

Ideally, they shouldn't change the hashrate at all, on any CPU with AES support

while hurting risc-v (without the aes) though

Future RISC-V chips will have AES though

We're tweaking for the future chips

fair enough, i'm surprised for the current ones to not have since they could be very useful for datacenters

RISC-V is yet to become a consumer product, and they'll _need_ AES and other crypto instructions for this (think of all https web pages)

and basically all internet tls encryption

i guess they are more on the AI crunching side of things, hence more weight on vector related instructions

and this L3 read delay (that I suggest to fill with AES) has only been getting bigger from Zen to Zen2 to Zen3 to Zen4

so clock-for-clock, Zen2 is slower than Zen, Zen3 is slower than Zen2 and Zen4 is slower than Zen3

so it shows one of the mistakes in RandomX design - it doesn't get faster for newer CPU generations

it only gets faster because they get higher clock speeds, but IPC (in RandomX instructions) gets lower

Should it have a hashrate impact on ARM ?

I guess, rather a power efficiency impact.

ARM also has cache and cache read delay

if AES takes more time on ARM, it could impact hashrate

"<sech1> so it shows one of the mistakes in RandomX design - it doesn't get faster for newer CPU generations" <--- seems like being able to get decent hashrate out of older hardware also has upsides though

but yeah generally it seems like it's a hard problem to anticipate CPU changes years in advance

yes, but when Zen3 gets 10-20% advantage over Zen2 in all tests, but is a bit slower on RandomX, it's a sign

*slower at the same clock speed

speaking personally I'd love for my Zen3 to be more competitive :D

I think I see waht you're getting at though

<p​olar9669:matrix.org> Does changing PoW like this mean it would act as a deterrent to anyone buying CPUs, which might become less efficient in the future due to Monero's ability to change PoW at any time?

We already kicked all the GPUs off so people should already know what's up --- good thing about CPU and GPU vs ASIC is their resale value is relatively unrelated to Monero's PoW

like honestly I wouldn't tell anyone to buy CPUs *just* for mining XMR to begin with

I already do for sure :D

<p​olar9669:matrix.org> So we don't encourage people to invest in any type of cpu mining setups, and if they do, they should be prepared to sell them. In the case of ASICs, they were essentially obsolete upon arrival.

<e​ndor00:matrix.org> If cpus are the only type of usable hardware, then there must be one that will be more efficient

<e​ndor00:matrix.org> And since they're cpus, they're still (re)usable for other purposes, if the mining efficiency were to somehow change in case of an algo tweak

and by the logic of things, it should be a newer CPU model

the most profitable CPU mining setup is one you give non-mining jobs, especially if it's a computer that would run 24/7 regardless. it's simply hard for dedicated mining setups to compete in terms of both capital outlay and energy use

i.e. a server mining on extra cycles -- would I get a *nicer* CPU than otherwise, because I plan to also mine, sure, but some of that capital and operating cost is effectively covered by whatever other activities I'm using it for

moneromooo: a lot of benchmarking sites are routinely testing randomx these days

Interesting. That should add pressure to manufacturers to keep these numbers decent if they think readers pay attention to that...

I'm surprised it happened more than occasionally though.

it's part of GeekBench 5 and newer, I think

other serious sites like servethehome: "We recently started using Monero mining in our data center lab for a burn-in application."

More AES will be more burn-in hehehe

a lot of sites that used to use Prime95 for burn-in now use randomx. it just does a more thorough job of exercising CPU components

RandomX is more sensitive to FCLK instability (memory controller)

does that make it more likely to crash on bleeding edge overclocks?

yes, but I think Prime95 is more sensitive to CPU instability, based on my tests

RandomX is more about memory and memory controller testing

Although, testmem5 with anta777 extreme profile is better at detecting memory errors

But RandomX is best at detecting FCLK instability

Basically, you need to run many different tests to check everything. Prome95, testmem5 and XMRig are my tools of choice

Prime95 in stress test (blend) for 12-24 hours

testmem5 (anta777 extreme) 10 iterations (usually takes 6 hours)

and then XMRig 24/7

xmrig 24/7 is production, not test :P