Why so little parallelism?
|
From: Nick Maclaren on 11 Dec 2006 13:30 In article <elk7tr$bv4$1(a)gemini.csx.cam.ac.uk>, nmm1(a)cus.cam.ac.uk (Nick Maclaren) writes: |> |> |> %A C. A. R. Hoare |> |> %T Communicating Sequential Processes |> |> Yup. You've got it. Cooperating. Sequential. Processes. That is |> precisely what most modern threads are, so I think that his title is |> still appropriate. Don't you? Communicating, of course :-( I have a blind spot on that one, as either word fits in the context. Regards, Nick Maclaren.
From: Eugene Miya on 11 Dec 2006 12:34 In article <457d9f0f$1(a)darkstar>, eugene(a)cse.ucsc.edu (Eugene Miya) writes: >|> I thought you said you were leaving this Usenet thread? In article <elk7tr$bv4$1(a)gemini.csx.cam.ac.uk>, Nick Maclaren <nmm1(a)cus.cam.ac.uk> wrote: >I said that I wasn't going to respond to your nonsense any longer, >which is not the same thing. I am, however, prepared to help with >your education. Oh you are like Steve Jasik from the old Mac crowd (everything circles on your decisions). >|> >It depends on what you mean by threads, but you are correct to some >|> >extent. Hoare's title is still appropriate. >|> >|> Oh yeah? >|> >|> >|> Of course a real programmer can write fortran in any language, as we >|> >|> used to say. >|> > >|> >As Jan Vorbrueggen says, Fortran introduced array operations as a >|> >first-class concept over 15 years ago! >|> >|> 1991? >|> Not clear. >|> >|> Yeah I am trying to figure out your line of reasoning, and it's short of >|> pulling teeth. >|> >|> %A C. A. R. Hoare >|> %T Communicating Sequential Processes > >Yup. You've got it. Cooperating. Sequential. Processes. That is >precisely what most modern threads are, so I think that his title is >still appropriate. Don't you? Yeah, and you cited 1960s (go back), and the CSP paper was 1978. And the cited person cited 70s. Unless you can find an earlier citation. >|> Programming languages - Fortran - Part 1: Base language >|> %R ISO/IEC 1539-1:1997(E) >|> the 1997 is the version (that's when "Fortran 95" was formally published), >|> and the E is for English. > >I don't know what you were up to in the early 1990s, but "Fortran 95" >was a minor tweak to Fortran 90, which was the revision that added >the array features. So, try ISO/IEC 1539:1991(E). Yup. 1991. Nick go back. You cited 1995: Article 39807 of comp.arch: From: nmm1(a)cus.cam.ac.uk (Nick Maclaren) Newsgroups: comp.arch Subject: Re: Proposition for Nick (open): Why so little parallelism? Date: 18 Nov 2006 13:31:03 GMT Organization: University of Cambridge, England Message-ID: <ejn1un$nut$1(a)gemini.csx.cam.ac.uk> References: <1161776197.073940.210000(a)f16g2000cwb.googlegroups.com> <455a4b26$1(a)darkstar> <455b59d2$1(a)darkstar> <ejg8m7$lfp$1(a)gemini.csx.cam.ac.uk> <455e0961$1(a)darkstar> NNTP-Posting-Host: draco.cus.cam.ac.uk Originator: nmm1(a)draco.cus.cam.ac.uk Path: darkstar!newsfeed.berkeley.edu!ucberkeley!news.tele.dk!feed118.news.tele.dk!news.tele.dk!small.news.tele.dk!tiscali!newsfeed1.ip.tiscali.net!proxad.net!news.cs.univ-paris8.fr!feeder.news.heanet.ie!feed4.jnfs.ja.net!jnfs.ja.net!gemini.csx.cam.ac.uk!news.cam.ac.uk!nmm1 .... Gene, sometimes you really are a clot. I wrote that to be precisely the converse of your equally ridiculous request. Without a clue as .... As far as software goes, try: .... The Fortran 95/2003 standard plus 2-3 vector computer User's Guides, to show a successful, clean parallel design for a small subset of calculations. .... |> [ A lot of petulance ] Petulance you say? eh? Losing your English cool? --
From: Del Cecchi on 11 Dec 2006 14:12 Eugene Miya wrote: > Del Cecchi wrote: > >>>> And Threads? Aren't >>>> >>>>>they just parallel sugar on a serial mechanism? > > > In article <_oOdneG2v-ejCODYnZ2dnUVZ_rOqnZ2d(a)metrocastcablevision.com>, > Bill Todd <billtodd(a)metrocast.net> wrote: > >>>>Not when each is closely associated with a separate hardware execution >>>>context. > > > Eugene Miya wrote: > >>>Threads are just lightweight processes. >>>Most people don't see the baggage which gets copied when an OS like Unix >>>forks(2). And that fork(2) is light weight compared to the old style VMS >>>spawn and the IBM equivalents. And Dijkstra and others ignored lots of >>>that stuff when he first wrote about it. > > > In article <1165861096.174435.238830(a)73g2000cwn.googlegroups.com>, > jacko <jackokring(a)gmail.com> wrote: > >>more baggage equals more bombs. > > > Metaphoric? Or real? > Process creation and context switching is lots of copying. > > >>>>And when multiple threads are used on a single hardware >>>>execution context to avoid explicitly asynchronous processing (e.g., to >>>>let the processor keeping doing useful work on something else while one >>>>logical thread of execution is waiting for something to happen - without >>>>disturbing that logical serial process flow), that seems more like >>>>serial sugar on a parallel mechanism to me. >>> >>>Distributed memory or shared memory? >> >>Any memory which ain't that slow and hot stuff. > > > How? > Which? > > > >>>>Until individual processors stop being serial in the nature of the way >>>>they execute code, I'm not sure how feasible getting rid of ideas like >>>>'threads' will be (at least at some level, though I've never >>>>particularly liked the often somewhat inefficient use of them to avoid >>>>explicit asynchrony). >>> >>>What's their nature? >> >>new anti sequential PrologAPL i assume? > > > Never heard of it. So where do people find out more? > I stopped following the New Generation Prolog work some years ago. > Are there still Inference Engines being made in Japan? > And when was APL tacked on? > "new anti sequential PrologAPL i assume?" mostly sounds like sarcasm, although sometimes it is hard to tell. Sure, processors are sequential, and only do a few micro ops per cycle. That drove the procedural, one step at a time nature of nearly everything we do with computers. -- Del Cecchi "This post is my own and doesn�t necessarily represent IBM�s positions, strategies or opinions.�
From: Eugene Miya on 11 Dec 2006 13:59 >>>>>Until individual processors stop being serial in the nature of the way >>>>>they execute code, I'm not sure how feasible getting rid of ideas like >>>>>'threads' will be (at least at some level, though I've never >>>>>particularly liked the often somewhat inefficient use of them to avoid >>>>>explicit asynchrony). >>>>What's their nature? In article <1165861096.174435.238830(a)73g2000cwn.googlegroups.com>, jacko <jackokring(a)gmail.com> wrote: >>>new anti sequential PrologAPL i assume? >> Never heard of it. So where do people find out more? >> I stopped following the New Generation Prolog work some years ago. >> Are there still Inference Engines being made in Japan? >> And when was APL tacked on? In article <4u5orpF16kei8U1(a)mid.individual.net>, Del Cecchi <cecchinospam(a)us.ibm.com> wrote: >"new anti sequential PrologAPL i assume?" mostly sounds like sarcasm, >although sometimes it is hard to tell. Oh, could be. I can give him the benefit of a doubt. One thing you can tell about most English speakers is that they don't know much about what's happening in the Rest Of the World. ROW is a technical Intel term. >Sure, processors are sequential, and only do a few micro ops per cycle. > That drove the procedural, one step at a time nature of nearly >everything we do with computers. Yep. Very powerful idea not well understood outside computing. Also what made the guys like Amdahl, Brooks, and Cray as giants of the field. --
From: Bill Todd on 11 Dec 2006 15:45
Eugene Miya wrote: > In article <_oOdneG2v-ejCODYnZ2dnUVZ_rOqnZ2d(a)metrocastcablevision.com>, > Bill Todd <billtodd(a)metrocast.net> wrote: >> Del Cecchi wrote: >> And Threads? Aren't >>> they just parallel sugar on a serial mechanism? >> Not when each is closely associated with a separate hardware execution >> context. > > Threads are just lightweight processes. Irrelevant to what you were purportedly responding to. > Most people don't see the baggage which gets copied when an OS like Unix > forks(2). And that fork(2) is light weight compared to the old style VMS > spawn and the IBM equivalents. Also irrelevant to what you were purportedly responding to. When (as I said, but you seem to have ignored) each thread is closely associated with a *separate* hardware execution context, it's simply the software vehicle for using that execution context in parallel with other execution contexts. .... >> And when multiple threads are used on a single hardware >> execution context to avoid explicitly asynchronous processing (e.g., to >> let the processor keeping doing useful work on something else while one >> logical thread of execution is waiting for something to happen - without >> disturbing that logical serial process flow), that seems more like >> serial sugar on a parallel mechanism to me. > > Distributed memory or shared memory? Are you completely out to lunch today? Try reading what I said again. > >> Until individual processors stop being serial in the nature of the way >> they execute code, I'm not sure how feasible getting rid of ideas like >> 'threads' will be (at least at some level, though I've never >> particularly liked the often somewhat inefficient use of them to avoid >> explicit asynchrony). > > What's their nature? To execute a serial stream of instructions, modulo the explicit disruptions of branches and subroutines and hardware interrupt facilities (which themselves simply suspend one serial thread of execution for another). At least if one is talking about 99.99+% of the processors in use today (and is willing to call SMT cores multiple processors in this regard, which given the context is hardly unreasonable). The fact that they may take advantage of peephole optimization to reorder some of the execution is essentially under the covers: the paradigm which they present to the outside world is serial in nature, and constructs like software threads follow fairly directly from it. - bill |