Slashdot Mirror
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.
Maybe this will mark the start of an upturn which will stop them changing CEOs quite so rapidly....
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
My bullshit detector is going off - and it's not because I don't believe this sort of technology is just around the corner - because it is. I just don't have confidence that it will be brought to us by HP... given recent evidence HP seems quite capable of snatching any defeat from the jaws of victory.
What has memory to do with reboot.
Powerless hybernation is much more interesting.
Windows users will still need them every time they change things, or to clean up tiny software flaws...
Disinfect the GNU General Public Virus!
they're selling us. It sounds good but I'll believe it when I see it (vaporware?).
"We are just a war away from Amerikastan. When god vs god the undoing of man." Dave Mustaine
Reboots are not necessary on many machines right now - I have to remind my boss to reboot every few weeks when something finally goes wonky in the network settings on his Mac laptop. Standby mode lasts for a very long time now... and most required reboots are from operating system updates. With modern SSDs, you don't even need to wait that long to boot. My work machine with a modern SSD takes about 7 seconds to boot Windows 7. My home machine, with less services to start, boots in about 4.
But honestly, they may be saying that, but it's not like DRAM speeds will be sitting still. And a store/load cycle that can compete with flash is an order of magnitude slower than one that can compete with modern DRAM chips. But don't let that get in the way of crystal ball gazing.
Why can't I mod "-1 Idiot"?
I was just waiting to be proven right.
I bet Windows will still require irregular reboots and Linux still won't, nevermind which memory technology is used.
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.
Man. I was going to put all of my savings into one of the new cold fusion companies that are going to be popping up at the end of the month. Now I'm going to have to split it with all the HP stock I need to buy.
Having to work for a living is the root of all evil.
HP shouldn't be inventing things - the real money is in providing services (at least that's what they told me on my MBA course)!
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?
I haven't encountered any OS besides z/OS that didn't require a reboot atleast every few weeks in order for the software side to remain stable.
This includes Windows, Linux, OS-X, Android and iOS. Most likely due to not-quite-perfect applications rather than the OS itself, but they still required an OS reboot.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Oracle must already by working hard to find out how to make it incompatible with their databases.
s/reboot/cold-boot;
This will store your system state in memory, meaning you don't need to hibernate.
Finally had enough. Come see us over at https://soylentnews.org/
NV DRAM. Well, that won't be exploited, then...
This will allow us to truly turn off a device and save a considerable amount of energy. It'll be a revolution similar to the transistors effect on the vacuum tube, but much faster.
I don't want all my actions be stored at home... ;)
This, if it ever sees light of a day, will probably need major rethinking of OS architecture. Some things like volatile RAM vs. permanent "files" on "disks" is logic hardcoded into every major OS and framework (java, .NET, C++, ...), not only as a code but as a major architectural constant. With this, everything changes IMHO, not only boot. For example, "files" are completely obsolete, unless we want to emulate with what we know and what we are used to.
839*929
But Flash isn't as fast as RAM.
"HP’s technology allows the memory layers to be put directly on top of the processor layer making for very fast systems on chip" Interestingly this is exactly what John Carmack stated he was hoping would happen in his last interview. It would make development of new game engine technology that takes full advantage of PC systems much easier.
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.
Sometimes a reboot is the only way to know for sure that everything is back as it should be. We have been conditioned by heavy-weight systems to think of rebooting as a bad thing. If reboots are cheap enough and the scope of reboots could be contained to be small enough, we could think of reboots as "garbage collection for processes," especially for misbehaving processes.
I don't think that monolithic systems such as we have today will ever be able to do this. We need to finally acknowledge that software is among (if not *is*) the most complex things that humans have ever created and hence will often exceed our ability to foresee/deal with all issues a priori. It seems to me that a more robust approach is to divide the system up into highly-independent restartable modules that share nothing and request services of each other through well defined interfaces such that if an error is found in one module it can largely be restarted without needing to restart too many of the modules that depend on it.
Am I mad? I don't think so. There are operating systems in which the OS and the applications are small, tightly focused, and have components which can be restarted independently: take minix http://www.minix3.org/ or qnx http://www.qnx.com/ as examples. Also Joe Armstrong's work http://www.erlang.org/download/armstrong_thesis_2003.pdf on Erlang http://www.erlang.org/ shows an approach to reliability based on acknowledging that "bad stuff happens in spite of our best efforts" and does a good job of rebooting small components of the overall system to bring the system back up to full health. See http://steve.vinoski.net/blog/2008/05/01/erlang-its-about-reliability/ http://cacm.acm.org/magazines/2010/9/98014-erlang/fulltext http://www.erlang-factory.com/upload/presentations/45/keynote_joearmstrong.pdf Some of the key points of Armstrong's methodology are to have independent, concurrent actors that interact through functional message-passing interfaces and can be restarted extremely quickly. A synchronous message passing style (in which the requester doesn't release the parameters associated with a request until after a successful result is returned), along with the actors being functional (meaning there is no hidden state), ensures component can be restarted independently.
(Now, lest you think me an Erlang fanboi, I confess that I find the syntax "baroque." The Go language http://golang.org/ on the other hand appears to have all that is needed to create a runtime system that implements all that Erlang provides but in a syntax and with semantics that many of us are much more willing to accept.)
-Anon
Don't get too excited guys... Apple already locked up anything HP produces with a long term contract. They're even going to build the factory for them! On the bright side, if this technology ever gets cheap enough, Apple will switch to it exclusively, meaning flash prices will come down finally for other vendors. Remember, Apple doesn't like flash.
Man. I was going to put all of my savings into one of the new cold fusion companies
Cold fusion? You could have bought ADBE years ago.
I haven't encountered any OS besides z/OS that didn't require a reboot
What, you never had a digital wristwatch, thermostat, or tv remote control?
The microcontrollers in such devices don't have an "operating system" distinct from the only application that runs on them.
Good luck with that. If something has Linux, a file system, and a network connection, it can run Oracle Berkeley DB and Oracle MySQL.
Some things like volatile RAM vs. permanent "files" on "disks" is logic hardcoded into every major OS and framework
For one thing, it's not necessarily as hardcoded as you might think in operating systems that have any concept of of "everything is a file". One can mmap a file as a block of memory, or one can mmap /dev/zero to allocate a block of memory. For another, perhaps you want "files" on "repositories" to be backed up, revision controlled, etc.
HP seems to be getting a lot of mention on /. lately. It's starting to rank right up there with *pple. And not all of it is the latest rehash of their boneheaded mismanagement circus. Do we have a HP mole on /. now?
I see this being aimed at data centers and servers more than the average desktop, RAM that never fails and cheap SSDs could boost HP's server sales tremendously.
Sounds like a nightmare for software design. A reboot is used today to clear up bad glitches in software. How will we be able to do that if rebooting does not reset software that has glitched. Sounds like a catch 22 to a good idea.
Imagine all the sensitive documents you work on, entering RAM during your time working with them.
If the system's working memory isn't volatile then you are at risk even when you use full disk encryption and power down. Your dm-crypt will be rendered useless when your tax returns and bank statements are dumped from memory after burglars make off with your gear.
Volatile memory is a wonderful thing.
It's a good thing too, because it's likely Samsung has been colluding with other NAND Flash manufacturers to keep prices high. They bought up a lot of competitors and the top 3 manufacturers control the vast majority of the market now. The DOJ actually investigated Samsung for collusion in 2007 (http://www.theregister.co.uk/2007/09/18/nand_flash_antitrust_probe_widens/) but abruptly dropped the case in 2009 (http://www.bloomberg.com/apps/news?pid=newsarchive&sid=aWgWSqhs_Jk0). Perhaps coincidentally when Obama became president. The main problem with NAND Flash is it's so massively capital intensive that you need $25 billion to construct a new fabrication plant. It's easy for companies like Samsung (which was fined a record $3 billion by the DOJ for colluding with LCD manufacturers to price fix LCD panels) to cheat the market system.
errr.. i think your either trolling, or your confusing adobe flash software with physical flash memory.
I refuse to believe scientific progress has been made- or that this is an improvement over traditional RAM until I see a room full of randomly flashing LED lights.
"That's the way to do it" - Punch
SSD is "volatile" due to the fact that it /will/ die after X cycles? And this is not because...?
Would some of you clever (and snarky) types consider the security issues that persistent RAM brings?
Powering off such a machine leaves it entirely ready to be used, true, but also entirely ready to be examined by whoever lifts it out of your bag at the airport or Starbucks. Freezing and bumping DRAM now is considered a genuine, if rare, security concern. No one talks much about hiberfil security. All of my RAM still loaded, ready to be dissected by whoever cares to physically take it away?
How long before someone works out a system to mount this RAM elsewhere and peruse it at their leasure?
deleting the extra space after periods so i can stay relevant, yeah.
How will they deal with encryption? Specifically, government/paranoid entities that want to protect their data from physical loss. It's one thing to freeze a stick of ram, move it to another computer and dump the memory.. but if you don't need to freeze it, don't have to worry about decay of data, and are practically guaranteed the data will still be available to you at any time in the future, how would this impact cryptographic usages?
From TFA:
"The plan is to license this technology to anyone who wants it, and we’ll teach them how to make it. But you’ll have to stand in line, we have a bunch of people queued for it. We’re doing this because, frankly, we didn’t see a hell of a lot of innovation happening out there."
Asked about the competition, Williams said: "Samsung has An even larger group working on this than we do."
Also interesting that HP got into this as buyers of technology who could not get the innovations they expected from "the market". So nowadays, it seems that to have a market function (innovate) as you would expect, you have to go and disrupt it...!
going by their market cap and the heroics of the hp management, seriously doubt HP will exists in 2013....
I'm not sure how the new CEO is yet, but man that was the stupidest crap I ever heard. I am glad they fired his ass and I hope the law suits against him hold true. I'm not one for wishing misfortune up on someone but stock holders should get back what they lost.
Or joking... your choice!
Databases are the branch of CS that will be most affected. I am unconvinced that cache will not be useful, as large storage (say, currently, petabytes) will at least have to be off-chip. However, this memory, coupled with "hardware" Transactional memory enforced via cache-coherency shakes the premises of Database theory to the core: ACID for cheap and fast with no "several orders of magnitude" to cover your sins.
Wait we cancelled all that....
We can finally dump the multiple layers of caching, look-ahead and other OS complexity
That sounds unlikely. To replace multiple layers of caching you need to come up with a technology which is not just faster than Flash and faster than DRAM, but also than cache RAM. A tall order for a single new technology.
Even if that was the case, it would have to have a uniform speed independent of size and process. Otherwise you would surely have Memristor RAMs of different price and speed. So you would again use smaller (and more expensive) Memristor RAMs to cache the bigger (and cheaper) Memristor RAMs.
It will become practical to implement neural networks in hardware. This will completely change the way we design and program software and databases.
That's been possible for a long time, slightly faster replacements for RAM and Flash will do basically nothing for that. So I'd get the opposite conclusion: software and databases won't be affected by this in any meaningful way.
Persistent and portable user sessions will become the norm. (Look at Sun Ray for an idea of how this works. [...])
Suspend to RAM is already possible, I use it on my desktop Linux machine all the time. Not needing the minimal power required to keep the RAM alive is nice, nothing more. Desktops usually have a connection to power anyway, and portables can keep that mode alive for a very long time. Portability of sessions is not affected by this at all. Sun Rays are just small boxes to run VNC clients on - sessions are portable between clients, but they stay on the very same server. Memristor technology doesn't help with that.
Didn't HP want to put an end to the hardware business and focus on software? Can someone please enlighten me because I'm probably missing something here...
When I hear about HP developing the "crossbar latch" (probably here on slashdot) in 2001...poor thought I was I bought some stock, assuming it would pay off big when HP began to reinvent things in this exact manner. It looks like that may take a few more years, but not many.
I assume this is one result of that research.
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
he's been rooted, and Windows is just pretending to update.
Never let a lack of data get in the way of a good rant.
1. Will they have on-chip hardware mediated encryption (for, say, stolen devices)?
2. Will there be a setting to force a complete reset (or do you want to have to buy a replacement to
get rid of that pesky malware... and given the venal nature of companies, will they deliberately
*not* provide that, to increase sales?
mark
Don't forget those annoying RST pins here and there. ...That has much more to do with cold boots than memory.
I sure hope this somehow doesn't put a crimp in Microsoft's plan of intimidating BOIS makers into shutting out F/OSS!
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.
Unlikely. Bus speed and lengths are already an issue. It doesn't if your storage is uniformly fast if the pipe to the processor can't keep up. The von Neumann bottleneck. Massively parallel, distributed systems would fix this, but people are really bad at thinking about problems that way, so I'm not sure how practical that would be.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
I dunno about everything being suddenly fast. Theres still the various sysbus to worry about. Information travel time is not cheap, and nor is available physical space. Memristors have to exist somewhere. Assuming their density is around the same as flash memory (per cost) either the storage space will have to be in a traditional HDD location or taking up more realestate on the already over croweded motherboards. Even assuming the memristors are all onboard, cpu cache is still several orders of magnitude faster than RAM today. I don't see an end to predictive algos for cpus or OS anytime soon.
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.
Wow, for once it's not a product (perpetually) 5 years in our future.
Of course, even a year and a half can make a huge difference. Imagine, if you will, what the market today would look like if AMD's long gestating Bulldozer processor had arrived on the scene 18 months ago. Who knows what else will arrived by then.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
In fact, this could be interesting for the regulators.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
Sounds good in theory. I bet even then though, Microsoft will still find a reason to have a giant disk-thrashing pagefile.
Why OpalCalc is the best Windows calc
Cache is used because of external bus limitations, not memory size limitations. Unless they can cram 4GB of memristor onto the die next to a cpu, there will always be an external memory bus. And there will always be registers. In fact with heavily pipelined CPU architectures you effectively have registers at every pipeline stage, not just the ones your assembler/compiler is worried about. Perhaps with huge amounts of cheap persistent memory on die we will see different architectures sometime in the future but the ones we have now can't directly work with that much.
Unfortunately, the version of disk encryption that my corporate IT department uses on my work laptop means that the hibernation system doesn't work. I can still suspend the laptop (which on a Dell means that it sleeps for maybe an hour, then decides that it's gotten too hot keeping the memory awake inside my laptop bag, so it wakes up the OS and turns on the fan, burning the rest of the battery by trying to cool itself inside the bag.) It's Windows XP, and I think the disk encryption software is from Checkpoint. Does anybody know if there are laptop bags that have enough mesh for ventilation while still providing good padding?
Other than for electricity-related reasons, the main times my laptop gets rebooted are Microsoft Windows Patch Tuesdays, or sometimes when other critical application updates come out that insist on rebooting. On the other hand, my virtual machines get rebooted a good bit more often - that's sort of the point :-)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
With completely new memory technology, say goodbye to the justly-hated RAMBUS and their patent-trolling stifling of the DRAM industry. Good riddance.
Contribute to civilization: ari.aynrand.org/donate
some indications point to memristor as good for a new sort of processor.
from wikipedia:
"HP prototyped a crossbar latch memory using the devices that can fit 100 gigabits in a square centimeter,[5] and has designed a highly scalable 3D design (consisting of up to 1000 layers or 1 petabit per cm3).[citation needed] HP has reported that its version of the memristor is currently about one-tenth the speed of DRAM.[36] The devices' resistance would be read with alternating current so that the stored value would not be affected.[37]"
100 gigabits in a square centimeter. I also read that these memristor beds are easily stacked into cubic "chips" without consequence. Wouldn't that mean E+9*9 or E+81 bits of storage per cubic centimeter?
"Stratigraphically the origin of agriculture and thermonuclear destruction will appear essentially simultaneous" -- Lee
> To replace multiple layers of caching you need to come up with a technology which is not just faster than Flash and faster than DRAM, but also than cache RAM.
That last step is what the SRAM mentioned in the article is. L1/L2 cache is made of SRAM. ("static RAM" made of transistors, the same clocked latches you saw in digital electronics class and maybe some CS classes. Different from DRAM, "dynamic RAM", which is made of capacitors that need to be periodically refreshed.)
However, I'm not entirely sure they'll get it fast enough on the timetable they give. We'll see. Replacing a flash-based SSD with memristors would already be a big deal. Replacing our big blocks of DRAM for main memory would be a really big deal, as would having them sitting directly on top of the CPU. (We're capable of making chips at a high enough clock speed that the few inches between the CPU and DRAM is enough for light speed limitations to matter!).
I don't think you thought that comment through. Which is funny, because you were busy unbundling what VM brings to the table.
Here's a case study. Two processes open the same file for writing, one of them is actively writing, while the other appears to be lurking with nothing to say. Copy-on-write is a fundamental technique for detecting write contention; best of all, detecting when write contention never actually happens. You need the ability to establish many-to-one mappings, to mark the mappings with permitted access modes (read, read/write), and the ability to trap on an access fault. COW permits a lazy fork, which is why Unix was the right answer (management at the process level), and NT wasn't (management at the thread level), to overstate by a factor of about a million, but true nevertheless.
It's possible that the OS might choose to mark some pages inaccessible in order to use access faults as a signal to help it manage physical memory locality. In fact, I'd be shocked if the technique is not already widely used, if not so much in J Random Desktop. Or did you also assume that gobs of MRAM would be on a single IO interface of a single core, forever and ever?
It seems most people encode in their mental maps that VM is the technology which fails to completely hide the fact that disk heads are the continental drift of electronic data access. When my leg heals, we throw the crutch away. VM == crutch.
You do pay a price in power consumption for the TLB lookup mechanism on every memory access. Probably get a lot of that back in the memory activity averted by COW semantics. Unless MRAM supports local page duplication, which isn't a crazy idea, given the likely width of the row access bus. But this idea never seems to survive DRAM commodity economics.
You get even more back by the billion emails your system doesn't end up sending because the TLB lookup was busy checking page execute privs, but 99.99% of people won't correctly attribute the systems theory effect to the musty deterrent so it will be another psychological no-op. What do we need Shelob for? No-one has gone through that tunnel in 1000 years.
Your call. It's funny how people so quickly presume that a technique associated with managing a point of pain exists only for that one reason. Many biologists proclaim (for dramatic effect or otherwise) that sex is an aberration that should never have occurred, since it's so much more convenient to go it alone. But the average person concludes that sex != crutch (with little true analysis), so I guess we're keeping that one, even if MRAM prevails.
As long as we have spinning platter drives, tape drives, etc. there will still be the concept of permanent files on disks.
Besides, I think the concept of files still has benefits for passing self-contained discrete chunks of data around between devices.
I'm not sure if that was a proper reply or just a stream of consciousness. :)
My only point with "memory mapped disk I/O" is that one of the uses of VM is to abstract disk I/O into regular memory accesses. Program just accesses memory, but the MMU and OS turn that into disk I/O calls behind the screens. If you don't have a disk, and instead just have one big RAM (or one big NUMA), you don't need to do that because there's no disk I/O calls to be translated to. Of course VM is still useful for other things; indeed that was my point, and I said as much.
Beyond that, I can't speak to Shelob or pop psychology or evolutionary models, but I don't think I can find them on the address bus anyway. :)
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Well, if the new stuff was magic, yes. It isn't. It's a factor 10 slower than DRAM, and that's already slow enough that we use L1, L2 and sometimes L3 cache. However, this stuff will probably require a controller chip similar to SSDs, so I expect that controller to come with 1024 Mb of GDDR L3 cache. That's sufficient to keep the L2 caches filled.
As for OS complexity, well no again. The split L1 caches per core are fundamentally complex. There's no way that we're going back to low-core CPU's with shared L1 caches.
http://www.usenix.org/publications/library/proceedings/usenix-nt98/full_papers/poster_skousen/skousen.pdf
Guys, this is the memristor we are talking about.
http://www.youtube.com/watch?v=bKGhvKyjgLY
1. Are they faster than existing flash memory?
2. Do they consume less power to make it advantageous.
3 Are they going to be less expensive?
Leslie Satenstein Montreal Quebec Canada
I do not know if memreistors have the same limitations as flash does. Things like page based writes and such make flash more disk like than memory like. however some systems like PalmOS used Flash more like ROM than a disk. So if it does work more like RAM then I say that cacheing and such will be the way to use it.
Everything else you talk about leads to one problem. It becomes very much tied to hardware. This can be a good thing in that you can get better performance but it makes moving forward much more difficult.
Using a vanilla model allows for easy porting of the OS and software to new hardware. I do not think we are holding computing back that much. I admit that am not happy with the cycle of Yet Another Unix that we seem to be in. Several OSs that had a lot of promise have faded like BeOS and even VMS but in some ways it is like the airliner industry. All new airliners are tubes with swept wings and engines mounted belwo the wings. The reason why is simple. It is the best platform for the job. That doesn't make it any less boring.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
I remember the same kinds of speculation about magnetic bubble memory years ago. If it come about as they are saying, great; if not, oh well.