Samsung Reveals DDR5-7200 512GB RAM
tomshardware.com
tomshardware.com
Back when 32GB was a lot (about a decade ago), I had 32GB of RAM in my desktop and would take whatever game I was competitively focused on at that time and install it to a RAM disk which would be written out to SSD occasionally and loaded back from SSD on boot. Loading times were essentially non-existent since it became an in-memory copy. I was limited to games under 12GB in size requirements, which now a days is nothing. Most AAA titles are 200GB+ on disk.
With 1TB of RAM you could set aside 128GBish for use as normal memory and 850GB as a RAM disk you can use for copy-back installations. Combining this with the fastest available PCI-E 4.0 nVME SSDs, it would even be pleasant considering the "long" boot times. You could have a 1TB fast SSD set aside just as your copy-back target.
Even though SSDs have gotten much much faster than they were a decade ago, they're still slower than RAM. Obviously for server uses with databases there's a need, and large numbers of VMs / containers for density, but in a more desktop-oriented use case it's not that you "need" this much RAM, but you can certainly find really great ways to use it to make your life easier and put you to the next level of performance.
Intel was doing some interesting work with Optane in this area, using performant SSDs with large RAM caches as DIMMs, seen by the system as memory, but able to be controlled via drivers to act as disks. There's obviously a place at a certain point to blur the lines. The biggest challenge is RAM is not persistent, disk is persistent, and that implies many things both for data structures as well as for how we interact with it and what sort of constraints we can assume.
The nice thing about good RAM disk software is that it's a bit-for-bit representation in memory persisted to disk, which means at least once it's loaded into RAM any processing becomes your only real limiting factor for the copying required to load a file.
I don't think this would be true for linux. since linux's page cache is unified across all mounted file systems, and with linux's tmpfs using the page cache directly for storing files, it doesn't make much sense that it would need to copy files for use.
if you formatted and mounted some other filesystem into the ram, sure. but tmpfs should avoid any such issue.
You'll still need some "scratch space" for the dynamic game state (because you don't want to duplicate the entire image as savegame files), but for asset data I think it makes a lot of sense and could simplify and speed up asset "loading" dramatically.
PS: it would make even more sense to map most asset data directly into GPU memory, don't know how far off affordable 512 GB video cards are though ;)
Is there a tool that can do that?
They should just try to build an Open Street Map world map and they would dream of that much RAM!
You could run several electron apps at the same time.
You don't really need ram disks, you can preload things to cache[0] and it will work just as if it were a ramdisk.
[0] https://serverfault.com/questions/43383/caching-preloading-f...
A PCIe4 NVMe can read at around 7 GB/s.
You'll likely find that few applications can actually manage that in practice, because you have to do something with all that stuff: uncompress it, process it into various in-memory data structures, etc. You need a high end CPU to go along with it, as well as software written to do all that decoding in parallel. It may require planning ahead of time just to ensure that it's possible to uncompress data that fast on existing hardware.
Many programs and games aren't going to bother because it massively increases complexity and the benefit isn't a lot for many applications. Eg, having a game load a level in 1 second rather than 15 on a 16 core CPU -- that's neat, but you were going to stay in that level for half an hour anyway, and it's a potential source for bugs.
You're only likely to see code take good advantage of such hardware if it was especially made for it, like you have an enormous world with a very high detail level that can't be preloaded and the code relies on constantly streaming it.
For AAA titles this is pretty commonplace, with progressive loading to eliminate loading zones. The exception is MMOs and single-map multiplayer games (CoD, etc) which have a loading point which they also synchronize users.
For League of Legends, in particular, it was interesting back in the day because it shows you how long it takes each person to load, I'd always be first by a large margin with a RAM drive. Of course it didn't help since you had to wait for everyone to load before you started, but in single-player games it was a huge benefit, especially epic RPGs which had minimal loading zones.
Anything not specifically intended for that scenario will probably load data too slowly for a RAM disk to improve matters, and anything made for a NVMe is going to be made to stream data in real time where it won't make a noticeable difference.
Eg, if you have textures and need things like decoding the PNG/JPG, creating an instance of the Texture class and filling in the fields, re-encoding it into whatever format and resolution your video card wants... that's where you're going to lose a lot of the performance.
https://www.pcgamer.com/anthem-load-times-tested-hdd-vs-ssd-...
https://hardforum.com/threads/nvme-m-2-ram-drive-raid-sata-i...
Like you said about requiring a bunch of processing, DirectStorage[0] should be able to skip a lot of processing when loading from NVMe. I haven't read that DirectStorage works with RAM disks, but even if it was, there might not be a difference in load times between them. You'd be better off buying more NVMe than RAM, if game load times are your only use case for a RAM drive.
[0] https://devblogs.microsoft.com/directx/directstorage-is-comi...
Exactly. The reason why they don't shown any difference is because games are not optimised for it yet. PS5 and Xbox now set the baseline for storage standard there will be lots of work going into that.
And everything is f***ing FAST!1!! :-)
That said I have an 8GB version and it's so far handling what I need to do fine, but I'm not doing any heavy dev work on it.
You couldn’t use the machine for anything else when it was open; even my “very high end” workstation machine crawled to a halt.
No-one could possibly ever need more than 1TB of RAM.
[EDIT: this was a winking reference to Bill Gates' famously misattributed quip that "640kb ought to be enough for anyone". Truthfully I don't know what to do with 1TB of RAM either, but I'm sure there'll be something!]
But that doesn't mean there aren't others that may have different use cases.
My replacement PC (actually an Alienware laptop) will only have 64GB. I don't think I'll miss it.
I think choice of your chassis has more influence on performance of your PC than particular brand of RAM chips.
About the only choice you have is to decide whether to go ECC or non-ECC.
As all my loads are for development and learning purposes, I decided to save on RAM and buy non-ECC, which makes entire system much cheaper.
(Typical) servers however have no problem with memory latencies as long as you throw in more channels to compensate with bandwidth. They don't care if the primary task gets done asap they care that 1000 tasks can get done asap and that the db is all in ram.
HN: Go away, you aren't welcome here.
He never said that.
We are talking about somebody who's company has been guilty of corrupting, lying, insulting, patent trolling, vendor locking, user spying, monopoly abusing, etc.
Yet after years of PR, he is now regarded as a hero.
So it's not unreasonable to think maybe he said it and later decided to rewrite history.
Heck, Gates probably remembered the times where a framebuffer was discussed as a theoretical construct, that would be useful if only one could have enough memory to implement one! And at 320x200, that's 10% of your 640K.
Need is a tricky word, but it's easy to use 1 TB of RAM, and it'd be easy to use even more. In memory databases are great; it's been a while, but I've run some of those and in some cases, we'd have to partition because we ran out of ram and the boxes topped out at 1.5TB (newer platforms do more, but also there was a platform migration due to acquisition to small machines, so we had to change our strategy). On a desktop system, if you don't have anything better to do, you could always disk cache the whole disk; I suspect a filesystem designed to be fully loaded into ram could make different tradeoffs and get different results than just caching all of a traditional FS.
I believe Ethereum's ethash consensus also works this way, which is why there aren't Ethereum ASICs.
Even with how difficult, expensive, and hot GDDR6X is that was still preferable for Nvidia's consumer cards.
If it is being used as a RAM on the motherboard, I imagine they would need to redesign the motherboard layout to accommodate the power and bandwidth for RAM slot to support HBM. Or a possibly HBM stick get it own pin connectors for PSU to avoid motherboard redesign.
>Therefore, HBM provides at least an order of magnitude higher bandwidth than DDRx DRAM [15] at a lower power consumption (nearly 7pJ/bit as opposed to 25pJ/bit for a DDRx DRAM) with a smaller form factor [65].
https://people.inf.ethz.ch/omutlu/pub/HBM-undervolting_date2...
I forgot that HBM is stacked. I wonder if it a form factor issue? HBM is clearly "thick boy" than conventional DRAM. I imagine they need to make some room for the HBM modules including double-sided stick.
I've noticed that popular speeds and timings across RAM generations have tended to keep roughly similar 9-10ns latency. Going by that, DDR5-7200 kits should have CAS timings around 32-36.
From a high level overview DRAM latency has been the same and will stay the same for long time. Doubling the bandwidth, lower energy usage, double capacity all while staying with the same latency is about as good as it get for DRAM. You will need eDRAM to get lower latency. That is why we see the trend of an increase of cache size on CPU.
I had 512M in 2003~ which was more than enough until 2009 when max available memory was closer to 4G, but usually 2G even in the high end.
From 2009 to 2015 my personal memory consumption went from 512mb to 16G- which is a meteoric leap. I suspect that the only thing holding back developers from using more ram between 2015 and 2021 is the fact that intel basically capped the upper limit to 16G on laptops, and most developers are using laptops.
Needless to say, my productivity could be better...
With just a moderate background app stack (terminal, libre, slack) My Ubuntu system routinely comes to a crashing halt at ~40 Chrome tabs, but the 8 GB MacOS system seemingly can handle > 75 Safari tabs without even noticing with a much heavier app stack loaded, including slack, terminal and microsoft excel (I rarely bother to even exit apps on my Mac - on my linux system I'm always trimming to get RSS down)
The underlying operating system and applications (particularly the browser) make a huge difference. I always tell people that as long as they aren't doing AV editing or any type of numerical analysis on large matrices, VMs, etc... (and if they are, they already know they need more resources) that 8 GB on a Mac == 16 GB on a Linux system (It's actually far better based on my experience, but I like to be conservative). It is very much non intuitive, but the vast majority of people really don't need anything more than an 8GB Mac. The speedy SSD makes a big difference as well.
I can use it to log on to my work computer or just browse the web. But it really doesn't make sense to get a new computer with anything less than 8GB.