It's still not a replacement for DRAM, though. The article says it can only take a million rewrites before failing. Depending on what a computer is doing, I'll bet the main memory can easily hit that limit in days to weeks.
The thing is that architecturally nothing has really changed from 70's. And even if it did, Oracle cannot just go and tweak some "magic numbers" (what would those be?) since the idea of spinning plates at the end of a long and perilous pipeline is at the core of any contemporary DBMS. To change this you cant just assign a junior developer for a week or two to "optimize" for SSD.
It is an monumental effort requiring that you throw away and/or revisit every presumption you made in the last 30-40 years that it took to build these DBMS.
It is similar to introduction of internal combustion engine to the world of horse and carriage.
At first glance, just mount the engine on the carriage and voila! It turns out that carriage was fundamentally changed to accommodate the internal combustion engine. To the degree that besides four wheels, modern ICE powered carriage looks nothing like old horse powered carriage.
The thing is that architecturally nothing has really changed from 70's.
Which is my case exactly. Despite going from KB of main memory to TB, and from a few MB of hard disk to PB, "nothing has changed". What makes you think this case will be different?
And even if it did, Oracle cannot just go and tweak some "magic numbers" (what would those be?) since the idea of spinning plates at the end of a long and perilous pipeline is at the core of any contemporary DBMS.
I was talking about the OS level, not Oracle's. Tuning virtual memory and related pipelines.
And, no, the "idea of spinning plates" it's not "at the core" of DBs. Don't even know what you imply by this. That, for some reason, Oracle say wouldn't take advantage and run orders of magnitude faster on pure dynamic memory? Oracle --and all DBs-- already runs just fine on non spinning SSDs. And most DBs already have special tunings to keep the working set or even everything in the main memory, and never touch the disk. That the underlying storage is a spinning platter of some dynamic memory 100 or 1000 times faster will not matter much.
There is an architecture revolution to be had, but it isn't as easy carving off a high speed bus from the CPU and turning your database speed up to a factor of 20.
If the write lifetime is a million writes, at 10ns/write you can burn that up in a millisecond.
Maybe you trust your server hardware to last for three years. You get about 38 writes per hour. I hope you aren't syncing a critical chunk of data once a minute.
So you have an insanely fast, nonvolatile store, but you can't just write to it willy-nilly. Let the engineering begin! (I'm sure it has for some people.)
 Malware can be expensive in a hurry. A couple quick loops and you can ruin 1000 blocks/second.
 If you have less than a few dozen servers you end up playing quality roulette. You have no idea which models from which vendors are going to hold up, so you make a guess based on reputation and price. Sometimes you are right, sometimes you are wrong. Sometimes you have a 50% mortality in 6 months. When you get a model that works well, by the time you know it lasts, you can't buy it any more. My strategy was always to buy a batch, run them in non-critical positions for 6 months to screen for early failures, if they were good, move the critical functions to them, but then get off of them before the age related failures begin. Three years was about my limit.
They do. SPARC64 has hardware contexts. Technically, the architecture wouldn't require this. A process's state would be a mapped linear segment of memory so you can have as many contexts as you can fit in RAM. There is no need then for traditional "save everything" context switching. You just move the CPU's execution context to a different area in RAM and the context is there.
AFAIK the main problem with hyper-threading is cache contention (two hyperthreads on the same CPU thrashing each-other's cache).
Anyway, I fail to see the point of this discussion, TFA states that MRAM attains speed comparable to that of the DRAM, which is much slower than CPU cache (at least one or two orders of magnitude slower), so that won't go away just now.
Also, the article speaks of "write speeds" (whatever that means) of tenth of nanoseconds but says nothing of latency. I suppose there are no refresh periods, which might improve over DRAM a little. It all seems very vague so far, I'm looking forward for some more technical and all-encompassing performance numbers.
Agreed on all points. This is a total gamechanger in terms of hardware and software architecture. Even if it follows the relatively-slow uptake of SSD's it completely revolutionizes the *aaS side of the net.
Amazon is a big player with AWS and this is the perfect opportunity for someone to come in and eat their lunch and change everything.
A memristor is a smaller and simpler component than once register cell. Due to this, leakage and speed of light are less of an issue than the current techology. I wouldn't expect replacement for a decade though.
That may be, but OP was talking about having 32 Gb of registers and obsoleting load/store instructions. Current technology doesn't have 32 Gb of SRAM in registers, it has less than 1k. Even if the cost of SRAM wasn't an issue, I would be surprised if you could increase the size of the register file by 30,000,000x while maintaining the same latency and throughput characteristics.
> My point is to remove the distinction between the register file and the main memory so that the entire CPU's working set is linear and no copies are required, therefore drastically increasing speed.
That has been tried several times before. As long as small is "enough faster", small&fast+large+overhead beats large. (In really fast processors, active register values are lots of places, so they don't even access the register file except for values that haven't been used for a while.)
> When you do this, you lose all the cache control latency and context switch overhead, resulting in a much smaller and faster core,
Huh? Context switch overhead is time, not space. Cache control is negligible space.
> leaving plenty of space for 32Gb on die :)
Not yet you don't. None of this stuff is as dense as dram and DRAM is just now hitting 4Gbit. Since fast processors do take some space....
Memristors will have a major impact on hardware architecture in the near to medium term. They promise permanent storage not just without the costs imposed by SSD (much slower performance than DRAM), but also random access without the costs imposed by hard drives (variable seek times depending on how data happens to be laid out on physical discs).
IMHO the impact on software architecture is likely to be much less pronounced at first, because software ecosystems -- OS kernels, libraries, utilities, applications, etc. -- can evolve only gradually over a period of many years. Consider that Ken Thompson and Dennis Ritchie reportedly created the /usr directory because they ran out of space on a 1.5MB hard disk (!) more than 40 years ago (!), yet we're still living with this directory ( see http://lists.busybox.net/pipermail/busybox/2010-December/074... ).
This is actually a valid point, most modern encryption schemes rely on the fact that the RAM can't be dumped easily.
I guess you could keep at least some volatile memory for storing sensitive information such as encryption keys. Of course unless the rest of the MRAM is encrypted you may indeed leak potentially sensitive data.
Maybe dedicated hardware could encrypt/decrypt the RAM contents on the fly when the CPU or the devices access it, but it sounds costly.
Processor cache could easily hold the encryption keys.
Now that memory controllers are integrated to modern CPUs, this could be achieved quite easily when revamping the architecture, adding a couple of special instructions.
Interesting link. However it doesn't solve the security issues caused by non-volatile unencrypted system memory. I guess custom hardware could encrypt/decrypt the data going trough the memory controller on the fly.