Mark Roulo (nothanks.delete@this.xxx.com) on March 20, 2021 5:49 pm wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on March 20, 2021 1:20 pm wrote:
> > Hugo Décharnes (hdecharn.delete@this.outlook.fr) on March 20, 2021 7:34 am wrote:
> > > Having programs delivered in annotated, intermediate representation (IR) would be great.
> >
> > In theory.
> >
> > Not necessarily in practice.
> >
> > Not only do you often have a big optimization problem (look at everybody who has tried
> > it: they pretty much always ended up having a "native mode" fallback for games), but
> > you have a very nasty testing problem, because often the IR is designed by compiler people,
> > and those people are more than happy to talk about "undefined behavior" etc.
> >
> > So the end result will generally be rather under-defined, and then different
> > hardware, and different recompilers will result in different behavior.
> >
> > That happens even with real hardware, but it at least tends to happen less. Partly because
> > the HW people have actually mostly learnt from their mistakes, while in many areas the compiler
> > people have been even more open to "undefined behavior" in the name of performance.
> >
> > Java (and wasm) is actually doing pretty damn well. It's unusually well-specified
> > for an IR (despite issues), it works, it's used, and it's fine.
>
> Were I trying to design some sort of distributable/executable IR-ish format
> I would focus on being able to specify "don't care" about sequencing.
>
> One weakness with the Java Virtual Machine is that loops MUST have an order, even if the iterations are
> independent. In theory a good OoO engine can/might be able to untangle all the artificial dependencies.
> I'd like the ability to just not put in artificial/wrong dependencies that must then be removed.
>
> Maybe there aren't enough of these for "normal" code to be worth while.

We have a system in place to write:

for (...) { doSomethingInBackgroundtask(...); } waitforBackgroundTasks();

A coder suggested we should have this. It was easy enough to add for what we had before, so I added it. Two years later I came across something that could use it, clapped my hands in excitement, and noticed there was a slight problem with the syntax and the code didn't actually compile. Apparently during that time no-one else had tried to use it (the problem with the syntax was minor. Took me less than a minute to fix).

So yeah, I think the problem is it's not actually a very common pattern. It tends to require lot of work to make sure things really can run in parallel. By the time that is done, syntax for actually spawning the individual tasks (functions) and waiting for them to finish is rather minor point.

If very simple things, like finding an item in an array, could be efficiently handled in this way, then sure, there would be more interest. However, spawning tasks has overhead, which I don't see going away with current architectures. I can't imagine an architecture that could run the normal code of "single-threaded spaghetti sprinkled with tiny sections of potentially parallel computing" any better than current ones do (and if I could, it wouldn't change the PS5 and Nintendo Switch we have today anyway).

-JLarja