From 9686c2cc70a903eb3953bbb2d9234c0279a65730 Mon Sep 17 00:00:00 2001 From: Georgy Evtushenko Date: Thu, 4 May 2023 05:26:49 +0400 Subject: [PATCH] Tell about compile-time optimizations --- docs/tuning.rst | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/docs/tuning.rst b/docs/tuning.rst index 2a25a7eff..652dfea39 100644 --- a/docs/tuning.rst +++ b/docs/tuning.rst @@ -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; + #else + using types = all_types; + #endif + + #ifdef TUNE_OffsetT + using offset_types = nvbench::type_list; + #else + using offset_types = nvbench::type_list; + #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 --------------------------------------------------------------------------------