If you look at the architecture of the old Sequent systems, they were able to get linear, or near linear speedup on systems up to 32 processors. They did it with a lot of cache magic. But they had a way that straight applications could win in this environment.
I think that we generally do not do big programs in this context. We do lots of little things. In this way, multiple cores are a big win, assuming that do the right cache magic. Mike Cherba <[EMAIL PROTECTED]> writes: % Just finished reading the article. In my mind the question really % becomes a matter of provisioning multiple processors to the best % effect. I've not played with the SMP portions of the Linux kernel as % I've not had a multiproc box to run it with. However, this is an area % of real concern for me as newer generations of the network processors I % work with will have up to 16 cores within a single chip. % % I find it interesting that the article only covers one percieved facet % of mutlicore performance and doesn't really cover effective division of % work as the number of processors goes toward infinity. While SMP is a % good approach for 2 or even 4 processors, I do not believe it to be the % best approach for numbers of cores higher than that. Especially % depending on the work to be done. Once you have more than a few cores, % you can afford to specialize the tasks of each core at an even lower % level. Certain functions work best with a single CPU focused on them. % % My concerns are that most software developers today do not understand % how to design applications which effectively make use of multiple % processing units. % % Just my $.02 ! % -Mike % % -- % "The meek shall inherit the Earth. The rest of us are getting the hell % off this rock!" % _______________________________________________ % EUGLUG mailing list % [email protected] % http://www.euglug.org/mailman/listinfo/euglug ----- John Sechrest . Helping people use . computers and the Internet . more effectively . . Internet: [EMAIL PROTECTED] . . http://www.peak.org/~sechrest _______________________________________________ EUGLUG mailing list [email protected] http://www.euglug.org/mailman/listinfo/euglug
