poole@forty2.UUCP (Simon Poole) (04/09/88)
I was able to play around a bit with the GEMDOS 'Ersatz' from Atari France:
First thing I did was run a few tests without TurboDos, one was
run the UniTerm manual thru LaTeX, and the other was
create 50 1.5 kB files on a 5MB HD partition with 120kB free (some-
thing for which GEMDOS is known to be very slow).
After I had run these two simple tests, I installed TurboDos and ran
up against the first problem, it uses at least 100kB of memory (the
program itsself is some 30kB, with other words I had to remove various things
before I was able to run TeX.
What one does notice immediatly, is that the desktop needs a lot less
disk accesses, this and the fact that TurboDos needs so much memory
could mean that it's 'just' a disk cache program, anyway the times for the
above tests:
GEMDOS TurboDOS
LaTeX | 9 min 40 s | 9 min 40 s | Comment: tmp files on Ramdisk
50 files| 3 min 6 s | 0 min 42 s |
Anybody got more data?
--
----------------------------------------------------------------------------
UUCP: ...mcvax!cernvax!forty2!poole Simon Poole
BITNET: K538915@CZHRZU1A
----------------------------------------------------------------------------braner@batcomputer.tn.cornell.edu (braner) (04/13/88)
In article <207@forty2.UUCP> poole@forty2.UUCP (Simon Poole) writes: >I was able to play around a bit with the GEMDOS 'Ersatz' from Atari France: >... > GEMDOS TurboDOS > LaTeX | 9 min 40 s | 9 min 40 s | Comment: tmp files on Ramdisk > 50 files| 3 min 6 s | 0 min 42 s | - seems that TurboDOS is more than a cache: creating new files on an almost-full HD is slow since GEMDOS has to analyse the FAT to find empty space, and it does so very inefficiently. No disk cache (of the kind that just keeps _sectors_ in RAM) can fix that, Turbodos must intercept the GEMDOS functions that operate at the _file_ level. The Latex test did not speed up since it was mostly calculating rather than I/O, and the tmp files were created on a (small?) RAMdisk (small FAT to analyse). It _is_ true that GEMDOS could benefit from caching of (sub)directory sectors, something that it does not do much of. It could also use hashing of files found in directory trees, for faster finding of them next time (i.e., the second time you access the file, say a compiler library file or a utility program, via a long PATH variable). This could be done inside a shell, too. Any chance TurboDOS could be posted on Usenet or put up for FTP? - Moshe Braner PS: PENICILIN, since it is supposed to suppress a VIRUS, should have been named INTERFERON :-)
jet@hcx1.SSD.HARRIS.COM (04/14/88)
/* Written 10:00 am Apr 13, 1988 by braner@batcomputer.UUCP in hcx1:comp.sys.atari.st */
In article <207@forty2.UUCP> poole@forty2.UUCP (Simon Poole) writes:
==Any chance TurboDOS could be posted on Usenet or put up for FTP?
==- Moshe Braner
I'll put a vote in for that!!!wolf@csclea.ncsu.edu (Thomas Wolf) (04/17/88)
In article <46700005@hcx1> jet@hcx1.SSD.HARRIS.COM writes: > >/* Written 10:00 am Apr 13, 1988 by braner@batcomputer.UUCP in hcx1:comp.sys.atari.st */ >In article <207@forty2.UUCP> poole@forty2.UUCP (Simon Poole) writes: > >==Any chance TurboDOS could be posted on Usenet or put up for FTP? > >==- Moshe Braner > >I'll put a vote in for that!!! A couple days ago I got an accelerator program from the the binaries section. Was that Turbodos? It sure is fast enough to fit the description (and during the auto-boot it displays a message that states that it comes from Atari-France. Anyhow, even if it isn't TurboDos (but I think it is), I can't believe how I ever did without it :-) My hard-disk is finally as fast as a hard-disk should be! Thank you for making it available on usenet. Tom Wolf Tom Wolf ARPA (I think): tw@cscosl.ncsu.edu or wolf@csclea.ncsu.edu