Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!natinst!rpp386!woody From: woody@rpp386.cactus.org (Woodrow Baker) Newsgroups: comp.lang.postscript Subject: Re: Compiled PostScript Summary: computing power Message-ID: <17548@rpp386.cactus.org> Date: 3 Jan 90 23:14:48 GMT References: <1666@intercon.com> <1673@intercon.com> Organization: River Parishes Programming, Plano, TX Lines: 27 In article <1673@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: > > As several people have noted in email to me, there is a class of operation > that could arguably benefit from compilation, namely, operations that are > very compute-intensive, such as Gouraud & Phong shading, things that keep > changing the CTM, and so on. > > I say arguably because I tend to do this kind of thing on the host and then > ship the output to the printer. I admit it gets a little sticky when your > host has less computing power than your printer (for example, Don and his > Apple II and LW NTX), but that's more of a misfeature of your setup than > of the printer itself... There most definitly are some VERY slow parts of Postscript. Why in the BLEEP the floatingpoint math is done in software is totaly beyond me. The original controller should have had an 68881 or something similar. To my knowledge none of the smaller lasers have a math co-procoessor. That one simple hardware addition would make a significant impact on through put. I use a '286 at 10 and 12 Mhz for most of what I do, and as far as it goes it's a lot less powerful than the printer as well. Why do you think that the 68000 was the platform of choice for Adobe and Apple. It has the power to do it and do it right, but still it would have been far better to have included a hardware fp processor, or at least made provision for it on the mb and in the software. Cheers Woody