> which is why the crunch has lasted so long,
It's been like a year-ish...
And maybe 2027 is a truly optimistic relief on some level,
> a second wave comes in 2028–29, and a lot of that new capacity is aimed at HBM and server memory, so consumer DDR5 and GDDR will likely ease last.
'Consumer DDR5' has a pretty big set of knock-on effects though.
Unless you are working at a 'tech' company, the norm is that even developer machines will be constrained on memory usage for a given workload[0][1]. IOW companies trying to keep procurement in check wind up looking at procurement cost vs lost productivity.
[0] - Modern infosec and corporate software, at least where I'm at, seems to be vaguely more efficient than electron apps, IOW I can reboot, open teams and my IDE, after 4GBish of my IDE and 1GB of a fresh Teams instance I'm already around 16 of 32GB.
[1] - I had to fight hard to get 32GB as a developer baseline at my org. They wanted 16GB. Ironically the JVM based devs get 64GB but still have slowdown issues on biuld...
It's been like a year-ish...
And maybe 2027 is a truly optimistic relief on some level,
> a second wave comes in 2028–29, and a lot of that new capacity is aimed at HBM and server memory, so consumer DDR5 and GDDR will likely ease last.
'Consumer DDR5' has a pretty big set of knock-on effects though.
Unless you are working at a 'tech' company, the norm is that even developer machines will be constrained on memory usage for a given workload[0][1]. IOW companies trying to keep procurement in check wind up looking at procurement cost vs lost productivity.
[0] - Modern infosec and corporate software, at least where I'm at, seems to be vaguely more efficient than electron apps, IOW I can reboot, open teams and my IDE, after 4GBish of my IDE and 1GB of a fresh Teams instance I'm already around 16 of 32GB.
[1] - I had to fight hard to get 32GB as a developer baseline at my org. They wanted 16GB. Ironically the JVM based devs get 64GB but still have slowdown issues on biuld...