Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!goose!conor From: conor@goose.UUCP (Conor Rafferty) Newsgroups: comp.sources.d Subject: Re: Postscript interpreter Message-ID: <30@goose.UUCP> Date: Sun, 22-Nov-87 17:33:25 EST Article-I.D.: goose.30 Posted: Sun Nov 22 17:33:25 1987 Date-Received: Wed, 25-Nov-87 05:07:29 EST References: <964@orcisi.UUCP> <219@horizon.UUCP> Sender: conor@dutch-goose.stanford.edu (Conor Rafferty) Reply-To: conor@dutch-goose.stanford.edu Followup-To: comp.sources.d Organization: Integrated Circuit Laboratory, Stanford University Lines: 31 Keywords: sluggish Expires: > p.s. If you have FPA, compile the source with -f68881 for a 2x speed up. Another free 10-15% can be gained by defining PanicIf as a macro. I have a naive question about this interpreter, and previous PostScript interpreters I've seen. Why aren't they blindingly fast relative to laserwriter versions? With 60 dpi on a sun screen (ballpark) and 360 dpi on a laserwriter I'd imagine there's a factor of 36 waiting to be picked up. But if I run the StarLines example from the PostScript blue book p.103, hardcopy is faster. I can see two obvious suggestions: 1) The interpreter is not bit manipulation bound. Sure, not entirely, but the top line of the prof(1)ile is %time cumsecs #call ms/call name 31.1 26.18 _NotThisBit The second line incidentally is PanicIf. 2) The laserwriter has hardware assist. I guess, though I'm not sure what. The interpreter must be assembly language in a ROM, no? Are we looking at the difference between C compiler output and handcoded assembly? Or the difference between coding for speed and coding for readability? This should not be taken as disparagement of an excellent code. --- conor rafferty The command conor@sierra.stanford.edu 1,$s/^\([^,]*\), *\(.*\)/\2 \1/ decwrl!glacier!conor@sierra although hard to read, does the job. --- Brian W. Kernighan "Advanced Editing on Unix"