Lau writes:
> > As far as I know, nothing my program does should be affected by the size
> > of the buffer, apart from filling it in the first place. So my findings
> > would seem to indicate that a buffer size of between 256 bytes! and 1k
are
> > optimal for this kind of thing. This is strange enough, considering that
> > iob.fmul is called more frequently the smaller the buffer. What
surprises
> > me is why were not seeing the benefits of iof.load in this (or at least
I
> > dont). Anyone got a theory?
> >
>
> I was watching this thread with interest. Maybe I should have commented
> earlier... that the results you have obtained are exactly what I was
> expecting.
Your explanation made reminded me that a considerable amount of buffering
is already going on (the hard disk, Windoze, and Smsq). iof.load is possibly
not much more efficient under those circumstances than iob.fmul. Compared
with the processing of the data going on, probably only a small proportion
of the time is spent on replenishing the data from storage.
<>
> Then there's caching... if you had enough memory, your test would
> produce some curious results... whichever buffer size you ran first
> would seem to be rather slow compared to the rest. As you ran your tests
> on your hard disk, the caching effect doesn't come into it, but I
> thought I'd mention it.
That was the significance of
2^n size no. s remarks
--- ----- ----- --- ---------------
x: xxx xxx xx Primer run
;)
> Finally, it all depends on how fast your processor and hard disk are.
> These days, processors tend to have a lot of cycles available per byte
> transferred from(to) disk. That's the reason why compressed hard disk
> partitions are actually *faster* to handle that uncompressed. The
> processor has lots of spare time on its hands to perform the
> (de)compression. Overall time to process a file becomes tied mainly to
> the raw disk access time to get all the data on/off the disk. A
> compressed file occupies about half the physical space, so can be
> handled in handled in half the overall time.
But I thought that PIO mode hard disks, the current norm, actually pushed
the data into memory with barely any intervention from the CPU. In that case
there would be some reduction in overall responsiveness if the CPU was busy
uncompressing data as opposed to having it readily available?
> Back to my earlier mention of caching... hard drives and their
> controllers do caching as well. I'm not certain if they do read-ahead
> caching.
>
> In summary, I believe your results are just giving the shear time it
> takes the drive to spin on its axis tracks * cylinders * interleave
> times, and have very little to do with any CPU processing.
>
> Answer to your original question: "How big a buffer should I use?"...
> one byte?
Hehe, youre probably right, though I think I'll rely on my test results in
this particular case. I suppose my real question was whether there is some
"sweet" buffer size pertaining to Qdos/Smsq, that minimises fiddly
edge conditions and the like. Just like the mc68 processor prefers to work
with words and long words rather than bytes and bits, is there a "word size"
for the file system? Even though it wont make much difference, I like to
know that everything is ticking over as efficiently as possible.
Per
