Wich algorithm

[idefix44]

LFU-R or LRU?
I use PrimoCache 0.9.2 to cache my system partition.
Windows XP32, 50GB. The Swap file is on this partition.
My system memory is 2GB and I set 256MB for the cache size. The Block size is 4KB and the overhead memory is 54.56 MB.
I choose the custom performance with read/write strategy and 10s of defer-write.
What can be the best (less wrong) for me?

Thanks for your incoming advices.

[InquiringMind]

Welcome to the forums Idefix44,

The answer depends on your file access pattern. If your system tends to access some files very often, then LFU-R would be the better choice since it retains the most frequently used. If that doesn't apply, then LRU (Least Recently Used) should be simpler/faster (the differences may not be perceptible though).

However in your case, I would definitely suggest a larger blocksize first (16KB+) to reduce the memory overhead. I would also suggest that PrimoCache may not be of much benefit on your system since you don't have invisible memory (anything over 3.25GB on a 32-bit system) which means PrimoCache is largely duplicating Windows' own file cache.

You may even slow down your system (with increased pagefile access) if your peak memory usage (this should be reported by Task Manager) exceeds 1.6GB

[CrypEd]

It is pretty easy explained.

LRU - recently used.

all previous read/writes fill up the cache in correct temperoral order, meaning the FIFO-principle (first in first out). If more recent data neeed to be cached, oldest blocks get wiped.
a good scenario would be synthetic benching, since you make sure that recent cache-data definetly will be cached.
In other word, with LRU, you force all the caches-power into your actual task.


LFU-R - freuently used.

in this mode, the cache keeps track about how frequently you use your data. so data you use more frquently will stay longer in the cache, while in full-cache situation recent-data that shows up first time might be discarded.
LFU-R is good when you frquently need to process data, while in the meantime between other reads happen that high likely wont ever happen again. in that case these data won't spamm your cache, but it's effectiveness grows with the time you use and when it is at effective usage growed and you try synthetic benchmarks on it, this high recent but not frequent data probably will not be accelerated after the second run, you would need to re-run it several times for it to replace your good-frequently data. this is the worst thing you can do with a LFU-R configured cache: spamm it with synthetic bench-data xD

My recommendation is to use LFU-R (frequently used) with system-partition and probably with your application/gaming partition, while I recommend using LRU for storage-partions containing isos, movies, or other media.

So clearly:
LFU-R: system, apps
LRU: storage

[InquiringMind]

...I recommend using LRU for storage-partions containing isos, movies, or other media.

While I would agree with much of your post, if someone is organized enough to have a separate volume for movies, ISOs, etc then I would advise not caching this at all. Files on that volume are not likely to be accessed frequently and, with media file playback, there is no benefit to higher transfer rates. So in such a case, PrimoCache would just use memory for little gain.

The one big exception is if someone is editing media files - in that case, caching them (or better yet, copying the files onto a separate, high-speed, cached volume) should provide a noticeable benefit.

Finally there are 2 unknowns in the LRU vs LFU-R argument. The first is processor/memory usage - LFU-R being a more complex algorithm will require more record-keeping. This might be an issue on a CPU-limited system (either a slow CPU or one constantly in use due to whole disk encryption, Folding @Home or other tasks).

The second is LFU-R's ability to flush no-longer used files - if a particular program was run often enough (one wit on these forums suggested CrystalDiskMark as a likely candidate ) then it might remain in cache indefinitely on the basis of past usage.

[CrypEd]

Sry but I cant follow your argue.

Files on that volume are not likely to be accessed frequently and, with media file playback, there is no benefit to higher transfer rates. So in such a case, PrimoCache would just use memory for little gain.

But recently!
Thats why i recommend LRU (RECENT... NOT frequent) for storage. Doh, i always say these acronyms are confusing.. they should just call it "Recent" and "Frequent", not "LRU" and "LFU-R".

So you not recommend to use LFU-R on storage, that's exactly what I say: You would need LRU for it. But telling LRU is no benefit (or caching at all) is wrong.

When i have a dedicated partition for ISOs and for movies. Having LRU (recent caching) active with R/W improves media playback. For example seeking inside a media-player on a file you just (recently) downloaded. You can easily see in primo-cache statistics, that the mediaplayer reads the file from RAM-cache while you ultra-fast seek through it, not possible with disabled on HDD. With caching disabled it is slow as hell, Whatever you like to edit after you download it will profit. When you save it after re-encoding within your defer-write timeout and delete the original you also benefit from TRIM. CHances are high that you loose all the benefits when using LFU-R, since it keeps track of frequently used data, whatever you recently do.

Seek-scrolling through movies on HDD is a 1-fps-Slideshow. On a SSD is a 8-fps-Slideshow. Movie in PrimoCache LRU is fluid. You do not have to wait for the player loading after seek... you simply instantly seek, that's awesome, i would not want to miss it.

So why you not recommend me seek my recently downloaded movies fast?
Or why you not recommend me ultra-fast mounting/installing recently downloaded ISOs?

just rhetorical questions.

LRU on storage sure is a blast, because storage is the place where I high likely access recent files, like ISOs or movies, that I first download to storage (write) and secondly access is (read) right after -> Recent Case.
While LFU-R is a blast for system and apps, since thats the place where I high likely frequently access files, like OS, programms, favourite games -> Frequent Case.

Whatever LFU-R needs more CPU than LRU takes more CPU, non is limiting on a nowadays PC. So when you say LFU-R may have issues on CPU-limited computers, thats perticular correct, but isn't relevant. On the same hand, when you try to improve one old computers disk-i/o you not only run into the uissue that LFU-R seems to me more limiting due to CPU but anything is limited due Mem-Bandwith xD

[InquiringMind]

OK, let me rephrase.

"Storage" data is unlikely to be accessed more than once, which is why I suggest not caching it at all.

In the case of software downloads, they'll only be used when installing which for most people should be a once-off.

In the case of media there is no benefit from increased read speed unless the hard disk cannot provide the bandwidth needed. To put that in context, the most demanding H.264/MPEG-4 hi-definition video profile (5.2 which covers resolutions up to 4,096×2,304) "only" needs 90MB/s, compared to the 150MB/s sequential speed offered by current 2TB drives. As long as the drive is defragged monthly or so, caching should be unnecessary.

Editing media is an exception which I noted above. I've never had any issues with seek-scrolling video on an (Primo)uncached drive but that's a feature I only use occasionally - someone who uses it a lot (and repeatedly jumps to the same points) may see a benefit with PrimoCache, but that seems the exception rather than the rule.

Whatever LFU-R needs more CPU than LRU takes more CPU, non is limiting on a nowadays PC.

You're likely right there - it would take some effort to produce an algorithm inefficient enough to make a perceptible difference and I think we can assume that Romex know how to code.