Resolved Why exactly is RAM faster? Can we achieve that speed with all components?

[revmacian]

First of all, I'm not even sure where this thread belongs so please forgive me if I posted in the wrong location.

I'm not just a computer consumer. In fact, I'm not sure what my label should be because I don't just purchase an item, I like to get down into an item to understand exactly how and why it operates the way it does. The main reason is that I enjoy physics and engineering. Another reason for that is, once you understand how a device works it is much easier to solve a problem yourself instead of relying on someone else to do it for you. That being said, I would like to understand something about computer components.

I have been building desktop computers for over a decade, it started when I moved from Microsoft windows to GNU/Linux in 2001 - Linux just seems to make you want to learn more. Only recently have I become interested in learning exactly why something works - going as far as to understand why the letter L, instead of a "Y" or a "J", appears on the screen when I press the "L" key on the keyboard.

It is my understanding that the RAM on a computer is the fastest storage component. The drawback is that RAM is volatile memory - RAM is wiped when power is removed.

So, my question is: why can't all storage components on a computer be exactly the same speed as RAM yet non-volatile? Does this have to do with number of transfer lanes? BUS? What exactly causes a speed difference between volatile memory and non-volatile memory?

Disclaimer: I am operating on knowledge and experience that is likely a decade old so some of this post may seem silly.

 

[bsamcash]

Being volatile is the very reason it is so fast. The usual analogy is your work desk versus a filing cabinet. You can quickly throw all of your papers on your desk and shuffle threw them very quickly, but that's not an efficient way to store them. When you want to store them long term you file them away, but then it takes longer to pull them out when you need them. That plus direct channel to the CPU.

 

[Erehy Dobon]

.

 

[revmacian]

Being volatile is the very reason it is so fast. The usual analogy is your work desk versus a filing cabinet. You can quickly throw all of your papers on your desk and shuffle threw them very quickly, but that's not an efficient way to store them. When you want to store them long term you file them away, but then it takes longer to pull them out when you need them. That plus direct channel to the CPU.

So, I'm assuming from your post that non-volatile memory must contain a map or set of pointers that tell the system where in memory each file can be found and it is this "look up" time that slows things down? This reminds me of the way old hard drives worked when a file was requested by the system - seek time.

So, if we have a 64GB RAM module and a 64GB SSD, why can't the SSD use the same type of storage layout that the RAM uses? After all, it does appear to be faster even though it is less efficient. Does RAM efficiency degrade over time?

 

[bsamcash]

So, I'm assuming from your post that non-volatile memory must contain a map or set of pointers that tell the system where in memory each file can be found and it is this "look up" time that slows things down? This reminds me of the way old hard drives worked when a file was requested by the system - seek time.

So, if we have a 64GB RAM module and a 64GB SSD, why can't the SSD use the same type of storage layout that the RAM uses? After all, it does appear to be faster even though it is less efficient. Does RAM efficiency degrade over time?

It can, but the kernel has to be written for that purpose. To back out of the analogy, the RAM holds whatever the CPU is currently processing. The program is written to hold itself into memory when it is being processed. But there really isn't a reason the RAM can't also be used for storage if the kernel allows it and the program is written for it. The reason it isn't traditionally is because RAM is at a premium where traditional storage is cheap. But there are Linux distros written to be ran completely from memory since they're so small.

 

[revmacian]

Actually, the fastest memory is Level 1 CPU cache. This memory is really fast but very expensive to produce. What CPU manufacturers do is have tiered levels of CPU cache: L1, L2, L3. Each one is progressively slower but typically larger due to costs.

Way back in the Nineties, Intel released Celeron CPUs with very little or no cache. This crippled performance but reduced costs.

RAM is accessed when whatever the CPU is doing doesn't fit into the onboard cache. When you run out of RAM, the system pages to disk. Again, each resource is slower and cheaper than the previous.

That's why server grade CPUs have larger cache sizes than desktop CPUs which in turn have larger caches than mobile CPUs.

When you buy a computer, if there are CPU upgrade options often the upgraded CPU has a larger cache.

This seems to point to the differences in manufacturing processes between L1, RAM and SSD. While I do understand that there are differences, I don't quite understand what those differences are. I recently studied how transistors work. Aren't L1, RAM and SSD all using transistors? Does the difference have to do with the nanometer process between the various components? Number of transistors? I suppose number of transistors would make a difference in monetary expense.
[automerge]1579374042[/automerge]

