* Ada lacks lighterweight-than-task parallelism
@ 2018-06-19 22:14 Dan'l Miller
2018-06-19 22:23 ` Dan'l Miller
` (4 more replies)
0 siblings, 5 replies; 39+ messages in thread
From: Dan'l Miller @ 2018-06-19 22:14 UTC (permalink / raw)
http://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_windows_10
As discussed in the article above, Microsoft is starting to unveil its formerly-secret development of what could be described as “Itanium done right“.
Whereas Itanium was VLIW jammed force-fit into an otherwise traditional ISA that had 8 concurrent sub-instructions per VLIW-instruction (and where most simultaneous multithreading [SMT] processor cores can execute up to 2 threads per processor-core on Intel, AMD, and IBM POWER processors), Microsoft's Explicit Data Graph Execution (EDGE) processor slices programs into up to 32 independent slices per thread/task.
Whereas Itanium insisted on the •compiler• at engineering-time finding 8 independent slices within a program, EDGE performs the analogue of such analysis in hardware at runtime—hence, overcoming one of Itanium's fatal flaws. (The other fatal flaw on which Itanium was misfounded was that the compiler could not predict at engineering-time the wildly varying latencies of L1 cache versus L2 cache versus L3 cache versus local DRAM versus ccNUMA-network DRAM; EDGE appears to mitigate that as well by apparently picking slices with the same timing characteristics or compatibly-interleavable timing characteristics.)
And EDGE processor is being currently sampled at 10nm manufacturing process through Qualcomm.
And Windows 10 has been successfully ported to EDGE processor (which is starting to look like a future product announcement for some forthcoming new Microsoft device).
And viola neither Ada nor POSIX threads, on the front end, have representations of slices. Nor do any extant Ada compilers have representation of slices on the backend—which is a true shame because slices would have been one of the enabling technologies for Itanium 18 (!) years ago. 18 years ago. I think Rumpelstiltskin slept for less time duration than that.
And this initial era of EDGE appears to be single-core. Imagine 2-core and 4-core and 8-core editions in the future for 64-, 96-, and 128-slice parallelism.
Ada for the Cold War in 1983 would focus on tasks as the only vehicle for parallelism. Ada for the 21st century would also embrace/facilitate slices somehow, via some sort of locality of reference or via some sort of demarcation of independence.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-19 22:14 Ada lacks lighterweight-than-task parallelism Dan'l Miller
@ 2018-06-19 22:23 ` Dan'l Miller
2018-06-20 0:03 ` Dan'l Miller
` (3 subsequent siblings)
4 siblings, 0 replies; 39+ messages in thread
From: Dan'l Miller @ 2018-06-19 22:23 UTC (permalink / raw)
On Tuesday, June 19, 2018 at 5:14:17 PM UTC-5, Dan'l Miller wrote:
> Imagine 2-core and 4-core and 8-core editions in the future for 64-, 96-, and 128-slice parallelism.
Or better yet, imagine an EDGE processor that gets the arithmetic correct better than I do on the fly:
Imagine 2-core, 4-core, 6-core, and 8-core editions in the future for 64-, 128-, 192-, and 256-slice parallelism.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-19 22:14 Ada lacks lighterweight-than-task parallelism Dan'l Miller
2018-06-19 22:23 ` Dan'l Miller
@ 2018-06-20 0:03 ` Dan'l Miller
2018-06-20 0:41 ` Lucretia
` (2 subsequent siblings)
4 siblings, 0 replies; 39+ messages in thread
From: Dan'l Miller @ 2018-06-20 0:03 UTC (permalink / raw)
On Tuesday, June 19, 2018 at 5:14:17 PM UTC-5, Dan'l Miller wrote:
> which is a true shame because slices would have been one of the enabling technologies for
> Itanium 18 (!) years ago. 18 years ago. I think Rumpelstiltskin slept for less time duration than that.
On 2nd thought: Rip van Winkle
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-19 22:14 Ada lacks lighterweight-than-task parallelism Dan'l Miller
2018-06-19 22:23 ` Dan'l Miller
2018-06-20 0:03 ` Dan'l Miller
@ 2018-06-20 0:41 ` Lucretia
2018-06-20 1:36 ` Dan'l Miller
2018-06-20 1:12 ` Shark8
2018-06-20 12:28 ` Brian Drummond
4 siblings, 1 reply; 39+ messages in thread
From: Lucretia @ 2018-06-20 0:41 UTC (permalink / raw)
On Tuesday, 19 June 2018 23:14:17 UTC+1, Dan'l Miller wrote:
> http://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_windows_10
>
> As discussed in the article above, Microsoft is starting to unveil its formerly-secret development of what could be described as “Itanium done right“.
One of the casualties of the Titanic was PA-RISC, HP should resurrect and redesign PA-RISC for the 21st century.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-19 22:14 Ada lacks lighterweight-than-task parallelism Dan'l Miller
` (2 preceding siblings ...)
2018-06-20 0:41 ` Lucretia
@ 2018-06-20 1:12 ` Shark8
2018-06-20 1:41 ` Dan'l Miller
2018-06-20 12:28 ` Brian Drummond
4 siblings, 1 reply; 39+ messages in thread
From: Shark8 @ 2018-06-20 1:12 UTC (permalink / raw)
On Tuesday, June 19, 2018 at 4:14:17 PM UTC-6, Dan'l Miller wrote:
>
> Ada for the Cold War in 1983 would focus on tasks as the only vehicle for parallelism. Ada for the 21st century would also embrace/facilitate slices somehow, via some sort of locality of reference or via some sort of demarcation of independence.
Don't hate on TASK!
TASK is a great construct, and particularly good for:
1) Isolating and/or interfacing both subsystems and jobs, with the possibility of taking advantage of multiprocessor capability;
2) Implementing protocols, via the ACCEPT construct; and
3) at a high-level rather than the "annotated GPU assembly" we get with (eg) CUDA/C.
As for something lightweight, we're working on that in the ARG right now:
* PARALLEL DO blocks,
* Parallel LOOPs [IIRC, it might be just FOR], and
* And some other things like operators, blocking-detection, etc.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-20 0:41 ` Lucretia
@ 2018-06-20 1:36 ` Dan'l Miller
2018-06-20 13:39 ` Luke A. Guest
0 siblings, 1 reply; 39+ messages in thread
From: Dan'l Miller @ 2018-06-20 1:36 UTC (permalink / raw)
On Tuesday, June 19, 2018 at 7:41:21 PM UTC-5, Lucretia wrote:
> On Tuesday, 19 June 2018 23:14:17 UTC+1, Dan'l Miller wrote:
> > http://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_windows_10
> >
> > As discussed in the article above, Microsoft is starting to unveil its formerly-secret development of what could be described as “Itanium done right“.
>
> One of the casualties of the Titanic was PA-RISC, HP should resurrect and redesign PA-RISC for the 21st
> century.
HP and HPE are 2 of Microsoft's closest partners-of-allied-vision (Intel not as much nowadays), both on servers and on mobile consumer products. I think that (despite being right on the heals of winning the multi-billion-dollar court judgement against Oracle) HPE's disinterest in continuing to board the sinking good ship Itanic occurred at precisely the same time as the rise of the secret EDGE-processor project at Microsoft. (I need to investigate who funded the university work from which EDGE is derived.) I think that EDGE might have HPE's post-Itanic fingerprints all over it. We will know for certain of an HPE–Microsoft joint effort if a server version of EDGE supports technology extracted from HPE's The Machine, e.g., resistive associative RAM.
In other words, your tongue-in-cheek comment is likely what this EDGE-processor is all about for HPE, minus the PA-RISC ISA itself: a non-Intel, non-ARM, non-SPARC, non-POWER replacement to the PA-RISC/Itanium vision for servers.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-20 1:12 ` Shark8
@ 2018-06-20 1:41 ` Dan'l Miller
2018-06-20 7:13 ` Dmitry A. Kazakov
0 siblings, 1 reply; 39+ messages in thread
From: Dan'l Miller @ 2018-06-20 1:41 UTC (permalink / raw)
On Tuesday, June 19, 2018 at 8:12:02 PM UTC-5, Shark8 wrote:
> On Tuesday, June 19, 2018 at 4:14:17 PM UTC-6, Dan'l Miller wrote:
> >
> > Ada for the Cold War in 1983 would focus on tasks as the only vehicle for parallelism. Ada for the 21st century would also embrace/facilitate slices somehow, via some sort of locality of reference or via some sort of demarcation of independence.
>
> Don't hate on TASK!
> TASK is a great construct, and particularly good for:
> 1) Isolating and/or interfacing both subsystems and jobs, with the possibility of taking advantage of multiprocessor capability;
> 2) Implementing protocols, via the ACCEPT construct; and
> 3) at a high-level rather than the "annotated GPU assembly" we get with (eg) CUDA/C.
I'm not saying anything negative about tasks. I am just saying that there should be more games to play in the casino than merely one and only one.
> As for something lightweight, we're working on that in the ARG right now:
> * PARALLEL DO blocks,
> * Parallel LOOPs [IIRC, it might be just FOR], and
> * And some other things like operators, blocking-detection, etc.
Excellent! These should produce slices for numeric computations. I am not as sure that they alone(!) will necessarily produce usable slices regarding non-numeric arbitrary processing via deep call-trees of subprograms.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-20 1:41 ` Dan'l Miller
@ 2018-06-20 7:13 ` Dmitry A. Kazakov
2018-06-20 12:03 ` Dan'l Miller
0 siblings, 1 reply; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-06-20 7:13 UTC (permalink / raw)
On 2018-06-20 03:41, Dan'l Miller wrote:
> On Tuesday, June 19, 2018 at 8:12:02 PM UTC-5, Shark8 wrote:
> I'm not saying anything negative about tasks. I am just saying that there should be more games to play in the casino than merely one and only one.
>
>> As for something lightweight, we're working on that in the ARG right now:
>> * PARALLEL DO blocks,
>> * Parallel LOOPs [IIRC, it might be just FOR], and
>> * And some other things like operators, blocking-detection, etc.
>
> Excellent! These should produce slices for numeric computations. I am not as sure that they alone(!) will necessarily produce usable slices regarding non-numeric arbitrary processing via deep call-trees of subprograms.
So it is not "lightweight", it is "scalar" parallelism.
The latter is quite a niche and IMO has no place in the language being
to low-level. It better be handled in the form of hints for the compiler
to deploy a certain form of optimization.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-20 7:13 ` Dmitry A. Kazakov
@ 2018-06-20 12:03 ` Dan'l Miller
2018-06-20 12:29 ` Dmitry A. Kazakov
2018-06-21 0:17 ` Shark8
0 siblings, 2 replies; 39+ messages in thread
From: Dan'l Miller @ 2018-06-20 12:03 UTC (permalink / raw)
On Wednesday, June 20, 2018 at 2:13:24 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-20 03:41, Dan'l Miller wrote:
> It better be handled in the form of hints for the compiler
> to deploy a certain form of optimization.
So, does Ada now or in Ada2020 have those hints?
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-19 22:14 Ada lacks lighterweight-than-task parallelism Dan'l Miller
` (3 preceding siblings ...)
2018-06-20 1:12 ` Shark8
@ 2018-06-20 12:28 ` Brian Drummond
2018-06-21 1:51 ` Dan'l Miller
4 siblings, 1 reply; 39+ messages in thread
From: Brian Drummond @ 2018-06-20 12:28 UTC (permalink / raw)
On Tue, 19 Jun 2018 15:14:16 -0700, Dan'l Miller wrote:
> http://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_windows_10
>
> As discussed in the article above, Microsoft is starting to unveil its
> formerly-secret development of what could be described as “Itanium done
> right“.
wait what? ... JAN GRAY?
(in the Further Reading section) breadcrumbs to
https://arxiv.org/abs/1803.06617
"Design productivity is still a challenge for reconfigurable
computing. It is expensive to port workloads into gates and
to endure 10**2 to 10**4 second bitstream rebuild design itera-
tions."
( ... no kidding, but tolerable where it improves program execution times
below 10**6 or 10**7 seconds)
so this is primarily work that emerged from the RC shadows, where for the
past quarter century, people like JG have exploited parallelism not at
the task level or even the "slice" level but at the gate level where that
helps...
and where one of the chief difficulties has been the interface between
that (unconstrained) level and the tightly constrained (single operation
stream from the compiler, reverse engineered into OO superscalar within
the CPU) level
and where some other efforts to smooth the way between parallelism
domains are still ongoing...
https://www.extremetech.com/computing/269461-intel-shows-off-xeon-
scalable-gold-6138p-with-an-integrated-fpga
https://www.nextplatform.com/2018/05/24/a-peek-inside-that-intel-xeon-
fpga-hybrid-chip/
(I'm imagining on-chip PCIE links working like the old Transputer
channels here, but streaming data to/from the bespoke hardware engine
directly, much less overhead than I used to have, doing RC with external
FPGA boards)
... if there are Ada dimensions here, one might be compiling Ada directly
to hardware...
https://www.cs.york.ac.uk/ftpdir/papers/rtspapers/R:Ward:2001.ps
...which paper is only slightly weakened by the fact that his published
example procedure is also synthesisable VHDL! in fact Xilinx XST
synthesises that example to run in a single clock cycle ...
... however, at an appallingly slow clock ...
vs 732 cycles for the paper's result and an estimated 44,000 for an 80486.
Thus the Ward paper's true merit is, ironically, that it allows automatic
extraction of a degree of sequentialism from an inherently parallel
example; opening the way to automatic generation of faster (and maybe
smaller) pipelined dataflow hardware.
Which is actually quite difficult, and historically an extensively manual
process in past RC processes - another bottleneck in addition to the
"bitstream rebuild" times JG complains about.
so why stop at the "slice" level as EDGE does?
it makes sense if there is automatic translation (compilation at usably
fast rates) from source to that level, AND if a large and sufficiently
generally useful structure of slices can be implemented in ASIC without
the time and area penalty of FPGA routing.
One way of looking at it is to see a "slice" as a higher-level or larger
grained FPGA LUT (which is a generalisation of one or several gates).
FPGAs have been becoming coarser grained anyway, as well as adding RAM
Blocks and (first multiplier, then DSP primitive) blocks by the hundreds
- because fewer more powerful primitive blocks reduce that routing (area
+ speed) penalty.
A few dozen BlockRams for example, configured the right way, open the
doors to allowing stack architectures to go supercalar (eliminating huge
problems addressing registers), though I don't know if this has ever been
exploited.
interesting development... perhaps a logical growth from JG's involvement
with the ultra fine grained XC6200 FPGA, where RC pretty much started.
-- Brian
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-20 12:03 ` Dan'l Miller
@ 2018-06-20 12:29 ` Dmitry A. Kazakov
2018-06-20 13:14 ` Mehdi Saada
2018-06-21 0:17 ` Shark8
1 sibling, 1 reply; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-06-20 12:29 UTC (permalink / raw)
On 2018-06-20 14:03, Dan'l Miller wrote:
> On Wednesday, June 20, 2018 at 2:13:24 AM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-06-20 03:41, Dan'l Miller wrote:
>> It better be handled in the form of hints for the compiler
>> to deploy a certain form of optimization.
>
> So, does Ada now or in Ada2020 have those hints?
No.
But I think if Ada integrated SPARK then with things like loop
invariants and provable purity of certain pieces of code, the compiler
should be able decide of the loop body can be ran concurrently. It would
be a better approach than to burden the programmer with low-level stuff,
IMO.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-20 12:29 ` Dmitry A. Kazakov
@ 2018-06-20 13:14 ` Mehdi Saada
2018-06-20 13:38 ` Dmitry A. Kazakov
0 siblings, 1 reply; 39+ messages in thread
From: Mehdi Saada @ 2018-06-20 13:14 UTC (permalink / raw)
So I guess you are in favor with deeper (and de facto) integration of compilers with static analysis tools ?
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-20 13:14 ` Mehdi Saada
@ 2018-06-20 13:38 ` Dmitry A. Kazakov
2018-06-20 14:01 ` Mehdi Saada
2018-06-21 0:19 ` Shark8
0 siblings, 2 replies; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-06-20 13:38 UTC (permalink / raw)
On 2018-06-20 15:14, Mehdi Saada wrote:
> So I guess you are in favor with deeper (and de facto) integration of compilers with static analysis tools ?
Absolutely. Not as tools. SPARK must become an integral part of Ada.
Static analysis and defined provable semantics is major strength of Ada.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-20 1:36 ` Dan'l Miller
@ 2018-06-20 13:39 ` Luke A. Guest
0 siblings, 0 replies; 39+ messages in thread
From: Luke A. Guest @ 2018-06-20 13:39 UTC (permalink / raw)
Dan'l Miller <t> wrote:
> In other words, your tongue-in-cheek comment is likely what this
> EDGE-processor is all about for HPE, minus the PA-RISC ISA itself: a
> non-Intel, non-ARM, non-SPARC, non-POWER replacement to the
> PA-RISC/Itanium vision for servers.
>
I was being serious. HP should never have been involved with titanic. If C=
wasn’t fucked over Mehdi Ali, we would’ve had PA-RISC Amiga’s bitd.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-20 13:38 ` Dmitry A. Kazakov
@ 2018-06-20 14:01 ` Mehdi Saada
2018-06-20 14:32 ` Dmitry A. Kazakov
` (2 more replies)
2018-06-21 0:19 ` Shark8
1 sibling, 3 replies; 39+ messages in thread
From: Mehdi Saada @ 2018-06-20 14:01 UTC (permalink / raw)
Considering how complicate writing Ada compilers already is, and seeing that there is no standard interface between those and tools - as far as I get it - it would likely make the hypothetic compilers huge and considering GNAT is the only one implementing (most) of the 2012 version, fusing tools and compilers might close for good the Ada compilers market.
Haven't you been promoting free market ?
Stop me if I made a mistake.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-20 14:01 ` Mehdi Saada
@ 2018-06-20 14:32 ` Dmitry A. Kazakov
2018-06-29 22:01 ` Randy Brukardt
2018-06-20 15:58 ` Niklas Holsti
2018-06-29 21:58 ` Randy Brukardt
2 siblings, 1 reply; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-06-20 14:32 UTC (permalink / raw)
On 2018-06-20 16:01, Mehdi Saada wrote:
> Considering how complicate writing Ada compilers already is, and seeing that there is no standard interface between those and tools - as far as I get it - it would likely make the hypothetic compilers huge and considering GNAT is the only one implementing (most) of the 2012 version, fusing tools and compilers might close for good the Ada compilers market.
> Haven't you been promoting free market ?
Yes.
> Stop me if I made a mistake.
How adding features like low-level parallelism makes compiler smaller?
I actually want a reduced Ada. The exiting type system must be moved to
the library level expressed in more general terms. Generics can be
removed. Representation clauses hugely reduced to essential. Containers
need not to be in the standard. I/O library can be hugely reduced once
the type system fixed. All dynamic checks can be removed, replaced by
static contracts: do this when that or raise Constraint_Error otherwise.
etc.
Essential are only the type system, compilation units, tasking and
statical analysis support.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-20 14:01 ` Mehdi Saada
2018-06-20 14:32 ` Dmitry A. Kazakov
@ 2018-06-20 15:58 ` Niklas Holsti
2018-06-29 21:58 ` Randy Brukardt
2 siblings, 0 replies; 39+ messages in thread
From: Niklas Holsti @ 2018-06-20 15:58 UTC (permalink / raw)
On 18-06-20 17:01 , Mehdi Saada wrote:
> Considering how complicate writing Ada compilers already is,
A formal definition of the language, as discussed in the "Ada successor"
thread, should make it a little easier.
> and seeing that there is no standard interface between those
> and tools
There is ASIS:
https://en.wikipedia.org/wiki/Ada_Semantic_Interface_Specification
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-20 12:03 ` Dan'l Miller
2018-06-20 12:29 ` Dmitry A. Kazakov
@ 2018-06-21 0:17 ` Shark8
1 sibling, 0 replies; 39+ messages in thread
From: Shark8 @ 2018-06-21 0:17 UTC (permalink / raw)
On Wednesday, June 20, 2018 at 6:03:31 AM UTC-6, Dan'l Miller wrote:
> On Wednesday, June 20, 2018 at 2:13:24 AM UTC-5, Dmitry A. Kazakov wrote:
> > On 2018-06-20 03:41, Dan'l Miller wrote:
> > It better be handled in the form of hints for the compiler
> > to deploy a certain form of optimization.
>
> So, does Ada now or in Ada2020 have those hints?
That's a hard question to answer.
Ada as it is now, could certainly have them -- the Standard allows implementation defined pragmas and aspects -- indeed, the advent of CUDA was [IMO] a very big lost opportunity. Had nVidia used Ada + pragmas & aspects instead of C + [essentially] embedded-GPU-assembly-directives it would have done a *LOT* to boost Ada's reputation in parallel (it used to have a good one) as well as spur on development of making GPU-enabled tasks [fairly] automatic. (Randy disagrees w/ me on this.)
The "tasklets" (parallel block/for/etc) that are in Ada2020 do a lot of that, and will probably be useful for compilers that are GPU-code enabled.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-20 13:38 ` Dmitry A. Kazakov
2018-06-20 14:01 ` Mehdi Saada
@ 2018-06-21 0:19 ` Shark8
2018-06-21 9:09 ` Dmitry A. Kazakov
1 sibling, 1 reply; 39+ messages in thread
From: Shark8 @ 2018-06-21 0:19 UTC (permalink / raw)
On Wednesday, June 20, 2018 at 7:38:11 AM UTC-6, Dmitry A. Kazakov wrote:
> On 2018-06-20 15:14, Mehdi Saada wrote:
> > So I guess you are in favor with deeper (and de facto) integration of compilers with static analysis tools ?
>
> Absolutely. Not as tools. SPARK must become an integral part of Ada.
> Static analysis and defined provable semantics is major strength of Ada.
>
Agreed; this is why I'm pushing for a heavily integrated IDE with my IDE-proposal.
I'd be quite interested to hear your thoughts on the subject.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-20 12:28 ` Brian Drummond
@ 2018-06-21 1:51 ` Dan'l Miller
2018-06-21 10:22 ` Brian Drummond
0 siblings, 1 reply; 39+ messages in thread
From: Dan'l Miller @ 2018-06-21 1:51 UTC (permalink / raw)
On Wednesday, June 20, 2018 at 7:28:24 AM UTC-5, Brian Drummond wrote:
> On Tue, 19 Jun 2018 15:14:16 -0700, Dan'l Miller wrote:
>
> > http://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_windows_10
> >
> > As discussed in the article above, Microsoft is starting to unveil its
> > formerly-secret development of what could be described as “Itanium done
> > right“.
>
> wait what? ... JAN GRAY?
>
> (in the Further Reading section) breadcrumbs to
> https://arxiv.org/abs/1803.06617
Interesting insight that I will investigate further, as what you point out might also be useful on Altera FPGAs embedded into Intel processors, which might end up being a competitor to EDGE as coming years unfold. (Indeed, Intel's purchase of Altera might have been the stimulus at Microsoft to pursue the apparent forthcoming commercialization of EDGE in the first place; the years would align about right).
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-21 0:19 ` Shark8
@ 2018-06-21 9:09 ` Dmitry A. Kazakov
2018-06-21 14:42 ` Shark8
0 siblings, 1 reply; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-06-21 9:09 UTC (permalink / raw)
On 2018-06-21 02:19, Shark8 wrote:
> On Wednesday, June 20, 2018 at 7:38:11 AM UTC-6, Dmitry A. Kazakov wrote:
>> On 2018-06-20 15:14, Mehdi Saada wrote:
>>> So I guess you are in favor with deeper (and de facto) integration of compilers with static analysis tools ?
>>
>> Absolutely. Not as tools. SPARK must become an integral part of Ada.
>> Static analysis and defined provable semantics is major strength of Ada.
>>
> Agreed; this is why I'm pushing for a heavily integrated IDE with my IDE-proposal.
> I'd be quite interested to hear your thoughts on the subject.
Why do you think that an IDE is important here? (Not that I will use
emacs, ever! (:-))
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-21 1:51 ` Dan'l Miller
@ 2018-06-21 10:22 ` Brian Drummond
0 siblings, 0 replies; 39+ messages in thread
From: Brian Drummond @ 2018-06-21 10:22 UTC (permalink / raw)
On Wed, 20 Jun 2018 18:51:44 -0700, Dan'l Miller wrote:
> On Wednesday, June 20, 2018 at 7:28:24 AM UTC-5, Brian Drummond wrote:
>> On Tue, 19 Jun 2018 15:14:16 -0700, Dan'l Miller wrote:
>>
>> > http://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_windows_10
>> >
>> > As discussed in the article above, Microsoft is starting to unveil
>> > its formerly-secret development of what could be described as
>> > “Itanium done right“.
>>
>> wait what? ... JAN GRAY?
>>
>> (in the Further Reading section) breadcrumbs to
>> https://arxiv.org/abs/1803.06617
>
> Interesting insight that I will investigate further, as what you point
> out might also be useful on Altera FPGAs embedded into Intel processors,
> which might end up being a competitor to EDGE as coming years unfold.
> (Indeed, Intel's purchase of Altera might have been the stimulus at
> Microsoft to pursue the apparent forthcoming commercialization of EDGE
> in the first place; the years would align about right).
Won't be a direct (similar tech) competitor, unless Altera are keeping
quiet about some coarse grained replacement for the FPGA slice, like
those little "Edge" cores. But interesting to watch...
(Intel and Altera go way back, I think Inel was Altera's original fab
back in the EPROM FPGA days, as well as being their "second
source" (quite how that worked, I'm not sure :-)
-- Brian
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-21 9:09 ` Dmitry A. Kazakov
@ 2018-06-21 14:42 ` Shark8
2018-06-21 15:55 ` Dan'l Miller
2018-06-21 16:06 ` Dmitry A. Kazakov
0 siblings, 2 replies; 39+ messages in thread
From: Shark8 @ 2018-06-21 14:42 UTC (permalink / raw)
On Thursday, June 21, 2018 at 3:09:26 AM UTC-6, Dmitry A. Kazakov wrote:
> On 2018-06-21 02:19, Shark8 wrote:
> > On Wednesday, June 20, 2018 at 7:38:11 AM UTC-6, Dmitry A. Kazakov wrote:
> >> On 2018-06-20 15:14, Mehdi Saada wrote:
> >>> So I guess you are in favor with deeper (and de facto) integration of compilers with static analysis tools ?
> >>
> >> Absolutely. Not as tools. SPARK must become an integral part of Ada.
> >> Static analysis and defined provable semantics is major strength of Ada.
> >>
> > Agreed; this is why I'm pushing for a heavily integrated IDE with my IDE-proposal.
> > I'd be quite interested to hear your thoughts on the subject.
>
> Why do you think that an IDE is important here? (Not that I will use
> emacs, ever! (:-))
>
Integration.
I don't mean "IDE" like the industry has come to think of it (editor + button-to-call-external-tool). / Think more like R-1000 on steroids, not GPS.
The integration that you're proposing isn't going to be happening on this revision of the language, BUT we can integrate it as closely as possible in the form of an IDE, acting /as if/ there were a requirement for such integration. (And indeed, the Ada spec requires a degree of this WRT static analysis currently, so it certainly is possible to integrate these things.)
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-21 14:42 ` Shark8
@ 2018-06-21 15:55 ` Dan'l Miller
2018-06-27 11:49 ` Marius Amado-Alves
2018-06-21 16:06 ` Dmitry A. Kazakov
1 sibling, 1 reply; 39+ messages in thread
From: Dan'l Miller @ 2018-06-21 15:55 UTC (permalink / raw)
On Thursday, June 21, 2018 at 9:42:44 AM UTC-5, Shark8 wrote:
> On Thursday, June 21, 2018 at 3:09:26 AM UTC-6, Dmitry A. Kazakov wrote:
> > On 2018-06-21 02:19, Shark8 wrote:
> > > On Wednesday, June 20, 2018 at 7:38:11 AM UTC-6, Dmitry A. Kazakov wrote:
> > >> On 2018-06-20 15:14, Mehdi Saada wrote:
> > >>> So I guess you are in favor with deeper (and de facto) integration of compilers with static
> > >>> analysis tools ?
> > >>
> > >> Absolutely. Not as tools. SPARK must become an integral part of Ada.
> > >> Static analysis and defined provable semantics is major strength of Ada.
> > >>
> > > Agreed; this is why I'm pushing for a heavily integrated IDE with my IDE-proposal.
> > > I'd be quite interested to hear your thoughts on the subject.
> >
> > Why do you think that an IDE is important here? (Not that I will use
> > emacs, ever! (:-))
> >
> Integration.
> I don't mean "IDE" like the industry has come to think of it (editor + button-to-call-external-tool). /
> Think more like R-1000 on steroids, not GPS.
>
> The integration that you're proposing isn't going to be happening on this revision of the language, BUT
> we can integrate it as closely as possible in the form of an IDE, acting /as if/ there were a requirement for
> such integration. (And indeed, the Ada spec requires a degree of this WRT static analysis currently, so it
> certainly is possible to integrate these things.)
In technology, if you name it & define it & then reify it then you own* it, even if the name existed before with a different definition and/or the definition existed before with a different name. There are numerous examples strewn throughout computer history, of which here are 3:
1) RAII in C++ world is attributed to Boost community, but as much as 7 years prior it was commonly called “allocation in only constructors; deallocation in only destructors” but Marshall Kline et. al. did not reduce the mantra to a catchy acronym or initialism.
2) The term microcomputer was commonplace prior to the release of the IBM Personal Computer in 1981. Nowadays we hardly hear the word microcomputer to refer to a PC, other than noting the Micro- of Microsoft refers to microcomputers.
3) The way of storing compiled Ada objects in R1000 also existed in Multics for PL/I a decade prior to R1000. Then it was later reprised again a half-decade later than R1000 for C++ via ObjectStore.
* not in the patent or trademark sense, but in the mindshare & fame sense. Well, on 2nd thought, actually mindshare and marketshare can lend itself well to establishing trademark in legal-world.
Shark8, you should pull open the thesaurus and name/define a next-generation replacement term for IDE. Something like holistic development environment (HDE). Indeed, there exists an archaic spelling of holistic that de-emphasises any misinterpretation of holistic as having anything to do with hole or holy**: wholistic, emphasizing wholeness. Plus wholistic would have very few collisions on Bing/Google searches. Wholistic development environment (WDE).
A wise technology leader once told me: if you need to explain yourself in embattled debate (e.g., no, •this• IDE, not •that• IDE), then you have already lost the argument.
** New-age people misinterpret the root-word of holistic as holy, not as whole from before the time that English's spelling was fully settled.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-21 14:42 ` Shark8
2018-06-21 15:55 ` Dan'l Miller
@ 2018-06-21 16:06 ` Dmitry A. Kazakov
2018-06-22 17:06 ` Shark8
1 sibling, 1 reply; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-06-21 16:06 UTC (permalink / raw)
On 2018-06-21 16:42, Shark8 wrote:
> On Thursday, June 21, 2018 at 3:09:26 AM UTC-6, Dmitry A. Kazakov wrote:
>> On 2018-06-21 02:19, Shark8 wrote:
>>> On Wednesday, June 20, 2018 at 7:38:11 AM UTC-6, Dmitry A. Kazakov wrote:
>>>> On 2018-06-20 15:14, Mehdi Saada wrote:
>>>>> So I guess you are in favor with deeper (and de facto) integration of compilers with static analysis tools ?
>>>>
>>>> Absolutely. Not as tools. SPARK must become an integral part of Ada.
>>>> Static analysis and defined provable semantics is major strength of Ada.
>>>>
>>> Agreed; this is why I'm pushing for a heavily integrated IDE with my IDE-proposal.
>>> I'd be quite interested to hear your thoughts on the subject.
>>
>> Why do you think that an IDE is important here? (Not that I will use
>> emacs, ever! (:-))
>>
> Integration.
> I don't mean "IDE" like the industry has come to think of it (editor + button-to-call-external-tool). / Think more like R-1000 on steroids, not GPS.
>
> The integration that you're proposing isn't going to be happening on this revision of the language, BUT we can integrate it as closely as possible in the form of an IDE, acting /as if/ there were a requirement for such integration. (And indeed, the Ada spec requires a degree of this WRT static analysis currently, so it certainly is possible to integrate these things.)
I see what you mean. I think it would be difficult to do without proper
integration. We need contracts properly inherited, e.g. in the case of
exceptions, as well as all sorts of conditional contracts, this if that,
I am OK if he is OK etc. Doing this outside the compiler would require
lots of helper files gathering information from the parser, compiler,
prover and redistributing it in all possible directions. My fear is that
it will be impossible to handle. GPS, gprconfig, gprbuild already
generate a dozen of such files, promptly to stumble upon. Recently I had
a persistent compiler crash. Project cleanup didn't help. Only when I
manually deleted all files except the sources it worked again.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-21 16:06 ` Dmitry A. Kazakov
@ 2018-06-22 17:06 ` Shark8
2018-06-22 18:53 ` Dmitry A. Kazakov
0 siblings, 1 reply; 39+ messages in thread
From: Shark8 @ 2018-06-22 17:06 UTC (permalink / raw)
On Thursday, June 21, 2018 at 10:07:01 AM UTC-6, Dmitry A. Kazakov wrote:
> On 2018-06-21 16:42, Shark8 wrote:
> > On Thursday, June 21, 2018 at 3:09:26 AM UTC-6, Dmitry A. Kazakov wrote:
> >> On 2018-06-21 02:19, Shark8 wrote:
> > Integration.
> > I don't mean "IDE" like the industry has come to think of it (editor + button-to-call-external-tool). / Think more like R-1000 on steroids, not GPS.
> >
> > The integration that you're proposing isn't going to be happening on this revision of the language, BUT we can integrate it as closely as possible in the form of an IDE, acting /as if/ there were a requirement for such integration. (And indeed, the Ada spec requires a degree of this WRT static analysis currently, so it certainly is possible to integrate these things.)
>
> I see what you mean. I think it would be difficult to do without proper
> integration. We need contracts properly inherited, e.g. in the case of
> exceptions, as well as all sorts of conditional contracts, this if that,
> I am OK if he is OK etc. Doing this outside the compiler would require
> lots of helper files gathering information from the parser, compiler,
> prover and redistributing it in all possible directions. My fear is that
> it will be impossible to handle. GPS, gprconfig, gprbuild already
> generate a dozen of such files, promptly to stumble upon. Recently I had
> a persistent compiler crash. Project cleanup didn't help. Only when I
> manually deleted all files except the sources it worked again.
GPS, gprconfig, gprbuild, etc are irrelevant, I'm not saying we start with extant tools and methodologies. Besides the "dozens of such files" are only indicative of the lack of integration between these tools. (Arguably you could make a highly-integrated system that did use files intermediately between its tools; however, even if they were initially as a set of integrated tools, unless there was a central library handling these file-types, they would accumulate ad hock changes/improvements and thus have unbalanced development: much like dialects in real-world/natural-language.) -- Plus, as you saw these dozens of files require management.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-22 17:06 ` Shark8
@ 2018-06-22 18:53 ` Dmitry A. Kazakov
0 siblings, 0 replies; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-06-22 18:53 UTC (permalink / raw)
On 2018-06-22 19:06, Shark8 wrote:
> On Thursday, June 21, 2018 at 10:07:01 AM UTC-6, Dmitry A. Kazakov wrote:
>> On 2018-06-21 16:42, Shark8 wrote:
>>> On Thursday, June 21, 2018 at 3:09:26 AM UTC-6, Dmitry A. Kazakov wrote:
>>>> On 2018-06-21 02:19, Shark8 wrote:
>>> Integration.
>>> I don't mean "IDE" like the industry has come to think of it (editor + button-to-call-external-tool). / Think more like R-1000 on steroids, not GPS.
>>>
>>> The integration that you're proposing isn't going to be happening on this revision of the language, BUT we can integrate it as closely as possible in the form of an IDE, acting /as if/ there were a requirement for such integration. (And indeed, the Ada spec requires a degree of this WRT static analysis currently, so it certainly is possible to integrate these things.)
>>
>> I see what you mean. I think it would be difficult to do without proper
>> integration. We need contracts properly inherited, e.g. in the case of
>> exceptions, as well as all sorts of conditional contracts, this if that,
>> I am OK if he is OK etc. Doing this outside the compiler would require
>> lots of helper files gathering information from the parser, compiler,
>> prover and redistributing it in all possible directions. My fear is that
>> it will be impossible to handle. GPS, gprconfig, gprbuild already
>> generate a dozen of such files, promptly to stumble upon. Recently I had
>> a persistent compiler crash. Project cleanup didn't help. Only when I
>> manually deleted all files except the sources it worked again.
>
> GPS, gprconfig, gprbuild, etc are irrelevant, I'm not saying we start with extant tools and methodologies. Besides the "dozens of such files" are only indicative of the lack of integration between these tools. (Arguably you could make a highly-integrated system that did use files intermediately between its tools; however, even if they were initially as a set of integrated tools, unless there was a central library handling these file-types, they would accumulate ad hock changes/improvements and thus have unbalanced development: much like dialects in real-world/natural-language.) -- Plus, as you saw these dozens of files require management.
OK, it is possible to do, theoretically, but it would be a huge project
and GCC is still relevant.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-21 15:55 ` Dan'l Miller
@ 2018-06-27 11:49 ` Marius Amado-Alves
0 siblings, 0 replies; 39+ messages in thread
From: Marius Amado-Alves @ 2018-06-27 11:49 UTC (permalink / raw)
Just call it ADE (Awesome Development Environment).
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-20 14:01 ` Mehdi Saada
2018-06-20 14:32 ` Dmitry A. Kazakov
2018-06-20 15:58 ` Niklas Holsti
@ 2018-06-29 21:58 ` Randy Brukardt
2 siblings, 0 replies; 39+ messages in thread
From: Randy Brukardt @ 2018-06-29 21:58 UTC (permalink / raw)
"Mehdi Saada" <00120260a@gmail.com> wrote in message
news:64a526cb-e6d5-44a6-b446-5b652ebe60ca@googlegroups.com...
>Considering how complicate writing Ada compilers already is, and
>seeing that there is no standard interface between those and tools - as
>far as I get it - it would likely make the hypothetic compilers huge and
>considering GNAT is the only one implementing (most) of the 2012
>version, fusing tools and compilers might close for good the Ada
>compilers market.
>Haven't you been promoting free market ?
>Stop me if I made a mistake.
For what it's worth, I agree (somewhat) with Dmitry. Not so much about SPARK
(the reliance on outside logic provers seems unnecessary for most work), but
more like CodePeer. CodePeer is one of a variety of static analysis tools
that are based on compiler optimization technology. It seems to me that that
such technology should be an intergral part of an Ada compiler's optimizer
(a lot of it exists anyway). In part because anything it can prove will also
allow making smaller/faster code (for instance, proving that a check cannot
fail also means that the compiler need not generate code for that check).
This does imply a need for Ada-specific optimization (which might be an
issue in a GCC/LLVM environment - although I think it can be dealt with).
Anyone have a few extra million $$$ laying around so I can build this?? ;-)
Randy.
P.S. The next Janus/Ada release, scheduled for late July, will have a small
corner of that capability implemented. There'll be a blog entry on
rrsoftware.com once the compiler details are settled.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-20 14:32 ` Dmitry A. Kazakov
@ 2018-06-29 22:01 ` Randy Brukardt
2018-06-29 22:15 ` Dmitry A. Kazakov
0 siblings, 1 reply; 39+ messages in thread
From: Randy Brukardt @ 2018-06-29 22:01 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:pgdoip$1ntl$1@gioia.aioe.org...
...
> How adding features like low-level parallelism makes compiler smaller?
Nothing low-level about parallel loops. They're in fact a higher-level
construct than an Ada task, since they're checked (by default) for safety
problems and any tasking used is implicit. "Parallel" is mainly a hint to
the compiler that parallelism can be used (there's almost no case today
where a compiler could automatically use parallel code, as there would be a
substantial risk of that code being slower than sequential code would be).
Randy.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-29 22:01 ` Randy Brukardt
@ 2018-06-29 22:15 ` Dmitry A. Kazakov
2018-06-29 22:47 ` Randy Brukardt
0 siblings, 1 reply; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-06-29 22:15 UTC (permalink / raw)
On 2018-06-30 00:01, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:pgdoip$1ntl$1@gioia.aioe.org...
> ...
>> How adding features like low-level parallelism makes compiler smaller?
>
> Nothing low-level about parallel loops. They're in fact a higher-level
> construct than an Ada task, since they're checked (by default) for safety
> problems and any tasking used is implicit.
That is not a definition of higher-level [abstraction] to me. Parallel
loop is a loop.
> "Parallel" is mainly a hint to
> the compiler that parallelism can be used (there's almost no case today
> where a compiler could automatically use parallel code, as there would be a
> substantial risk of that code being slower than sequential code would be).
Why does it need such hints?
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-29 22:15 ` Dmitry A. Kazakov
@ 2018-06-29 22:47 ` Randy Brukardt
2018-06-30 8:41 ` Dmitry A. Kazakov
0 siblings, 1 reply; 39+ messages in thread
From: Randy Brukardt @ 2018-06-29 22:47 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:ph6b2l$1cta$1@gioia.aioe.org...
> On 2018-06-30 00:01, Randy Brukardt wrote:
...
>> "Parallel" is mainly a hint to
>> the compiler that parallelism can be used (there's almost no case today
>> where a compiler could automatically use parallel code, as there would be
>> a
>> substantial risk of that code being slower than sequential code would
>> be).
>
> Why does it need such hints?
One reason is that a loop is defined to iterate operations in a specific
order. For instance, in
for I in 1..5 loop -- I takes on the values of 1, 2, 3, 4, and 5, in that
order. The ability of a compiler to parallelize in such a case then requires
determining all of the following:
(1) That there are enough iterations in order to make parallelizing
worthwhile;
(2) That there is enough code in each iteration in order to make
parallelizing worthwhile;
(3) That there is no interaction between iterations;
(4) That there is no use of global variables.
With "parallel", the compiler knows that the programmer has requested
unordered, parallel iteration, so it only needs make safety checks and
create the appropriate implementation.
Otherwise, it can't make the optimization without knowing all of the above
(having simple loops run very slowly because they were parallelized
unnecessarily is not going to be accepted by many). Indeed, you pretty much
can only do it when the number of iterations is static and the body of the
iteration doesn't contain any external calls -- and the number of iterations
is relatively large.
It's clearly possible that sometime in the future, we'll have new hardware
and operating systems that would make the overhead small enough that such
optimizations could be done automatically in enough cases to make it worth
it. But that's fine; the situation then would be similar to that for
"inline" -- not 100% necessary but still a useful hint to the compiler.
Randy.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-29 22:47 ` Randy Brukardt
@ 2018-06-30 8:41 ` Dmitry A. Kazakov
2018-06-30 15:43 ` Brad Moore
0 siblings, 1 reply; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-06-30 8:41 UTC (permalink / raw)
On 2018-06-30 00:47, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:ph6b2l$1cta$1@gioia.aioe.org...
>> On 2018-06-30 00:01, Randy Brukardt wrote:
> ...
>>> "Parallel" is mainly a hint to
>>> the compiler that parallelism can be used (there's almost no case today
>>> where a compiler could automatically use parallel code, as there would be
>>> a
>>> substantial risk of that code being slower than sequential code would
>>> be).
>>
>> Why does it need such hints?
>
> One reason is that a loop is defined to iterate operations in a specific
> order. For instance, in
> for I in 1..5 loop -- I takes on the values of 1, 2, 3, 4, and 5, in that
> order. The ability of a compiler to parallelize in such a case then requires
> determining all of the following:
> (1) That there are enough iterations in order to make parallelizing
> worthwhile;
> (2) That there is enough code in each iteration in order to make
> parallelizing worthwhile;
> (3) That there is no interaction between iterations;
> (4) That there is no use of global variables.
>
> With "parallel", the compiler knows that the programmer has requested
> unordered, parallel iteration, so it only needs make safety checks and
> create the appropriate implementation.
There should be unordered types in the meaning that the compiler is
allowed to choose any order. Like enumeration type which has no specific
order. It must be a property of the type you iterate through, not a
property of the loop.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-30 8:41 ` Dmitry A. Kazakov
@ 2018-06-30 15:43 ` Brad Moore
2018-07-01 9:46 ` Dmitry A. Kazakov
0 siblings, 1 reply; 39+ messages in thread
From: Brad Moore @ 2018-06-30 15:43 UTC (permalink / raw)
I don't think that would fit into the language very well, and I dont think this is particularly appealing to me, though at one time I was suggesting that we could apply aspects such as parallel and other controls to a locally declared subtype, we moved away from that idea. We have "reverse" syntax for loops already which specifies an order. It would be inconsistent to sometimes specify the order on the loop, and sometimes somewhere else. It also seems like it would be messy for ADT's such as containers. Sometimes you want to iterate through a type sequentially, for example when the work to be performed per iteration is very small and not worth doing in parallel, and sometimes you want to specify parallel execution, if you know that there is significant processing required for each iteration. You might have a container with many elements. It sounds like you'd have to declare two container objects, (one parallel, and one sequential), and then copy all the elements from one to the other whenever you wanted to switch from sequential to parallel iteration or vice versa, when really you only want or need a single container object.
Similarly, you might want to iterate through an enumeration with a particular order for one loop, and a different order for another loop. It seems to be better to apply the hint to the loop construct rather than the iterator type, which is also consistent with other approaches such as in OpenMP and Cilk.
Brad Moore
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-06-30 15:43 ` Brad Moore
@ 2018-07-01 9:46 ` Dmitry A. Kazakov
2018-07-02 13:13 ` Marius Amado-Alves
0 siblings, 1 reply; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-07-01 9:46 UTC (permalink / raw)
On 2018-06-30 17:43, Brad Moore wrote:
> I don't think that would fit into the language very well, and I dont think this is particularly appealing to me, though at one time I was suggesting that we could apply aspects such as parallel and other controls to a locally declared subtype, we moved away from that idea. We have "reverse" syntax for loops already which specifies an order. It would be inconsistent to sometimes specify the order on the loop, and sometimes somewhere else.
I would say that semantically "reverse" applies to a set (range is a
set) rather than to the loop. If sets were first-class:
for I in reverse (Ordered_Set) loop
> It also seems like it would be messy for ADT's such as containers. Sometimes you want to iterate through a type sequentially, for example when the work to be performed per iteration is very small and not worth doing in parallel, and sometimes you want to specify parallel execution, if you know that there is significant processing required for each iteration. You might have a container with many elements. It sounds like you'd have to declare two container objects, (one parallel, and one sequential), and then copy all the elements from one to the other whenever you wanted to switch from sequential to parallel iteration or vice versa, when really you only want or need a single container object.
I would declare different enumerators for the container. It is a good
practice to be able to enumerate a container by a key or by position or
by something else (e.g. by code points for strings).
> Similarly, you might want to iterate through an enumeration with a particular order for one loop, and a different order for another loop. It seems to be better to apply the hint to the loop construct rather than the iterator type, which is also consistent with other approaches such as in OpenMP and Cilk.
To me that is still a property of the enumerated object rather than of
the loop. Otherwise you must hard-wire implementation into the loop
instead of the set/index/mapping type. It is container's business, IMO.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-07-01 9:46 ` Dmitry A. Kazakov
@ 2018-07-02 13:13 ` Marius Amado-Alves
2018-07-02 15:05 ` Dmitry A. Kazakov
0 siblings, 1 reply; 39+ messages in thread
From: Marius Amado-Alves @ 2018-07-02 13:13 UTC (permalink / raw)
"To me that is still a property of the enumerated object rather than of the loop." (Kasakov)
Hmmm... are there not cases where the *same* "unordered" object sustains two (separated) loops, loop1 truly "unordered" but loop2 with more complex processing requiring *order*?
(Hence loop1 parallelizeable but loop2 not.)
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-07-02 13:13 ` Marius Amado-Alves
@ 2018-07-02 15:05 ` Dmitry A. Kazakov
2018-07-02 16:01 ` Marius Amado-Alves
0 siblings, 1 reply; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-07-02 15:05 UTC (permalink / raw)
On 2018-07-02 15:13, Marius Amado-Alves wrote:
> "To me that is still a property of the enumerated object rather than of the loop." (Kasakov)
>
> Hmmm... are there not cases where the *same* "unordered" object sustains two (separated) loops, loop1 truly "unordered" but loop2 with more complex processing requiring *order*?
An ordered set or a set of a stochastic/independent order is iterated in
the only way it offers. Iteration is an interface to a set or container,
no magic, just a set of operations like 'First, 'Succ etc.
Answering the question, if the same object must be iterated differently
then, obviously to me, it must offer two different interfaces for doing
so. Interfaces can be views as in the case of "in reverse", and so could
be an interface for ad-hoc parallel loops.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-07-02 15:05 ` Dmitry A. Kazakov
@ 2018-07-02 16:01 ` Marius Amado-Alves
2018-07-02 16:48 ` Dmitry A. Kazakov
0 siblings, 1 reply; 39+ messages in thread
From: Marius Amado-Alves @ 2018-07-02 16:01 UTC (permalink / raw)
" ... if the same object must be iterated differently it must offer two different interfaces for doing so" (K.)
Absolutely, and I've done that multiple times. Then 'Parallelizeable would be a property of the iterator--not of the object. A simple Boolean attribute indicating to the compiler "parallelize if you can" or "dont." (Defaulting to False I guess.)
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Ada lacks lighterweight-than-task parallelism
2018-07-02 16:01 ` Marius Amado-Alves
@ 2018-07-02 16:48 ` Dmitry A. Kazakov
0 siblings, 0 replies; 39+ messages in thread
From: Dmitry A. Kazakov @ 2018-07-02 16:48 UTC (permalink / raw)
On 2018-07-02 18:01, Marius Amado-Alves wrote:
> " ... if the same object must be iterated differently it must offer two different interfaces for doing so" (K.)
>
> Absolutely, and I've done that multiple times. Then 'Parallelizeable would be a property of the iterator--not of the object. A simple Boolean attribute indicating to the compiler "parallelize if you can" or "dont." (Defaulting to False I guess.)
No, there should be no any iterators in the first place. In a properly
designed language you need no helper types.
And it is certainly not a Boolean flag. A property is something which
can be proved to be true. One property is existence of random
independent evaluation of the access. It is a property of the given set
type (or mapping/container type).
Another property is absence of cross effects of the loop body
evaluation, which depends on the properties of operations and objects
that appear in the body.
None of these are properties of the loop itself, so it is strange to tie
this to the loop statement. That would be a promise the language cannot
hold unless it can prove it holding. If it can, and the only way to know
is the contracts of the objects involved, then it would need no further
hints.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2018-07-02 16:48 UTC | newest]
Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-19 22:14 Ada lacks lighterweight-than-task parallelism Dan'l Miller
2018-06-19 22:23 ` Dan'l Miller
2018-06-20 0:03 ` Dan'l Miller
2018-06-20 0:41 ` Lucretia
2018-06-20 1:36 ` Dan'l Miller
2018-06-20 13:39 ` Luke A. Guest
2018-06-20 1:12 ` Shark8
2018-06-20 1:41 ` Dan'l Miller
2018-06-20 7:13 ` Dmitry A. Kazakov
2018-06-20 12:03 ` Dan'l Miller
2018-06-20 12:29 ` Dmitry A. Kazakov
2018-06-20 13:14 ` Mehdi Saada
2018-06-20 13:38 ` Dmitry A. Kazakov
2018-06-20 14:01 ` Mehdi Saada
2018-06-20 14:32 ` Dmitry A. Kazakov
2018-06-29 22:01 ` Randy Brukardt
2018-06-29 22:15 ` Dmitry A. Kazakov
2018-06-29 22:47 ` Randy Brukardt
2018-06-30 8:41 ` Dmitry A. Kazakov
2018-06-30 15:43 ` Brad Moore
2018-07-01 9:46 ` Dmitry A. Kazakov
2018-07-02 13:13 ` Marius Amado-Alves
2018-07-02 15:05 ` Dmitry A. Kazakov
2018-07-02 16:01 ` Marius Amado-Alves
2018-07-02 16:48 ` Dmitry A. Kazakov
2018-06-20 15:58 ` Niklas Holsti
2018-06-29 21:58 ` Randy Brukardt
2018-06-21 0:19 ` Shark8
2018-06-21 9:09 ` Dmitry A. Kazakov
2018-06-21 14:42 ` Shark8
2018-06-21 15:55 ` Dan'l Miller
2018-06-27 11:49 ` Marius Amado-Alves
2018-06-21 16:06 ` Dmitry A. Kazakov
2018-06-22 17:06 ` Shark8
2018-06-22 18:53 ` Dmitry A. Kazakov
2018-06-21 0:17 ` Shark8
2018-06-20 12:28 ` Brian Drummond
2018-06-21 1:51 ` Dan'l Miller
2018-06-21 10:22 ` Brian Drummond
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox