ephraim@think.COM (Ephraim Vishniac) (04/27/89)
Several months ago, Ed Darken reported that he'd written a simple
program to check the Mac's I/O speed and found it execrable,
independent of I/O block size. Ed was kind enough to send me his
code, and I've finally gotten around to investigating his results.
Alas, I've lost his net address in the meantime, but I thought the
explanation might be of general interest.
Ed's program pre-allocated a file on disk, then did a series of writes
to the file. That is, he did PBCreate, PBOpen, PBAllocate, a series
of FSWrites, and a PBClose. Output rates were terrible, down around
25kB/S on a Mac II with a hard disk. Varying the block size on the
FSWrites didn't seem to help at all.
Guessing that FSWrite was doing a series of single-sector writes, I
modified Ed's program to use PBWrite instead, and I got the following
results:
Block size Output rate (k Bytes / Second)
512 26.3
1024 51.7
1536 60.8
2048 93.8
4096 142.9
8192 177.8
16384 206.9
Plainly, FSWrite has serious brain damage. Fortunately, substituting
PBWrite is trivial and yields large improvements for larger block
sizes.
Ephraim Vishniac / Internet: ephraim@think.com / AppleLink: ThinkingCorp
Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214
"Arlo Guthrie, it seems, has found what he was looking for:
God, and the Macintosh." (Boston Globe)pratt@boulder.Colorado.EDU (Jonathan Pratt) (04/27/89)
In article <39736@think.UUCP> ephraim@think.COM (Ephraim Vishniac) writes: > >Plainly, FSWrite has serious brain damage. Fortunately, substituting >PBWrite is trivial and yields large improvements for larger block >sizes. > This is a bit hard to swallow. In every development system I've looked at FSWrite simply fills out a parameter block and calls the _Write trap. Doesn't PBWrite simply call _Write with the ParmBlkPtr you've supplied? Shouldn't be any difference. I would bet the problem is elsewhere. Jonathan /* Jonathan Pratt Internet: pratt@boulder.colorado.edu * * Campus Box 525 uucp: ..!{ncar|nbires}!boulder!pratt * * University of Colorado * * Boulder, CO 80309 Phone: (303) 492-4293 */
russotto@wam.UMD.EDU (04/27/89)
In article <39736@think.UUCP> ephraim@think.COM (Ephraim Vishniac) writes: > >Several months ago, Ed Darken reported that he'd written a simple >program to check the Mac's I/O speed and found it execrable, >independent of I/O block size. Ed was kind enough to send me his >code, and I've finally gotten around to investigating his results. >Alas, I've lost his net address in the meantime, but I thought the >explanation might be of general interest. > >Ed's program pre-allocated a file on disk, then did a series of writes >to the file. That is, he did PBCreate, PBOpen, PBAllocate, a series >of FSWrites, and a PBClose. Output rates were terrible, down around >25kB/S on a Mac II with a hard disk. Varying the block size on the >FSWrites didn't seem to help at all. > >Guessing that FSWrite was doing a series of single-sector writes, I >modified Ed's program to use PBWrite instead, and I got the following >results: > > Block size Output rate (k Bytes / Second) > 512 26.3 > 1024 51.7 > 1536 60.8 > 2048 93.8 > 4096 142.9 > 8192 177.8 > 16384 206.9 > >Plainly, FSWrite has serious brain damage. Fortunately, substituting >PBWrite is trivial and yields large improvements for larger block >sizes. > >Ephraim Vishniac / Internet: ephraim@think.com / AppleLink: ThinkingCorp >Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214 > > "Arlo Guthrie, it seems, has found what he was looking for: > God, and the Macintosh." (Boston Globe) Since FSWrite is development-system-dependant, could you please tell us which development system was used? (I've written several of those routines to replace the horrible Megamax C routines, and I don't see how one could mess them up that badly... Well, Megamax could... but I use MPW now) -- DISCLAIMER: Not only does the University not share my opinions, they don't want me sharing my opinions. "This 'Pnews', what does it do?" Matthew T. Russotto russotto@wam.umd.edu
ephraim@think.COM (Ephraim Vishniac) (04/27/89)
In article <8904270059.AA02169@vs08csc.UMD.EDU> russotto@wam.UMD.EDU writes: >In article <39736@think.UUCP> ephraim@think.COM (Ephraim Vishniac) writes: >>Several months ago, Ed Darken reported that he'd written a simple >>program to check the Mac's I/O speed and found it execrable, >>independent of I/O block size. >>Guessing that FSWrite was doing a series of single-sector writes, I >>modified Ed's program to use PBWrite instead, and I got the following >>results: [Output rates increasing sub-linearly with block size] >>Plainly, FSWrite has serious brain damage. That should be, "Plainly, FSWrite *had* serious brain damage." >Since FSWrite is development-system-dependant, could you please >tell us which development system was used? Ed originally wrote his program in MPW C (before MPW 3.0, so probably with 2.?) and also ported it to LSC 2.??. I'm now running with LSC 3.01p4. I should have finished doing my homework before posting my results, as it seems that the problem Ed originally observed is gone from LSC 3.01p4. That is, I went back to the original program, ran it again, and got results just like those from using PBWrite. So, using FSWrite is actually a non-problem if you're using an up-to-date version of LSC. BTW, I also nosied both versions of Ed's program (with FSWrite and with PBWrite) and confirmed that both are effectively calls to _Write. Unfortunately, I didn't have an old version around to see if FSWrite had changed. Ephraim Vishniac / Internet: ephraim@think.com / AppleLink: ThinkingCorp Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214 "Arlo Guthrie, it seems, has found what he was looking for: God, and the Macintosh." (Boston Globe)