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!mx02.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: Sat, 25 Jun 2016 22:09:23 -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 1466910561 12272 24.196.82.226 (26 Jun 2016 03:09:21 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sun, 26 Jun 2016 03:09:21 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:30938 Date: 2016-06-25T22:09:23-05:00 List-Id: "Hadrien Grasland" wrote in message news:f4c3e42a-1aa1-4667-83d7-de6f81a8fdd2@googlegroups.com... ... >> I'd like to understand better the motivations for these features, so if >> you >> (or anyone else) wants to try to explain them to me, feel free. (But keep >> in >> mind that I tend to be hard to convince of anything these days, so don't >> bother if you're going to give up easily. ;-) > >See above. Being able to easily write highly concurrent code is of limited >use >if said code ends up running with terrible performance because modern OSs >are not at all optimized for this kind of workload. We shouldn't need to >worry about how our users' OS kernels are setup, and user threading and >coroutines are a solution to this problem. Only if you want to make the user work even harder than ever. It seems to me that the problem is with the "typical" Ada implementation more than with the expressiveness of features, when it comes to highly parallel implementations. Mapping tasks directly to OS threads only works if the number of tasks is small. So if it hurts when you do that, then DON'T DO THAT!! :-) There's no reason for any particular mapping of Ada tasks to OS threads. I agree with you that the best plan is most likely having a number of threads roughly the same as the number of cores (although that could vary for a highly I/O intensive task). Ada already exposes ways to map tasks to cores, and that clearly could be extended slightly to manage the tasking system's mapping of threads to tasks. I use Ada because I want it to prevent or detect all of my programming mistakes before I have to debug something. (I HATE debugging!). I'd like to extend that to parallel programming to the extent possible. I don't want to be adding major new features that will make that harder. Randy.