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: Wed, 2 Aug 2017 23:30:29 -0500 Organization: JSA Research & Innovation Message-ID: References: <9e51f87c-3b54-4d09-b9ca-e3c6a6e8940a@googlegroups.com> <290e79ee-6626-468b-932b-94dfe724ec45@googlegroups.com> Injection-Date: Thu, 3 Aug 2017 04:30:30 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="27276"; 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:47565 Date: 2017-08-02T23:30:29-05:00 List-Id: "Lucretia" wrote in message news:290e79ee-6626-468b-932b-94dfe724ec45@googlegroups.com... On Wednesday, 2 August 2017 04:44:03 UTC+1, Robert Eachus wrote: ... >You and I see Ada going in the same direction, Ada needs to and should be >targetting massively multi-core/threaded systems. With 202x, I want to see >this push such that parallel blocks can be compiled down to SPIR-V, for >example. Or being able to compile a subprogam as a compute kernel, all >within one language. I want this too. But I don't want low-level constructs that tie Ada to today's (and yesterday's architectures). So talking about "cache-lines" and explicit CPU assignment is simply the wrong thing to do for Ada. That's stuff the compiler should be doing for you, in order to get the best way to execute your code. That way, when you get a new computer and compiler, your code will automatically adjust to do the right thing on that (presumably very different architecture). What happens with Robert E's code if suddenly most machines are using transactional memory? It's tied to traditional cache lines, but such things probably wouldn't exist. Etc. There's always going to be a few people in need of absolutely bleeding edge performance, but (a) you're almost never going to get that from a compile [any compiler, for any language], and (b) that vast majority of problems don't need absolutely bleeding edge performance anyway (or even any particular level of performance). Moreover, getting bleeding edge performance requires a lot of knowledge about tasking/multi-processors that is way beyond the usual programmer. I'm putting my money (and effort) on the relatively high-level constructs proposed for Ada 2020 (which should have some lower-level tuning features). I want *everyone* to be able to take advantage of the speed-ups offered by parallel programs, not just 0.1% that understand modern memory models. Randy. P.S. The really low-level features that don't map very well to more modern hardware is precisely what is wrong with C. At least C is so common that processors have to find ways to support that stuff; that would not be true for Ada or for any other language for that matter.