Slashdot Mirror
How To Use a Terabyte of RAM
Spuddly writes with links to Daniel Philips and his work on the Ramback patch, and an analysis of it by Jonathan Corbet up on LWN. The experimental new design for Linux's virtual memory system would turn a large amount of system RAM into a fast RAM disk with automatic sync to magnetic media. We haven't yet reached a point where systems, even high-end boxes, come with a terabyte of installed memory, but perhaps it's not too soon to start thinking about how to handle that much memory.
Given that the core components of an OS are only a few GB, even 8GB systems might be able to do this, today.
GPL Deconstructed
For some uses we use all the RAM and for others we don't. For instance I think WIN98 boot disks create a RAMDRIVE which is pretty usefull when you can't access any of your hard drives because they aren't formatted or partitioned.
...I might be able to run Vista!!! (I wonder how many people have written this prior to me already?)
It's a lot of RAM and at today's computational speeds, it's not likely that it could be used for anything beyond a RAM drive.
Is it too soon to think about how to use that much RAM? NO! It's the lack for forward thinking that caused a lot of artificial limitations that have been worked around in the past. We're still dealing with limitations on file systems and the like. I've got an old Macintosh that can't access more than 128GB or something like that because its BIOS can't handle it... I had to get another PCI controller installed to handle larger drives.
What it is time to think about is now to code without such limitations built-in. This would better enable things to grow more easily and naturally.
Cute, but there's no guarantee any of that malloc'ed space will actually be in RAM. The OS might decided to dump all that to a HDD or somesuch.
RAM is getting cheaper every day. Capacity is constantly growing. I just bought 4 GB RAM for about the same price I paid a few years ago for 1 GB. Right now I could build a system with 16 GB RAM without breaking the bank, all from basic consumer-grade parts available on NewEgg. It isn't going to be long before we see systems with more RAM than we know what to do with. Turning a chunk of it into a big RAMdisk sounds like a good idea to me.
"Work is the curse of the drinking classes." -Oscar Wilde
As to the problem of how to use 1 TB of RAM, spending any time at all thinking of this is foolish and wasteful. Of course, I remember the days when we rated our computers in how many kilo bytes of memory we had, and plenty of readers here will remember having 20 to 40 meg hard disks in PC's with far less than 1 meg of physical RAM memory. In those days (and I'll avoid the famous Bill Gates quote on the subject), how would you have spent your time deciding what to do with the memory if you had a computer with 1 gig, 2 gig or even 4 gig of memory? You may have come up with all sorts of amazing ideas. But none of them would have done you any good, because the developers (Mostly Microsoft, but Linux is far from lean and mean any more either) already decided what to do with it, waste it and leave you wanting more. And one of your ideas for a 4 gig system might not have even been to just pretend that most of the last gig of memory wasn't there and ignore it!
So why even have a post about what to do with a terabyte of memory? The solution is simple, install Windows 9 and try to quickly order more memory on-line before the memory hungry service pack comes out, forces it's install on you, and your TB isn't enough.
I'm an American. I love this country and the freedoms that we used to have.
Eighty Megamebibytes And Constantly Swapping?
Besides, isn't it obvious how one should use a terabyte of RAM? Use it to upgrade your PC to run Windows Vista MegaUltimate, of course. :-D
Or, to put it another way, the question of what to do with the extra RAM is a non-issue. Install software. Software developers will find a way to waste as much RAM as you can put in and performance will still be slow. It's just the nature of progress....
*sigh*
Check out my sci-fi/humor trilogy at PatriotsBooks.
Basically, use a UPS
Then it goes on with the other questions, like, what if the hardware or kernel crashes and answers them with 'use things that don't crash'.
Agh. I mean, that's really, really bad engineering. You don't engineer things with the assumption that everything will work. You engineer them to fail gracefully when everything that can go wrong does go wrong. And preferably with margin.
If the system requirements for this are UPS, crashproof hardware and a completely bug-free OS, well, I'm sorry, but there's no system in the world capable of fulfilling the requirements.
Still, I'm sure there are cases where it's useful; as long as speed is of higher importance than data integrity, this sounds very useful.
In the early 80s there was this funny machine called a System/38 from IBM that morphed in the AS/400 that is now called an iSeries. Now this machine was a RDBMS engine with simple green screens attached.
Under the covers the System/38 was a cisc box, the AS/400 could be CISC or RISC and the iSeries is all risc. From an app dev point the same compiled object code could run on all three. Stop and think about for a second.
Now the System/38 had a very advanced constraint based security system. For example you could use an object that you could not see. But in general is allowed for very fine grain control of security. Of course this has been improved throught to the iSeries.
Also, this machine had a single address space for all storage. An app didn't need to worry about memory size, the machine automatically used ram as disk and disk as ram.
Of course this machine has had a life of 30+ years and most OS designers have zero idea about just how revolutionary it is same sort of thing as the MCP for a Burroughs B5000. People who do not know history are doomed to repeat it over and over again.
Give it up, this is a religious war. Those of us who prefer vi(m) consider it a more focused editor. We neither need, nor want the extensibility crave. Those of you who prefer emacs consider the extensibility vital to your work, and can't imagine how anyone can live without it.
We have been debating this forever, and will continue to do so, as long as there are vi(m) and emacs users out there. There is no "right" answer, so just enjoy the jokes (they are normally harmless, and often good for at least a smile).
Thats the only reason i can see to have that much ram. Unless our current crop of so called programers bloat their code to fill the expansion for yet another worthless feature.
---- Booth was a patriot ----
If the table fits in the cpu's data cache don't the lookups get executed as fast as possible (multiple lookups per cycle fully utilizing the ILP window)? Granted, i*c+j would be a single lea instruction anyways.. but even so there could be benefits to using a lookup to eliminate a branch that would otherwise be in the inner loop or to handle some odd case (that would otherwise be a branch in your loop) etc.
bite my glorious golden ass.
The question should be not WHAT to fill it with, but how to read/write gargantuan amounts of data quickly.
Upward mobility is a slippery slope - the higher you climb the more you show your ass.