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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.129.203.11 with SMTP id q11mr12632613ywi.10.1501684741287; Wed, 02 Aug 2017 07:39:01 -0700 (PDT) X-Received: by 10.36.86.12 with SMTP id o12mr244973itb.5.1501684741238; Wed, 02 Aug 2017 07:39:01 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!s6no94958qtc.1!news-out.google.com!12ni649itl.0!nntp.google.com!u14no492812ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 2 Aug 2017 07:39:00 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2a02:c7d:3c35:b000:325a:3aff:fe0f:37a5; posting-account=L2-UcQkAAAAfd_BqbeNHs3XeM0jTXloS NNTP-Posting-Host: 2a02:c7d:3c35:b000:325a:3aff:fe0f:37a5 References: <9e51f87c-3b54-4d09-b9ca-e3c6a6e8940a@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <290e79ee-6626-468b-932b-94dfe724ec45@googlegroups.com> Subject: Re: Real tasking problems with Ada. From: Lucretia Injection-Date: Wed, 02 Aug 2017 14:39:01 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:47558 Date: 2017-08-02T07:39:00-07:00 List-Id: On Wednesday, 2 August 2017 04:44:03 UTC+1, Robert Eachus wrote: > > >A function Cache_Line_Size in System or System.Multiprocessors seems r= ight. > >=20 > > No, it doesn't. It assumes a particular memory organization, and one t= hing=20 > > that's pretty clear is that whatever memory organization is common now = will=20 > > not be common in a bunch of years. Besides, so many systems have multip= le=20 > > layers of caches, that a single result won't be enough. And there is no= way=20 > > for a general implementation to find this out (neither CPUs nor kernels= =20 > > describe such information). >=20 > Um. No. Systems may have multiple levels of caches of different sizes an= d different numbers of "ways" per cache. But the actual cache line size is= almost locked in, and is the same for all caches in a system. Most system= s with DDR3 and DDR4 use 64 byte cache lines because it matches the memory = burst length. But other values are possible. Right now HBM2 is pushing GP= Us (not CPUs) to 256 byte cache lines. Will we eventually have Ada compile= rs generating code for heterogeneous systems? Possible. What I am working= on is building the blocks that can be used with DirectCompute, OpenCL 2.0,= and perhaps other GPU software interfaces.=20 You and I see Ada going in the same direction, Ada needs to and should be t= argetting massively multi-core/threaded systems. With 202x, I want to see t= his push such that parallel blocks can be compiled down to SPIR-V, for exam= ple. Or being able to compile a subprogam as a compute kernel, all within o= ne language. i.e. parallel ... and ... end with Compute; -- Offload to compute if available. FYI, Khronos group is pretty much converging on SPIR-V as the intermediate = language of choice for compute, OpenCL 2.0, Vulkan and now, OpenGL 4.6, all= have it. Just because Ada was designed for the DoD, doesn't mean that that is it's o= nly use, i.e. smaller embedded systems. We all know we can use the language= for it's impressive portability, but even a portable language has non-port= able areas, that's what the System packages are for, no? Seems, you may have hit against the old grey-beards wall of not wanting to = modernise maybe? > > >Is adding these features to Ada worth the effort? Yes. > > No way. They're much too low level, and they actually aren't enough to = allow=20 > > parallelization. You want a language which allows fine-grained parallel= ism=20 > > from the start (like Parasail); trying to retrofit that on Ada (which i= s=20 > > mainly sequential, only having coarse parallelism) just will make a mes= s.=20 > > You might get a few problems solved (those using actual arrays, as oppo= sed=20 > > to containers or user-defined types -- which one hopes are far more com= mon=20 > > in today's programs), but there is nothing general, nor anything that f= its=20 > > into Ada's building block approach, at the level that you're discussing= . > >=20 > For now we can agree to disagree. The difference is the size of the arra= ys we have to deal with. When arrays get to tens of millions of entries, a= nd operations on them can take tens of billions operations, I don't think I= am talking about fine grained parallelism. The main characteristics of th= e operations I want to get working: matrix multiplication and inversion, li= near programming, FFT, FLIR and FLRadar, Navier-Stokes, all have the form o= f a set of huge data arrays constant once loaded, and can be parallelized a= cross large numbers of CPU cores, or GPUs. Have we hit the limits of the language (and any future Ada's)? Is this what= it it takes to create a new fresh modern take on Ada? Now, where did I put= that David Botton guy? :) P.S: This is how forks happen. P.P.S: This is how people leave a language too. Luke.