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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.107.198.12 with SMTP id w12mr14451450iof.105.1523075321229; Fri, 06 Apr 2018 21:28:41 -0700 (PDT) X-Received: by 2002:a9d:4c99:: with SMTP id m25-v6mr503230otf.6.1523075321036; Fri, 06 Apr 2018 21:28:41 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feed.usenet.farm!feeder4.feed.usenet.farm!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!k65-v6no335142ita.0!news-out.google.com!u64-v6ni469itb.0!nntp.google.com!u184-v6no346373ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 6 Apr 2018 21:28:40 -0700 (PDT) In-Reply-To: <87po3cvpst.fsf_-_@jacob-sparre.dk> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=68.147.43.80; posting-account=lzqe5AoAAADHhp_gregSufVhvwu22fBS NNTP-Posting-Host: 68.147.43.80 References: <1aa8f536-250d-4bef-9392-4d936f916e5f@googlegroups.com> <9377f941-31d0-4260-818a-8e189aac8c19@googlegroups.com> <10e74e0c-119a-4d86-8a12-c05101f744f1@googlegroups.com> <87po3cvpst.fsf_-_@jacob-sparre.dk> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <4d3e18c3-2b55-4ec8-af5a-f811fd1f5a6b@googlegroups.com> Subject: Re: Benchmarks Game: Thread ring (Was: Large number of tasks slows down my program (using debian) - any fix?) From: Brad Moore Injection-Date: Sat, 07 Apr 2018 04:28:41 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:51373 Date: 2018-04-06T21:28:40-07:00 List-Id: On Thursday, April 5, 2018 at 11:59:00 PM UTC-6, Jacob Sparre Andersen wrot= e: > Brad Moore writes: >=20 > > [...] I believe the reason why it works as fast as it did, is that an > > Ada protected object can have one task perform the action of the > > protected object on behalf of other tasks that are queued on an entry > > of the protected object. >=20 > > The results comparing this version against other approaches in other > > languages can be seen here, where the entries are executed on a > > quad-core machine: >=20 > > https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance= /threadring.html >=20 > From the CPU load data, it looks like the Ada solution has four tasks > running full time, and not just a single one. >=20 Yes, in fact this appears to be the only example that fully loads all the c= ores. Some of the language examples only involve 1 core, which to me sugges= ts that what is really happening in those cases is something more like a co= routine, which I think is not really a fair comparison. When I said one task can service the queue on behalf of other tasks, I was = thinking that the implementation might be "passing" the baton between the "= pseudo"-threads maybe 503 passes at a time, releasing the 503 Ada tasks tha= t are waiting on the entry, then those 503 tasks would queue back up on the= entry (not necessarily all 503 at a time), but however many do get in at a= time (based on how many are queued on the entry when the entry guard is op= ened), they would effectively get released at approximately the same time, = but still in a serial order. So, I would expect all cores to be fully loade= d. I don't know if GNAT actually has the protected object implemented this = way, I just know that that is a possible (and I think recommended) implemen= tation. Cheers, Brad