HP To Introduce Flash Memory Replacement In 2013
Spy Hunter writes "Memristors are the basis of a new memory technology being developed by HP and Hynix. At the International Electronics Forum, Stan Williams, senior fellow at HP Labs, said, 'We're planning to put a replacement chip on the market to go up against flash within a year and a half. We're running hundreds of wafers through the fab, and we're way ahead of where we thought we would be at this moment in time.' They're not stopping at a flash replacement either, with Williams saying, 'In 2014 possibly, or certainly by 2015, we will have a competitor for DRAM and then we'll replace SRAM.' With a non-volatile replacement for DRAM and SRAM, will we soon see the end of the reboot entirely?"
Ofcourse we will not see the end of the reboot entirely. I have yet to encounter a Windows or Linux system that you can upgrade without rebooting. (In practice that is, in theory it should all work.)
Memristors will make a dent in the small scale UPS market since there will be no need to shut down gracefully but we will still need large scale backup system where you want to continue running your operation during power outage.
The real change we will see is when memristors replace flash and dram since there will no longer make sense to keep the bulk storage in a different memory from the rest of the system. Everything will be memory mapped always like it was in the good old ROM-based days.
The problem is that both Windows and Linux is badly prepared for this since both of them uses executable program structures that require modification upon loading. A lot of programs are also using datafiles in an abstract format that require extensive parsing before usage. (Like XML or other text based configuration files.)
This makes it hard to transition into XIP-system where loading is something that doesn't happen. (Did anyone with a battery backed SRAM PCMCIA-card try eXecute In Place on the Amiga? I would like to know if it actually worked or if it was just a term mentioned in the manuals. It should have worked since it's not really any different from compiling programs for memory-resident operation.)
Reboots usually don't happen because of hardware, and certainly not because of the type of RAM you're running. It's bad software.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
it won't mean the end of the reboot, stupid editor. This is sSlashdot, don't you know you have a Microsoft-Windows-BSOD-Daily-reboot meme to maintain?? :)
What I think it could mean the end of is the HDD, or rather the distinction between memory and storage. If all your apps and long-term-storage data could be placed into RAM, then you'd do it wouldn't you. (this assume a few things, like reliability and long-term unpowered persistence) but imagine having 500Gb of RAM that just happened to hold all your data, rather than keeping it separate and shuffling it between the two. That could be quite a change for the way we see computers compared to the ways we've been using them for the last 40 odd years.
We can finally dump the multiple layers of caching, look-ahead and other OS complexity designed to hide several orders of magnitude difference between register/DRAM access and persistent storage (tape/Hard drive/core memory...). Operating systems can return to the level of simplicity they had back when everything was uniformity slow. But now everything will be uniformly fast and we'll can focus complexity on multiprocessing.
It will become practical to implement neural networks in hardware. This will completely change the way we design and program software and databases.
Persistent and portable user sessions will become the norm. (Look at Sun Ray for an idea of how this works. Sun Ray sessions are typically logged in for months at a time. This means software has to be better behaved but it also means we won't have to rely on user memory to restore a desktop and applications to... now where was I?
The structures that require modification are copies of the data on disc, why should that change? Copy these from the non-running programme to private pages, modify the process page table, job done.
Unless the version of the kernel with security patches is larger than the old version and won't fit in the same pages, or the security patch changes the meaning of a data structure in RAM. Then you need an Oracle product to make the transition.
Given the HP board of directors' track record in making good decisions, one could speculate that they would invest in TTL chip technology for the same reason.
Yes, hundreds of wafers ahead of schedule is good, but they haven't even sold one chip yet. It's hardly time to go all in and throw the car keys on the table, too.
John
When was that exactly? Only the very earliest, very simple computers didn't have at least two kinds of memory (working memory and storage). And they didn't have an operating system.
-- Ed Avis ed@membled.com
Right now, we have two main models for storage - files and a flat address space. Neither is well suited to flash memory, let alone something like memristors.
There are other architectures. Burroughs machines from 1960 onward had memory addressing that worked like pathnames. Think of memory addresses as being hierarchical, like "process22/object21/array4[5]". Objects were paged in and out, but were not persistent. The IBM System/38 went further and made such objects persistent. However, such architectures are not compatible with C programming, which assumes that addresses are numbers.
Flash is usually treated as disk, even though it has an access time that's faster than the time the OS takes to grind through the file system code. Flash is much more of a random access device, but it's seldom supported as one. One possibility would be to support flash memory as a name/value tuple store, like the "non-SQL" databases.
PC-type architectures still don't have a channel architecture (like IBM mainframes since 1967), where a user program can have non-privileged access to a device without the OS being in the middle. (Channel support means a process can talk to a device directly by sending messages, messages which the device can securely associate with the sending process and its privileges. The device has to maintain security and has the information to do so.) So smart devices that do lots of little fast transactions, like a tuple store or an object store, have to be mediated through the OS. So most OSs are still reading big blocks from flash, then caching them in RAM. That's already limiting, and memristors make it more so.
The success of C and the UNIX model (which even Windows NT and its successor follow) is based on a vanilla hardware model. That's holding computing back.
It's a common misconception (reinforced by several GUIs) that "virtual memory" means "using disk as virtual RAM". That's not accurate.
Virtual memory means the address a program sees is not the real address in storage. It's translated by the MMU (Memory Management Unit). This lets you do any number of things, only some of which have to do with paging/swapping to disk. In particular, it lets different programs have different views and access of the same storage, which is important for separation of privileges between processes (useful for even single-user systems, and required for practical multi-user systems).
It would be the case that some of the uses for VM would go away, though. No need for disk swapping/paging. No need for memory mapped disk I/O if you have no disk, either.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Everybody here is prattling on about whether we can or cannot eliminate reboots by using memristors - completely missing the point of this new technology. We are talking about a 5 nanometer process here! One in which you can build up many layers! One in which parameters can be traded off in various ways to either make a better DRAM than DRAM, a better SRAM than SRAM, or a better flash than flash. The point is not necessarily to replace all of those with a single part. The point is that there is VAST potential to break through barriers. We are talking about a flash replacement with much higher density, lower power, increased endurance, and (speculatively) lower cost. This could be the a damn big breakthrough; a game changer.
Or it could be that demand has grown fast enough to keep pace with growth in supply. This does happen naturally sometimes. The smartphone market has been growing for that entire time, the amount of flash in each phone is been going up, there's also the tablet market and the ebook reader market, the digital camera market, solid state drives for all those Macbook Airs, and so on. This can keep prices high without monopoly or collusion. If the manufacturers know they're guaranteed to sell everything they make at the current price, then it doesn't benefit them to lower their prices.
If flash fabs didn't cost tens of billions of dollars to make, then yes, we might still be able to argue that manufacturers were colluding to limit production to keep prices high. But due to the expense, they've got a pretty good argument that building new fabs is too risky. Especially since we're bumping up against the reliability limits of flash now; they can't just double density again.
This is where HP hopes to swoop in with memristor tech and save the day / get rich. They're claiming their test runs are already competitive with flash performance and with better reliability, and that the tech is no where near its limits yet. Theoretically, as soon as they start putting this into production, they'll start grabbing the high end market share, and either the price of flash with crash in response (the fabs are about paid off already, so they have a lot of flexibilty to lower prices) or everyone will license from HP and make memristors.