Big OOO, SpMT, and possible designs
|
From: nmm1 on 20 May 2010 09:27 In article <r5ofc7-d94.ln1(a)laptop.reistad.name>, Morten Reistad <first(a)last.name> wrote: >> >>Yup. The requirement to look good on benchmarks written in sequential, >>hard-to-parallelise C has made it really hard to market parallel >>computers except for multicores that essentially run each their own >>sequential programs. > >May I suggest apache and squid web page serving, mysql lookups and >stores, and phone calls through asterisk as benchmarks? But those ARE precisely the ones that essentially run each their own sequential programs! Regards, Nick Maclaren.
From: Torben �gidius Mogensen on 20 May 2010 10:34 Morten Reistad <first(a)last.name> writes: > In article <7zfx1neyk0.fsf(a)ask.diku.dk>, > Torben �gidius Mogensen <torbenm(a)diku.dk> wrote: >>Now, if APL had been the dominant language through the 1990s, we would >>have seen very different hardware now. > > Java became the dominant language with their special requirements. > We have seen very little hardware to support that. Java is not all that different from C. Both are essentially sequential imperative languages. Torben
From: Morten Reistad on 20 May 2010 11:49 In article <ht3dbm$neg$1(a)smaug.linux.pwf.cam.ac.uk>, <nmm1(a)cam.ac.uk> wrote: >In article <r5ofc7-d94.ln1(a)laptop.reistad.name>, >Morten Reistad <first(a)last.name> wrote: >>> >>>Yup. The requirement to look good on benchmarks written in sequential, >>>hard-to-parallelise C has made it really hard to market parallel >>>computers except for multicores that essentially run each their own >>>sequential programs. >> >>May I suggest apache and squid web page serving, mysql lookups and >>stores, and phone calls through asterisk as benchmarks? > >But those ARE precisely the ones that essentially run each their own >sequential programs! Up to a point. You have locking and context semantics to hold you up. Especially asterisk is a challenge there, because any media stream will have to exist in two contexts; the in and out part of the call. I don't know how to get around that without making a dispatcher table which will be the mother of all locking contention. -- mrr
From: Rick Jones on 20 May 2010 13:36 nmm1(a)cam.ac.uk wrote: > But those ARE precisely the ones that essentially run each their own > sequential programs! Isn't the whole point (perhaps that is the problem?) of SMP tuning is to make an N-way system look as much like N 1-way systems as possible? rick jones -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: nmm1 on 20 May 2010 16:08
In article <ht3ruj$rvu$5(a)usenet01.boi.hp.com>, Rick Jones <rick.jones2(a)hp.com> wrote: > >> But those ARE precisely the ones that essentially run each their own >> sequential programs! > >Isn't the whole point (perhaps that is the problem?) of SMP tuning is >to make an N-way system look as much like N 1-way systems as possible? Yes :-( hat is precisely why the successes are primarily the embarrassingly parallel problems. Regards, Nick Maclaren. |