Table of Contents
Parts of MPFQ allow tuning: different possible codes are generated, and the fastest one is marked as preferred for later code generations.
Presently, the only part of MPFQ which allows this mechanism is the multiplication of binary polynomials. Hard-coded defaults offer satisfactory performance, but tuning helps in improving the speed. Possible targets are:
tune-gf2nRun tuning for all binary field sizes configured.tune-TAG, e.g.tune-0-to-64Perform tuning for the specified field sizes. The tuning results are saved into the filegf2x/wizard.tablewhich serves as a cache database if the tuning target is run again. Typemake help | grep tunto see the list of available tuning targets.
Notice that in order to observe the possible speedup gained from
tuning, you must rebuild the affected target. The CMake
dependency system should normally see, if you run e.g. make
check after tuning, that binaries have to be rebuilt so
that the newly chosen code is used.
A word of caution concerning tuning. The tuning process is not immune to speed measurement difficulties. The different possible codes are generated as function in a separate object file, and compared with respect to each other. This is not the same context as your favorite application, which in particular is likely to include the MPFQ functions as inlined code. Future releases of MPFQ will likely try to adopt a different approach to tuning.
A consequence of these measurement difficulties is that if
you run make bench-apps, make
tune-gf2n, in order, and make bench-apps
again, you might not see as noticeable an improvement for
as the tuning code claims. In
contrast, the
tuning benefit for 
is
visible.