Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!uxc!uxc.cso.uiuc.edu!ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald
From: mcdonald@uxe.cso.uiuc.edu
Newsgroups: comp.sys.ibm.pc
Subject: Re: Why unix doesn't catch on
Message-ID: <45900231@uxe.cso.uiuc.edu>
Date: 4 May 89 14:36:00 GMT
References: <13527@steinmetz.ge.com>
Lines: 30
Nf-ID: #R:steinmetz.ge.com:13527:uxe.cso.uiuc.edu:45900231:000:1248
Nf-From: uxe.cso.uiuc.edu!mcdonald    May  4 09:36:00 1989



>	Having coded some fairly large (20-100k line) programs in
>various languages, assembler isn't going to make a big difference in
>speed or size over a reasonable C (or other) compiler. With a good
>algorithm for the job you should see less than 2:1 in speed and 20% in
>size (based on recoding a few critical routines).
I certainly call 2:1 speed difference a "big difference"!
If AutoBad were twice as fast, a 10 hour "hide" would be
only 5 hours! A three month molecular dynamics calculation would be
only six weeks!!!!!!!



>	Since the display hardware only updates every 35ms (or so) and
>the eye won't notice anything much under 40ms, why worry about doing
>something which is already close to the threshold of perceptability? If
>you can't see that it's faster, why do it?
I find it tough to generate a whole screen in 35 msec even on a fast
386 machine using carefully hand-optimized assembler code! Maybe
you could do a horizontal line routine in C and get it fast enough,
but I have never actually seen C screen graphing routine that
were anwhere near optimal.

>Save assembler for
>the module at the innermost loop, a few interrupt handlers, and things
>like that.
         And those critical screen graphics routines!

Doug McDonald