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.
I recently bought an M1 iMac, but mistakenly got the 8GB version instead of 16GB. It’s underpowered. My older, 64GB iMac screams by comparison, which is sad, considering how fast the M1 chip is. RAM is important.
Massive Google Sheets are the main memory hog for me… I suppose I could do work to make the sheets more efficient or move them into a better kind of database. But that would take effort.
Lol. That reminds me of the enormous Excel spreadsheets sent around Ubisoft for P&L reasons. I once had the mispleasure of using it, thank god Microsoft office is 64bit because that spreadsheet was gigabytes in size and multiples of that in memory.
You couldn’t use the machine for anything else when it was open; even my “very high end” workstation machine crawled to a halt.
The other day I was in an Apple Store and ran some basic tests on two MacBooks. One with 8Gb RAM, M1 chip and the other with 16Gb RAM, Intel Core i7 chip. I simultaneously ran on both machines a Python script that calculates a Fibonacci number non-recursively. The M1 performed significantly worse for any values entered. This surprised me, so I guessed that had something to do with RAM?
"Samsung's 512GB DDR5 memory module is exciting, but it's aimed towards the data center and server market. Consumer DDR5 memory will likely top out at 64GB."
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!]
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.
Even still, it's extremely unlikely. Unethical as he was, there's little doubt that Gates has an extremely good understanding of computers. And back then, memory limits were extremely tight and programmers ran into them all the time. Graphics and sound were a serious challenge in the DOS era.
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.
> No-one could possibly ever need more than 1TB of RAM.
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 personally use my PC as lab for building applications. I tend to run a bunch of VMs and one thing I am always short of is memory. CPU cores were more of a problem in the past but now there is a plenty of cores available. I am currently using 128GB and I would definitely wish more, but probably I wouldn't know what to do with 1TB.
But that doesn't mean there aren't others that may have different use cases.
I've also been using 128GB for the last few years on my dev PC. It's great for running VMs, but honestly I could have had 64Gb and would have only rarely noticed the difference.
My replacement PC (actually an Alienware laptop) will only have 64GB. I don't think I'll miss it.
If you're running a bunch of VMs, technically you could do that just as well with a cluster of smaller PCs. (No individual VM needs 1TB, after all.) I see a lot of people on /r/homelab using RPi clusters for this use-case.
I have never been able to detect any subjective difference between different brands of RAM chips for consumer products. It is probably one of the most boring components.
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.
4x64gb is already a lot of RAM for a consumer during the ddr5 generation. Even with a 16 core processor with SMT that's 8 GB each for 32 threads. Any larger and it starts to really hurt latencies that consumers actually vie for.
(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.
Having more memory to address means you need more circuits that direct your reads/writes to the right place. Travelling a longer distance / through more complicated routes means the latency for each request will be higher on average.
More of a "if your a consumer that needs more than 1tb RAM, buy a server board" issue. The number of consumers that need that much memory are tiny and don't warrant a manufacturer making a board just for them.
Cuckatoo Cycle is a proof of SRAM. Cuckatoo32, as used in some cryptocurrency, requires 512MB of SRAM to solve efficiently (in addition to 512MB of DRAM).
The solution process is dominated by writing and reading of individual random bits.
Currently available Cuckatoo32 ASICs only have 64MB on-chip SRAM, causing an 8-fold reduction in efficiency, which still outperforms GPUs.
Litecoin/Dogecoin use an scrypt-based consensus algorithm; scrypt was designed to be "memory-hard" as a way of preventing ASIC-based brute-forcing of password hashes. So that's a "proof of having some memory", at least. (I think the relevant knob on the call to scrypt could just be turned way up to get a "proof of having a lot of memory.")
I believe Ethereum's ethash consensus also works this way, which is why there aren't Ethereum ASICs.
A good PoW should have very fast verification. That's why scrypt makes a poor choice of PoW (technically, the hashcash PoW with scrypt as hash function). It's quite possible to have an instantly verifiable memory hard PoW, where only finding solution takes lots of memory, while verification takes none. For example, Cuckoo Cycle and its variants [1].
HBM is the expensive, it requires and organic substrate (or silicon? I forget) which is expensive, the increased thermal density is more difficult to cool which is expensive.
Even with how difficult, expensive, and hot GDDR6X is that was still preferable for Nvidia's consumer cards.
From what I remember, it can be power intensive which required more power to the motherboard to supply additional power to HBM. HBM2 will consume more than 100w due to increased I/O. It made sense why they are using it in GPU since it can handle additional power from it with 4/6/8 PIN Connectors from PSU directly.
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.
IIRC HBM is actually more power efficient but the problem is power density since HBM is stacked. Could also be trace length.
>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].
I figured they are making improvement in HBM but wasn't expecting an massive improvement with power saving. That is great to know.
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.
Is there a "rule of thumb" to estimate speeds vs DDR4? The "7200" implies it will 2x as fast as DDR4-3600. But what about latency? It seems like latency has not been improving along with bandwidth..
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.
Meanwhile, new machines with 4 GBs of RAM are still being sold in my country. Most laptops within reach of a typical family have 8 GBs, and no slots to add more.
One anecdotal data point - I have two systems that I routinely work with every day - My Dell XPS 7590 (16B) that runs Ubuntu 20.04 and my 8 GB MacBook air M1.
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.
At the beginning of the year, I have picked up a second hand R720 with 192GB. Haven't used all of it yet but the mental peace of having it right here is so satisfying. Used all the 44 cores, though. It cost me half of the money I would have had to pay for a laptop with 64GB.
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.