Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!csd4.milw.wisc.edu!leah!rpi!rpi.edu!deven From: deven@pawl.rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga Subject: Re: UNIX vs. Amiga speeds Message-ID: Date: 23 Mar 89 07:43:59 GMT References: <6352@cbmvax.UUCP> <6359@cbmvax.UUCP> Sender: usenet@rpi.edu Reply-To: shadow@pawl.rpi.edu (Deven Thomas Corzine) Organization: RPI Public Access Workstation Lab, Troy NY Lines: 131 In-reply-to: ditto@cbmvax.UUCP's message of 21 Mar 89 17:50:36 GMT In article <6359@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >In article <6352@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>In article , deven@pawl.rpi.edu (Deven Corzine) says: >>> Your assumption that Unix is inherently slow is patently absurd. >> >>Untrue. The Amiga Exec is just plain more efficient than the AT&T UNIX >>Kernel. Task swaps under exec are extremely light weight when compared to >>UNIX swaps. FFS runs around 3x the speed of the standard System V file >>system, on the same A2500 hardware, without swapping in the way (at least >>that was the last rough figure -- don't know if Steve's latest have >>recently been compared with Mike/Johann's latest, but I wouldn't expect >>too much change). Despite what the UNIX-or-death folks say, UNIX isn't >>perfect. >Absolutely true. An important thing to remember though, is that when you >point to particular areas where OS "X" is better than OS "Y", you have to >figure out how much those areas come into play in what you consider >"normal use." Having a more effecient kernel only helps to the extent >that the system spends time in the kernel. Oh, good. I'm not alone. >For example, if you run one CPU intensive program under AmigaDos, and an >equivalent program under Unix, with nothing else running on either system, >the ineficciencies in a Unix task switch won't matter and the difference >between the systems will be negligible. However, In a situation with >several remote users logged in to the the system via telnet, where there >are a few context switches for every keystroke, Unix will start to feel >the overhead in a context switch, and the effective CPU speed will start >to drop. Ironically, AmigaDos is not appropriate for such use (multiple >interactive users) and its advantages there are seldom seen, but those >advantages do come into play with things like applications that run in >multiple processes, etc. >For another example, consider a program which is about half CPU bound and >half file I/O bound. Running this program under AmigaDos (with FFS) and >Unix will show the FFS to be much faster than the Unix filesytem. Run >TEN of these programs simultaneously on each system and I'll bet Unix >will be faster because of things like read-ahead and larger block sizes. heh heh... now try it with the OFS... :-) >>> If you ran Unix on the Amiga without paging (which isn't possible) or >>> swapping (which is quite possible, but only really feasible with a HD) >>> you will get similar speeds to programs running on the Amiga under >>> AmigaDOS. >> >>You CAN'T run UNIX without paging, that's part of the task swap overhead >>in UNIX, and one of the reasons it goes slower (and, of course, this >>slowdown also makes fork() possible, so it's not a clear loss. >Hmm? Deven and Dave both seem to be saying that Unix requires paging, >which isn't true. Unix existed for 10 or 15 years before AT&T released >a paging version. The early versions were "swapping" systems; only an >entire process could be swapped to disk. Paging systems move small pages >of memory to disk when they are not being used. On a paging or swapping >system, it is trivial to configure the system not to use secondary storage >for virtual memory (when all physical memory is in use, attempts to use >more will result in out-of-memory errors). Ambiguous sentence structure. I was saying if you ran Unix on the Amiga without implementing paging (which is impossible *on the Amiga* [ignoring 2500's here]) and without implementing swapping (which you could certainly implement on the Amiga, but is of questionable value, and you would have to be certifiably insane to try swapping to floppies...) then you should get performance rivalling Exec/AmigaDOS. Maybe not quite as good, but definitely in the same ballpark. >>I'm not at all claiming that it goes considerably slower, just >>slower. >I'm not convinced. Unix has things like demand-loading of executables >and shared libraries with demand-copied shared data segments. These are >things that only help in certain situations, but the same is true of >things like fast context switches or file systems optimized for large >sequential reads. All these factors will sometimes pile up toward one >system, making it faster, and they will sometimes balance out. I'm not >convinced that either Unix or AmigaOS is inherently "faster" overall. >And of course, all the above factors are subject to change with new >releases of Unix or AmigaDos; hopefully we'll someday see Unix with >superfast context switches and real time response, and AmigaOS with MMU >address translation, shared text&data segments, automatic stack >allocation, read-ahead, and memory protection. I agree totally here. >> Also, once you start swapping, obviously, you will go slower. >>It doesn't take that many programs running to start swapping. Care to >>guess how may programs I have running on my Amiga system here (if you >>guessed 35, you'd win the cupie doll). I'm using less than 1.7 >>megabytes of RAM. Shared libraries sure make a difference. >I don't see what that has to do with Unix vs. AmigaDos performance, >aside from the additional memory usage of the Unix OS itself. To do >equivalent things with equivalent performance under Unix and AmigaDos, >the Unix system might need another megabyte of RAM to avoid paging. >Then again, it might not, because there are situations where AmigaDos >uses more memory than Unix (such as stack space, for example -- how >many people always use a 10K or 20K stack size because of that >occational program that needs it). Memory fragmentation is another >example. And if you are only one megabyte short on physical memory, I >claim that the paging is not noticable. It might have a slight effect >on some I/O intensive operations, but will generally not effect the >CPU time of programs because memory which is in use is not paged out. >(Unless you are just plain using far more virtual memory than you have >physical memory, and I think we all agree that once you do that, swap >I/O is a fact of life). And the fact remains that Exec current doesn't support paging, so it cannot use more VM than real RAM available. True, a Unix kernel which supports paging will have slower context switches even if everything fits in ram, just because of the overhead to check if paging is needed. On the other hand, the Unix machine can continue to run (albeit slowly) using more memory than it has, which Exec can't do. It's a tradeoff, whichever way you go, you've got advantages and disadvantages. vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv >has grown to 10, with more expected." ford@kenobi.commodore.com >- The Unix Programmer's Manual, ...!sdcsvax!crash!kenobi!ford > 2nd Edition, June, 1972. ditto@cbmvax.commodore.com ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ marvelous quote. :-) Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.