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!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Real tasking problems with Ada. Date: Mon, 31 Jul 2017 23:41:58 -0500 Organization: JSA Research & Innovation Message-ID: References: <9e51f87c-3b54-4d09-b9ca-e3c6a6e8940a@googlegroups.com> Injection-Date: Tue, 1 Aug 2017 04:42:00 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="31046"; mail-complaints-to="news@jacob-sparre.dk" 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.7246 Xref: news.eternal-september.org comp.lang.ada:47539 Date: 2017-07-31T23:41:58-05:00 List-Id: "Robert Eachus" wrote in message news:9e51f87c-3b54-4d09-b9ca-e3c6a6e8940a@googlegroups.com... > First, it should be possible to assign tasks in arrays to CPUs. Use a discriminant of type CPU and (in Ada 2020) an iterated_component_association. (This was suggested way back in Ada 9x, left out in the infamous "scope reduction", and then forgotten about until 2013. See AI12-0061-1 or the draft RM http://www.ada-auth.org/standards/2xaarm/html/AA-4-3-3.html). ... >1) Add a function Current_CPU or whatever (to System.Multiprocessors) that > returns the identity of the CPU this task is running on. Obviously in a > rendezvous > with a protected object, the function would return the ID of the caller. Why do you say this? Ada doesn't require the task that calls a protected object to execute it (the execution can be handdled by the task that services the barriers - I don't know if any implementation actually does this, but the language rules are written to allow it). > Probably do the same thing in a rendezvous between two tasks for > consistency. > Note that Get_ID function in System.Multiprocessors.Dispatching_Domains > does that but it requires adding three (unnecessary) packages (DD, > Ada.Real_Time, and Ada.Task_Identification) to your context without really > using anything there. Say what? You're using Get_Id, so clearly you're using something there. Get_Id (like the rest of dispatching domains is likely to be expensive, so you don't want it dragged into all programs. (And CPU is effectively part of all programs.) > 2) Allow a task to its CPU assignment after it has started execution. It > is no big deal if a task starts on a different CPU than the one it will > spend > the rest of its life on. At a minimum Set_CPU(Current_CPU) or just > Set_CPU should cause the task to be anchored to its current CPU core. > Note that again you can do this with Dispatching_Domains. So the capability already exists, but you don't like having to with an extra package to use it? Have you lost your freaking mind? You want us to add operations that ALREADY EXIST to another package, with all of the compatibility problems that doing so would cause (especially for people that had withed and used Dispatching_Domains)? When there are lots of problems that can't be solved portably at all? >Next, a huge problem. I just had some code churn out garbage while I was >finding the > "right" settings to get each chunk of work to have its own portion of an > array. Don't tell > me how to do this safely, if you do you are missing the point. No, you're missing the point. Ada is about writing portable code. Nothing at the level of "cache lines" is EVER going to be portable in any way. Either one writes "safe" code and hopefully the compiler and runtime can take into account the characteristics of the target. (Perhaps parallel loop constructs will help with that.) Or otherwise, one writes bleeding edge code that is not portable and not safe. And you're on your own in such a case; no programming language could possibly help you. >A function Cache_Line_Size in System or System.Multiprocessors seems right. No, it doesn't. It assumes a particular memory organization, and one thing that's pretty clear is that whatever memory organization is common now will not be common in a bunch of years. Besides, so many systems have multiple layers of caches, that a single result won't be enough. And there is no way for a general implementation to find this out (neither CPUs nor kernels describe such information). >Is adding these features to Ada worth the effort? No way. They're much too low level, and they actually aren't enough to allow parallelization. You want a language which allows fine-grained parallelism from the start (like Parasail); trying to retrofit that on Ada (which is mainly sequential, only having coarse parallelism) just will make a mess. You might get a few problems solved (those using actual arrays, as opposed to containers or user-defined types -- which one hopes are far more common in today's programs), but there is nothing general, nor anything that fits into Ada's building block approach, at the level that you're discussing. Randy.