It can, but the kernel has to be written for that purpose. To back out of the analogy, the RAM holds whatever the CPU is currently processing. The program is written to hold itself into memory when it is being processed.

I watched a video about the Scott CPU and it blew my mind how much work a CPU typically does. It reminded me a lot of how things worked when I was learning how to code in assembly years ago.

But there really isn't a reason the RAM can't also be used for storage if the kernel allows it and the program is written for it. The reason it isn't traditionally is because RAM is at a premium where traditional storage is cheap. But there are Linux distros written to be ran completely from memory since they're so small.

Ah yes, I do remember running Knoppix, MEPIS and Puppy Linux during my GNU/Linux years. These distros were loaded into a RAM drive and operated directly from there even on a computer that didn't contain any hard drive. But, it did make me aware of the advantages of running an OS from a read/write system (HDD) versus running an OS from a read-only file system (CD-ROM).

 

[hughm123]

RE: "This seems to point to the differences in manufacturing processes between L1, RAM and SSD. [...] I don't quite understand what those differences are. [...] Aren't L1, RAM and SSD all using transistors?"

There are multiple differences:

1. Different storage types use different memory cells which have different read/write performance:

- SRAM (L1) and DRAM (main memory) both use transistors, but each SRAM cell has 6 transistors versus 1 for a DRAM. This and the fact DRAM is optimized for density versus speed means DRAM is unavoidably slower than SRAM. Meanwhile the cell size difference is why SRAM cannot be used for main memory

- All of the non-volatile types use a mechanism other than transistor switching for writes which is almost always slower. For example Flash uses tunneling for erase which is very slow, in part because there is a tradeoff to make sure the cell does not lose it's state via tunneling when not selected. There are other non-volatile memory options (MRAM, FeRAM, PCM, etc.) but these are all slower than SRAM and normally also slower than DRAM. All of the non-volatile types (especially the new ones) also have limits of the number of program/erase cycles before wear-out

2. Larger storage arrays (L3, main memory, SSD) need to be physically larger which makes the access time slower because of the time to get to distant parts of the array and back. There is also significant latency added by hardware/software arbitration logic (since L3/memory/SSD is shared between CPU cores).

Someone asked about using SRAM as RAM. The "Cell" processor from Sony and IBM was one example of this. The problem was that if your program's data was bigger than 256KiB then the program needed to manually swap data in and out. This was not a commercial success -- most programmers prefer the cache system to do this automatically, generally with some prefetching to optimize speed. It is technically possible though and some embedded CPUs may do this.

 

[revmacian]

RE: "This seems to point to the differences in manufacturing processes between L1, RAM and SSD. [...] I don't quite understand what those differences are. [...] Aren't L1, RAM and SSD all using transistors?"

There are multiple differences:

1. Different storage types use different memory cells which have different read/write performance:

- SRAM (L1) and DRAM (main memory) both use transistors, but each SRAM cell has 6 transistors versus 1 for a DRAM. This and the fact DRAM is optimized for density versus speed means DRAM is unavoidably slower than SRAM. Meanwhile the cell size difference is why SRAM cannot be used for main memory

- All of the non-volatile types use a mechanism other than transistor switching for writes which is almost always slower. For example Flash uses tunneling for erase which is very slow, in part because there is a tradeoff to make sure the cell does not lose it's state via tunneling when not selected. There are other non-volatile memory options (MRAM, FeRAM, PCM, etc.) but these are all slower than SRAM and normally also slower than DRAM. All of the non-volatile types (especially the new ones) also have limits of the number of program/erase cycles before wear-out

2. Larger storage arrays (L3, main memory, SSD) need to be physically larger which makes the access time slower because of the time to get to distant parts of the array and back. There is also significant latency added by hardware/software arbitration logic (since L3/memory/SSD is shared between CPU cores).

Someone asked about using SRAM as RAM. The "Cell" processor from Sony and IBM was one example of this. The problem was that if your program's data was bigger than 256KiB then the program needed to manually swap data in and out. This was not a commercial success -- most programmers prefer the cache system to do this automatically, generally with some prefetching to optimize speed. It is technically possible though and some embedded CPUs may do this.

Wow, surprisingly I understood everything you said and it all makes sense.. I now have a better understanding of how my computers work. Thank you for your knowledge!