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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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 Path: g2news2.google.com!news3.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!bolzen.all.de!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Embedded languages based on early Ada (from "Re: Preferred OS, processor family for running embedded Ada?") Newsgroups: comp.lang.ada,comp.lang.vhdl User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <113ls6wugt43q$.cwaeexcj166j$.dlg@40tude.net> <1i3drcyut9aaw.isde6utlv6iq.dlg@40tude.net> <1j0a3kevqhqal.riuhe88py2tq$.dlg@40tude.net> <45E9B032.60502@obry.net> <1gu2cq68c8hr$.1264r2leozvow.dlg@40tude.net> <45E9BEFC.3020202@obry.net> Date: Sat, 3 Mar 2007 21:26:05 +0100 Message-ID: <1osaczgd7ljq3$.1xvn2jd987ire.dlg@40tude.net> NNTP-Posting-Date: 03 Mar 2007 21:25:48 CET NNTP-Posting-Host: 3610c5e6.newsspool3.arcor-online.net X-Trace: DXC=UlHQVTcW8i>]E=H1Q9`787McF=Q^Z^V384Fo<]lROoR1Fl8W>\BH3Y2QFKXiB`9j^:DNcfSJ;bb[5IRnRBaCd1K:SL4f2T?7M On Sat, 03 Mar 2007 19:31:24 +0100, Pascal Obry wrote: > Dmitry A. Kazakov a �crit : > >> The idea (of PAR etc) is IMO quite opposite. It is about treating >> parallelism rather as a compiler optimization problem, than as a part of >> the domain. In the simplest possible form it can be illustrated on the >> example of Ada's "or" and "or else." While the former is potentially >> parallel, it has zero overhead compared to sequential "or else." (I don't >> count the time required to evaluate the operands). If we compare it with >> the overhead of creating tasks, we will see a huge difference both in terms >> of CPU cycles and mental efforts. > > I don't buy this :) Well, maybe I don't buy it too... (:-)) Nevertheless, it is a very challenging and intriguing idea. > You don't have to create tasks for every computations. (On some futuristic hardware tasks could become cheaper than memory and arithmetic computations.) > You put in place a writer/consumer model. A task prepare > the data and put them into a list (protected object) and you have a set > of tasks to consume those jobs. This works in many cases, requires only > creation of tasks once (not as bad as OpenMP which creates threads for > parallel computations). Ah, but publisher/subscriber framework is itself a solution of some problem, which is not a domain problem. If you had a distributed middleware you would not care about publishers and subscribers. You would simply assign/read a variable controlled by the middleware. Interlocking, marshaling whatsoever would happen transparently. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de