By: Jukka Larja (roskakori2006.delete@this.gmail.com), March 23, 2021 6:26 am
Room: Moderated Discussions
Moritz (better.delete@this.not.tell) on March 22, 2021 12:40 pm wrote:
> Jukka Larja (roskakori2006.delete@this.gmail.com) on March 22, 2021 7:11 am wrote:
>
> > > Then do not spawn an actual thread but only let the compiler add/sprinkle the instructions into
> > > the normal flow of the main task at times it assumes there is a stall or free capacity.
> >
> > Consider usual flow of code: 1) do some thing, 2) use results of
> > work done in 1), 3) use results of work done in 1) and 2) etc..
> >
> > At which point does the "sprinkling of instructions into the normal flow" happen?
> > Unless the compiler is magical, the simple to write pattern is to annotate some
> > work as parallel, wait for it to complete and continue to next part.
>
> You said there were two parallel tasks that needed interleaving.
> I suggested not to have two threads that are explicitly interleaved by the processor but have
> the compiler mix/reorder the instructions in one context and let the processor find the ILP.
Ah, I've been thinking about having "some parallel work" inside mostly sequential program. Like having a loop that does some thing to all items in an array. I'm not sure if I've ever come across sequencial code where there would be two (or few) separate flows that could be executed in parallel (there are, of course, plenty, if one is allowed to do some mutexing and other stuff that a non-magical compiler can't be expected to do automatically). It's certainly either much more rare or much harder to spot than small loops that could theoretically be ran in parallel with small amount of tweaking.
Unless you mean some really short sequencies, in which case OoO hardware is already executing them in parallel. Or small loops that compiler may wholly unroll.
-JLarja
> Jukka Larja (roskakori2006.delete@this.gmail.com) on March 22, 2021 7:11 am wrote:
>
> > > Then do not spawn an actual thread but only let the compiler add/sprinkle the instructions into
> > > the normal flow of the main task at times it assumes there is a stall or free capacity.
> >
> > Consider usual flow of code: 1) do some thing, 2) use results of
> > work done in 1), 3) use results of work done in 1) and 2) etc..
> >
> > At which point does the "sprinkling of instructions into the normal flow" happen?
> > Unless the compiler is magical, the simple to write pattern is to annotate some
> > work as parallel, wait for it to complete and continue to next part.
>
> You said there were two parallel tasks that needed interleaving.
> I suggested not to have two threads that are explicitly interleaved by the processor but have
> the compiler mix/reorder the instructions in one context and let the processor find the ILP.
Ah, I've been thinking about having "some parallel work" inside mostly sequential program. Like having a loop that does some thing to all items in an array. I'm not sure if I've ever come across sequencial code where there would be two (or few) separate flows that could be executed in parallel (there are, of course, plenty, if one is allowed to do some mutexing and other stuff that a non-magical compiler can't be expected to do automatically). It's certainly either much more rare or much harder to spot than small loops that could theoretically be ran in parallel with small amount of tweaking.
Unless you mean some really short sequencies, in which case OoO hardware is already executing them in parallel. Or small loops that compiler may wholly unroll.
-JLarja
