Brian Beesley wrote:
Griffith, Shaun wrote:
>
> One drawback is the possibility of comparing apples to oranges, i.e., one
> combination running with a different system loading than another.
A real, practical problem related to this is that varying
system load may make a significant difference as to the relative
efficiency of two methods, so you'd have to be careful about how you
did the timing.
e.g. on Intel processors, whether or not MMX is in use by another
active process substantially affects the performance of anything
which thrashes the FPU, because the MMX & FPU register sets are
common & switching between MMX mode & FPU mode is relatively slow.
If something like this happens in the normal course of computation, it matters little for programs such as Prime95 and others with low priority. Most of the work is done when nothing else is processing, and I would hope that MMX and similar interruptions are not running on my machine when I'm not there to enjoy it. If it happens during the tuning phase, that would pose a problem.
Perhaps tuning should be programmed to run after some interval of uninterrupted CPU access (whatever that means). If a program tried to tune itself just after it loaded, there could still be a few processes around complicating things (like users with fidgety mice?) Or an occasional "refresh tune" at some user specified time might be useful.
> Another drawback is of course is to manage the added memory taken up
> "redundant" code. However, with the exponents running now the code size
> should be negligible compared to the data.
On IA32 systems, how the code is aligned is also a factor. To compare
accurately, you'd really need the separate code fragments to be in
their own dedicated segments. This is not the way that un*x or Win32
applications are usually coded.
Not being up on the latest HLL compilers, I would still suspect that some compiler directives/options would be available to handle alignment properly without much headache, especially if it is as important as you suggest. And "usually coded" is perhaps superfluous here, as the programs we're discussing would be "unusually coded" because of the tuning approach itself. Point taken.
Another problem suggests itself - this code would take a lot more
debugging, for reasons which ought to be self-evident. Also, you'd
need to label each result with the method used.
Which may be the ultimate reason it remains undone. However, command line options could be used to force the code through each tuning configuration. The code could be proven to work correctly (to the same degree that current code is proven, by cross-checking sample input), though with significantly more effort, and perhaps with little added benefit. The configuration chosen by the tuning process could be documented to the user with another command line switch (printing out configuration and run times).
Regards,
Shaun
