271–280 of 355 posts
Earlier quoted context omitted.
This is coming from an insane demand spike, not some nefarious plot by the RAM manufacturers.
> This is coming from an insane demand spike, not some nefarious plot by the RAM manufacturers. Something something, 2000 dot-com bubble, something
Earlier quoted context omitted.
RAM production is highly inelastic and controlled by an oligopoly. They have little desire to increase production considering the lead time and the risk that the AI demand might be transient. They actively prefer keeping confortable margins than competing between each other. They have already been condemned for active collusion in the past. New actors from China could shake things up a bit but the geopolitical situat…
They are increasing production as fast as they can (which is not fast at all, it's more like slowly steering a huge ship towards the correct direction) because current prices are too high even when accounting for the historical oligopoly dynamics. They can easily increase their collective profits by making more.
Earlier quoted context omitted.
Out of curiosity, why has there not been a slight paradigm shift in modern system programming languages to expose more control over the caches?
Same as the failure of Itanium VLIW instructions: you don't actually want to force the decision of what is in the cache back to compile time, when the relevant information is better available at runtime. Also, additional information on instructions costs instruction bandwidth and I-cache.
I guess this is one place where it seems possible to allow for compiler annotations without disabling the default heuristics so you could maybe get the best of both.
Earlier quoted context omitted.
> you don't actually want to force the decision of what is in the cache back to compile time, when the relevant information is better available at runtime That is very context-dependent. In high-performance code having explicit control over caches can be very beneficial. CUDA and similar give you that ability and it is used extensively. Now, for general "I wrote some code and want the hardware to run it fast with lit…
x86 provides this control with non-temporal load/store instructions.
I had my formative years in programming when memory usage was something you still worried about as a programmer. And then memory expanded so much that all kinds of “optimal” patterns for programming just become nearly irrelevant. Will we start to actually consider this in software solutions again as a result?
I doubt it. I predict in a few years, maybe sooner, one/some of the AI companies buying up the supply will either have achieved their goal or collapsed, and then the market will be flooded with a glut of memory driving prices low again. Or, conversely, the demand stays high for a sustained period of time and the suppliers just increase supply. There's no hard bill of materials/technical reasons for the memory prices…
Earlier quoted context omitted.
Isn't that literally every modern OS, always, unless you tell it to act differently?
Yes - I didn't mean to imply it was only one of the OSes. Further up the comments people were talking about how memory efficiency is now more important but I was trying to make the point that with compression and virtual memory it still doesn't matter all that much even if memory is double the price.
Of course compression being now computationally cheap also helps.
Earlier quoted context omitted.
I've actively started to use outlook and teams through chrome to free up some of my ram, easily saves 3-4gb. It's gotten ridiculous how much ram basic tools are using, leaving nothing for doing actually real work
Every app ships with its own isolated web browser now. That idea needs to die. Back to native apps without bloated toolkits!
Earlier quoted context omitted.
Agree that the whiteboard thing is often not applicable but it's so nice when a developer has efficient code if only because it indicates that they know what's going on and also that there are fewer bugs and other bottlenecks in the system.
Those bugs don’t come from using the wrong algorithm, they come from not understanding the business case of what you’re writing. Most performance issues in the real world for most cases don’t have anything to do with the code. It’s networking, databases, etc. Your login isn’t slow because the developer couldn’t do leetcode
I had my formative years in programming when memory usage was something you still worried about as a programmer. And then memory expanded so much that all kinds of “optimal” patterns for programming just become nearly irrelevant. Will we start to actually consider this in software solutions again as a result?
I do embedded Linux and ram usage is a major concern, same for other embedded applications.
I’m partying like it’s the 90s, on a 32-bit processor and a couple hundred MB of ram.
I had my formative years in programming when memory usage was something you still worried about as a programmer. And then memory expanded so much that all kinds of “optimal” patterns for programming just become nearly irrelevant. Will we start to actually consider this in software solutions again as a result?