home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / next / hardware / 2562 < prev    next >
Encoding:
Internet Message Format  |  1992-11-07  |  3.0 KB
  1. Path: 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
  2. From: jfr@RedBrick.COM
  3. Newsgroups: comp.sys.next.hardware
  4. Subject: Re: New RISC workstations / 88110 demise
  5. Keywords: RISC
  6. Message-ID: <1992Nov5.160900.12965@RedBrick.COM>
  7. Date: 5 Nov 92 16:09:00 GMT
  8. References: <1992Nov2.170741.2092@jhunix.hcf.jhu.edu> <Bx5Iwn.to.2@cs.cmu.edu> <1992Nov5.070604.2071@cubetech.com>
  9. Sender: usenet@RedBrick.COM
  10. Organization: Red Brick Systems, Los Gatos, CA
  11. Lines: 43
  12. Nntp-Posting-Host: glitter.redbrick.com
  13.  
  14. In article <1992Nov5.070604.2071@cubetech.com> andrew@cubetech.com writes:
  15. >In article <Bx5Iwn.to.2@cs.cmu.edu> ddj+@cs.cmu.edu (Doug DeJulio) writes:
  16. >>In article <1992Nov2.170741.2092@jhunix.hcf.jhu.edu> eboltz@jhunix.hcf.jhu.edu (Eric Scott Boltz) writes:
  17. >>>This week's Info World, "Reports from the Field" claims that NeXT has
  18. >>>terminated the dual 88110 NRW and will go with the P5 (Pentium) from
  19. >>>Intel in future machines.
  20. >>>
  21. >>>This sucks for a few reasons:
  22. >>>1. We won't have a faster NeXT till the P5 ships.
  23. >>>2. We're stuck with Intel.
  24. >>>3. The NRW will be AS FAST AS A HIGH-END CLONE.
  25. >>
  26. >>This last item is not neccesarily true.  Let's suppose NeXT goes with
  27. >>the P5.  Remember that the NeXT OS, Mach, already has support for
  28. >>multiprocessor systems.  Doesn't the P5 have enhanced support for
  29. >>working in multiprocessor systems?  Can you imagine a four processor
  30. >>P5 system, with one processor devoted to a realtime Display PostScript
  31. >>environment, another devoted to a realtime sound server (including a
  32. >>port pin-compatible with the current DSP port), and two more for
  33. >>general purpose CPU tasks?  NeXT could put out a wide variety of
  34. >>systems simply by changing the number of processors.
  35. >
  36. >Dedicating processors is stupid (a whole P5 for sound?  what a waste).
  37. >Let mach split everything up on all the processors and use thread
  38. >priorities to ensure good interactive performance.
  39. >
  40.   I agree with the comment on a P5 for sound.  The exception to this
  41.   would seem to be the Window Server.  I would assume there could be
  42.   some extremely useful optimizations both in hardware and software
  43.   that could be made if a complete processor is dedicated to the
  44.   window server process.  Since the Window Server has to be constantly
  45.   operating anyway (unlike the sound process and most other processes),
  46.   dedicating a single processor for this app might be useful.  
  47.   
  48.   Of course this has to be handled carefully in order to not disrupt
  49.   support for systems where there is no specialized Window Server
  50.   processor.  I.e., there still has to be a normal WS process that
  51.   is simply assigned and locked to the WS processor on a multi-process
  52.   system, and has internal smarts that lets it optimize operations
  53.   (such as direct access to a video bus, or something like that)
  54.   in the dedicated processor environment.  
  55.  
  56.   Jon Rosen
  57.