Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Silicon Graphics, Inc. (SGI) -- Ignore unavailable to you. Want to Upgrade?

To: Patrick Gainer who wrote (3925)	1/2/1998 6:14:00 AM
From: Alexis Cousein	Read Replies (1) \| Respond to of 14451

Re: Scaling OSes fro multiprocessors, semaphores et al. >But only slightly. I would argue it is very straightforward >for any competent software engineer with a bit of experience. Having watched benchmarks that had system (spent in the OS instead of in the application) time go up from 10% up to 60% for the leap of 2 to 4 processors on an NT system, effectively eating up the extra CPU (with CPUs with 256MB of secondary cache; it's better with larger caches), I think that either Microsoft software engineers have only very recently acquired 'a bit of experience', or you're underestimating. Mind you, that was on throughput, i.e. running only single CPU jobs, not even MP pograms. a) you were starting off with a Unix base OS; already quite capable for multiprocessing using time multiplexing on one CPU, and for quite some time. The leap from multiprocessing well on one CPU to doing it on more CPUs is smaller than what you get starting off with other OSes. b) semaphores are only one aspect, and there are many such aspects in the OS. Many small tasks add up to a very large one -- tracking down bottlenecks takes time; once you find one you can either be lucky, i.e. it's easy to fix things, or unlucky, i.e. you have to redesign critical parts of the OS. You usually aren't always lucky ;). c) Semaphores aren't the hardest part. An efficient scheduler that doesn't trash the processor caches, and doesn't starve any processes (especially those producing data other processes are waiting for), and handles interrupts well, is. So is avoiding false sharing in large parts of the OS routines. Forgetting even one instance of this can kill you. And I'm not even mentioning the fact that, if you have undetected potential races in software pieces, you can expect to have a lot of trouble debugging it on a fully loaded machine with lots of CPUs, so it's even more difficult to make all of this robust.