Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!intercon!news From: amanda@mermaid.intercon.com (Amanda Walker) Newsgroups: comp.lang.postscript Subject: Re: FPU for PostScript Message-ID: <1703@intercon.com> Date: 10 Jan 90 00:53:54 GMT References: <1666@intercon.com> <17582@rpp386.cactus.org> <1990Jan9.044252.18617@ico.isc.com> <1990Jan9.170357.25101@ux1.cso.uiuc.edu> <1990Jan9.182332.8554@cs.rochester.edu> Sender: news@intercon.com Reply-To: amanda@mermaid.intercon.com (Amanda Walker) Organization: InterCon Systems Corporation Lines: 80 In article <1990Jan9.182332.8554@cs.rochester.edu>, ken@cs.rochester.edu (Ken Yap) writes: > Why don't we base this discussion on something more substantial? I > repost an article I saved. Hope this leads to better discussion. I knew this discussion was getting familiar. Thanks! > Experience with a pure software implementation > of PostScript (of which the LaserWriter is a good example) gives us an > understanding of what parts of the implementation would benefit most > from hardware support. Another thing that I would imagine it's good for is that by running the implementation on something like a UNIX box, you can profile it and actually look at where the time goes. This is critical for finding out what will actually make the most difference when you speed it up. > (1) Low-level raster manipulations, principally painting character > bitmaps and filling trapezoids located at arbitrary bit boundaries. > For typical pages, this activity dominates everything else if all > characters are already in the font cache. This sounds like a good candidate for hardware. The experience of some of the PostScript clone controllers seems to show that a TI 34010 graphics processor or an AMD 29000 can significantly improve the interpreter's ability to lug bits around. > (2) Character scan conversion. This is a very compute intensive > operation because the original character definitions are at a high > level and are being pushed through the full PostScript graphics > machinery. In particular, there is a lot of arithmetic, both fixed and > floating point. This looks like the least tractable as far as throwing off-the-shelf hardware at it is concerned. A good FPU (like a 68881 or 68882), perhaps with some hand-tuned code for multiplying things by the CTM, would be my guess at the best approach. > (3) [...] A text document that consists primarily of > strings and calls to simple PostScript procedures consumes relatively > little time in the interpreter; a document that executes a lot of > PostScript code for each mark placed on the page consumes > proportionately more. This seems to indicate that the major avenue of improvement is not the tokenizer but the code that runs through executable arrays. Now, these look a lot from the outside like pretty conventional token-threaded code. A change to subroutine-threaded code could make a significant improvement in execution speed, although it might take more space and could introduce compatibility problems with code that does 'put's into executable arrays. > More to the > point, obtaining the best performance requires the ability to perform > communication, execution, and printing activities in parallel. Yes. One thing I noticed from using a Dataproducts LZR-2665 was that even though its controller didn't seem too much faster than a LaserWriter at imaging, the aggregate throughput was often much higher since it has two page buffers, and could be imaging a page while the previous one was still being sent out to the marking engine. Hardware buffering for serial ports (and maybe even a second processor for AppleTalk or Ethernet) would also reduce this kind of waiting. There's nothing like having a Linotron 300 ignore its input stream for 10 seconds per page to make you appreciate an I/O processor :-). > A shifter-masker is > included in the Adobe Redstone controller, versions of which are used in all > present PostScript printers except the LaserWriter. This activity is one > that would benefit greatly from having a separate, parallel processor; its > interface with the rest of PostScript would be quite simple. Well, aside from the fact that this is a little dated, advances in the 68000 family can also gain some of these benefits. The 68020 and 68030, for example, are much better at shifting and doing bit field operations that the 68000 was. Amanda Walker Speaker To PostScript InterCon Systems Corporation --