we didn’t want to force users to specify dependences for every task they created
If the user doesn't want to specify dependencies, then it is no different than a normal static scheduler, right? I.E, the task graph would consist of tasks without any dependence and they can be executed in whatever order is desired, similar to how it is done now.
we were / are sufficiently skeptical about a compiler's ability to determine such dependences automatically without being unduly conservative.
That's fine too, but I believe it could have been an invaluable piece of infrastructure to handle what rare cases were found to be parallelizable.
beginexpressions” rather than just begin statements as we currently do. The current Futures module contributed by Nick Park was an attempt to express similar patterns without any language changes. I think all of these options are still on the table, but we haven’t had sufficiently compelling use cases to invest further in any of them.
was to lean on single variables to express such dependencies.
Was it ever planned to have the
single be injected implicitly? I've never seen
single used in practice today, either. I do like the option of having native first-class support for futures though, but I've a feeling this won't happen in the near future (no pun intended)
beginexpression” concept would’ve injected singles implicitly (and uses of that pattern would’ve likely been good motivation to work more on optimizing it). E.g.,
var total = left.total() + begin right.total();could be thought of as being converted into
var tmp$: single; begin tmp$ = right.total(); var total = left.total() + tmp$;
--llvm --savec=tmpbut I haven't ever tried to run them with
lli. I would imagine that to run the .bc with
lliit would need also some symbols we normally link with and I'm not sure how that would work (does
llihave a facility to work with compiled C libraries in .a files?).