From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1a44c40a66c293f3 X-Google-Thread: 1089ad,7e78f469a06e6516 X-Google-Attributes: gid103376,gid1089ad,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!news-in.ntli.net!newsrout1-win.ntli.net!ntli.net!news.highwinds-media.com!newspeer1-win.ntli.net!newsfe7-win.ntli.net.POSTED!53ab2750!not-for-mail From: "Dr. Adrian Wrigley" Subject: Re: Embedded languages based on early Ada (from "Re: Preferred OS, processor family for running embedded Ada?") User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Message-ID: Newsgroups: comp.lang.ada,comp.lang.vhdl References: <113ls6wugt43q$.cwaeexcj166j$.dlg@40tude.net> <1i3drcyut9aaw.isde6utlv6iq.dlg@40tude.net> <1j0a3kevqhqal.riuhe88py2tq$.dlg@40tude.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Sat, 03 Mar 2007 16:59:52 GMT NNTP-Posting-Host: 82.21.99.109 X-Trace: newsfe7-win.ntli.net 1172941192 82.21.99.109 (Sat, 03 Mar 2007 16:59:52 GMT) NNTP-Posting-Date: Sat, 03 Mar 2007 16:59:52 GMT Organization: NTL Xref: g2news2.google.com comp.lang.ada:9657 comp.lang.vhdl:7621 Date: 2007-03-03T16:59:52+00:00 List-Id: On Sat, 03 Mar 2007 15:26:35 +0000, Jonathan Bromley wrote: > On Sat, 03 Mar 2007 13:40:16 GMT, "Dr. Adrian Wrigley" > wrote: > >> What syntax do I use, and which >>compiler, OS and processor do I need to specify and exploit >>fine-grain concurrency? >> >>In 1987, the answers were "par", Occam, Transputer. Twenty >>years later, Ada (or VHDL, C++, C#), Linux (or Windows), Niagara >>(or Tukwila, XinC, ClearSpeed, Cell) do not offer us anything >>remotely similar. In fact, in twenty years, things have >>got worse :( > > Absolutely right. And whose fault is that? Not the academics, > who have understood this for decades. Not the hardware people > like me, who of necessity must understand and exploit massive > fine-grained parallelism (albeit with a static structure). No, > it's the programmer weenies with their silly nonsense about > threads being inefficient. By the way... I am a satisfied customer of yours (from 1994). If there is any blame to share, I place it upon the language designers who don't include the basics of concurrency (and I include Ada, which has no parallel loops, statements or function calls. Nor decent pure functions). I do hardware, processor and software design. But I'm not keen on trying to fix-up programming languages, compilers and processors so they mesh better. (Unless someone pays me!) > Glad to have got that off my chest :-) But it's pretty frustrating > to be told that parallel programming's time has come, when (I'm not saying this - so don't be frustrated! What I'm saying is that multithreading has become "buzzword compliant" again, so may there's an opportunity to exploit to address longstanding technical deficiencies and rebrand Ada and/or VHDL) > I spent a decade and a half trying to persuade people that it > was worth even thinking about and being told that it was > irrelevant. Parallel programming's time hasn't quite arrived :( But it's only 3-5 years away! Still. (like flying cars, fusion power and flat screens, which never seem to get nearer. {Oh. tick off flat screens!}) > For the numerical-algorithms people, I suspect the problem of > inferring opportunities for parallelism is nearer to being solved > than some might imagine. There are tools around that > can convert DSP-type algorithms (such as the FFT that's > already been mentioned) into hardware that's inherently Again, this is ages old now. But it can't convert C-type programs reliably and efficiently. > parallel; there are behavioural synthesis tools that allow > you to explore the various possible parallel vs. serial > possibilities for scheduling a computation on heterogeneous > hardware. It's surely a small step from that to distributing > such a computation across multiple threads or CPUs. All > that's needed is the will. A small step. Like from Apollo 11. Once the language/software/compiler/processor deadlock is broken, things will move rapidly. Give it another 15 years, and we might be half way there. Glad to see that we're not so far apart as I thought! -- Adrian