02:00:36 I think the whole dialog here is more like “how can we tune parameters to align better with new incoming CPU architecture” 02:01:09 for example tuning towards newer AMD architectures, afaik similar to what was done years ago for initial RandomX 02:01:29 performance of each section has changed relatively to each other over the past few years 03:25:24 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. 06:40:37 the additional AES instructions will fill in the "free space" that exists on both Intel and AMD CPUs now 06:41:16 Ideally, they shouldn't change the hashrate at all, on any CPU with AES support 06:41:27 while hurting risc-v (without the aes) though 06:41:48 Future RISC-V chips will have AES though 06:41:54 We're tweaking for the future chips 06:42:52 fair enough, i'm surprised for the current ones to not have since they could be very useful for datacenters 06:43:03 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) 06:43:25 and basically all internet tls encryption 06:43:49 i guess they are more on the AI crunching side of things, hence more weight on vector related instructions 06:46:02 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 06:46:36 so clock-for-clock, Zen2 is slower than Zen, Zen3 is slower than Zen2 and Zen4 is slower than Zen3 06:47:11 so it shows one of the mistakes in RandomX design - it doesn't get faster for newer CPU generations 06:47:50 it only gets faster because they get higher clock speeds, but IPC (in RandomX instructions) gets lower 06:57:39 Should it have a hashrate impact on ARM ? 06:58:02 I guess, rather a power efficiency impact. 06:59:34 ARM also has cache and cache read delay 06:59:44 if AES takes more time on ARM, it could impact hashrate 13:55:27 " 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 13:56:08 but yeah generally it seems like it's a hard problem to anticipate CPU changes years in advance 13:56:49 yes, but when Zen3 gets 10-20% advantage over Zen2 in all tests, but is a bit slower on RandomX, it's a sign 13:57:01 *slower at the same clock speed 13:58:57 speaking personally I'd love for my Zen3 to be more competitive :D 13:59:06 I think I see waht you're getting at though 14:00:29 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? 14:01:28 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 14:01:47 like honestly I wouldn't tell anyone to buy CPUs *just* for mining XMR to begin with 14:02:24 * moneromooo dreams of a world where people routinely weigh randomx performance before buying a CPU... 14:02:35 I already do for sure :D 14:04:21 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. 14:11:09 If cpus are the only type of usable hardware, then there must be one that will be more efficient 14:12:01 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 14:12:15 and by the logic of things, it should be a newer CPU model 14:17:24 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 14:18:12 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 14:52:40 moneromooo: a lot of benchmarking sites are routinely testing randomx these days 15:01:24 Interesting. That should add pressure to manufacturers to keep these numbers decent if they think readers pay attention to that... 15:01:46 I'm surprised it happened more than occasionally though. 15:11:07 it's part of GeekBench 5 and newer, I think 15:14:18 https://cpu-benchmark.org/cpu/amd-ryzen-5-3500/ 15:14:52 other serious sites like servethehome: "We recently started using Monero mining in our data center lab for a burn-in application." 15:16:04 More AES will be more burn-in hehehe 15:16:29 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 15:17:42 RandomX is more sensitive to FCLK instability (memory controller) 15:18:48 does that make it more likely to crash on bleeding edge overclocks? 15:25:03 yes, but I think Prime95 is more sensitive to CPU instability, based on my tests 15:26:27 RandomX is more about memory and memory controller testing 15:27:13 Although, testmem5 with anta777 extreme profile is better at detecting memory errors 15:27:26 But RandomX is best at detecting FCLK instability 15:27:58 Basically, you need to run many different tests to check everything. Prome95, testmem5 and XMRig are my tools of choice 15:28:20 Prime95 in stress test (blend) for 12-24 hours 15:28:36 testmem5 (anta777 extreme) 10 iterations (usually takes 6 hours) 15:28:42 and then XMRig 24/7 15:44:36 xmrig 24/7 is production, not test :P