| Performance boosting disc cache developed |
|
Published: 15th Oct 2005, 13:30:01GMT Source: drobe.co.uk
By Chris Williams
|
| Page 1 of 1 |
|
| Third party developer wants to give Filecore a hand |
|
The primary motto of RISC OS is 'doing more with less', meaning it tries to get the most of the hardware it's running on. This is true for older Acorn kit, but less true for more modern platforms. One area that could do with attention is disc caching, and Dominic Beesley has begun an attempt to implement this. He hopes to gather some brave users to test drive his work in order to find out how effective his disc cache is.
 Disc caching works by storing large chunks of frequently used files in free memory, so that when an application tries to access a particular file, the operating system can refer to the copy kept in RAM rather than tell the hard disc (or some other storage media) to locate the file. It's considerably faster to read from and write to memory than access a hard disc, so therefore performance is increased. The operating system has to ensure that at some point the data in memory is written back to the disc for safe keeping. This caching operation is transparent to the user and application software, as they are not aware of these internal optimisations being performed by the operating system.
ADFS already employs a set of buffers but they reportedly work in a limited fashion. Dominic's module uses a 16M cache with read-ahead and write-through features. This means the cache makes an educated guess as to which data the user is going to access next and preempts this by copying the files to memory beforehand. Write-through works by writing data directly to disc as well as the cache, minimising the amount of data lost if the computer were to suddenly crash or lose power. This sacrifices a potential performance boost to writing operations, though.
Dominic said, "The cache works by sitting between Filecore, the part of RISC OS that knows what to read and write to discs, and the low-level device drivers: ADFS, SCSIFS, and IDEFS, which know how to drive specific pieces of equipment. Calls to the low level drivers to read or write a block from the disc are intercepted, and if the information is in the cache, the cache is used instead of the disc. It's actually fairly simple."
With the disc cache module enabled, seconds are shaved off building projects with the Castle C++ compiler and applications including !PDF are "smoother" to use. Dominic added, "I'll be including a little benchmark suite - nothing too scientific yet - with the test suite to see what sort of improvements in speed are noted on different hardware sets. I've not done too much in the way of benchmarking yet though as I'm more interested in getting it bulletproof stable and then speeding things up."
The software is not Iyonix compatible, however, because of its low level nature and a lack of a machine to test it on. He hopes to in the future improve the read-ahead algorithm and enable write-behind buffering to that data sent to a hard disc is grouped together to boost performance. The buffer cache could also expand and shrink intelligently according to how much free memory is available in the system, and Dominic says the algorithm that decides what stays in the cache could be improved. Support could also be added for CDFS and non-Filecore devices, and correct handling of removable media.
To alpha test Dominic's work, see the link below. He's currently considering whether or not to open source the module, or charge cash for it, depending on how well received it is and if he can get it to work for the Iyonix and A9.
Links
Dominic's disc cache announcementRelated articles
Blu-ray disc burn breakthrough
This article has been linked to, or is available in the following formats:
|
| |
|
joty (+2.7)
15/10/05 9:09PM |
I'm not convinced that caching at FileCore level is the best strategy. I think it is much better done at FileSwitch level.
1. All (buffered) FS will be cached then (even network onces).
2. When a file gets deleted or its filesize gets changed, you know that cached memory blocks of that file can be reused with zero penalty. Likewise for directory contents caching.
3. As further enhancement you can prefetch cache filecontents (especially with random access file access), either by reading more data than initially requested, either via callbacks (reentrant FS only I suppose and rather tricky).
Probably more complex than dominic's approach but I assume with better caching strategy possibilites and performance. |
mrchocky (+1.0)
16/10/05 2:46AM |
Under Linux (and similarly under some other operating systems), much of the system's free memory is used for caching - since it obviously isn't being used for anything else this is a good idea, and it's naturally built into the OS in the way John suggests. |
AJW (+1.0)
16/10/05 12:10PM |
I wouldn't want network filing systems cached without the knowledge of the FS, as that would cause cache consistency problems. It would be really nice to see the whole filing system structure get an overhaul so things like this could be implemented in a sensible manner. |
joty (+3.0)
16/10/05 2:14PM |
To AJW:
I don't see why there would be cache consistency problems by definition when caching is done at FileSwitch level.
You monitor and/or intercept the usual FS vectors (OSFileV, OSArgsV, OSGBPBV, etc). For file/dir changes done on the server or via other clients you need extra code : when your code catches upcalls too of files/dirs being changed, you can update your file/dir cache contents if needed (I believe this is already enough for Access). When you're using file contents from your cache, the cache code can always do a quick OS_File 5 alike call to your network FS to see if there file is still there on the server (actually FileSwitch itself already does this before loading a file, I'm not sure if this is intentional and something you can rely on). I'm pretty sure you can find plenty of practical approaches to avoid cache consistency issues in open source network FS client code. This is not a RISC OS specific subject after all.
And nobody is saying that all buffered FS need to be cached, just leave it as an option to specify which FS people want to be cacheble.
Caching CDFS would probably worthwhile enough to do caching via FileSwitch. And I'm wondering what the difference in performance increase would be between dominic's approach and FileSwitch caching on SparkFS behaviour. The former will cache the compressed file contents only, FileSwitch based caching can cache compressed and/or the uncompressed file contents. FileSwitch based caching strategy could make much intelligent decisions based on the file spec, filetype or file locations for judging which files have higher priority to get into the cache or even better leave them alone uncached (think Wimp$Scrap, !Sprites, !Boot and !Run).
"It would be really nice to see the whole filing system structure get an overhaul so things like this could be implemented in a sensible manner"
I don't see how an overhaul of FS structure could help caching more than what we already have today. IMHO it can be implemented in a sensible manner right now (and I don't want to imply Dominic's approach is not sensible, I just think it could be done better but with more effort I guess). AJW, could you explain this more what you mean ? |
Jaco (+0.0)
16/10/05 3:19PM |
If you think there is a better way then do it yourself or contact the programmer to help him.
There are a thousands of option to implement something... you will have to choose one and some will always think another option is better. No use discussing that here it's even counter productive. |
mrchocky (+1.0)
16/10/05 4:38PM |
In reply to Jaco:
that's a rather odd thing to say. There clearly are superior ways for it to be implemented; although some of them may be impractical due to the design of the OS. To work out which and for people to understand why, discussion is precisely what is required. |
AJW (+1.0)
16/10/05 8:38PM |
In reply to joty:
OK, it might be possible to avoid the cache consistency issues, but that's not going to be the most efficient way of doing it (OS_File 5 may not be that quick - it can require several network round trips in some cases). Some protocols such as NFS have support for caching, which is going to result in a much better system if they can integrate with the caching system in use. |
hubersn (+1.0)
17/10/05 10:25AM |
Let's replace CDFS first before thinking about cacheing it... |
disccache (+6.4)
17/10/05 4:08PM |
In reply to Joty:
Yes, I'm looking at all those too...however at the lower level I know where the contents are going to go on disc and can put in some improvements in terms of grouping and ordering (writing multiple blocks in order in one go) i.e. small files in a directory. I am hoping to extend out to fileswitch caching at a later date and allow it to be configured either way. I understand the pros and cons of both ways of doing it. I went for the filecore route as that was what I wanted to do at the time. However I now realise just how slooooow filecore can be sometimes so may well revise.
To chocky: The cache is fixed size at present for testing, but I'm hoping to be able to use all (or a percentage of) free memory and resize as necessary...this may or may not be practical though. It'll mean quite a bit of poking around with dynamic areas.
I'll be collecting all the replies up and will try and send out the test suite by the end of next weekend |
| |
|
|
|
|
Use the search bar at the top of the page to find games, utilities and more!
|
|
