If you actually care about performance you should be generating batches of output and pulling entropy out of it, not invoking the PRNG every time you need a random byte. The icache and dcache impact of running all that prng code is going to eat into the performance of your actual software in a way that microbenchmarks won't show. So the need to do that with chacha isn't necessarily a problem, it may be pushing you towards a better design.

Dcache impact? Of accessing the state which, for a non-cryptographically-secure PRNG, is often 128 bits? I'm not seeing it. Even CSPRNGs don't usually have state that's all that much larger. Surely there would be much higher dcache impact from storing and loading the batches of output. On the other hand, I can buy icache, along with function call overhead and lack of parallelism...

Depends on the algorithm, I suppose? Many algorithms that consume randomness in a way that is performance sensitive, like audio or image synthesis, are going to be processing streams of data and in that context being able to just stream random bits out of a cache line and into registers and through operations without making a bunch of calls is going to produce some advantages, even if a modern out of order processor can hide a lot of that. TBH I doubt the function call overhead even matters so much as the overall structure being something that will approach the maximum throughput of your hardware.

It's a big advantage that the internal state of some PRNGs is very small, but you're still mutating the internal state, which means now you're creating dependency chains and dirtying a cache line, etc. Someone who's actually built chips before would know far better than me whether all of that adds up to a 1% hit to throughput or a 10% hit, though.

MCG (like pcg64_fast) is like a single 128-bit mul and a mask. There’s not a lot of icache impact.