To read all comments associated with this story, please click here.
If this proves out, it is certainly likely to eliminate the RAM/disk dichotomy as we know it. However, I do think we will still have something like it for removable storage, and possibly expanding storage.
I also hope that it proves to be as fast as SRAM, not just DRAM -- if so, we can rewrite the rules entirely on CPU caches -- they would probably still exist to eliminate memory contention across all CPU cores, but they would no longer be needed to handle the widening difference between cache and main memory performance.
Good call. Even better than eliminating the ram/disk dichotomy would be eliminating the ram/disk/cache trichotomy (if that's a word). It's impressive how we can immediately think of awesome applications for something like this but I'm sure that it will take quite some time for the "killer app" for this technology to come along. When it does though, I'd imagine it is likely to cause some huge changes throughout all technology- just consider how important the switch from vacuum tubes to transistors was.
Adding to what james_parker wrote, it seems there would be no point to hold to ram/hdd dichotomy at all with this new technology...since apparently there's not that much point as it would seem to do it already, if one would believe Varnish HTTP accelerator website
http://varnish.projects.linpro.no/wiki/ArchitectNotes
(since I definatelly can't be described as CS-anything, I can't really judge...other than what is under this link sounds at least resonable to me)
BTW, nice to know that HP actually is still also a research company (I thought they became just another Dell some time ago...)
While it may be as fast as DRAM ( DDR? DDR2? ) there are still considerably faster types of memory I'd love to see fill the void of RAM. i.e. The L1/L2 cache memory which can give 20GB/s or better :-)
I would love to see the following setup:
(All memory persistent)
64 Core CPU ( w/ thread splitting and per-CPU rates )
Each core:
1GB 1PB/S L1, fully associative, versioning
50GB 500TB/S+ L2, fully associative, versioning
Global:
500GB 50TB/S+ L3, versioning, and flex-partitioned
RAM:
10TB 1TB/S+
Ultra High Capacity Storage:
18PB 500GB/S+, solid-state, w/ integrated interface-speed 10GB cache ( say, 1TB/s ).
The tiering is for cost :-) Not to mention size concerns :-)
This system would be very hard for Microsoft to slow down, though I am certain they would find a way.
But... I mean... Haiku would certainly be an instant-on OS even if no special work was done :-)
Windows Vista may take 100ms or so, being human-noticeable ( albeit tolerable ).
Heck, the CPU cores wouldn't even need to be that fast :-)
Ahh.. just imagine the games we could write!
It MIGHT even be able to run SETI so fast we end up waiting for the data to come from the telescopes every 10 seconds or so ( that would be sweeet ).
hmm... I seriously think I need to sleep more than four hours a day, but then I can't program for $@!# :-(
"50 GB L2 cache"
Led me to do a very rough thought experiment. A Core 2 processor at 65 nm process with 2 (might be 4) MB of cache is 143 square mm. Lets say cache is half of it, or 70 square mm.
If 50 GB ~= 50,000 MB, that's 2 MB * 25,000 to get 50 GB of cache. At a 65 nm process, that'd be 70 square mm * 25,000, or about 1,750,000 square mm.
That'd be a square of about 1,300 mm, or a square 1.3 meters per side. Each processor die would be about the size of a small table. If there's 64 of them, then that's a processor 10 meters per side. I guess if you arrange them in a stack you might end up with something like a small car.
I suppose that's only at 65 nm. Maybe with super gamma ray lithography or by pushing individual atoms around it'll get the size down to something that would be able for a person to carry easily.
I'm sure my math is off, but I'd hope my mistakes don't invalidate the orders of magnitude that MB -> GB includes.
"Not to mention size concerns" Indeed!







Member since:
2005-11-13
A device with the density of a hard drive (hundreds of gigabytes or even terabytes), and the speed of dram, we could potentially assign some space for working memory (now named ram) and the rest for "storage".
Think of this:
For normal everyday use, we "only" dedicate 4 or 8 gb for "ram".
Today we are going to work with HD video, so we use 32gb of free space as "ram", and the rest of the device as storage.
Or even better, the "storage" is fast enough that we don't need to have "ram" in the middle.
Edited 2008-05-02 00:09 UTC