Article View: comp.sys.next.hardware
Article #938Re: New RISC workstations / 88110 demise
From: jfr
Date: Thu, 05 Nov 1992 16:09
Date: Thu, 05 Nov 1992 16:09
43 lines
3087 bytes
3087 bytes
In article <1992Nov5.070604.2071@cubetech.com> andrew@cubetech.com writes: >In article <Bx5Iwn.to.2@cs.cmu.edu> ddj+@cs.cmu.edu (Doug DeJulio) writes: >>In article <1992Nov2.170741.2092@jhunix.hcf.jhu.edu> eboltz@jhunix.hcf.jhu.edu (Eric Scott Boltz) writes: >>>This week's Info World, "Reports from the Field" claims that NeXT has >>>terminated the dual 88110 NRW and will go with the P5 (Pentium) from >>>Intel in future machines. >>> >>>This sucks for a few reasons: >>>1. We won't have a faster NeXT till the P5 ships. >>>2. We're stuck with Intel. >>>3. The NRW will be AS FAST AS A HIGH-END CLONE. >> >>This last item is not neccesarily true. Let's suppose NeXT goes with >>the P5. Remember that the NeXT OS, Mach, already has support for >>multiprocessor systems. Doesn't the P5 have enhanced support for >>working in multiprocessor systems? Can you imagine a four processor >>P5 system, with one processor devoted to a realtime Display PostScript >>environment, another devoted to a realtime sound server (including a >>port pin-compatible with the current DSP port), and two more for >>general purpose CPU tasks? NeXT could put out a wide variety of >>systems simply by changing the number of processors. > >Dedicating processors is stupid (a whole P5 for sound? what a waste). >Let mach split everything up on all the processors and use thread >priorities to ensure good interactive performance. > I agree with the comment on a P5 for sound. The exception to this would seem to be the Window Server. I would assume there could be some extremely useful optimizations both in hardware and software that could be made if a complete processor is dedicated to the window server process. Since the Window Server has to be constantly operating anyway (unlike the sound process and most other processes), dedicating a single processor for this app might be useful. Of course this has to be handled carefully in order to not disrupt support for systems where there is no specialized Window Server processor. I.e., there still has to be a normal WS process that is simply assigned and locked to the WS processor on a multi-process system, and has internal smarts that lets it optimize operations (such as direct access to a video bus, or something like that) in the dedicated processor environment. Jon Rosen
Technical Details
Message-ID:
<1992Nov5.160900.12965@RedBrick.COM>Path:
arc1-ca.pugleaf.net!sparky!uunet!portal!lll-winken!cert!netnews.upenn.edu!dsinc!cs.widener.edu!iggy.GW.Vitalink.COM!pacbell.com!decwrl!sdd.hp.com!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!rpi!scott.skidmore.edu!psinntp!psinntp!spunky!jfrReferences:
<1992Nov2.170741.2092@jhunix.hcf.jhu.edu> <Bx5Iwn.to.2@cs.cmu.edu> <1992Nov5.070604.2071@cubetech.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!portal!lll-winken!cert!netnews.upenn.edu!dsinc!cs.widener.edu!iggy.GW.Vitalink.COM!pacbell.com!decwrl!sdd.hp.com!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!rpi!scott.skidmore.edu!psinntp!psinntp!spunky!jfr From: jfr@RedBrick.COM Newsgroups: comp.sys.next.hardware Subject: Re: New RISC workstations / 88110 demise Keywords: RISC Message-ID: <1992Nov5.160900.12965@RedBrick.COM> Date: 5 Nov 92 16:09:00 GMT References: <1992Nov2.170741.2092@jhunix.hcf.jhu.edu> <Bx5Iwn.to.2@cs.cmu.edu> <1992Nov5.070604.2071@cubetech.com> Sender: usenet@RedBrick.COM Organization: Red Brick Systems, Los Gatos, CA Lines: 43 Nntp-Posting-Host: glitter.redbrick.com