Big OOO, SpMT, and possible designs
|
From: Terje Mathisen "terje.mathisen at on 21 May 2010 04:11 Torben �gidius Mogensen wrote: > 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. For some problems, Jave makes things even worse due to even stricter insistence on "there can only be one possible answer here, and that is the one you get by evaluating all fp operations in the exact order specified". Not conductive to optimized code. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
From: Morten Reistad on 21 May 2010 04:54 In article <ht44so$brk$1(a)smaug.linux.pwf.cam.ac.uk>, <nmm1(a)cam.ac.uk> wrote: >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. Well, if the 5 most widespread internet programs are classed as "embarrassingly parallell" that is good news, because there are so many scripts and applications based on those. If you can get mysql to run with screaming speed on 100+ processors on typical internet workloads then a whole class of problems suddenly scaled up performance by an order of magnitude. Ditto for the web feeding software (apache, squid), media switching (Ser/kamailio/asterisk) and the OS itself. These are extra important because applications like these are the ones at the core of large infrastructures. All the small applets and customer views access these to perform persistent transactions. From the measurements we have done the important contention parts happen in the OS kernel. That is the single most critical piece to parallellise. That reduces the count of programs to look at substantially. -- mrr
From: nmm1 on 21 May 2010 05:39 In article <hauhc7-8g4.ln1(a)laptop.reistad.name>, Morten Reistad <first(a)last.name> wrote: >In article <ht44so$brk$1(a)smaug.linux.pwf.cam.ac.uk>, <nmm1(a)cam.ac.uk> wrote: >>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. > >Well, if the 5 most widespread internet programs are classed as >"embarrassingly parallell" that is good news, because there are so >many scripts and applications based on those. If you can get mysql >to run with screaming speed on 100+ processors on typical internet >workloads then a whole class of problems suddenly scaled up performance >by an order of magnitude. Yes and no. Amdahl's law applies just as much to aggregate workloads as to single programs, and that's the problem. The current approaches are far too often treating the problem as if those are the ONLY ones that matter. That's not good. >From the measurements we have done the important contention parts >happen in the OS kernel. That is the single most critical piece to >parallellise. Yup. That's the next step. I am interested in the one after that, like any good academic :-) Regards, Nick Maclaren.
From: Morten Reistad on 21 May 2010 12:34 In article <ht5kcg$1dl$1(a)soup.linux.pwf.cam.ac.uk>, <nmm1(a)cam.ac.uk> wrote: >In article <hauhc7-8g4.ln1(a)laptop.reistad.name>, >Morten Reistad <first(a)last.name> wrote: >>In article <ht44so$brk$1(a)smaug.linux.pwf.cam.ac.uk>, <nmm1(a)cam.ac.uk> wrote: >>>In article <ht3ruj$rvu$5(a)usenet01.boi.hp.com>, >>>Rick Jones <rick.jones2(a)hp.com> wrote: >>>hat is precisely why the successes are primarily the embarrassingly >>>parallel problems. >> >>Well, if the 5 most widespread internet programs are classed as >>"embarrassingly parallell" that is good news, because there are so >>many scripts and applications based on those. If you can get mysql >>to run with screaming speed on 100+ processors on typical internet >>workloads then a whole class of problems suddenly scaled up performance >>by an order of magnitude. > >Yes and no. Amdahl's law applies just as much to aggregate workloads >as to single programs, and that's the problem. The current approaches >are far too often treating the problem as if those are the ONLY ones >that matter. That's not good. That is why I rejoice if a new class of problems is called "embarrassingly parallell"; because that means the knee im Amdahls curve has been moved by a factor of ten or so. The applications mentioned surely can work very well in parallell environments, but there are some contention points. Like enqueueing packets or messages, dispatcher table updates etc. But we are seeing that the OS kernel primitives are the limiting factors, not the applications. When asterisk switches 12800 calls on 8 processors, asterisk itself uses less than 100% of cpu on ONE processor, but Linux itself took the other 7. Web servers behave likewise. >>From the measurements we have done the important contention parts >>happen in the OS kernel. That is the single most critical piece to >>parallellise. > >Yup. That's the next step. I am interested in the one after that, >like any good academic :-) I tend to end in the thick of implementation, like any good systems designer. -- mrr
From: Rick Jones on 21 May 2010 13:16
> >From the measurements we have done the important contention parts > >happen in the OS kernel. That is the single most critical piece to > >parallellise. > Yup. That's the next step. I am interested in the one after that, > like any good academic :-) That's ironic - in my corner of the 'net at least a great deal of effort was put into getting a kernel to scale and thus out of the way and we are having to address the applications and their developers :) rick jones -- denial, anger, bargaining, depression, acceptance, rebirth... where do you want to be today? 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... |