On Tue, May 20, 2014 at 2:10 PM, Joshua Cranmer 🐧 <pidgeo...@gmail.com>wrote:
> And it also presumes that all of the CPUs are going to be more or less > available Please clarify what you are referring to by "more or less available". "more or less" makes me think you're referring to a fractional value, such as load. As I have stated before, my API makes no assumptions regarding load. In practice, then, why can't applications just set the value of their > thread pool to size 8, and let the OS scheduler sort it out in the end, if > the OS scheduler can handle extra load gracefully? In practice, this is what parallel applications *currently* do as they have no other choice without this API. The OS scheduler can handle balancing the load fine to keep your system responsive, but it can't optimize your algorithm to more efficiently take advantage of CPU resources. Using "workers = 8" will result in worse performance on a dual-core machine than an octa-core machine, but you are right that it will still work. Depending on your algorithm's management and messaging overhead, spawning too many workers can lead to pretty dramatic slowdowns for memory/message-intensive algorithms. For other algorithms that don't need to copy and postMessage many MBs of data to every worker, you are right that the performance penalty for overspawning workers is less significant. I can dynamically change the sets of CPUs to which I will let my program > run (and in fact, I do have use cases for this: high-quality timing > experiments, or binding long-running applications) I realize that but simply because the only users who will change their CPU count or affinities during the same session are developers (yes, I realize normal users may change their number of CPUs between different sessions by replacing any socketed CPUs), it doesn't seem worth adding a HardwareConcurrencyChanged event. Just refresh your webapp after changing your CPU count/affinities for your tests. :) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
