Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!agate!riacs!shelby!portia.stanford.edu!declan From: declan@portia.Stanford.EDU (Declan McCullagh) Newsgroups: comp.sys.next Subject: Re: Perceived Performance/DSP Message-ID: <1990Jul15.202600.17995@portia.Stanford.EDU> Date: 15 Jul 90 20:26:00 GMT Sender: declan@portia.Stanford.EDU (Declan McCullagh) Organization: AIR, Stanford University Lines: 62 Ivo Welch (ivo@next.agsm.ucla.edu) writes: >What really startles me is how little general-purpose software uses the DSP. I'd say the problem is that at least in the current version of the operating system, the DSP can't be shared - it's a "single user" chip. So if you're using it for some giant nifty sound manipulation or FFTs, and a spreadsheet wants to use it, that's too bad. So far, I don't really see that as a problem, since if a lot of NeXT software wants to use the DSP, you'll have some conflict over it... >I am not interested in music or electronics. IMHO, NeXT should bundle a simple >speech recognition system, so that Informix can have businessmen talk to their >spreadsheets. Can you say "Up-down-1.24-enter-1.23-next-help"? Have you seen the Sphinx spreadsheet demo? It does exactly that (albeit a bit slowly)... >This would make businesspeople buy a NeXT. I'm not so sure. Didn't a PC made by Texas Instruments have some simple voice recognition software bundled with it - about five years ago? It didn't seem to be selling too well... >On the other hand, many academics buy a NeXT because it's the best workstation >for the money (particularly after the 68040 upgrade). Exactly! It would be wonderful to find a (high-end) niche for NeXT to target, something that would allow them to move into the corporate world through the legendary back door... ... Carlos Salinas (carlos@eeyore.caltech.edu) writes: >From what I've read about Unix's scheduling algorithm, CPU intensive >activities are scheduled with a low priority, I/O intensive activities are >scheduled with a higher priority. Why? To increase the responsiveness of a >terminal login (I/O intensive.) At first, Unix systems were assumed to have very little physical memory and fast hard drives, which led to this I/O intensive approach to things (early PDP-11s supported a maximum of only 248K of main memory). Also, since the Vax systems 4BSD was developed on were CPU limited but with excess I/O capacity, this approach remained viable. Now, the NeXT needs a perky, responsive interface, and that may require a substantially different approach to scheduling... After all, Unix wasn't really designed to support a graphics interface. >Luckily NeXT is not entirely Unix, the core system is Mach. This leaves the >door open for better schedulers. A few messages ago, Robert Lin posted that NextStep v2.0 might have a substantially revised scheduler, so we can at least hope... -Declan ------------------------------------------------------------------------------ Olympic Technologies / Registered NeXT Developers \ declan@portia.stanford.edu ------------------------------------------------------------------------------