Time to merge memory?
-
192 bit?? I'm presuming that's the width of data and address bus combined but even then I'd expect 128 bits as a maximum. I need to read up, clearly...
Regards, Rob Philpott.
-
Now that SSDs are becoming more common and with the rise of 64 bit architectures I've been wondering whether we might see the day soon where we don't distinguish between RAM and 'disc' storage, instead just mapping everything into a vast address space. I don't know how wide address buses are on 64 bit processors, but I doubt they are 64 bits but if they are (and they could be), and we gloss over problems to do with speed of access it seems possible. You'd need some sort of caching - a bit like on processors. So ingrained is the idea of RAM and disc storage its hard to imagine what it would be like without it. Persistence would disappear, as once you've instantiated an object there it would stay, indefinitely. I don't know what that would mean for the traditional idea of a file system. Interesting thought - well if you're me anyway.
Regards, Rob Philpott.
Rob Philpott wrote:
Persistence would disappear, as once you've instantiated an object there it would stay, indefinitely. I don't know what that would mean for the traditional idea of a file system.
Presuming that they do become equal in replacement that would still not happen. The bus is still serial. Ip is still serial. Application bottlenecks still exist. Geographic redundancy needs still exist, etc.
-
Welcome to Back to the Future.... 1979, to be precise. That was when the System/38 was introduced by IBM with a 48-bit addressing scheme. The system did away with notions of main memory being different from disk storage. Disk was managed as an extension of main memory. But then, according to the "we-know-best" Unix crowd, if it is not in Unix, it is not worth having. And in computer system architecture courses in Brain Washing Facilities -- sorry, Universities -- the only architecture worth learning teaching is the Intel '86 series!
-
Now that SSDs are becoming more common and with the rise of 64 bit architectures I've been wondering whether we might see the day soon where we don't distinguish between RAM and 'disc' storage, instead just mapping everything into a vast address space. I don't know how wide address buses are on 64 bit processors, but I doubt they are 64 bits but if they are (and they could be), and we gloss over problems to do with speed of access it seems possible. You'd need some sort of caching - a bit like on processors. So ingrained is the idea of RAM and disc storage its hard to imagine what it would be like without it. Persistence would disappear, as once you've instantiated an object there it would stay, indefinitely. I don't know what that would mean for the traditional idea of a file system. Interesting thought - well if you're me anyway.
Regards, Rob Philpott.
-
Now that SSDs are becoming more common and with the rise of 64 bit architectures I've been wondering whether we might see the day soon where we don't distinguish between RAM and 'disc' storage, instead just mapping everything into a vast address space. I don't know how wide address buses are on 64 bit processors, but I doubt they are 64 bits but if they are (and they could be), and we gloss over problems to do with speed of access it seems possible. You'd need some sort of caching - a bit like on processors. So ingrained is the idea of RAM and disc storage its hard to imagine what it would be like without it. Persistence would disappear, as once you've instantiated an object there it would stay, indefinitely. I don't know what that would mean for the traditional idea of a file system. Interesting thought - well if you're me anyway.
Regards, Rob Philpott.
small point most desktop windows PC work themselves into corrupted corners and need to be refreshed by restarting them If we only have one copy of each program in "ram" I lose my vital support tool of "restart the PC" or at least I could restart but it would have no benefit as I still just use the corrupted copy :( or does this utopia only allow perfect programs to be used?
-
I prefer to keep my temp or swap (depending the OS in use) on my RAM... by creating a RAM disk... It's safe and recommended highly if you're on an SSD
Wait! Swap == RAM complementation, is it right!? So why did I would "lower" available RAM to create a RAM Drive to store a swap drive!?!?!? :confused:
-
Wait! Swap == RAM complementation, is it right!? So why did I would "lower" available RAM to create a RAM Drive to store a swap drive!?!?!? :confused:
1. You're In no way like to thrash your SSD with rapid writes 2. You're never gonna make a good use of your 16 GB+ RAM! 3. For video and photo editors, which make a massive use of temp/swap space, it's a boon
-
Now that SSDs are becoming more common and with the rise of 64 bit architectures I've been wondering whether we might see the day soon where we don't distinguish between RAM and 'disc' storage, instead just mapping everything into a vast address space. I don't know how wide address buses are on 64 bit processors, but I doubt they are 64 bits but if they are (and they could be), and we gloss over problems to do with speed of access it seems possible. You'd need some sort of caching - a bit like on processors. So ingrained is the idea of RAM and disc storage its hard to imagine what it would be like without it. Persistence would disappear, as once you've instantiated an object there it would stay, indefinitely. I don't know what that would mean for the traditional idea of a file system. Interesting thought - well if you're me anyway.
Regards, Rob Philpott.
We already have RAMDisks (Which you can create using your own RAM and one of a myriad of free apps) These are generally crazily fast (20x faster than SSD's - Tested on my n00bish DDR2-800 RAM), although require actual RAM to store data (And due to the nature of RAM, would get your data lost in an unexpected power failure :p) If you have 10+ GB RAM, create yourself a 2GB+ RAMDisk, and benchmark it - You'll love the results ^_^
-= Reelix =-
-
Now that SSDs are becoming more common and with the rise of 64 bit architectures I've been wondering whether we might see the day soon where we don't distinguish between RAM and 'disc' storage, instead just mapping everything into a vast address space. I don't know how wide address buses are on 64 bit processors, but I doubt they are 64 bits but if they are (and they could be), and we gloss over problems to do with speed of access it seems possible. You'd need some sort of caching - a bit like on processors. So ingrained is the idea of RAM and disc storage its hard to imagine what it would be like without it. Persistence would disappear, as once you've instantiated an object there it would stay, indefinitely. I don't know what that would mean for the traditional idea of a file system. Interesting thought - well if you're me anyway.
Regards, Rob Philpott.
It will take a while for this, mainly because SSDs are not fast enough to compete with RAM speed, and even while we can create hard disks based on RAM modules they're not cheap nor very useful when power goes out.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
Now that SSDs are becoming more common and with the rise of 64 bit architectures I've been wondering whether we might see the day soon where we don't distinguish between RAM and 'disc' storage, instead just mapping everything into a vast address space. I don't know how wide address buses are on 64 bit processors, but I doubt they are 64 bits but if they are (and they could be), and we gloss over problems to do with speed of access it seems possible. You'd need some sort of caching - a bit like on processors. So ingrained is the idea of RAM and disc storage its hard to imagine what it would be like without it. Persistence would disappear, as once you've instantiated an object there it would stay, indefinitely. I don't know what that would mean for the traditional idea of a file system. Interesting thought - well if you're me anyway.
Regards, Rob Philpott.
-
1. You're In no way like to thrash your SSD with rapid writes 2. You're never gonna make a good use of your 16 GB+ RAM! 3. For video and photo editors, which make a massive use of temp/swap space, it's a boon
- The question is not whether to push it fo flash or not, but whether to push it out at all. Why do you want to add the (significant) overhead of paging if you've got more RAM? Leave it in RAM as ordinary working storage! 2) Huh? If you've got 16 GB (or less) as RAM, and then introduce paging, you are creating a virtual RAM space greater than 16 GB - flat as the earth (locally, that is). If you are able to make good use of a virtual RAM address space >16 GB, why would it be more difficult to make good use of >16 non-virtual RAM space? 3) Very few if any photo/video editors are even close to a 16 GB working set, no matter what material you are editing. Even when you process video, you do it clip by clip. Clips >16 GB are exceptional. Practically all such processing is sequential; it doesn't consider all the video information of a clip as a whole. Double buffering and DMA has been established techniques for ages, and when your CPU churns HD video (or higher), every modern disk is fast enough to provide data for the CPU.
-
Welcome to Back to the Future.... 1979, to be precise. That was when the System/38 was introduced by IBM with a 48-bit addressing scheme. The system did away with notions of main memory being different from disk storage. Disk was managed as an extension of main memory. But then, according to the "we-know-best" Unix crowd, if it is not in Unix, it is not worth having. And in computer system architecture courses in Brain Washing Facilities -- sorry, Universities -- the only architecture worth learning teaching is the Intel '86 series!
When the 38 arrived, the file system came a little late, so the first user couldn't save their data permanently except by leave them in program variables. The libraries for processing "open" and "write" and "close" were not there. Those libraries did nothing but move data from some "RAM" addresses to other "RAM" addresses (plus maintaing pointers and other metadata to make "RAM" appear as if it were a physical disk split into surfaces and tracks and sectors), but practically all existing programs were assuming an open/write/close interface to make data persistent. To illustrate the conveniece of flat address space: A friend of mine worked on a S38 having two disk drives with removable media. He regularly received data from two data sources, each on a separate disk, and the data sets were to be merged pairwise to a new, third disk. So he defined a virtual 3rd disk, merged the two physical ones onto the third - the OS found free space on either of the disks. Then he could virtualize one of the source disks and make the third, merged disk non-virtual, and lift a merged physical disk off the drive... It did take some shuffeling of data to get all the merged-disk-pages onto the physical disk and everything else moved off that physical disk, but the low level OS (i.e. the virtual to physical mapping functions) handled that automatically.
-
Solid State Disks calls for a new technology in RAM. We want faster!
"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>
-
We already have RAMDisks (Which you can create using your own RAM and one of a myriad of free apps) These are generally crazily fast (20x faster than SSD's - Tested on my n00bish DDR2-800 RAM), although require actual RAM to store data (And due to the nature of RAM, would get your data lost in an unexpected power failure :p) If you have 10+ GB RAM, create yourself a 2GB+ RAMDisk, and benchmark it - You'll love the results ^_^
-= Reelix =-
But why on earth would you give away 2 GB of RAM to a simulated disk? What is the gain of churning the data through file system and disk simulation code, rather than just leaving it where it is? Pulling values directly out of a variable is magnitutes faster than executing a 'read' file system function, even when that read ends up in some RAM location.
-
But why on earth would you give away 2 GB of RAM to a simulated disk? What is the gain of churning the data through file system and disk simulation code, rather than just leaving it where it is? Pulling values directly out of a variable is magnitutes faster than executing a 'read' file system function, even when that read ends up in some RAM location.
Primarily since the read/write speeds of the simulated disk are 20x faster than regular disks (Including state-of-the-art SSD's). Also, when you're sitting with 32GB RAM (8GBx4 - Easy enough these days), creating a 16GB RAMDisk would still leave you far more RAM than you would ever need. Plonk a game there, and you effectively eliminate loading times (As the majority (95%) of loading times are due to data being pulled off the physical drive) So, instead of asking "Why", you should be asking "Why not" :)
-= Reelix =-
-
When the 38 arrived, the file system came a little late, so the first user couldn't save their data permanently except by leave them in program variables. The libraries for processing "open" and "write" and "close" were not there. Those libraries did nothing but move data from some "RAM" addresses to other "RAM" addresses (plus maintaing pointers and other metadata to make "RAM" appear as if it were a physical disk split into surfaces and tracks and sectors), but practically all existing programs were assuming an open/write/close interface to make data persistent. To illustrate the conveniece of flat address space: A friend of mine worked on a S38 having two disk drives with removable media. He regularly received data from two data sources, each on a separate disk, and the data sets were to be merged pairwise to a new, third disk. So he defined a virtual 3rd disk, merged the two physical ones onto the third - the OS found free space on either of the disks. Then he could virtualize one of the source disks and make the third, merged disk non-virtual, and lift a merged physical disk off the drive... It did take some shuffeling of data to get all the merged-disk-pages onto the physical disk and everything else moved off that physical disk, but the low level OS (i.e. the virtual to physical mapping functions) handled that automatically.
I didn't work on the S/38, only on the successor AS/400 so I am unable to comment on the file system not being there when the S/38 arrived. As to "OPEN" and "CLOSE", I remember those functions are not needed for physical files (as opposed to logical files which are views derived from one or more physical files) in the AS/400. You can read or write files without specifically opening them or closing them at the end of processing. I am pretty sure that is a carryover from the S/38.
-
Primarily since the read/write speeds of the simulated disk are 20x faster than regular disks (Including state-of-the-art SSD's). Also, when you're sitting with 32GB RAM (8GBx4 - Easy enough these days), creating a 16GB RAMDisk would still leave you far more RAM than you would ever need. Plonk a game there, and you effectively eliminate loading times (As the majority (95%) of loading times are due to data being pulled off the physical drive) So, instead of asking "Why", you should be asking "Why not" :)
-= Reelix =-
but... if you read it directly from RAM, neither from a RAM-disk, nor from a Flash-disk, nor from a magnetic disk - then it might be 200x as fast. Maybe 500x as fast. Why write it anywhere at all? Why not use data where they are located before you write them to any sort of disk? Why is it better to have it on a RAM disk than having it in RAM?
-
but... if you read it directly from RAM, neither from a RAM-disk, nor from a Flash-disk, nor from a magnetic disk - then it might be 200x as fast. Maybe 500x as fast. Why write it anywhere at all? Why not use data where they are located before you write them to any sort of disk? Why is it better to have it on a RAM disk than having it in RAM?
-
Or earlier - October 1974 http://en.wikipedia.org/wiki/ICL_VME[^] when ICL introduced VME/B
Wikipedia states "Files and other persistent objects are recorded in a repository called the Catalogue. Unlike other operating systems, the file naming hierarchy is independent of the location of a file on a particular tape or disk volume. In days where there was more need for offline storage, this made it easy to keep track of files regardless of their location, and to move files between locations without renaming them. As well as files, the Catalogue keeps track of users and user groups, volumes, devices, network connections, and many other resources. Metadata for files can be held in an object called a File Description." That doesn't sound like there being no distinction between main memory and disk memory, which is how the System/38 and its successor the AS/400 handle files. If a specific page (data area) of a file is not in memory, it is brought into memory but the page is not written back to disk unless it is "dirtied" by being updated. Otherwise, files reside partially in main memory and partially on disks.
-
Now that SSDs are becoming more common and with the rise of 64 bit architectures I've been wondering whether we might see the day soon where we don't distinguish between RAM and 'disc' storage, instead just mapping everything into a vast address space. I don't know how wide address buses are on 64 bit processors, but I doubt they are 64 bits but if they are (and they could be), and we gloss over problems to do with speed of access it seems possible. You'd need some sort of caching - a bit like on processors. So ingrained is the idea of RAM and disc storage its hard to imagine what it would be like without it. Persistence would disappear, as once you've instantiated an object there it would stay, indefinitely. I don't know what that would mean for the traditional idea of a file system. Interesting thought - well if you're me anyway.
Regards, Rob Philpott.
I don't see a case for merging the two types of storage conceptually even if there was a single device that could deliver both optimal speed and capacity. There is still a valid case for a distinction between persistent storage for the stuff you want to keep until otherwise specified and dynamic storage for stuff that's only temporary in nature as a by-product of various algorithms. The type of storage you want can be specified in your code but the actual implementation of it is more of a side issue. In both cases you have to decide when and how you are going to delete the stuff. That decision is affected by performance issues related to the technology but that sort of thing really ought to be specified as part of a security policy. Turning the power off is a crude way to wipe unwanted RAM, but you'd still want to do that even if it wasn't one of the physical characteristics of the device.