9 ms·

God, what a mess we are in. I can't wait for memristors to become commercialized and get TBs of register speed memory on every processor core. None of this cac

God, what a mess we are in. I can't wait for memristors to become commercialized and get TBs of register speed memory on every processor core. None of this cache, paging, NUMA nonsense.

pjc50 12y ago
This is not going to happen any time soon. Even within the core, you can't have everything at "register speed" anyway; and as soon as you have multiple sockets NUMA pops up again.
- mitchty 12y ago
  Yep memristors will be cool sure, but they aren't going to solve all our problems. Even within a core not everything will work at "register speed". I'd consider memristors to be something more helpful to our vm subsystems than anything.
dietrichepp 12y ago
This is not a problem solved by memristors. The more memory you have, the more addressing and multiplexing you need to address it. The delay in a multiplexer grows logarithmically with the number of inputs. With a cache, it is even worse, because you have to address it by the real address, not the address in cache. So there will always be a hierarchy of speeds, unless you can figure out a completely different way to design a multiplexer. In the best case scenario, memristors give us TBs of NVRAM.
- simula67 12y ago
  I am not a hardware designer, but are you saying one large 64 bit multiplexer to access the whole memory would be impractically slow ? Even if we don't get register speed, it would simplify software design, wouldn't it ?
  - nhaehnle 12y ago
    I'm not dietrichepp, but that's the gist of it. Look into how multiplexers are actually implemented, and it becomes painfully obvious that hardware cannot magically solve your problems. And the "even if we don't get register speed" already applies today. In a sense, your system does have one large multiplexer to access all of memory. It's called the memory controller. The point is that this is painfully slow and far from register speed, so caches are built on top of it to make it faster. The same applies to disk access.
  - dietrichepp 12y ago
    Yes, it would be slow and large. Because it's large, you'd get less memory in the same area. Another factor is that RAM and CPUs are usually on completely different dies to begin with, which are manufactured with somewhat different processes so you can't just copy and paste them onto the same chip. Incidentally, this is what computers looked like 30 years ago. You could have a CPU with a bunch of address and data pins wired up to a RAM chip that would give you whatever address you wanted right away. Loosely speaking, a modern computer still works the same way, but memory speeds haven't kept up with CPU speeds. So, to make our software run faster, we put layers of smaller, faster memory between the CPU and the larger, slower memory. But the hardware hides all of this from the software: you don't have to care, unless you want to optimize things. So we have registers, L1 cache, L2 cache, RAM, SSDs, HDDs, and the network. You can write a program today and all seven layers of caching might be mostly transparent, some more so than others. A lot of this complexity is in the hardware, and other parts of it are in the OS. Application developers have it easy.
- sp332 12y ago
  We could throw away von Neumann architecture, move computation out to the data, and build an ALU per every 32k of memory (plus some FPUs here and there). That gives us 33.5 billion compute units per TB of register-speed memory :)
  - 314 12y ago
    The programming model would look a lot like a GPU does today. If computation was regular and uniformly distributed across the memory then life would easy and everything would work quickly. When computation patterns get chunky there would be a hellish fight to make it fit the architecture. So processing trees and graphs would require a lot of tricky coding to work around the memory model.

God, what a mess we are in. I can't wait for memristors to become commercialized and get TBs of register speed memory on every processor core. None of this cache, paging, NUMA nonsense.

pjc50 12y ago

This is not going to happen any time soon. Even within the core, you can't have everything at "register speed" anyway; and as soon as you have multiple sockets NUMA pops up again.

mitchty 12y ago
Yep memristors will be cool sure, but they aren't going to solve all our problems. Even within a core not everything will work at "register speed". I'd consider memristors to be something more helpful to our vm subsystems than anything.

dietrichepp 12y ago

This is not a problem solved by memristors. The more memory you have, the more addressing and multiplexing you need to address it. The delay in a multiplexer grows logarithmically with the number of inputs. With a cache, it is even worse, because you have to address it by the real address, not the address in cache. So there will always be a hierarchy of speeds, unless you can figure out a completely different way to design a multiplexer. In the best case scenario, memristors give us TBs of NVRAM.

simula67 12y ago
I am not a hardware designer, but are you saying one large 64 bit multiplexer to access the whole memory would be impractically slow ? Even if we don't get register speed, it would simplify software design, wouldn't it ?
- nhaehnle 12y ago
  I'm not dietrichepp, but that's the gist of it. Look into how multiplexers are actually implemented, and it becomes painfully obvious that hardware cannot magically solve your problems. And the "even if we don't get register speed" already applies today. In a sense, your system does have one large multiplexer to access all of memory. It's called the memory controller. The point is that this is painfully slow and far from register speed, so caches are built on top of it to make it faster. The same applies to disk access.
- dietrichepp 12y ago
  Yes, it would be slow and large. Because it's large, you'd get less memory in the same area. Another factor is that RAM and CPUs are usually on completely different dies to begin with, which are manufactured with somewhat different processes so you can't just copy and paste them onto the same chip. Incidentally, this is what computers looked like 30 years ago. You could have a CPU with a bunch of address and data pins wired up to a RAM chip that would give you whatever address you wanted right away. Loosely speaking, a modern computer still works the same way, but memory speeds haven't kept up with CPU speeds. So, to make our software run faster, we put layers of smaller, faster memory between the CPU and the larger, slower memory. But the hardware hides all of this from the software: you don't have to care, unless you want to optimize things. So we have registers, L1 cache, L2 cache, RAM, SSDs, HDDs, and the network. You can write a program today and all seven layers of caching might be mostly transparent, some more so than others. A lot of this complexity is in the hardware, and other parts of it are in the OS. Application developers have it easy.
sp332 12y ago
We could throw away von Neumann architecture, move computation out to the data, and build an ALU per every 32k of memory (plus some FPUs here and there). That gives us 33.5 billion compute units per TB of register-speed memory :)
- 314 12y ago
  The programming model would look a lot like a GPU does today. If computation was regular and uniformly distributed across the memory then life would easy and everything would work quickly. When computation patterns get chunky there would be a hellish fight to make it fit the architecture. So processing trees and graphs would require a lot of tricky coding to work around the memory model.