Shelby still foaming at the mouth it seems

annoymint

is the guy still around?

he just commented tevador/RandomX #11#issuecomment-841842803

tromp replied too. I think tromp is forgetting that e.g. we require support of IEE754 rounding modes, specifically to keep edge cases in play

and shelby's comment that we don't make use of branch predictors is also false

the CPUs have them and will always use them - can't be turned off

"Or may possible to more deeply pipeline for certain permutations that might occur too infrequently in typical programs"

I guess that's a valid point if randomx programs where clearly more randoms than all other programs ran on CPUs, combined

So they'd optimize CPUs for all other actually-not-so-random programs in the world, hence loosing performance on randomx ^^

<\x> hyc: got me this last week imgur.com/a/xrNK6m2

<\x> intel's last 14nm+++ ULV chip

Anyway good hand-wavy wall of text, I missed that guy lol

<\x> the first and last 6c/12t ulv i think

lol

with a random distribution of instructions, that means occasionally a stream will be emitted that matches a CPU's optimization target

This random stream of instructions actually has frequencies of different instructions tuned to match real CPUs :D

also frequencies of memory reads/writes

:)

One worrying tendency is that Zen3 has lower IPC than Zen2 on RandomX due to slow L3 cache. RandomX didn't assume this (bigger, but slower cache)

xmrig has an optimization to prefetch L3 accesses too, but there's not much of computation to squeeze there. Maybe future RandomX tweak can address it.

But when I tested it on rx/arq (I think) with 256 KB scratchpad (L2 only), Zen3 had 4% better IPC.

So the general direction of CPU progress matches what RandomX was tuned for