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 Path: border1.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.ada Subject: Re: can someone help me with this code (explanation) Date: Tue, 30 Sep 2014 23:59:17 +0200 Organization: A noiseless patient Spider Message-ID: References: <6e1f86e6-c17a-428e-bb19-460c5ba26c8a@googlegroups.com> <1ec7272d-de7f-43dd-be30-009c437011de@googlegroups.com> Reply-To: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 30 Sep 2014 21:59:17 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="3c43ca61e7cae464e9811be0f871aa3d"; logging-data="8632"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX192DnbqFyM8M5uZ12hwBVz6Kb0Tgr2peqo=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: Cancel-Lock: sha1:F5XsfilNUCKWFOUQzVnIIfl5Dbw= Xref: number.nntp.giganews.com comp.lang.ada:189258 Date: 2014-09-30T23:59:17+02:00 List-Id: On 30.09.14 06:22, Brad Moore wrote: > In fact, only the Go and the Haskell entries are consistently ahead of this latest version for all 4 processor configurations. The Ada version has 503 tasks executing with calls on a protected entry (where each task maps to an OS thread in GNAT). Looking at the Go example, I'm guessing that the 503 lightweight threads are being executed by a single OS thread, likely under a work-stealing scheduler, where the work never gets stolen by other cores, since this benchmark mostly involves a sequential handoff of a token to the next thread. It that's whats happening, then it might explain why the Go version is still quite a bit faster, since executing the problem on the same core doesn't require as much overhead and locking to do the handoff. > > FWIW, adding (to #6) delay 0.0; to the task body after the conditional loop exit resulted in some changes in running time, on my testing machines. Results depend very much on the compiler, and on (absence of) optimization. Nothing like the order of magnitude of #6, though. (On GNU/Linux: the system compiler (Debian, gcc 4.4.5) and GNAT 2013 4.7.4; Xeon E5-2620, two cores of a KVM.)