Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!husc6!mit-eddie!killer!elg From: elg@killer.DALLAS.TX.US (Eric Green) Newsgroups: comp.sys.cbm Subject: Re: SEQ file access speedup Message-ID: <7143@killer.DALLAS.TX.US> Date: 14 Feb 89 03:38:56 GMT References: <89Feb10.182100est.2732@godzilla.eecg.toronto.edu> <7124@killer.DALLAS.TX.US> Reply-To: elg@killer.Dallas.TX.US (Eric Green) Organization: The Unix(R) Connection BBS, Dallas, Tx Lines: 64 This is the results of benchmarking a) loading, and b) doing GETIN until EOF, from ML, doing nothing inbetween. All tests were done with a 98 block file consisting of the main body of a BBS program. It was just the handiest program that I had available on both SFD and 1541 formats. I put it onto a blank 1541 disk, to prevent fragmentation. It was already first on the SFD disk (the boot disk for the BBS, which I only recently made up). My basic thought was that sequential file access can take place just as fast as LOAD'ing. The benchmark confirms that for IEEE drives and the standard 1541. There's a couple of constraints here. First of all, doing TALK and UNTALK (chkin/clrchn) for each sequentially-read byte is extremely slow. When you do chkin or clrchn, each call sends a command byte out to the drive. So doing fast sequential access means buffering your sequential file data anyhow (e.g. a simple filter program would be best off reading in 256 bytes, filtering them, then writing them to the output file, instead of doing clrchn/chkin/clrchn/chkout for each individual byte -- a 4-to-1 overhead). When you do that, SEQ access isn't slow at all.. just look at these timings: C-64, IEEE Flash, SFD-1001, 'load"bbs",8' : 18 seconds """""""""""""""""""""""" ML loop, seq read: 18 seconds C-64, C-LINK II, SFD-1001 LOAD: 14 seconds READ: 14 seconds 128 Ramdos: READ: 9 seconds 64 Ramdos: READ: 8 seconds 128 -- 1571 -- load -- 8 seconds read -- 26 seconds in 64 mode, with 1571: load -- 60 seconds read -- 62 seconds 64 mode, with Epyx fastload cart. -- LOAD 26 seconds with Mike J. Henry's "fastboot v2": 26 seconds Unfortunately I couldn't see if the Super Snapshot was faster than the Epyx or fastboot product. My brother sold ours because it was incompatible with his C-64 (a very early production model), and because "it wasn't any faster than the fastload cartridge" (his words, not mine -- I never even used the darn thing). Some trivia: the main difference between LOAD'ing (burst mode) and READ'ing (fastmode) on the 1571 is that fast mode negotiates a transaction for each byte, while burst mode negotiates on a per-block basis. Burst mode is unique in that manner -- even the IEEE drives negotiate on a per-byte basis (probably why they're slower than burst mode, despite fairly equivalent hardware). Some other trivia: Using ACPTR should be faster than using GETIN, if subroutine overhead is as big a problem as some hint. GETIN has to do all sorts of testing to see where to dispatch to -- is it keyboard, or is it disk? This overhead should be noticible when compared to LOAD, which calls ACPTR directly. But for both the IEEE drives and the 1541, there was no significant difference between LOAD and GETIN times, implying that transfer speed, and not internal Kernal overhead, was the limitation. -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | \X/ >> In Hell you need 4Mb to Multitask << |