The processor has fixed resource capabilities, if you run it at the maximum the only tradeoff is power. If you don't account for power it's like driving a car with unlimited fuel, why should you use a pid controller to control how many pistons fire if my fuel is unlimited? Just have the engine run idle always.
I mean there's wear and tear on an engine but this aspect of the analogy doesn't translate to threads.
The only other place where I see this is useful is competing tasks. One task needs more resources from a thread pool shared by other tasks. A pid controller can allocate existing threads based off of pressure. Allocating more threads to a pool in this case though, still doesn't make sense.
> The only other place where I see this is useful is competing tasks. One task needs more resources from a thread pool shared by other tasks. A pid controller can allocate existing threads based off of pressure. Allocating more threads to a pool in this case though, still doesn't make sense.
Imagine you got 16 CPUs/cores and a 4 stage pipeline, lets say we want to run one thread per CPU/core for max performance (avoiding context switching). Without knowing anything about the workload: what is the best way to distributed the threads over the stages? You can't tell. Even if you tested all the possilble ways to spread out the threads over the different stages on some particular workload, then as the workload changes you wouldn't have optimal allocation anymore. A controller can adjust the threads per stage until it finds the optimal allocation for the current workload and change it as it changes.
Right, the scenario you describe is exactly WHAT I mentioned: Competing tasks for threads.
This article is NOT exactly about that. It's about allocating more threads to a thread pool. I'm addressing the pointlessness of using PID controllers for allocating new threads.
Not exactly about that? It's literally the example from the motivation. The first thing I do in the plan section is to say "Let's focus on a single stage of the pipeline to make things easier for ourselves." and in the contributing section "We've only looked at one stage in a pipeline, what happens if we have multiple stages? is it enough to control each individual stage separately or do we need more global control?".
The example is about allocating threads to threadpools.
It is not about utilizing existing threads in threadpools.
Thats where YOU are mistaken. Your example has threads preallocated to core affinity. Which is what Im saying when I say run all pistons on the engine even when idle.
Aws charges per wattage or per thread? Don't think so. It makes sense if you are the cloud provider yourself but I don't see this as relevant for most businesses.
It depends on the specific setup you have, but if you have fewer workers, then either you need fewer things that you pay for, or else you can get by on a smaller box.
The processor has fixed resource capabilities, if you run it at the maximum the only tradeoff is power. If you don't account for power it's like driving a car with unlimited fuel, why should you use a pid controller to control how many pistons fire if my fuel is unlimited? Just have the engine run idle always.
I mean there's wear and tear on an engine but this aspect of the analogy doesn't translate to threads.
The only other place where I see this is useful is competing tasks. One task needs more resources from a thread pool shared by other tasks. A pid controller can allocate existing threads based off of pressure. Allocating more threads to a pool in this case though, still doesn't make sense.