Skip to content

Commit

Permalink
Tell about compile-time optimizations
Browse files Browse the repository at this point in the history
  • Loading branch information
gevtushenko committed May 4, 2023
1 parent e3335ab commit 9686c2c
Showing 1 changed file with 28 additions and 0 deletions.
28 changes: 28 additions & 0 deletions docs/tuning.rst
Original file line number Diff line number Diff line change
Expand Up @@ -144,6 +144,34 @@ treated as equally important.
.add_int64_power_of_two_axis("Elements{io}", nvbench::range(16, 28, 4));


When you define a type axis that's annotated as :code:`{ct}`, you might want to consider optimizing
the build time. Many variants are going to be build, but the search is considering one compile-time
use case at a time. This means, that if you have many types to tune for, you'll end up having
many specializations that you don't need. To avoid this, for each compile time axis, you can
expect a `TUNE_AxisName` macro with the type that's currently being tuned. For instance, if you
have a type axes :code:`T{ct}` and :code:`OffsetT` (as shown above), you can use the following
construct:

.. code:: c++

#ifdef TUNE_T
using types = nvbench::type_list<TUNE_T>;
#else
using types = all_types;
#endif

#ifdef TUNE_OffsetT
using offset_types = nvbench::type_list<TUNE_OffsetT>;
#else
using offset_types = nvbench::type_list<int32_t, int64_t>;
#endif


This logic is automatically applied to :code:`all_types`, :code:`offset_types`, and
:code:`fundamental_types` lists when you use matching names for the axes. You can define
your own axis names and use the logic above for them (see sort pairs example).


Search Process
--------------------------------------------------------------------------------

Expand Down

0 comments on commit 9686c2c

Please sign in to comment.