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!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: RFC: Prototype for a user threading library in Ada Date: Wed, 6 Jul 2016 20:00:14 -0500 Organization: JSA Research & Innovation Message-ID: References: <58b78af5-28d8-4029-8804-598b2b63013c@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1467853211 26321 24.196.82.226 (7 Jul 2016 01:00:11 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 7 Jul 2016 01:00:11 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:31029 Date: 2016-07-06T20:00:14-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:nlj244$43i$1@gioia.aioe.org... > On 05/07/2016 23:24, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message ... >> I'd look at replacing: >> Read (Handle, Data, Last); >> with something like: >> loop >> if Ready (Handle) then >> Read_Ready_Data (Handle, Data, Last); >> exit if Last > Data'Last; >> end if; >> Yield; >> end loop; > > This is in order of several magnitudes slower because after yield to > return back not before next time slot, e.g. timer interrupt. It is no > different from polling. That's actually an advantage, as it greatly decreases the possibility that this task will waste time retrying repeatedly. And it is very rare that it would matter (assuming that I/O is properly buffered), as the vast majority of I/O will run at full speed, and that which doesn't is very slow (relatively speaking) anyway. (i.e., you're waiting for a packet to come across a network -- that's a long time -- usually tenths of seconds -- compared to the slot time.) Finally, our task supervisor doesn't use slots, and I've spent quite a bit of effort avoiding the use of Sleep in Windows such that it would take longer than the next delay expiration. It wouldn't be good for a low-power application, but I doubt any tasking system would be there. > Bit even if RTS had proper drivers on top of the system ones it would > still greatly slower in most case. Disagree. My experience with Internet servers is that one can and should use relatively long delays in I/O without hurting response times. I think files would be similar (although the delays would be smaller). No way to tell for sure without building some examples. ... >>> Well, the difference is that Inline can be safely ignored. Limitation on >>> the task number cannot be. >> >> Same either way - we're "just" talking about performance. > > Unless the system limit on the number of physical threads apply. That would never happen. > And the situation is reverse. With inlining you may fail at compile time > with GNAT when it runts out of memory, and it is recoverable error since > you can forbid inlining. Usually, compilers just don't inline in such circumstances, and no one really cares unless they happen to look at a machine code listing. (Since the inlining probably didn't make much difference in the first place.) Inline is a suggestion, not a promise (much like Suppress). There's never a reason to treat such things as commands. [Yes, one of the reasons RR doesn't have the sort of customer base that AdaCore has is that I'm not willing to implement stupid stuff just because some customers are confused. :-)] > With mapping tasks to threads you fail at run-time, and there is nothing > you can do to prevent that from happening. Certainly not: the threads are all created at program-startup (5 threads for 4 cores, I think), and the number doesn't change after that, unless one calls the library routine for that purpose. That would be a very rare thing, and failure wouldn't cause the program to fail, just run slower. An OS that didn't allow as many threads as there are cores isn't going to work for this system anyway, so the compiler would never exist in the first place. (So you'd get your compile-time detection.) No language-defined I/O (or the sockets library, for that matter) would use blocking I/O. User-defined code could, of course, call blocking I/O (that being the main reason to allow more threads to be added manually). But it would be strongly discouraged. Randy.