3 ms·

I am not sure why would you want to do this. If I take an example of the bottling pipeline, it seems to me that the best way to process the bottles on an SMP sy

by js8 2y ago

I am not sure why would you want to do this. If I take an example of the bottling pipeline, it seems to me that the best way to process the bottles on an SMP system is to have multiple threads where each thread is doing all the work for a single bottle, sequentially. Maybe, if the processes at each stage are I/O-bound, then it might make sense. But if they are CPU-bound, then I am not sure this way of pipelining helps - you're moving data between different CPUs, destroying cache locality.

adrianmonk 2y ago
I was about to suggest the same thing, and I still think it makes a lot of sense. However, the cache locality thing is complicated. Each bottle has data associated with it, but each processing stage might also have data. For example, maybe a particular stage uses a lookup table. Or maybe stages keep statistics as they process bottles. If you have one CPU doing all the work for a particular stage, then per-stage data stays in its cache. But if you have one CPU doing all the work for a particular bottle, then all the per-bottle data stays in its cache. So there's a trade-off that depends on the specifics.
- kitd 2y ago
  More importantly, each processing stage may have external resources it needs to manage to do its function. In many cases, it makes more sense to let the stage own the resource for all bottles, than to have a per-bottle process having to contend for the resource at the point it's needed.
  - hinkley 2y ago
    You get very different Little’s Law shapes from the too for sure. Who here hasn’t bought themselves some time from vertically or horizontally scaling a database by hoisting a bunch of calculations up and out of the transaction? Do them before or after the constraint. The farther you have to reach to coordinate use of the constraint the better it might be to hand the inputs to the constraint and let an experts handle things.
anonymoushn 2y ago
You probably gain some ILP or avoid some pipeline stalls by handling a lot of bottles at a time rather than one.
- hinkley 2y ago
  Particularly if you’re doing collision detection against static sets of data. Filter this data for entries that look this way. Or don’t look that way.

by js8 2y ago

adrianmonk 2y ago

I was about to suggest the same thing, and I still think it makes a lot of sense. However, the cache locality thing is complicated. Each bottle has data associated with it, but each processing stage might also have data. For example, maybe a particular stage uses a lookup table. Or maybe stages keep statistics as they process bottles. If you have one CPU doing all the work for a particular stage, then per-stage data stays in its cache. But if you have one CPU doing all the work for a particular bottle, then all the per-bottle data stays in its cache. So there's a trade-off that depends on the specifics.

kitd 2y ago
More importantly, each processing stage may have external resources it needs to manage to do its function. In many cases, it makes more sense to let the stage own the resource for all bottles, than to have a per-bottle process having to contend for the resource at the point it's needed.
- hinkley 2y ago
  You get very different Little’s Law shapes from the too for sure. Who here hasn’t bought themselves some time from vertically or horizontally scaling a database by hoisting a bunch of calculations up and out of the transaction? Do them before or after the constraint. The farther you have to reach to coordinate use of the constraint the better it might be to hand the inputs to the constraint and let an experts handle things.

anonymoushn 2y ago

You probably gain some ILP or avoid some pipeline stalls by handling a lot of bottles at a time rather than one.

hinkley 2y ago
Particularly if you’re doing collision detection against static sets of data. Filter this data for entries that look this way. Or don’t look that way.