I wonder if DDR5 will be fast enough to compensate for the slower latency (or maybe they improved latency this time?)
To be honest I didn't felt yet any need to move off my current machine, I would only upgrade its GPU, but I can't do that because I can't afford a new GPU AND a new Monitor (I use a CRT monitor with VGA cable... it is a very good monitor so no reason to replace it, but newer GPUs don't support it).
Core-to-RAM latency is in the neighborhood of 50 ns (well-tuned Intel system with low-latency memory) to ~80 ns (bottom-of-the-barrel system). At propagation speed, that's about 10 meters. A big chunk of this latency is internal to the CPU (so is not influenced by distance to the memory at all), another big chunk is the inherent slowness of accessing a DRAM array (10+ ns, independent of the location of the memory).
It's worth pointing out how little this has changed over the past decades. A 2006 AMD CPU is 100 % competitive in regards to memory latency with Intel's 2020 flagship desktop CPU.
AFAIK ddr4 having higher latency than ddr3 is a myth. It has a higher cl number, but that's measured in cycles, so the higher cl number of ddr4 is compensated by its higher clocks. The actual latency (measured in nanoseconds) is about the same, or slightly lower in ddr4 than ddr3.
https://www.anandtech.com/show/16143/insights-into-ddr5-subt...
[1] https://www.eurogamer.net/articles/digitalfoundry-2019-moder...
A point not mentioned there but that is a major reason for me to use CRT: Contrast.
The contrast in most flat screens I tried is just terrible, a classic example I use is trying to play Superhot and then watch Game of Thrones right after... Superhot was everything white, so I fiddled with the controls until it was playable.
Then Game of Thrones everything was black. So I fixed it... then went back to Superhot and everything was white again.
With CRT after I adjusted it, I don't need to adjust anymore.
PS4 was an x86 CPU + AMD GCN GPU.
A huge amount of games will be portable from the get-go. GCN and RDNA have extremely similar assembly languages.
The only major assembly language change from GCN -> RDNA is DPP / cross-lane operations (kinda like pshufb from x86). But I'm not even sure if the PS4 had those instructions.
Native BC would be
1. It runs native hardware (PS2 EE on Early PS3) 2. It runs without updates required (PS2 running inside emulator on later PS3)
This requires actual updates by the dev for individual games to work
> The only major assembly language change from GCN -> RDNA is DPP / cross-lane operations (kinda like pshufb from x86). But I'm not even sure if the PS4 had those instructions.
Yeah, it didn't. AFAIK, they were added in GCN 3, while the PS4 is GCN 1.1.
I'd be surprised if this fact was true.
GCN 1.0 and GCN 1.2 aren't even binary compatible. Opcode 0x1 is "ReadLane" in GCN 1.0, but is "Add F32" in GCN 1.2.
https://github.com/CLRX/CLRX-mirror/wiki/GcnInstrsVop2
Vop2 are the "2-source / 1-destination" instruction format. You can see from the table that GCN 1.0 and GCN 1.2 don't even line up at all.
It wouldn't be hard to compile GCN 1.0 into GCN 1.2 instructions, but it wouldn't be binary-compatible, just assembly-language compatible (like 8080 -> 8086).
--------
Some other facts:
* RDNA is Wave32 native. Wave64 compatibility is available though, so that should mostly work for backwards compatibility (aside from DPP, which you do point out may not exist in PS4)
* S_WAITCNT ("wait for memory" instruction) has grossly changed in RDNA. In GCN, waiting for VM_CNT(0) will wait on loads and stores. But VM_CNT(0) only waits for loads on RDNA.
You need to change every S_WAITCNT VM_CNT(0) (GCN) into S_WAITCNT VM_CNT(0), followed by a new S_WAITCNT_VSCNT 0 instruction (wait for 0 outstanding loads, THEN wait for 0 outstanding stores).
This isn't "binary compatible", but if you just inserted one instruction on every GCN S_WAITCNT, you'd get the proper behavior in RDNA.
-----
I'm seeing GCN -> RDNA as a "mostly easy compile" between the assembly languages. But it doesn't seem binary compatible to me. I wouldn't be surprised if there were one or two issues that popped up however.
Also factor in that it usually takes a few years until the full potential of a platform it tapped, so the PS4 in it's prime days for games.
Although, realistically, it'll be a few months into next year before I actually get one.
Worst case, creditors cant take experiences from you, nor would they bother with most consumer goods.
I’m wanting to stay eligible for low rate mortgages or leases, and thats the priority but yolo. More motivation to make more before it becomes a problem, the end.
All that said, I do see them somehow screwing it up.
Switching between games is a non-trivial (yeah yeah mock me, 1st world problems) thing on the ps4 in that the active game must be quit first, then the new loaded. You may not be on a suitable spot to quit either, far from save point. On ps5 (or xsx) it's supposedly a very quick alt-tab kind of thing.
So far, I'm kind of happy in secret that the rest of the family prefers the Nintendo :)
The after purchase testing was even better than expected. i7 920 compiled a specific compilation unit in 14 seconds. 3900x in 3.5 seconds. And that was before any tuning, I had done some bios tuning for i7 920, while 3900x I just limited the power to make it quieter. The IPC is more than double, the larger caches are probably the thing that pushes IPC beyond expectations. (I got more cores to improve scaling of multithreaded code.) Both times were recompilations where there was enough ram to have all the files cached and the the folders used where on ssd:s with modern CPU used nvme and older one SATA. Even if the nvme matters that upgrade wouldn't of been possible without getting modern MB. The make system was make, and what I used was LLVM tutorial code in single file that included many LLVM headers. The software wasn't upgraded between those runs, just moved disks from old system to new system and copied the data.
I did look before the purchase if there was IPC improvements that would of made more sense to buy new than buy some Westmere 6 core to upgrade my system. Results made it clear to me that getting any cheap new CPU would of been preferable over wasting time with getting the westmere. The IPC improvements for compilation were way higher than average IPC improvements.
But even sandy bridge was weak enough in the benchmarks that it would of made sense to upgrade from that. Before purchase I just looked from phoronix benchmarks/open benchmarking database a compilation benchmark that had worst CPU scaling for more cores and used that as approximation for single threaded compilation.
My own results were much larger than what I assumed it would of been based on comparing the sandy bridge to modern CPU:s and then multiplying that with clock speed advantage and IPC advantage of sandy bridge vs i7 920.
Oh, when I got i7 920 I decided not to upgrade until I got 8 cores. Then it was AVX-512 happened I knew I must have that so that I could play around optimizing code with it, Intel just could get it's 10nm very soon so that I could get those 8 core AVX-512 parts in reasonable price and power envelope. I just did the math, and realized wasted time because slow CPU would cost me more over next 2 years than upgrading.
Improving CPU:s has become harder simply because all the easier things have been done, and cost of improving one metric often causes worsening another thing slightly.
edit: Just to add, it isn't impossible to improve, but it's just has become harder. And this knowledge was part of reason why until I saw actual benchmarks I wasn't too interested in upgrading. I just found out the one thing I cared had gotten much better during that period.