This question is a narrowing-down of these related questions:How much effort should we spend to programming for multiple cores?Concurrency: How do you approach the design and debug the implementation?Given that each user's computers may have different performance characteristics with respect to calculations, memory, disk I/O bandwidth and network I/O bandwidth, and that it is difficult to implement an automated self-tuning system in your software, how much configurability should we give to the end-users so that they can find ways (by trial-and-error?) to improve our software's efficiency?If we give users the ability to change these settings, how do we give visual feedback to users so they can measure the performance changes?
How much configurability to give to users regarding concurrency?
optimization;concurrency;configuration;user control
You never want to expose average users to the internal guts of how your application works--especially if you are supporting it.  The BeOS used to ship with a utility that would allow you to turn off a processor (this is before multicore processors) just to see the impact on performance.  And yes, you could turn off all the processors.  That's when the machine just froze up and the only recourse to reboot the machine.Most platforms will provide a way for you to query the system for the number of cores/processors on the machine.  By running a few profile tests in your environment, you can determine characteristics of how your application runs most efficiently.  You can have the app set up its internal configuration using simple ratios to the number of cores available.  I'm sure you're thinking that is the type of thing that a sys admin might want to have control over.  You may or may not be right.If we are talking server software here, then I think a better approach is to use an approach similar to Java's Hot Spot technology.  Basically, Hot Spot will recompile optimized portions of your code (completely removing sections that won't ever apply) and swap that new implementation in when it is safe.  It makes its decisions on the branch behavior during runtime (and the value of static values, etc.).In a similar approach you could have key performance areas monitored.  As long as you have an appropriate cost function you have an effective meter to fine-tune your configuration at runtime and adapt to variations in performance outside your application's control.  If performance is getting lower, you can either spin up a new concurrent task or take some down.  You can have it choose to run something remotely vs. locally if the cost of communications and the current load of the software on the server warrant it.Giving a user access to the way the internals of your application works is like giving them a loaded gun.  Bottom line is that unless you are going to train someone how to properly use a gun, it's probably best not keep it around--much less load it.  They can shoot themselves in the foot, or worse.