4 ms·
Yeah, but one thing that often gets overlooked when talking about 'non-parallelizable tasks' is that most tasks aren't actually non-parallelizable, rather that
by icegreentea 12y ago
Yeah, but one thing that often gets overlooked when talking about 'non-parallelizable tasks' is that most tasks aren't actually non-parallelizable, rather that they are weakly parallelizable (less than linear speed-up), or they have a large time constant (the 'train-up' time of adding additional resources). If you can identify this and recognize your current position, it can still be possible to accelerate your timelines by adding more people in some cases.
- HCIdivision17 12y agoCan we say courting is the equivalent of the 'train-up' period for having a baby?
- JoeAltmaier 12y agoDefinitely THAT can be parallelized. Just play the field!
- adwn 12y agoBut make sure that you have proper isolation between the subtasks.
- JoeAltmaier 12y agoStill you can't parallelize design/coding/debugging/packaging, much. Maybe each of those tasks can be individually, weakly.
- leni536 12y agoI think the main message that independently working on the same task can be a weak parallelization of random time tasks (independently random depending who is working on it). It simply falls in the category of "less than linear speed-up" parallelization. Since it is a trivial one, you can take it into account most of the time, however it's not too efficient.