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.143.149 with SMTP id r143mr14511141iod.120.1523118503614; Sat, 07 Apr 2018 09:28:23 -0700 (PDT) X-Received: by 2002:a9d:554b:: with SMTP id h11-v6mr1703751oti.12.1523118503398; Sat, 07 Apr 2018 09:28:23 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.am4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!k65-v6no824440ita.0!news-out.google.com!u64-v6ni1231itb.0!nntp.google.com!k65-v6no824438ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 7 Apr 2018 09:28:23 -0700 (PDT) In-Reply-To: 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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Large number of tasks slows down my program (using debian) - any fix? From: Brad Moore Injection-Date: Sat, 07 Apr 2018 16:28:23 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 4714 X-Received-Body-CRC: 437564261 Xref: reader02.eternal-september.org comp.lang.ada:51383 Date: 2018-04-07T09:28:23-07:00 List-Id: On Saturday, April 7, 2018 at 2:15:37 AM UTC-6, Jeffrey R. Carter wrote: > On 04/07/2018 06:39 AM, Brad Moore wrote: > >=20 > > You are correct that technically the compiler would be right to complai= n here, > > but I tried the code and compiled it exactly as presented on the websit= e, and it compiles fine for me. > >=20 > > What version of compiler are you using? >=20 > Technically, it compiled with a warning that the call would raise Program= _Error.=20 > I got the warning with a wavefront of GNAT Pro 18 under Linux. Running th= e=20 > program did result in the exception. >=20 > > I tried your version of the code with my version of the compiler, but t= he times for both versions were almost identical. It sounds like your compi= ler is quite different from the one I am using. I am running under Linux on= an AMD quadcore system. >=20 > Interesting. I also tried my version with FSF GNAT 7.2.0 on a Core i7 wit= h 4=20 > virtual processors under Linux and got times about 6.6-9.6 s, depending o= n=20 > options. Fastest seems to be my default set of options >=20 > -gnatan -gnato2 -O2 -fstack-check >=20 > and the slowest >=20 > -gnatp -gnat05 >=20 > (compiler runs in Ada-12 mode by default). Sorry, my two runs had identical times, because the sources were identical,= I somehow copied the files incorrectly renaming yours to .old and mine to = the new one in my test directory. After fixing this, I do see a noticeable difference. My version took 44.4 seconds with your suggested compiler options, and your version took 11.1 seconds. I notice also that I dont think there is a real need for 503 Ada tasks for = this benchmark. There are conceptually 503 objects that "pass the baton" se= rially in a ring, each time the protected object is called. So, I then thought, why not set the number of Ada worker tasks to 4 instead= of 503, while keeping the number of baton passers at 503. When I change that, the code improves to complete in 6.9 seconds. Then I thought, why even have 4 workers. Why not just one? When I set the n= umber of Ada tasks to 1, then there is even more improvement, the code comp= letes in 1.6 seconds. With just 1 worker, why even have a protected object? Why not just make it a procedure call? And so on.. After doing this though, I cannot help but think that somewhere along the w= ay, I would have crossed the line of fairness and the intent of what the be= nchmark is attempting to test. I have also lost some of the demonstration o= f Ada tasking features. I liked the entry usage because waiting for an entr= y barrier to open seemed something like a runner waiting for the previous r= unner to pass him the baton. With a protected procedure, that handoff analo= gy seems to get lost. If you think your version is a fair test though, it is an interesting compa= rison point, then I'd suggest you submit your version to the benchmark site= , if you like. They are fairly picky in what they'd accept. There is a chan= ce they'd reject it, but you never know. Brad=20