Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Spansion Inc. -- Ignore unavailable to you. Want to Upgrade?

To: Woerns who wrote (3175)	1/24/2008 12:29:11 PM
From: Joe NYC	Respond to of 4590

Woerns, I dont' think that Virident memory serves as traditional disk cache like Joe says. That would be the same approach like using normal NAND flash with a wear leveling controller in front of the disk and still using just as little DRAM like before. But probably Eclipse would be more expensive. I think that the Eclipse package containing of both DRAM and ORNAND has to serve as normal memory. I don't know how to tell the operating system to occupy the little DRAM part only and the data base to occupy the huge ORNAND part. In the computer stone age sometimes I created a RAM-disk in DOS mode in order to not always use the floppy drive. Probably similar but more state of the art things are possible today. DRAM serves as a disk cache today, in a vast majority of server apps, unless there is a specialized server app that can keep its data in memory. Like a database server. Database server, when it has enough memory at its disposal, just keeps copies of the tables (that normally reside on disk) it its own memory. There may be some specialized sophisticated apps, that can load data to some sophisticated memory structures, but those tend to still be relatively rare. The internet search engines may be an instances of such apps. Normally, apps are written in a way that they run on the hardware that is available at the time. Large memories to store entire data sets were not really available in the past, so apps were written for a combination of disk and DRAM storage. As large memories proliferate, so will apps written to take better advantage of them. And the apps will be more optimized. These days, when you work with a hybrid of disk and DRAM, the app are optimized to avoid large number of random accesses, There are more than 2 orders of magnitude in DRAM vs. disk latency. Disk is roughly 10 ms, DRAM is roughly 100ns. I count 5 orders of magnitude. So if you start designing the app knowing you will never suffer 5 orders of magnitude slow down, you will not concentrate on defensive measure to avoid them, you concentrate on taking best advantage of what you do have to deliver the best performance (on what the apps were already doing) or come up with entirely new things never possible before. As far as implementation of Virident, I think it is done in a way that there would be no changes necessary to the OS. So to the OS, it will look just like ordinary DRAM. Internally, I think DRAM is just a write buffer, and there is some mechanism to intercept reads to return the correct data (either from DRAM buffer or flash). Also, a policy would have to be set up to keep track of pending writes, and to write only ones that have not been re-written for some time (say a minute or a second or whatever is appropriate), so that you are not writing and re-writing a variable that, for example, serves as a counter in some inner loop. IMO, the ballpark figures as of today would be to have some 2 to 4 GB of DRAM and 10s or 100s GB of flash. That way, the OS and all of the temporary stuff would be in the DRAM, and vast data that is mostly read-only would be in flash. Joe