Newsgroups: comp.sys.cbm
Path: utzoo!utgpu!jarvis.csri.toronto.edu!godzilla.eecg.toronto.edu!leblanc
From: leblanc@eecg.toronto.edu (Marcel LeBlanc)
Subject: SEQ file access speedup (was: Simultaneous disk & RS-232 access)
Message-ID: <89Feb10.182100est.2732@godzilla.eecg.toronto.edu>
Summary: Not really worth the trouble
Keywords: custom serial I/O, IEEE-488 drives, RAMDOS
Organization: EECG, University of Toronto
References: <738@csd4.milw.wisc.edu> <7023@killer.DALLAS.TX.US> <765@csd4.milw.wisc.edu> <89Feb3.212709est.2386@godzilla.eecg.toronto.edu> <779@csd4.milw.wisc.edu> <89Feb7.220647est.2663@godzilla.eecg.toronto.edu> <826@csd4.milw.wisc.edu>
Date: Fri, 10 Feb 89 15:05:51 EST

In article <826@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) writes:
>]drives.  When I decided (2 yrs ago) that 1571 drives didn't give me enough
>]storage, I considered getting an IEEE drive, but then I learned about the
>]new 1581 drives that had been announced.  I managed to get two from
>]Commodore, and I'm glad I did.  It loads much faster than IEEE drives (my
>]assembler LOADs include files, taking maximum advantage of load speed), and
>]has good storage capacity (800K vs 1M/floppy for 8250).
>
>IF you're on a 128, or IF you're on a 64 with some sort of fastloader.
>Which is still only a marginal speedup, considering that file based
>operations are not enhanced by such devices.  (Since that's the major
>type of operation I need around here, that's what I look at.)  BLITZ!
>isn't speeded up at all by FastLoad... hehehe

I can appreciate that file operations are very important to you, and a
relatively small number of others (maybe 10's of thousands?).  But you
aren't exactly a typical C64 user, and neither am I.  For the millions that
use their C64 to play the latest games, all they are concerned about is how
fast they can start up the game, or how quickly the next level can be loaded
in.  Speeding up file operations is a more difficult issue.

Let's keep things in perspective here.  Although it's possible to speed up
sequential file access with 'transparent' speedup software, you will never
get as much of a speed increase as is possible on LOADs.  This has less to
do with the transfer protocol, than with the LOW PERFORMANCE limitations of
the C64 kernal.  To remain compatible with existing software, speedup
software must intercept OPEN, CLOSE, CHKIN, CHKOUT, CHRIN, GETIN, & CHROUT.
You can't expect that much speed if you call a subroutine for every byte of
a transfer.  You CAN expect much more speed if you call a subroutine to
transfer large blocks of memory (LOAD & SAVE).  All of this assumes at least
minimal optimization in the LOAD and SAVE routines.  If these are just
implemented as loops that repeatedly call the single byte transfer routines,
then the performance won't be any better.

For example, consider LOAD vs. sequential read on IEEE-488 drives, or C128
burst vs. fast serial.  The C128 gives you great burst serial speed (LOAD &
SAVE), but using fast serial instead of slow serial doesn't give you that
much of a speed increase (maybe 2x).  Since software overhead is the
dominant factor here, I'll guess that seq read on IEEE drives also gives
about a 2x speedup.  If somebody has concrete numbers, please post!

Before Eric Green decides to flame me :-), I should point out that I haven't
forgotten that block transfers can be hidden from applications software.
For devices like the 1541/71/81, it's quite reasonable to expect speedup
software to transfer pieces of a file in blocks, then read from this buffer
when a call is made to CHRIN or GETIN (same for CHROUT on write).  This
would have been great in the early days of the C64 & 1541 (my GUESS, 3-3.5x
speedup)!  But today, too much software bypasses CHRIN/CHROUT to use
ACPTR/CIOUT directly.  It's also a great idea for the C128 if you can spare
enough memory to burst load the whole file (or use an REU).

So what was the point of this posting?  Just that, if the software you use
has to do sequential file reads or writes, you are limited in how much it
can be speeded up without re-writing it.  The main reason I use Buddy 128
(an assembler) is that it LOADs include files (which defaults to burst
serial), giving me great speed on a 1581.  The SAME speedup factor (10-12x)
is possible on the C64 using software only (with 1541/71/81)!  This is at
least twice as fast as IEEE can load.  A complete assembly, which requires
2 passes through 600K of tokenized source, takes about 12 mins.  Using seq
reads on a C64 would probably take about 1.5 hours, or 50 mins using IEEE
drives (I haven't timed these, so they are just guesses).

If somebody can suggest a faster method of speeding up seq file accesses,
please let us know!  What we really need is a new OS for the C64...

Marcel A. LeBlanc	  | University of Toronto -- Toronto, Canada
leblanc@eecg.toronto.edu  | also: LMS Technologies Ltd, Fredericton, NB, Canada
-------------------------------------------------------------------------------
UUCP:	uunet!utai!eecg!leblanc    BITNET: leblanc@eecg.utoronto (may work)
ARPA:	leblanc%eecg.toronto.edu@relay.cs.net  CDNNET: <...>.toronto.cdn

