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=unavailable autolearn_force=no version=3.4.4
Path: 
 buffer1.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.glorb.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!fx25.iad.POSTED!not-for-mail
From: Brad Moore <brad.moore@shaw.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: can someone help me with this code (explanation)
References: <a352821d-bdcc-4598-8843-3262382cadb9@googlegroups.com>
 <m01adf$7tp$1@dont-email.me>
 <6e1f86e6-c17a-428e-bb19-460c5ba26c8a@googlegroups.com>
 <c8j0lhFl112U1@mid.individual.net>
 <1ec7272d-de7f-43dd-be30-009c437011de@googlegroups.com>
 <c8jb5lFns5kU1@mid.individual.net> <m024t3$j1p$1@dont-email.me>
 <m0335c$mto$1@dont-email.me> <m036bm$8h6$1@dont-email.me>
 <m03jp8$rv7$1@dont-email.me> <m03nc0$k10$1@dont-email.me>
 <m03sdr$5d8$1@dont-email.me> <m03udc$l86$1@dont-email.me>
 <m040rm$8em$1@dont-email.me> <m0431m$os2$1@dont-email.me>
 <YdqWv.248036$Hb3.163742@fx03.iad> <m0f93l$8do$1@dont-email.me>
In-Reply-To: <m0f93l$8do$1@dont-email.me>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <9eVWv.147739$_r4.8604@fx25.iad>
NNTP-Posting-Host: 68.145.219.148
X-Complaints-To: internet.abuse@sjrb.ca
X-Trace: 1412177925 68.145.219.148 (Wed, 01 Oct 2014 15:38:45 UTC)
NNTP-Posting-Date: Wed, 01 Oct 2014 15:38:45 UTC
Date: Wed, 01 Oct 2014 09:38:48 -0600
X-Received-Bytes: 3069
X-Received-Body-CRC: 2526495397
Xref: number.nntp.giganews.com comp.lang.ada:189282
Date: 2014-10-01T09:38:48-06:00
List-Id: <comp.lang.ada>

On 14-09-30 03:59 PM, Georg Bauhaus wrote:
> 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.)
>


I tried your suggestion on my system. Ubuntu/Linux GPL 2014 compiler AMD 
quadcore, but this added 20-30 seconds to the processing time unfortunately.

Incidentally, I believe the reason approach #6 works is because the task 
executing a protected entry can execute the protected action on behalf 
of the other tasks that have passed the guard on that protected entry. 
(See RM 9.5.3 22-23)