I like to grab RAM towards the end of the generation, so far it has been the best bang for my buck (for my personal computer). From the production estimates, looks like I'll jump into DDR5 at the end of 2023 or most likely 2024
Yeah, when DDR4 came out first, the early modules were easily outperformed by good DDR3 modules on every metric except power consumption. DDR5 will be king in a few years.
I have a 4690K and my RAM is a 32GB EVGA DDR3 ram that I suspect was made by hynix or the other manufacturer of fast rams, that runs at speed up to par with the slowest DDR4 but with DDR3 latency, it is very awesome.
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).
>that runs at speed up to par with the slowest DDR4 but with DDR3 latency, it is very awesome.
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.
I think that's what he's saying, that if the latency is equivalent on best ddr3 and lowest ddr4 and ddr3 is cheaper or you already own it maybe better to wait.
Latency is significantly impacted by the physical distance between RAM and CPU’s. Which combined with modern cache sizes means they get diminishing returns trying to minimize it and thus make different tradeoffs.
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.
10 meters one way = 5 meters round trip. Trace the longest physical path a signal travels from your CPU to a memory chip on the DIMM and back, it’s likely longer than you think. And yea on it’s own plenty of overhead, but everyone making latency tradeoffs bashing their design as part of a larger system with a single unavoidable limit.
Eurogamer did write a review about playing modern games on a (very good) CRT monitor [1]. It's better than any LCD and even OLED monitors according to them:
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.
Some of those last generation CRTs had amazing picture. I had one from 2003 or so that could do 2048x1564 with a picture better than anything you could get from an LCD until the late 2000s.
You may know this already, but if not - if you have others to share the console with (eg kids, partner), I think it'll be worth going for the '5 just from that perspective.
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 :)
Depends upon what you pay - certainly the second market will see a surge and drop in prices. If you can tech on top end 5 years later, it's not that bad and sure wallet friendly.
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.
I do not understand your argument as the parent post is saying the PS5 can play PS4 games. So the PS5 will also benefit from the great games coming on PS4. The prices of the games would be the same, you would benefit from the same experience of the devs developing on the PS4. The only disadvantage is that the PS5 will be pricer. And it will also be less ecological-friendly if you intend to buy an used PS4. But that's it.
I've seen a few people who ride one generation back and buy used. It means you can get the console incredibly cheap (and can choose the best/most reliable variant), have a huge catalogue of games to explore (which are also incredibly cheap), and already know which games are standout and which are misses. Doesn't work if you're into the latest multiplayer games though.
Should be, at the end of the day they are both just X86_64 systems. It isn't like the console generations of old where each one would used a specialized CPU usually designed specifically for that console. (The PS3 had to include a full PS2 chip for its compatibility layer)
All that said, I do see them somehow screwing it up.
But it doesn't have any games worth playing on it, whereas the ps4 has an established and extensive library that would take (me, at least) quite some time to get through. Probably long enough for the ps5 to become more purchasable than a steel Daytona, unlike now where it"s apparently extremely difficult to buy
For me, I'll get a PS5 for Demons' Souls alone. When you factor in upcoming games like the new Horizon Zero Dawn next year and the graphics-upgrades like Cyberpunk 2077, its definitely worth it.
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.
Not really. They plan to try to make "as many PS4 games BC as possible" which means they are actively porting games they deem worth porting, versus it being natively supported
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.
It's deeper than that, the shaders are _binary_ compatible.
> 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.
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.
Or it's _really_ close, but the systems are complex enough that they feel they need to QA/cert the games again even if the vast majority of games require no changes.
It would be silly for Sony to not support BC to at least PS4 games (if not PS3-2-1 through some sort of emulation) since Xbox Series X will have BC down to the first Xbox console.
I was planning on same thing, until I estimated how much faster modern PC was at single threaded compilation tasks compared to my old one, and how it impacted my productivity. I should of upgraded earlier.
I thought so also, but decade of small improvements do accumulate to a large number. Something like 20% improvement 4 times would be doubling the IPC, but single threaded compilation is where I got more than that.
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.
The i7 920 is a dozen years old (2008). No explanation required. I was thinking there wasn't much of an IPC increase over the last half dozen years or so, but there's absolutely been one over that long. Though really it's funny how little it's still increased - in 1996 we were just getting Pentiums at 150 MHz, and I don't think anyone would argue those are anywhere near comparable.
If we split the cycle time in two components, one is transistor and one is interconnect. Interconnect delay per length increases as much as the length decreases in each shrink. The transistor delay halves. That halving got transistor delay below the interconnection delay, so doubling that got huge improvements. Also for IPC there is diminishing returns, and easily available improvements got eaten early, and everyone is chasing diminishing returns. The Pentium PRO brought OoO and went from 2 to 3 decode and from 2 to 4 micro-ops/second. Core 2 went from 1 to 2 FP pipelines.
Everyone is hitting the same issues, O(n^2) power and die costs for some structures widening things, but smaller fraction of code getting improved by widening. But it isn't all, it also increases latency which is either lower clocks or increased branch missprediction penalty.
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.
I try to refresh when a new ram gen launches with a new socket. That gives me a good shot at long term upgradability. Waiting on zen 4 now for my next complete build.
You are very patient. I'm not sure about skipping this generation, because who knows when we will get ECC UDIMMs for AMD cpus. It could be late 22 or or even mid 23.
ECC on AMD seems quite hard in practice even though the CPU support isn't artificially limited like with Intel. Making sure the motherboard supports it is hard and then the RAM options are extremely limited and generally quite slow and expensive. Threadripper is maybe better but that's quite a jump in cost. It would be so nice to finally be able to assemble low-cost home servers and workstations with ECC but it remains a niche where you have to give up a lot to get it.
I've been waiting for DDR5, I knew it was coming and my PC runs the games I play just fine on DDR3. I do have a Thinkpad p51 that has Xeon/DDR4, so I didn't completely skip DDR4.