Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!mailrus!husc6!think!bloom-beacon!bu-cs!bzs
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.arch
Subject: Re: using (ugh!  yetch!) assembler
Message-ID: <24135@bu-cs.BU.EDU>
Date: 28 Jul 88 20:07:57 GMT
References: <6341@bloom-beacon.MIT.EDU> <60859@sun.uucp> <474@m3.mfci.UUCP> <2926@utastro.UUCP> <476@m3.mfci.UUCP>
Organization: Boston U. Comp. Sci.
Lines: 26
In-reply-to: colwell@mfci.UUCP's message of 24 Jul 88 14:21:03 GMT


The other funny thing that gets lost in these arguments is that I
repeatedly have the experience of speeding up other people's code
dramatically w/o resorting to assembler. For example I just made
available a bunch of changes to a Postscript interpreter for X11 which
speeds it up quite a bit, all by rethinking some of the C code after
monitoring it and looking at the places it spent most of its time
on a bunch of test examples.

Basically the problems were that it called some routines as much as a
few hundred thousand times for even relatively simple images. Some
serious open-coding, register decls, changing array refs in loops to
equivalent but faster pointer stepping etc and it sped up a lot.

Sure, I could have gone another step and seen if some routines might
have been better coded in assembler, it occurred to me although it
also seemed there were more HLL changes to do if I really wanted to
continue. The guy was a good coder, he just seemed far more concerned
with getting it right than raw speed which certainly made sense at
that point in devpt, routines I open-coded (eg) were easy decisions as
hindsight, now that I could view a lot of that code as stabilized.

And I FTP'd the whole mess to another architecture
(Sun/68020->Encore/32332), typed 'make', and it ran faster over there
also a few minutes later.

	-Barry Shein, Boston University