Chapter 3. Tuning

Table of Contents

Build targets for tuning
Exporting and importing tuning results

Build targets for tuning

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-gf2n Run tuning for all binary field sizes configured.

  • tune-TAG, e.g. tune-0-to-64 Perform tuning for the specified field sizes. The tuning results are saved into the file gf2x/wizard.table which serves as a cache database if the tuning target is run again. Type make help | grep tun to 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 \(\mathbb{F}_{2^{251}}\) as the tuning code claims. In contrast, the tuning benefit for \(\mathbb{F}_{2^{113}}\) is visible.