cs326ag@ux1.cso.uiuc.edu (Loren J. Rittle) (04/09/91)
In article <1991Apr8.222503.23643@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: > > Michael, you keep saying Display Postscript isn't a problem, but in fact >it is. Interpreted languages are usually on the order of 4-10 times slower >than compiled languages. DP is reasonably complex, and given how large Disclaimer: I don't own a NeXT and most likely never will. I am a tried and true Amiga lover, but when I see someone `going' crazy, I have to speak up. Ray, I have no real idea about DPS on the NeXT, but ARexx ran some simple tests I put it through half as fast as C code to produce the same results... Since DPS is drawing graphics (a normally slow process on machines without custom chip support... :-), I'd bet the trade-off is not so bad. Most of the time is spent doing draws of objects on the screen with the '0[34]0. See, no matter what language generates the commands to draw, the bottleneck (for *all* current systems, I know about) is in the graphic hardware (or in this case, the line/shape drawing code running on the '0[34]0). [As an aside: those ARexx/C tests when writing to standard console window (i.e. simple graphics), made it so one could not tell by timing which code was running. Put that in your pipe and sm...] Because PostScript (something I do know about) is related to Forth, it can be quite `lean and mean' and produce results in time that rivals those produced by compiled languages. Beside, the NeXT does not use DPS for every window on the blasted screen, only applications that need it request it! Chances are very good that if the application requests a DPS window it really need it and would have to do many of the same things that go on in the DPS code. >postscript descriptions of complex screens can get, I'd say that your 15mips >DP interpreter would run at an effective 2-3 MIPS. (Probably slower than Here again, I'm afraid you are off base... If an application really needs the power of DPS, *it* *would* *run* at the same speed, plus the author of the program would have to code that power in his application, without DPS. Sure he may be able to hand optimize for his exact case and gain some finite amount of speed, but I dare say that it would not be worth it! Look the *same* argument you are using against DPS could, in theory be used against, say, ARexx. For this reason, I can't let it slip by. See with ARexx, no application writer ever has to hand code a macro language on the Amiga again. It may not be the best macro language in *every* case, but overall it is a damn good thing that I would not want to be without today. DPS is the same type of thing... Maybe less useful in your eyes, but as a developer, it can save a hell of a lot of time. Why do you think that many DP (see why DPS is used for Display PostScript, DP is desktop publishing... :-) packages only produce PS code? Cause it's damn easy, that's why... [I know, today all the big DP programs on the Amiga can make bitmaps, too.] Anyways, the whole point is moot as with POST v1.5, applications can request DPS services (A new version of a commercial program that I'm beta testing does this, nope I'm not saying, so don't even ask). I believe you are only against it, cause its on the NeXT... >SoftPC) If Jobs was smart, he would have put an extra 68030 in the NeXT >to offload the DP work. If an Amiga user adds an 040 card to the A3000, the >onboard 030 will become availible for offloading i/o, etc. This may or may not be true. In theory, the hardware will work together, but to realize any practical configuration `interesting' software will need to be written. I have no doubt that someone, somewhere will figure out a good way to may use of it, but it won't be useful the moment you drop your '040 card in. >/~\_______________________________________________________________________/~\ >|n| rjc@albert.ai.mit.edu Amiga, the computer for the creative mind. |n| >|~| .-. .-. |~| >|_|________________________________| |_| |________________________________|_| Nice castle! Loren J. Rittle -- ``The Amiga continues to amaze me--if I had not been told that this video was created using the Amiga and Toaster, I would not have believed it. Even Allen said, `I think I know how he did most of the effects.' '' - Jim Lange Loren J. Rittle l-rittle@uiuc.edu
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (04/09/91)
In article <1991Apr8.233820.23307@ux1.cso.uiuc.edu> cs326ag@ux1.cso.uiuc.edu (Loren J. Rittle) writes: >In article <1991Apr8.222503.23643@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: >> >> Michael, you keep saying Display Postscript isn't a problem, but in fact >>it is. Interpreted languages are usually on the order of 4-10 times slower >>than compiled languages. DP is reasonably complex, and given how large > >Disclaimer: I don't own a NeXT and most likely never will. > I am a tried and true Amiga lover, but when I see > someone `going' crazy, I have to speak up. > >Ray, > I have no real idea about DPS on the NeXT, but ARexx ran some simple tests >I put it through half as fast as C code to produce the same results... Since >DPS is drawing graphics (a normally slow process on machines without custom >chip support... :-), I'd bet the trade-off is not so bad. Most of the >time is spent doing draws of objects on the screen with the '0[34]0. >See, no matter what language generates the commands to draw, the >bottleneck (for *all* current systems, I know about) is in the >graphic hardware (or in this case, the line/shape drawing code running >on the '0[34]0). Basically, true. The more i/o bound a program is, the faster it will run. (interpreted). Try the following in Arexx. 'do for 10000;end'. It takes AWHILE on a std 68000. >[As an aside: those ARexx/C tests when writing to standard console >window (i.e. simple graphics), made it so one could not tell by timing >which code was running. Put that in your pipe and sm...] > > Because PostScript (something I do know about) is related to Forth, >it can be quite `lean and mean' and produce results in time that rivals >those produced by compiled languages. Beside, the NeXT does not >use DPS for every window on the blasted screen, only applications >that need it request it! Chances are very good that if the application >requests a DPS window it really need it and would have to do many >of the same things that go on in the DPS code. I don't know the full implementation details of DP. Forth is implemented in a variety of ways, but usually it's tokenized and attached to a small (fast) run time module. Other methods use threaded jsrs, etc. One thing I like about forth is basically anyone can write an interpreter/parser for it. It's syntacically simple. I don't want to get flamed, but I dislike reverse polish notation. >>postscript descriptions of complex screens can get, I'd say that your 15mips >>DP interpreter would run at an effective 2-3 MIPS. (Probably slower than > > Here again, I'm afraid you are off base... If an application really >needs the power of DPS, *it* *would* *run* at the same speed, >plus the author of the program would have to code that power >in his application, without DPS. Sure he may be able to hand optimize >for his exact case and gain some finite amount of speed, but I dare >say that it would not be worth it! I guess I'm a alittle ignorant of DP on the NeXT. I thought DP was forced on the user and it couldn't be disabled. The speed I was talking about is, 2-3 million DP instructions executed per second. Of course the i/o runs at 15mips, but between each DP instruction you have the parser overhead and translation. >Look the *same* argument you are using against DPS could, in theory >be used against, say, ARexx. For this reason, I can't let it slip >by. See with ARexx, no application writer ever has to hand code >a macro language on the Amiga again. It may not be the best >macro language in *every* case, but overall it is a damn good >thing that I would not want to be without today. DPS is the >same type of thing... Maybe less useful in your eyes, but as >a developer, it can save a hell of a lot of time. Why do you >think that many DP (see why DPS is used for Display PostScript, >DP is desktop publishing... :-) packages only produce PS code? >Cause it's damn easy, that's why... [I know, today all the big >DP programs on the Amiga can make bitmaps, too.] But Arexx isn't used to build the display. I *love* Arexx, however I wouldn't use it to render bitmaps and animate. DPS is a neat idea, but about as useful as using an Arexx port on AmigaTeX to create a DVI file and then preview it as your primary display system. >Anyways, the whole point is moot as with POST v1.5, applications >can request DPS services (A new version of a commercial program that I'm >beta testing does this, nope I'm not saying, so don't even ask). >I believe you are only against it, cause its on the NeXT... I'm against it, because I think it wastes CPU resources. Sure, if I had a cray, I'd have interpreted C code as the primary language develop code in, but I don't. If DPS is really an option, than it's ok. But if all display rendering has to go through DPS than it's a waste. This is much like the 'take over the OS thread' we had in comp.sys.amiga. programmer. The graphic.library routines are too slow for fast action games, so Owning the blitter and display is the best method. DPS would be an order of magnitude worse than the graphics.library animob routines. >>SoftPC) If Jobs was smart, he would have put an extra 68030 in the NeXT >>to offload the DP work. If an Amiga user adds an 040 card to the A3000, the >>onboard 030 will become availible for offloading i/o, etc. > >This may or may not be true. In theory, the hardware will work >together, but to realize any practical configuration `interesting' >software will need to be written. I have no doubt that someone, >somewhere will figure out a good way to may use of it, but it won't >be useful the moment you drop your '040 card in. Welp, I'm an enterprising hacker...:-) If I got an 040 card, I'd probably hack something up. I already have some ideas on what could be done with it. >>/~\_______________________________________________________________________/~\ >>|n| rjc@albert.ai.mit.edu Amiga, the computer for the creative mind. |n| >>|~| .-. .-. |~| >>|_|________________________________| |_| |________________________________|_| >Nice castle! > >Loren J. Rittle >-- >``The Amiga continues to amaze me--if I had not been told that this video was > created using the Amiga and Toaster, I would not have believed it. Even > Allen said, `I think I know how he did most of the effects.' '' - Jim Lange > Loren J. Rittle l-rittle@uiuc.edu -- /~\_______________________________________________________________________/~\ |n| rjc@albert.ai.mit.edu Amiga, the computer for the creative mind. |n| |~| .-. .-. |~| |_|________________________________| |_| |________________________________|_|