marcus@horizon.UUCP (Marcus de Barros) (11/11/87)
I've attempted to compile the Postscript interpreter recently posted to the net on my Sun. Its seems that the include file wwinfo.h is missing from the distribution. Does anyone have this file? If so, please send to me. Thanks, Marcus de Barros Science Horizons (619) 942-7333
michael@orcisi.UUCP (11/15/87)
> I've attempted to compile the Postscript interpreter recently posted to the > net on my Sun. Its seems that the include file wwinfo.h is missing from > the distribution. Does anyone have this file? If so, please send to me. The problem is faulty Makefile logico used to make hard.o. I think a simple solution for building PS with the pixrect driver is to use something like: sunPS: $(OBJECTS) $(GRAPHICS) pixrect.o canon.a cc $(CFLAGS) $(OBJECTS) $(GRAPHICS) pixrect.o canon.a -lm -lpixrect -o sunPS (i.e. remove the hard.o stuff completely. This approached hasn't be tested for the other driver configurations). p.s. If you have FPA, compile the source with -f68881 for a 2x speed up.
conor@goose.UUCP (Conor Rafferty) (11/23/87)
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"cyrus@hi.UUCP (Tait Cyrus) (11/23/87)
I have been playing with the PostScript Interpreter that was posted
a few weeks back and find that I like it. I have a few gripes though.
1) I am running on a SUN 3/160. Although I compiled everything
with CFLAGS = -O -f68881, I find that it is still VERY SLOW.
Currently it takes about 10-20 seconds for it to initialize
itself and then another 20-30 seconds (or longer) to display
the first page (I am previewing output from ptroff). This
seems a bit long to me. Has anyone been able to get it to
run any faster?
2) The Apple LaserWriter Plus knows about many different fonts.
The interpreter only knows about a very few ( 7 to be exact).
Is there any way to let the interpreter know about ALL of the
fonts?
I had several problems, at first, with trying to preview the output from
ptroff because a lot of fonts were used in definitions. When the previewer
incountered these, it generated an error (of course). As a result of
these errors, the interpreter was put into a 'weird' state and would
not correctly interpret the rest of the file.
--
@__________@ W. Tait Cyrus (505) 277-0806
/| /| University of New Mexico
/ | / | Dept of EECE - Hypercube Project
@__|_______@ | Albuquerque, New Mexico 87131
| | | |
| | hc | | e-mail:
| @.......|..@ cyrus@hc.dspo.gov or
| / | / seismo!unmvax!hi!cyrus
@/_________@/juancho@utcsri.UUCP (11/23/87)
>incountered these, it generated an error (of course). As a result of >these errors, the interpreter was put into a 'weird' state and would >not correctly interpret the rest of the file. Adobe postscript flushes the file, so any attempt to work after an error is above the postscript standard. I like the fact that it continues to try to work but agree with you about the weird state. I will add my $0.02 worth. The errors are not implemented in a similar fashion to adobe stuff. Trying to understand PS's errors is a bigger head ache than trying to understand adobe. The biggest problem is that no line number is given for the error. > > >-- > @__________@ W. Tait Cyrus (505) 277-0806 > /| /| University of New Mexico > / | / | Dept of EECE - Hypercube Project > @__|_______@ | Albuquerque, New Mexico 87131 > | | | | > | | hc | | e-mail: > | @.......|..@ cyrus@hc.dspo.gov or > | / | / seismo!unmvax!hi!cyrus > @/_________@/ -- John W. Buchanan Dynamic Graphics Project Computer Systems Research Institute (416) 978-6619 University of Toronto juancho@toronto.CSNET {allegra,cornell,decvax,ihnp4,linus,utzoo}!utdgp!juancho
michael@mqcomp.oz (Michael Homsey) (11/24/87)
In comparing the real Lazer printer to the PS interp, don't forget that the Lazer divers may have 2 68000 (or other processors) *DEDICATED* (I/O and page makeup) while you are using a machine shuffling little piles of sand here and there. (-:-) -- Michael Homsey (michael@mqcomp.mq.oz) Computing Discipline School of Mathematics, Physics, Computing and Electronics Macquarie University 2109 NSW Australia
michael@orcisi.UUCP (11/26/87)
> 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. On our Sun 3/160, Xvalue() was one of the greatest time consumers (and easily macro-able). I did my analysis with gprof. I believe Yintersect() and AddInteresting() were the next two candidates for optimization. I didn't keep the actual results around however. These is an awful lot of subscripting used to access various array data structures (i.e. using []). Some of this occurs in loops that could be easily re-coded to use pointers with incrementing. Also, there is one spot where qsort() is called which results in many calls to the "comparison function". Re-coding this would help. I think this is the reason why I remember AddInteresting() being so time-consuming. These comments are intended to make this great implementation just a little bit better.