SSD / RAM speeds, a pointless question.

Where are you going to execute the software if you have no RAM?

ChatGPT is your friend. "how long does it take to get a byte of data from L1 Cache, Main RAM, NVME SSD."

Ask how long it takes to load a single integer data value from: L1 Cache, Main RAM, NVME SSD.

Back in the days when the world was young we used to use the analogy that getting a byte of data from L1 cache was a trip to the kitchen, getting it from a Hard drive was like a trip to the Moon.

Now it seems the trip to disk is only comparable to about the length of the UK.

The number of computers I have crashed by using all their RAM for cache :-).

Modern PCs rely on multiple levels of CPU cache, to return data in single digits of clock cycles, trying its hardest to avoid doing expensive fetches from RAM at maybe a hundred clock cycles, and if it had to fetch from SSD that'd be tens of thousands of clock cycles

So if everything was SSD, it'd be glacially slow.

Since the question was pointless, you might like a pointless observation, which is ...

That dynamic RAM is a cheapskate poor relation to "proper" static ram.

I seem to recall that when DRAM access times were reduced to around

- this would have been around 1981 / 82 ?

At the time I was working on a system which used a Motorola MC68020 and some time was spent considering an upgrade from 20MHZ clocks to 25MHZ clocks. The idea was shelved, pending availability of faster static RAM because the only other option would be to insert one or more wait states in to every access.

Apparently theres a school of thought that says there is some technical advantage in keeping the ram clocks going at full speed, even if you have to insert 20 wait states in order to do so - I am not so sure

TBH I am a bit surprised that we are even discussing this. Although DRAM speed and density have been increased dramatically over the years, its astonishing that the technology has hardly changed in around 50 years, and that "Electrically Alterable" ROM (EAROM) was introduced more than

Also "RAMless" microcontrollers were around at least 40 years ago because they had a small amount of on chip (I assume static) RAM. Theres probably several dozen variants of the Intel 8051 configured like that, among many others

If you want glacially slow, try my Pentium 3 Dell desktop. But it still runs Zoneminder, so it hasn't died yet.

I have been involved on the periphery of modern memory controller design. It is extraordinary how much is going on.

What's more, the smallest unit you can read from an SSD is likely to be 4KB. If you have no RAM to put it in you'd have to read that for each byte (or whatever unit you want).

Writing would be even worse; a block has to be cleared before it can be written, so you'd immediately run out of cleared ones. And each block can only be written so many times - of the order of 1000s for a consumer SSD.

-- Richard

I'd guess that's using a fair amount of electricity compared to say a Mac Mini or a mini PC - 60W/hr compared to 15W/hr?

So come the time . . .

I bought a brand new Desktop PC, and a new camera input card, to replace the Dell. I could not get the card to work, even with the help of the manufacturer, and the updated Zoneminder had so many bells and whistles that it didn't appear to do the basics. So the new PC is now my main Desktop PC.

Programs wouldn't have to be loaded into RAM as they could run in situ. Maybe just RAM for temporary data; or maybe not even that.

Bit like home micros like the BBC (or Master), which ran its in-built programs (BASIC interpreter, spreadsheet, text editor, word processor) from ROM.

That would require SSD blocks or pages to be able to be mapped into address space, which might be possible with NVMe storage but not SATA.

Well the first thing to say is that SSDs ARE RAM. And probably lower energy than DRAM.

The second is that that is how computers worked in the 1950s. a couple of K of ferrite bead store and tape drives. Need to call a subroutine? Roll it in from tape, execute it and then reuse that RAM for the next one. COBOL is structured to work with that architecture.

No different from running from a CD or DVD. Or an SD card if its a PI :-)

It's all been done., You juggle cost, performance, power consumption and so on to get the best compromise for the application.

Never heard of Swap?

yes, that's done *by* the operating system, not the SSD hardware

So would be "SSD blocks or pages to be able to be mapped into address space,"

not if the isn't any RAM to load them into.

The power consumption of an SSD and the RAM in a typical desktop computer fairly similar - of the order of 10W. The power relative to the storage size will be lower for the SSD, but the vastly faster access to RAM means that the energy to access a byte from SSD would be much greater than the energy to access a byte from RAM.

Executing directly from an SSD would be the very opposite of that.

I don't see anything in Cobol that's particularly suitable for that. Overlays were used in numerous languages on machines that didn't have demand paging, which achieves a similar effect at the OS level.

ROMs appeared in the address space at the hardware level. Access times were similar to RAM. CDs and DVDs are nothing like that.

-- Richard

Don't be silly. Mapping something into address space does not insist on there being any RAM at all

The underlying memory mappers could map anything in - hard drives, tapes, SD cards. SSDs. Spinning rust.

With hardware memory management so can disks etc. Once you have eliminated local RAM, you just use hardware to map in sectors of rust or tape or ROM or anything you want, Of course accessing any of them byte by byte is extremely slow, which is why you have at least minimal RAM - say a sectors worth - in the first place. You cannot directly access an SSD as if it were normal RAM. Even ROM may need hardware wired wait states,

SSDs may be faster but they do nor 'exist in the CPUs address space' Nor really could they.