Is there some benchmarks of some realistic use cases out there which shows that instruction memory bandwidth can have a significant impact on performance?

(on modern common CPUs ofc)

What does "instruction memory bandwidth" mean? Is it the overhead of reading instruction bytes into the CPU from memory?

Unrolling loops, and very long sections of code without branches, can render the caches useless. Caches are only useful when the data is read more than once, so the CPU is always reading from DRAM. I imagine that will create huge slowdowns. AKA cache thrashing.

I meant real life benchmarks which show a significant speep impact of code density for modern ISAs.

Is that even a thing?

It probably is, but the term "code density" needs to be explained more. Does it mean always choosing the shortest set of instructions to complete a task (i.e. code golf)?

I'm confused as well. "code density" seems like you want to benchmark the decoder. Compiled code isn't very dense. Size optimized code can be very dense.

Usually what you want to do is pick some part of the pipeline you want to test and then design or search for a test that does that -- it probably exists.

It translates to this question: On modern CPU, can memory bandwidth can be an issue for feeding instructions to the CPU? That in real life use cases.

Isn't the first reply the answer? If not then there needs to be more clarity on exactly what is meant to be measured and what criteria are used to decide what is an issue.

Basically, the CPU stalls because it cannot load from memory fast enough the machine instructions, that in real life use cases.

(risc-v and arm have "compressed" and "thumb" machine instructions, but I am really not convince it makes a performance difference on non-niche hardware)

Yes. Initialization code executes only once and pollutes the cache. The processor is _very_ good at predicting the next cache line needed for the instruction cache though. One could make that prediction more difficult and the initialization code much larger. Did you know that the Collatz (3x+1) trajectories are unpredictable but always reach one (exit condition)? ... fill a large piece of memory with these cache lines (the processor does not know they are the same). Put numbers into EAX and call to a cache line. I'm sure there are many techniques to do the same thing. Obviously, you'll need to fill enough cache lines to cover the Collatz trajectories you're using. Also you'll need the trajectory length to exceed your cache size divided by 64.

Edit: actually, the trajectories seem too sparse for a given bit length - a more complex attenuation of the signal would be needed, or multiple trajectories is easier.

ARM Thumb (16-bit) instructions are generally slower than the full length 32-bit instructions for a given task. Thumb is more constrained and requires more instructions to complete a task. Thumb wasn't designed for performance though, it was intended for memory constrained systems. So any performance comparison is flawed because it was never the intent to be a performance advantage.

x86 has single byte instructions, but a single byte can only encode a small amount of detail, and thus those instructions are limited in scope. Adding more bytes gives more expressibility, reducing instruction counts, but increases byte counts. There is a trade-off. Where should that trade-off be made? Depends upon the task.

That is a conjecture, not a proven result. If anyone finds a counterexample they will be famous.

... we're probably safe for the range needed in this benchmark.
(Until the processor manufacturer starts copying benchmark methodologies.)

I am reminded of the Itanium EPIC instruction encoding: 128 bits per "bundle".

It was very powerful and could potentially be quite compact. But it turned out to be too complex and too hard for the compilers to make good code.

Maybe 32-bits/instruction is the sweet spot? Many RISC encodings use 32-bits.

For non-performance applications the field is much more diverse. Especially the older Z80, 6502, etc. and the current PIC (8, 10, 12, 14, 16 bit) and AVR (16 bit).

So, this is what I expected, those benchmarks do not exist, memory bandwidth is hardly a thing while dealing with CPU machine instructions.

While I am thinking of it, what about the memory alignment of the machine instruction fetch window? Because, if I am not too much mistaken, modern CPUs are using this instruction fetch window for their own optimizations (branch prediction, etc). Maybe it is worth a forum thread on its own as it is what matters in the end?

Benchmarks are useless anyway, so I don't think it matters much.