The first x86 assembler snippet, example 1(a), on page 2 is really amusing. It shows a profound lack of experience with x86.
SoftRAM 95 (1996)
21–30 of 64 posts
Re: SoftRAM 95 (1996)
#22I went half in on "RAM Doubler" with a friend. He had their other products that were an uninstalled and some other goofy utilities. It didn't do jack. At the time (1996?) RAM was cheap enough to just buy another 8MB instead of some software
RAM Doubler for the Mac wasn’t a scam. Because of the piss poor way that Classic MacOS handled memory where you had to manually tell it how much memory an application could use and applications needed that much contiguous memory, you could easily find yourself with plenty of RAM but it being fragmented and unusable. Also, you needed to have as much disk space as you had RAM + any “virtual memory”. RAM Doubler used th…
Re: SoftRAM 95 (1996)
#23>While this seems an easy relationship to satisfy, more-complex models based on real-world performance parameters and access patterns indicate that it is, in reality, very difficult to obtain a performance boost with this method. Now that improvements in CPU speed have outpaced improvements in storage speed, it's easier to benefit from compressed swap in ram. Linux includes "zswap"[0], which in my experience works we…
Storage speed has really outpaced CPU speed for the decade zswap has been out. It still has its place but if you have modern flash storage it may well be a throughput drop and power usage increase to enable zswap (particularly with the default algorithms). Latency for pulling single pages has never really been limited by CPU performance, that's always been faster and will probably never change due to physics.
Re: SoftRAM 95 (1996)
#24I went half in on "RAM Doubler" with a friend. He had their other products that were an uninstalled and some other goofy utilities. It didn't do jack. At the time (1996?) RAM was cheap enough to just buy another 8MB instead of some software
RAM Doubler for the Mac wasn’t a scam. Because of the piss poor way that Classic MacOS handled memory where you had to manually tell it how much memory an application could use and applications needed that much contiguous memory, you could easily find yourself with plenty of RAM but it being fragmented and unusable. Also, you needed to have as much disk space as you had RAM + any “virtual memory”. RAM Doubler used th…
Re: SoftRAM 95 (1996)
#25Earlier quoted context omitted.
RAM Doubler for the Mac wasn’t a scam. Because of the piss poor way that Classic MacOS handled memory where you had to manually tell it how much memory an application could use and applications needed that much contiguous memory, you could easily find yourself with plenty of RAM but it being fragmented and unusable. Also, you needed to have as much disk space as you had RAM + any “virtual memory”. RAM Doubler used th…
Speed Doubler also added multi-threaded copying to the Finder long before Apple did. Without Speed Doubler you couldn’t copy a file and do anything else at the same time (aside from switch to already-running background applications). Just that was worth the price of admission
Re: SoftRAM 95 (1996)
#26>While this seems an easy relationship to satisfy, more-complex models based on real-world performance parameters and access patterns indicate that it is, in reality, very difficult to obtain a performance boost with this method. Now that improvements in CPU speed have outpaced improvements in storage speed, it's easier to benefit from compressed swap in ram. Linux includes "zswap"[0], which in my experience works we…
Storage speed has really outpaced CPU speed for the decade zswap has been out. It still has its place but if you have modern flash storage it may well be a throughput drop and power usage increase to enable zswap (particularly with the default algorithms). Latency for pulling single pages has never really been limited by CPU performance, that's always been faster and will probably never change due to physics.
That's probably shifted as everyone moves to PCIe based storage solutions, particularly on the low-mid range phones that don't have super high performance cores.
Re: SoftRAM 95 (1996)
#27>While this seems an easy relationship to satisfy, more-complex models based on real-world performance parameters and access patterns indicate that it is, in reality, very difficult to obtain a performance boost with this method. Now that improvements in CPU speed have outpaced improvements in storage speed, it's easier to benefit from compressed swap in ram. Linux includes "zswap"[0], which in my experience works we…
Re: SoftRAM 95 (1996)
#28I went half in on "RAM Doubler" with a friend. He had their other products that were an uninstalled and some other goofy utilities. It didn't do jack. At the time (1996?) RAM was cheap enough to just buy another 8MB instead of some software
RAM Doubler for the Mac wasn’t a scam. Because of the piss poor way that Classic MacOS handled memory where you had to manually tell it how much memory an application could use and applications needed that much contiguous memory, you could easily find yourself with plenty of RAM but it being fragmented and unusable. Also, you needed to have as much disk space as you had RAM + any “virtual memory”. RAM Doubler used th…
So it was the cloud, essentially.
Re: SoftRAM 95 (1996)
#29Earlier quoted context omitted.
Storage speed has really outpaced CPU speed for the decade zswap has been out. It still has its place but if you have modern flash storage it may well be a throughput drop and power usage increase to enable zswap (particularly with the default algorithms). Latency for pulling single pages has never really been limited by CPU performance, that's always been faster and will probably never change due to physics.
It's not like you really want to use SSD for frequently used swap though, it's just going cause unnecessary wear.