Hacker News new | comments | show | ask | jobs | submit login

This is the next wave of technology. It solves so many fundamental problems. I can't wait to have a few GiB of MRAM in a workstation.

Load/store architectures may go away due to this. Imagine 32Gb of CPU registers.




> Imagine 32Gb of CPU registers.

Sounds like the most expensive context switch ever.


The point is you don't switch contexts, you maintain parallel contexts.


If that were a win (having multiple sets of registers that you can "buffer flip" between) don't you think current CPUs would implement that with, say 8 or 16 banks of registers?


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.


Isn't that what Intel's hyper-threading does?


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.


Modern CPUs have dozens to hundreds of registers. It's difficult to scale registers though due to fundamental technological limits.


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.


I don't see how you are going to fit those registers into CPU. This new kind of RAM will still be used for main memory.

The good news is we don't need hard disk any more. This will indeed change a lot of what we know about operating system.


Memristors have the possibility to perform logic as well.


I'm excited to see them used as neural networks http://www.eetimes.com/electronics-news/4088605/Memristor-em...


It only said it wad RAM speed, not register or cache speed. There are speed of light constraints in the memory hierarchy too surely?


Yes, it said it was as fast as DRAM, not SRAM (the latter is what is used for cache and registers).


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.


I was the the OP. The CPU spends a lot of time moving shit around rather than doing work.

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.

When you do this, you lose all the cache control latency and context switch overhead, resulting in a much smaller and faster core, leaving plenty of space for 32Gb on die :)

No existing architectures will do this as they rely on the memory hierarchy. I'm talking about a new architecture.


> 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....


What will that new architecture look like? ... Since I can't seem to reply to your comment...so an 8 bit processor :-) It would be interesting to pair this with the new 100 core chips.


Like zero page in the 6502.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: