AMD Ryzen has issues with high frequency RAM! - Fix will come in 1-2 months

Tomsen · March 12, 2017

On 3/3/2017 at 10:06 PM, Dabombinable said:

I/O bound would mean that the FSB is causing the bottleneck not the CPU. If the CPU wasn't the bottleneck you wouldn't see a performance increase, eg playing some games at 4K which would have a CPU bottleneck at 1080p.

Well, the FSB *could* be the bottleneck, it could be many things. It could simply be the latency of sending/receiving data from off-die components.

Your example is flawed. I would imagine that the game is running some sort of loop for each frame, where is might do some physic calculation, adjust player/object location, etc.

Example:

Each of these function will have a number of I/O request to system memory. We keep it simple and call it 5 I/O request to system memory per frame. With 60 FPS you will have 300 I/O request. At 120 FPS you will have 600 I/O request to system memory.

What you are failing to see, is that I/O request is a basic part of the CPU. You can't really do any processing without any input or output.

On 3/3/2017 at 11:35 PM, MageTank said:

The discussion was never "CPU Bound". Someone said "Anything that is CPU intensive, benefits from faster ram" or something along those lines. You clarified that it was due to CPU I/O, I simply said his first part about faster ram mattering for gaming being true. Then we both started arguing semantics about "absolute truths" and "vast majorities" and ended up here.

As for how I'd like you to prove it, I don't know. I made that perfectly clear when I said "I agree with you that it's an I/O problem, I just can't prove it". It's why I use an all-encompassing blanket term. Easier for people to understand, and requires less explanation on my part. Win-Win. It fits the description of a CPU I/O problem, almost perfectly:

I just don't understand enough about the design of modern CPU's to know if such limitations still exist, and are the source of the problems we see solved by faster memory. CPU Overhead (which includes this I/O issue) is vague, but it basically means something on the CPU side of things (which, memory is on the CPU side) is holding the GPU back. Is it perfect? Not by any means, but it still conveys the intent of our message. If you have high CPU overhead, faster memory might be of aid. If faster memory doesn't help, OC the CPU as hard as you can and try again. Funny thing is, slow CPU's can bottleneck fast ram (G4400 vs my Samsung B-Die for example).

Either way, I'll concede. You clearly believe in the "faster ram helps" cause, and that's good enough for me. Who knows, maybe in the future you will be able to educate me on this I/O thing and we will finally be able to tell people "why" faster ram helps? lol.

I/O has and probably always will be the biggest limiting factor in CPU performance. It is down to the basic fact that you can't do any CPU operation without any I/O. If I tell you to subtract two numbers, you can't possible calculate the result without knowing the operands (the very data you will be subtracting), and you wouldn't be able to tell me either.

There is a reason we dedicate over half the CPU die on components to either lower or eliminate the I/O penalty. There are of course also implementations in the CPU core themselves like branch-predictor, Out-of-Order engine, speculative execution/fetching (fetching the instruction/operands before actually being requested), context switching, etc etc. Do note, that neither of those implementation completely fixes it, the issue is very much still there. It is probably the reason why we haven't progressed much further in IPC.

In regards to how faster memory might help, it is down to two things: More bandwidth *AND* lower latency. Even high bandwidth memory that have higher CAS latency, might actually have lower real time latency (since CAS is measured in clock-cycles). To demonstrate using crucial data: http://www.crucial.com/usa/en/memory-performance-speed-latency

So imagine this *very* simple example. You have 100 instructions that needs to write each of their result to system memory in order before starting to execute the next instruction. An instruction might take around ~1ns to complete, but the latency to system memory might be ~100ns. So you have a 100ns latency between each of the 100 instructions. The CPU will idle for 99ns between each instruction.

To categorize it on the CPU side is kinda silly. Since the CPU is the host processor, every component is on the CPU side. I made the example previously that if we change the bottleneck from system memory to storage or networking, it would be even more silly to say that the CPU is the bottleneck, wouldn't you agree?

Jito463 · March 30, 2017

On 3/3/2017 at 3:06 PM, Dabombinable said:

I/O bound would mean that the FSB is causing the bottleneck not the CPU. If the CPU wasn't the bottleneck you wouldn't see a performance increase, eg playing some games at 4K which would have a CPU bottleneck at 1080p.

AMD hasn't had a Front-Side Bus since the Athlon 64's were introduced.