Message-ID: <330@pucc-i>
Date: Mon, 25-Jun-84 18:12:48 EDT
Article-I.D.: pucc-i.330
Posted: Mon Jun 25 18:12:48 1984
Date-Received: Thu, 28-Jun-84 02:34:02 EDT
Organization: Purdue University Computing Center
Lines: 41

I tried to respond to this by mail, but it didn't work.  I said earlier that
Apple Pascal is *much* faster on disk accesses than Apple DOS, and that it
is also faster than CP/M.

How much faster than CP/M?  I don't have CP/M myself, so my information here is
second hand.  I do know that Pascal uses a "two-ascending" sector interleaving
scheme, while CP/M uses "three-ascending".  Two-ascending is guaranteed to be 
faster as long as you are not missing sectors and having to wait an extra full
rotation.  Pascal can do this because there is less intermediate processing
going on during a block read.

I don't have a reference handy and I can't quote any performance statistics,
but I recall reading that Pascal beats CP/M on disk access, which is what
you would expect when reading half the sectors that go by instead of a third.

Apple DOS uses a "three-descending" interleaving scheme, which is equivalent
to "thirteen-ascending" and means there is a LOT of waiting between sectors
if you try to read them in ascending order.  A common optimization scheme
is to read the sectors in descending order to cut down on the wait time, but
that still leaves you with the equivalent of a "three-ascending" scheme,
the same as CP/M.

As everyone knows, there is no free lunch.  In order to get faster disk
access, you have to give up something.  In Pascal, what you give up is
chaining;  files are always allocated in sequential blocks instead of
being strung randomly around the disk.  This means you can occasionally
run out of room on a file because space on the disk is fragmented.
In practice, I have found that the problem is not serious (file compaction
is quick and easy and does not have to be done very often) and I gladly make 
the tradeoff.  

There is a second benefit:  because there are no chaining sectors, you get 
more space for actual data on each disk (274 out of 280 blocks to be exact, 
where a block is 512 bytes = 2 sectors, the smallest amount of data you can 
address on a Pascal disk).  That leaves 2 blocks for a boot program and
4 blocks for the disk directory.  The actual data storage per disk is
140,288 bytes out of 143,360.
-- 

Dave Seaman			"My hovercraft is full of eels."
..!pur-ee!pucc-i:ags

Message-ID: <375@ames-lm.UUCP>
Date: Thu, 5-Jul-84 02:41:29 EDT
Article-I.D.: ames-lm.375
Posted: Thu Jul  5 02:41:29 1984
Date-Received: Sun, 1-Jul-84 05:19:51 EDT
References: <330@pucc-i>
Organization: NASA-Ames Research Center, Mtn. View, CA
Lines: 6

[]
	Must correct the previous article - the DOS 3.3 skew is two-
descending, and this is the fastest possible sector arrangement, *if*
you patch DOS 3.3 so that the software is fast enough to read every other
sector. Without the patch, DOS 3.3 misses its first chance at each sector
and doesn't catch it 'til a full spin later. That's why it's so slooow.

Message-ID: <2926@rabbit.UUCP>
Date: Sat, 30-Jun-84 01:36:13 EDT
Article-I.D.: rabbit.2926
Posted: Sat Jun 30 01:36:13 1984
Date-Received: Sun, 1-Jul-84 06:37:21 EDT
References: <330@pucc-i>, <375@ames-lm.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 17


Sorry to contradict everything said so far, but THE fastest disk access
for apple is using a routine called RWT. No that wasn't a typo. I do
not mean RWTS. I mean Read/Write a Track. No sectors. Sectors slow 
the whole mess down.

There is a trade-off: convenience v. speed.

You have to copy these disks with a nibble copier, and its no good for
multiple file handling. It is great if you need reams of data (say for
a spelling correction program) very quickly.

I know of no such markewted utility, so you'd have to write your own
DOS. too bad.

Steve Hawley
!rabbit!sdh