Re: RamFAST & GS/OS cache

[toddpw@cco.caltech.edu (Todd P. Whitesel)]

hal@budapest.math.macalstr.edu (Harold Byron Bouma) writes:

>> I am going to bug Drew to support GS/OS cache :)

>	Good, you should. Its much better caching and the GS will improve from  
>it. Even the Turbo IDE card does it as well.

Drew's position on this is that the method the RamFast currently uses is faster
than it would be if he supported GS/OS caching. This is because the GS/OS cache
has to (a) find the block by searching a list, and (b) manually move the block
to the caller. So for data blocks the GS/OS cache is generally going to be
slower than the RamFast unless you have a very fast Zip. But for directory
blocks, the GS/OS cache makes a lot of sense _IF_ the FST's are smart enough
to directly search for them in the cache rather than calling the driver and
forcing a manual copy into the FST's own memory (which is also usually going to
be slower than just blasting the block in from the RamFast).

Todd Whitesel
toddpw @ cco.caltech.edu