2 ms·

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 regi

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.

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.