[vsipl++] [patch] Tunable parameters

[Stefan Seefeld]

Jules,

Jules Bergmann wrote:

> Originally, the threshold was checked directly in rt_valid:
> 
>     bool rt_valid(...)
>     {
>       return size >= 16384 && ...
>     }
> 
> Since the number was magic and subject to change (as we optimize the 
> library, as hardware changes), I thought it would be good practice to 
> label the number as a "tunable parameter," and perhaps include some 
> history on how it's value was arrived at:

>     bool rt_valid(...)
>     {
>        return
>         // Tunable: compare vmul -2 --svpp-num-spes {0,8} ...
>             size >= 16384 &&
>         ...
>     }
> 
> That way we could search for magic numbers in the source ("/Tunable", 
> and have the information on how they were generated.

I find this very valuable indeed.


> Because other factors go into choosing the right number (operation, 
> value type, etc), it made sense to move the magic number into an 
> evaluator function:
> 
>     bool rt_valid(...)
>     {
>       return
>         size >= tunable_threshold() &&
>         ...
>     }

OK. (For avoidance of doubt: this remains a very evaluator-specific 
function, so this wouldn't become part of the generic Evaluator 
interface, right ?)

> If the "tunable" prefix is confusing, perhaps just "threshold()" would 
> be more clear?  That is still searchable.

I think with all the context of this discussion, 'tunable' has already 
become much more meaningful. This is true for whatever name we choose: 
documentation is key. ;-)
I think the high-order bit to capture in a comment is the tuning 
process, from 300000 feet:
Compile with VSIP_IMPL_TUNE_MODE=1, and then find the cross-over problem 
sizes by comparing benchmark runs with 0 and N SPEs.

I think 'tunable_threshold' is better than any alternative I can come up 
with.

Thanks,
		Stefan


-- 
Stefan Seefeld
CodeSourcery
stefan at codesourcery.com
(650) 331-3385 x718