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: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: "Jeffrey R. Carter" Newsgroups: comp.lang.ada Subject: Re: Large number of tasks slows down my program (using debian) - any fix? Date: Sat, 7 Apr 2018 20:41:12 +0200 Organization: Also freenews.netfront.net; news.tornevall.net; news.eternal-september.org Message-ID: References: <1aa8f536-250d-4bef-9392-4d936f916e5f@googlegroups.com> <9377f941-31d0-4260-818a-8e189aac8c19@googlegroups.com> <10e74e0c-119a-4d86-8a12-c05101f744f1@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 7 Apr 2018 18:41:12 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="49324a93ff7ace8128c1aa0e3f81a704"; logging-data="31806"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18W4EaxbPVyDil7XILUzlFLfT+T6GOGpCY=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-Reply-To: Content-Language: en-US Cancel-Lock: sha1:pFAJb//shC87WBOjzTR14I6uT04= Xref: reader02.eternal-september.org comp.lang.ada:51387 Date: 2018-04-07T20:41:12+02:00 List-Id: On 04/07/2018 06:28 PM, Brad Moore wrote: > > 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" serially 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. The problem requirements include: "create 503 linked pre-emptive threads" so I suspect that would not be a valid implementation. > If you think your version is a fair test though, it is an interesting comparison 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 chance they'd reject it, but you never know. I saw opportunities in your code to replace explicit actions with elaboration, which is usually a good thing. That got rid of the Start procedure, which made the barrier of the entry always True, which resulted in changing the entry to a procedure. I'm not sure whether it's a fair test or not. In your version, the tasks queue up on the entry in some order, and queue themselves back on the entry again as soon as the calls complete, so the tasks are calling the entry repeatedly in the same order. In my version, all the tasks are calling the protected procedure repeatedly, but we don't know if there's an order in which they execute the calls. So my version may be less like a ring than yours. But I'm not sure your version is a fair test, either. There aren't tasks linked in a ring. There are just a bunch of tasks that manipulate data in a PO until they have done so the correct number of times. That doesn't seem to fulfill the spirit of the requirements. -- Jeff Carter "English bed-wetting types." Monty Python & the Holy Grail 15