Linked by Thom Holwerda on Fri 28th Oct 2005 11:17 UTC
Hardware, Embedded Systems Herb Sutter, a software architect from Microsoft, gave a speech yesterday at In-Stat/MDR's Fall Processor Forum. Addressing a crowd mostly consisting of hardware engineers, he talked about how the software world was ill-prepared to make use of the new multicore CPUs coming from Intel and AMD.
Thread beginning with comment 52466
To read all comments associated with this story, please click here.
MP readiness
by on Fri 28th Oct 2005 15:24 UTC

Member since:

"As BeOS shows, when wholy multithreaded, a system get better responsiveness. When running on a SMP machine, it expand performance too."

True, one quote amongst many. Multithreaded/multiprocessor ready applications should show performance gains in SMP/multicore machines unless extremely poorly designed. This being said, I'd fully place the blame on MS for not pushing awareness of performance gains of SMP/multicore aware software. After all it has been fairly cheap to build SMP machines for some time now, however windows software, generally, never really took advantage of it as compared to other OSes and applications developed for those OSes. As an end user example, I would have expected games to long since have taken advantage of SMP when available, alas this has never happened as most developers eventually trot out the "'s more difficult to debug, so just buy a 'bigger' CPU..." excuse.

Reply Score: 0

Re: MP readiness
by on Fri 28th Oct 2005 16:18 in reply to "MP readiness"
Member since:

"windows software, generally, never really took advantage of it as compared to other OSes and applications developed for those OSes."

Threading is supported since Win32 (around 1994-95, IIRC), when for example Linux and xBSD thread support came a little bit later, not talking about MacOS Classic. Anyway, most if not all *live* OSes support threading at least, so are ready (more or less) for SMP.

What's important here is what programming model mainstream programmers are used to. And, as a matter of fact, most of them are used to the classic sequencial and the event-driven model.
Win32, Coccoa, Qt, QDK, Java AWT & SWING, all provides fundations for both models and don't make threading your software nor mandatory nor recommanded. They all provides threading support but it's up to the developers to chose to use it or not.

This doesn't means developers don't used threads sometimes, just they're not yet fluent in real asynchronous software design.

Which is not *that* easy, BTW, compared to previous programming model. And could quickly become really messy too, thanks to deadlocks.
Just like many IT methods, doing multithreading just for the sake of it is not always the right way to do things. Sometime a "naive" threaded model keep your design and code (and debugging) simpler, sometime sequencial programming is better. It all depends on what you're after and the compromise you're ready to accept.

But just for performance on SMP systems, threading is a good way to do it today, sure.

Reply Parent Score: 1

RE: Re: MP readiness
by on Fri 28th Oct 2005 19:02 in reply to "Re: MP readiness"
Member since:

Microsoft Windows had full support for multiple threads and SMP with Windows NT 3.1, released in 1993.

Windows NT and derivatives (depending on the version) have supported from 2-32 processors (that number might have gotten larger); there is/was a single processor kernel and an SMP kernel, and one was installed/booted depending on the machine configuration it was installed on, at least at first.

Where SMP gets fun and suffers a general system performance degradation is during low-level kernel operations in interrupts that require spinlocks. This is why there is/was the single processor kernel and the SMP kernel.

Whether you have more than one processor per package or not, it makes no execution difference for correctness to the programmer, and indeed, it doesn't even matter if there's only one processor to the programmer for correctness: an application that uses more than one thread that is written correctly for synchronization will execute correctly on any number of processors, whereas one written incorrectly may appear to work on a single processor machine, or one particular machine, but will be notably less stable when run on a true SMP system where more than one thread can actually be modifying the same data at the same time with a higher probability. Technically, an incorrectly written multithreaded application can suffer the same problem if there are race conditions, but the user may get lucky more often than not, while their luck will degrade greatly based on the number of processors and threads that touch the same data at the same time increase.

Reply Parent Score: 0

RE: MP readiness
by rayiner on Fri 28th Oct 2005 19:48 in reply to "MP readiness"
rayiner Member since:

I'd fully place the blame on MS for not pushing awareness of performance gains of SMP/multicore aware software.

It's sort of futile to blame Microsoft. Microsoft can't change the nature of software engineering. Writing parallel code is, well, hard. It's easier in some languages (Erlang), than others (C), but its still not as easy as writing single-threaded code. Engineers don't like to do things that are hard, not until tools evolve to make them easy. Current software is fragile enough as it is --- can you imagine how much more it would suck if it were aggressively multithreaded too?

Programmers will switch en-masse to writing parallel code when tools are developed that make it nearly as easy as writing single-threaded code. These tools will take the form of language-extensions/new languages, explicit compiler support, explicit OS support, well-designed OS-level APIs, and new algorithms and advances in computer-science theory. The current "a N-way parallel program is just N single C threads" paradigm just won't cut it.

Reply Parent Score: 1