acphssrw@csuna.UUCP (Stephen R. Walton) (08/17/88)
In article <4479@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <1800@vu-vlsi.Villanova.EDU>, cheung@vu-vlsi.Villanova.EDU >(Wilson Cheung) says: >> Why is the disk drive so slow? > >Are you still floppy based? The PCs I've used around here (XTs and ATs) have a >pretty miserable disk performance when running similar things. Amen to that. The ONLY thing PC's do faster than the Amiga is directory listings and other wild-card-search related things. And there're lots of ways around that on the Amiga: a "fastdir" program such as Rob Peck's, or a disk cacher which only caches directory blocks (BlitzDisk can do this, takes minimal memory, and it comes "free" with TxEd Plus). In fact, I ran some disk performance benchmarks some time ago, and the Amiga's _floppies_ were competitive with an XT's _hard disk_ in most respects; they were about equal in reading/writing long files.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/18/88)
:Amen to that. The ONLY thing PC's do faster than the Amiga is :directory listings and other wild-card-search related things. Yah, but the fast file system really fixes the problem ... 100+ entries/sec for directories. No more problems! But one thing both the original and FFS use is that beloved hash table... You can put a dozen directories in your PATH and it only takes an instant to search for commands, unlike an IBM. And when you really get down to it, I find openning files quickly MUCH more important than scanning directories. Using an IBM-AT 386 @ 16MHz, it still takes up to three seconds to go through about 200 entries (in the 4 or 5 directories I had in the path) to find the executable I wanted.... In otherwords, a DISKBOUND operation. This problem does not occur with the Amiga and I frankly have never had to think about the number, or ordering, of my path. -Matt
peter@sugar.uu.net (Peter da Silva) (08/19/88)
In article <8808180059.AA05505@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > Using an IBM-AT 386 @ 16MHz, it still takes up to three seconds to > go through about 200 entries (in the 4 or 5 directories I had in the path) > to find the executable I wanted.... In otherwords, a DISKBOUND operation. You're comparing apples to oranges. MS-DOS shouldn't be your standard for comparison... UNIX should. Why aim for the mud when the stars are within your grasp? -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
elg@killer.DALLAS.TX.US (Eric Green) (08/26/88)
In message <2505@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) says: >In article <8808180059.AA05505@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU $ (Matt Dillon) writes: $ $$ Using an IBM-AT 386 @ 16MHz, it still takes up to three seconds to $$ go through about 200 entries (in the 4 or 5 directories I had in the path) $$ to find the executable I wanted.... In otherwords, a DISKBOUND operation. $ $You're comparing apples to oranges. MS-DOS shouldn't be your standard for $comparison... UNIX should. Unix, though, still is no speed demon on searching directories, insofar as finding a particular program to run. Directories, at least under old AT&T versions, are sequentially organized in no particular order -- meaning an O(n) search time, where n is the number of files in all those directories. That's why csh and ksh have hacks in them to speed up finding programs (hash tables, etc.), which are just as much hacks as the "fastdir" programs on the Amiga. Of course, Unix DOES have disk caching, while MSDOS doesn't... and most Unix systems DO have faster disk drives than MSDOS machines... but, all in all, the performance for directory searches should be similiar between the two systems. [Note: All the Unix info is from the Bach Book, which means it's probably for some old generic AT&T version... I'm not up-to-date on everything the Berzerkoids have done with BSD4.3). -- Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 MISFORTUNE, n. The kind of fortune that never misses.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/26/88)
:Unix, though, still is no speed demon on searching directories, :insofar as finding a particular program to run. Directories, at least :under old AT&T versions, are sequentially organized in no particular :order -- meaning an O(n) search time, where n is the number of files :in all those directories. That's why csh and ksh have hacks in them :to speed up finding programs (hash tables, etc.), which are just as :much hacks as the "fastdir" programs on the Amiga. : :Of course, Unix DOES have disk caching, while MSDOS doesn't... and :most Unix systems DO have faster disk drives than MSDOS machines... :but, all in all, the performance for directory searches should be :similiar between the two systems. Plus the fact that the CSH remembers all the executables in your search path, and most programs are run from a shell. All BSD UNIX versions after 4.1 (i.e. 4.2, 4.3) use very intelligent caching and very fast access so this isn't a problem. 4.3 additionaly caches directory paths in the kernel for even faster access. (namei is cached). The big thing though is the CSH. -Matt
peter@sugar.uu.net (Peter da Silva) (08/27/88)
In article <5305@killer.DALLAS.TX.US>, elg@killer.DALLAS.TX.US (Eric Green) writes: > In message <2505@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) says: > $You're comparing apples to oranges. MS-DOS shouldn't be your standard for > $comparison... UNIX should. > Unix, though, still is no speed demon on searching directories, > insofar as finding a particular program to run. True, *but* it's way faster in getting a list of the files in a directory and globbing wildcards. Also, > Directories, at least > under old AT&T versions, are sequentially organized in no particular > order -- meaning an O(n) search time, where n is the number of files > in all those directories. No, this time is dominated by disk I/O, so n is the number of blocks that have to be read off disk. At 16 bytes to a directory entry, and 512 byte blocks, for the worst case UNIX is faster than best case AmigaDOS for up to 32 files (it takes 2 disk accesses to verify a filename in AMigaDOS), and just as fast for up to 64 files. I haven't figured in the effect of hash table collisions in AmigaDOS, and on average you're going to have half the number of accesses in UNIX. And then... > Of course, Unix DOES have disk caching, while MSDOS doesn't... And AmigaDOS doesn't. Even with FACC AmigaDOS doesn't have preferential caching of directory entries. > and > most Unix systems DO have faster disk drives than MSDOS machines... > but, all in all, the performance for directory searches should be > similiar between the two systems. On MS-DOS, the whole file entry is stored in the directory, so there are even fewer slots per directory entry and MS-DOS has worse directory-search behaviour than UNIX. I've run MS-DOS and UNIX on the same hardware. UNIX is noticably faster. I'd like to make the same comparison on a 2500UX some time. MOST Amiga directories have fewer than 64 files in them. About the only directory you're going to find with worse behaviour under the UNIX file system than the AmigaDOS one is c:. There aren't that many occasions for large directory structures under AmigaDOS... there's no /usr/lib/termcap, or /usr/mail, or /dev, or /usr/spool/uucp. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/28/88)
:blocks, for the worst case UNIX is faster than best case AmigaDOS for up :to 32 files (it takes 2 disk accesses to verify a filename in AMigaDOS), :and just as fast for up to 64 files. I haven't figured in the effect of :hash table collisions in AmigaDOS, and on average you're going to have :half the number of accesses in UNIX. :> Of course, Unix DOES have disk caching, while MSDOS doesn't... : :And AmigaDOS doesn't. Even with FACC AmigaDOS doesn't have preferential :caching of directory entries. Actually, the FFS does. The old file system did too but it was really stupid caching. The FFS is *much* better at it. Still not as fast as UNIX but that is only because UNIX directories, being files, can be accessed sequentially very quickly. When you get down to openning a specific file, such as would be done in a large CAD system or when searching the PATH, the FFS is *much* faster! :On MS-DOS, the whole file entry is stored in the directory, so there are :even fewer slots per directory entry and MS-DOS has worse directory-search :behaviour than UNIX. : :I've run MS-DOS and UNIX on the same hardware. UNIX is noticably faster. :I'd like to make the same comparison on a 2500UX some time. MS-DOS combines the worse of both worlds. -Matt
wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) (08/29/88)
In article <2568@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes: > > MOST Amiga directories have fewer than 64 files in them. About the only > directory you're going to find with worse behaviour under the UNIX file > system than the AmigaDOS one is c:. There aren't that many occasions for > large directory structures under AmigaDOS... there's no /usr/lib/termcap, > or /usr/mail, or /dev, or /usr/spool/uucp. Well maybe you should try doing some animation, I find that I have a lot of directories with more than 64 files in them. Also I really don't believe the comparsion to the UNIX file system is valid. I worked on 4 or 5 different UNIX machine and the performance varies widely as far as the file system in concern. I never seen another machine that does a simple directory as slow as the Amiga does. There is simply no reason for such a bad file system, and I find it hard to compare to anything. However all things considered, the Amiga file system is the only thing that is really awful on the Amiga. So I'm looking forward to getting the new fast file system in 1.3 and prehaps it will be as good as the rest of the Amiga. Wayne Knapp