By: Moritz (better.delete@this.not.tell), March 21, 2021 6:00 am
Room: Moderated Discussions
Jukka Larja (roskakori2006.delete@this.gmail.com) on March 21, 2021 12:26 am wrote:
> We have a system in place to write:
> for (...) { doSomethingInBackgroundtask(...); } waitforBackgroundTasks();
The for-loop is an example of code that you write without wanting it.
You do not want a counter, you do not want to issue operations on it, you do not want to jump, you do not want to compare, you likely do not care if it gets done in random order, descending order or all at once. All you wanted to say is: "Do this parameterized job N times."
> A coder suggested we should have this. It was easy enough to add for what we had before, so I added it.
> 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.
"People are neither used to nor trained to work that way." Is not an argument against new technology/ways. If that were the case we would not use forks and would not have this discussion.
> However, spawning tasks has overhead, which I don't see going away
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.
> 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
Then something about the code has to change to allow the CPU to fetch more executable/ready instructions.
Maybe some very convenient concept like the stack must go.
> We have a system in place to write:
> for (...) { doSomethingInBackgroundtask(...); } waitforBackgroundTasks();
The for-loop is an example of code that you write without wanting it.
You do not want a counter, you do not want to issue operations on it, you do not want to jump, you do not want to compare, you likely do not care if it gets done in random order, descending order or all at once. All you wanted to say is: "Do this parameterized job N times."
> A coder suggested we should have this. It was easy enough to add for what we had before, so I added it.
> 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.
"People are neither used to nor trained to work that way." Is not an argument against new technology/ways. If that were the case we would not use forks and would not have this discussion.
> However, spawning tasks has overhead, which I don't see going away
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.
> 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
Then something about the code has to change to allow the CPU to fetch more executable/ready instructions.
Maybe some very convenient concept like the stack must go.