I see a lot of folks here saying they wouldn't know what to do with this much memory, but I can say as someone who was able to successfully use RAM disks in the past, that this would be /amazing/ on a desktop doing typical desktop tasks, including things like gaming.
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.
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.
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.
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.
> 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.
I mean, it's hard to keep up with a NVMe as it is.
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.
Only if everything is already in 100% usable condition.
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.
You can do the same with your whole OS. With Linux at least. And some distros which enable that. Boot it from USB with a parameter (often via Menu) like "toram", and be done with it.
Even installing or deinstalling software, customizing it to your needs and likes, and remaster that in RAM to be rewritten into your custom boot-image, so you won't have to do that again and again in case of restart or the occasional kernel-updates. That is working for me, lazily reaching uptimes of about four months with no crashes in between.
Here’s something I’ve been wondering. Once an application lives in RAM in a RAM disk, does it have to be duplicated into a working area of the RAM or can it be manipulated directly? Is the file system-RAM dichotomy a historical anachronism at this point?
Yes because processes are not mapped 1-to-1 to their executable file format. Have a look at this video[0] which explains the structure of an ELF file (the binary format used for executable files in many OSes). The ELF structure basically describes how the process memory should be initialize with data and code.
Yes, usually it still most be copied, because on-disk data structures are generally historical relics optimized for HDDs and therefore don't map directly to in-memory data structures. Loading from disk to RAM generally isn't just a copy operation, but requires some sort of processing for most applications.
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.
At least for games it makes a lot of sense IMHO to have the entire game including static data structs/tables and asset data (geometry, textures, audio, ...) "baked" into a single image that can be directly mapped into memory.
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 ;)
Yeah, thus "games" where exchanging data through standard file formats isn't important. There's at least one big downside though: modding wouldn't exactly be trivial with such monolithic game images.
Developers will always find ways to utilize all the resources on a single PC, that's why we need to use clusters of servers. The "don't know what to do with this much memory" argument has always been completely bonkers, by people who probably only use their PC for browsing social media.
I don't believe it, mostly because I used ramdisks back in 2012 when I had 64GB of RAM. They barely improved load times over SSDs, and for some games didn't improve it at all. With modern NVMe drives...I imagine no one can perceive the difference. Also ram disks are kind of a pain to deal with.
Yes, there's been numerous tools over the years. I don't know what the current best option is, but in the past I used DIMM Drive and SuperSpeed RAM Disk. I think these days SoftPerfect RAM Disk is probably a good option since the others are dead/gone, and SoftPerfect is still updating it's software.
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.