3 ms·
You're at least over-optimistic (certainly more wrong than GP). How are you measuring the performance of the app, then? Depending on your software, it might be
by CHY872 11y ago
You're at least over-optimistic (certainly more wrong than GP).
How are you measuring the performance of the app, then? Depending on your software, it might be throughput, it might be latency, it might be failure-related, etc etc.
The means with which the computer is supposed to work out 'oh, this app should be tuned for latency' is missing; and in many cases they can't know it (data-dependent etc). That's the hard bit. You have no way of working out 'better'.
Even if you have a good metric (user specified etc) you're still going to suffer, because there are many failure modes you won't have thought of. For example, say you're running an application and a database. It could easily be the case that the database taking too much memory slows the application down, and improves average latency by reducing contention. That would be a positive for the database, but a negative overall.
So, you'd need to have overall knowledge of a system. Then things get really complicated.
Where stuff can be optimised programatically, it generally already is; there's no setting for it. For example, the JIT settings in most runtimes are not exposed to the user (unless they dig deep). The remaining configuration settings should be things that the system can't deduce itself, and so needs to be told.
Trying to 'optimise' this without knowing what needs to be optimised is silly.
- jedisct1 11y agoLet the user choose the cost function.
- CHY872 11y agoOn a typical app, the user will have to trade off: peak/average memory, peak/average cpu, file storage usage, network, latency, throughput, cache behaviour, tolerance to pauses, and somehow produce a viable weighting function out of all of this. This function will need a tonne of refinement, because the initial weighting or three will lead to wastage, and it will end up being complex and nonlinear. The optimisation process will be expensive and time-consuming. The tuning process will be basically voodoo, harder than easily documentable configurations. Right now, experience can lead to dramatic improvements with ease. At the moment, tuning GC will also give you pointers for how to improve your program; and tuning your program will also give you pointers for tuning GC. That'll go. Then, we get the same problems as before wrt contention for system resources, so the system has to somehow be aware of all the other programs running on the computer. This all ends up being very difficult; much harder than performance tuning. Again, things that the system can work out on its own, the user shouldn't specify. Things that the system can't work out on its own, the user should specify, or the system should make a good guess.
- nightcracker 11y agoThis is effectively turning the nobs, just in an indirect and potentially ineffective way.