I've finally decided to migrate my Expression Templates Library (ETL) project to
C++17. I've talking about doing that for a long time and I've released several
releases without doing the change, but the next version will be a C++17 library.
The reason why I didn't want to rush the change was that this means the library
needs a very recent compiler that may not be available to everybody. Indeed,
after this change, the ETL library now needs at least GCC 7.1 or Clang 4.0.
I've already made some previous experiments in the past. For instance,
by using if constexpr, I've managed to speed up compilation by 38% and I've also written an article about the fold expressions introduced in C++17. But I haven't migrated a full library yet. This is now done with ETL. In this article, I'll try to give some example of improvements by using C++17.
This will only cover the C++17 features I'm using in the updated ETL library,
I won't cover all of the new C++17 features.
if constexpr
The most exciting new thing in C++17 for me is the if constexpr
statement. This is a really really great thing. In essence, it's a normal
if statement, but with one very important difference. The statement that
is not taken (the else if the condition is true, or the if
constexpr if the condition is false) is discarded. And what is interesting
is what happens to discarded statements:
The body of a discarded statement does not participate in return type
deduction.
The discarded statement is not instantiated
The discarded statement can odr-use a variable that is not defined
Personally, I'm especially interested by points 1 and 2. Let's start with an
example where point 1 is useful. In ETL, I have a make_temporary function. This
function either forwards an ETL container or creates a temporary container from
an ETL expression. This is based on a compile-time traits. The return type of
the function is the not the same in both cases. What you did in those case
before C++17, is use SFINAE and make two functions:
template <typename E, cpp_enable_iff(is_dma<E>)>
decltype(auto) make_temporary(E&& expr) {
return std::forward<E>(expr);
}
template <typename E, cpp_enable_iff(!is_dma<E>)>
decltype(auto) make_temporary(E&& expr) {
return force_temporary(std::forward<E>(expr));
}
One version of the function will forward and the other version will force
a temporary and the return type can be different since these are two different
functions. This is not bad, but still requires two functions where you only want
to write one. However, in C++17, we can do much better using if constexpr:
template <typename E>
decltype(auto) make_temporary(E&& expr) {
if constexpr (is_dma<E>) {
return std::forward<E>(expr);
} else {
return force_temporary(std::forward<E>(expr));
}
}
I think this version is really superior to the previous one. We only have one
function and the logic is much clearer!
Let's now see an advantage of the point 2. In ETL, there are two kinds of
matrices, matrices with compile-time dimensions (fast matrices) and matrices
with runtime dimensions (dynamic matrices). When they are used, for instance for
a matrix-multiplication, I use static assertions for fast matrices and runtime
assertions for dynamic matrices. Here is an example for the validation of the
matrix-matrix multiplication:
template <typename C, cpp_disable_iff(all_fast<A, B, C>)>
static void check(const A& a, const B& b, const C& c) {
static_assert(all_2d<A,B,C>, "Matrix multiplication needs matrices");
cpp_assert(
dim<1>(a) == dim<0>(b) //interior dimensions
&& dim<0>(a) == dim<0>(c) //exterior dimension 1
&& dim<1>(b) == dim<1>(c), //exterior dimension 2
"Invalid sizes for multiplication");
cpp_unused(a);
cpp_unused(b);
cpp_unused(c);
}
template <typename C, cpp_enable_iff(all_fast<A, B, C>)>
static void check(const A& a, const B& b, const C& c) {
static_assert(all_2d<A,B,C>, "Matrix multiplication needs matrices");
static_assert(
dim<1, A>() == dim<0, B>() //interior dimensions
&& dim<0, A>() == dim<0, C>() //exterior dimension 1
&& dim<1, B>() == dim<1, C>(), //exterior dimension 2
"Invalid sizes for multiplication");
cpp_unused(a);
cpp_unused(b);
cpp_unused(c);
}
Again, we use SFINAE to distinguish the two different cases. In that case, we
cannot use a normal if since the value of the dimensions cannot be taken
at compile-time for dynamic matrices, more precisely, some templates cannot be
instantiated for dynamic matrices. As for the cpp_unused, we have to use for the
static version because we don't use them and for the dynamic version because
they won't be used if the assertions are not enabled. Let's use if constexpr to avoid having two functions:
template <typename C>
static void check(const A& a, const B& b, const C& c) {
static_assert(all_2d<A,B,C>, "Matrix multiplication needs matrices");
if constexpr (all_fast<A, B, C>) {
static_assert(dim<1, A>() == dim<0, B>() //interior dimensions
&& dim<0, A>() == dim<0, C>() //exterior dimension 1
&& dim<1, B>() == dim<1, C>(), //exterior dimension 2
"Invalid sizes for multiplication");
} else {
cpp_assert(dim<1>(a) == dim<0>(b) //interior dimensions
&& dim<0>(a) == dim<0>(c) //exterior dimension 1
&& dim<1>(b) == dim<1>(c), //exterior dimension 2
"Invalid sizes for multiplication");
}
cpp_unused(a);
cpp_unused(b);
cpp_unused(c);
}
Since the discarded won't be instantiated, we can now use a single function!
We also avoid some duplications of the first static assertion of the unused
statements. Pretty great, right ? But we can do better with C++17. Indeed, it
added a nice new attribute [[maybe_unused]]. Let's see what this gives
us:
template <typename C>
static void check([[maybe_unused]] const A& a, [[maybe_unused]] const B& b, [[maybe_unused]] const C& c) {
static_assert(all_2d<A,B,C>, "Matrix multiplication needs matrices");
if constexpr (all_fast<A, B, C>) {
static_assert(dim<1, A>() == dim<0, B>() //interior dimensions
&& dim<0, A>() == dim<0, C>() //exterior dimension 1
&& dim<1, B>() == dim<1, C>(), //exterior dimension 2
"Invalid sizes for multiplication");
} else {
cpp_assert(dim<1>(a) == dim<0>(b) //interior dimensions
&& dim<0>(a) == dim<0>(c) //exterior dimension 1
&& dim<1>(b) == dim<1>(c), //exterior dimension 2
"Invalid sizes for multiplication");
}
}
No more need for cpp_unused trick :) This attribute tells the compiler
that a variable or parameter can be sometimes unused and therefore does not lead
to a warning for it. Only one thing that is not great with this attribute is
that it's too long, 16 characters. It almost double the width of my check
function signature. Imagine if you have more parameters, you'll soon have to use
several lines. I wish there was a way to set an attribute for all parameters
together or a shortcut. I'm considering whether to use a short macro to use in
place of it, but haven't yet decided.
Just a note, if you have else if statements, you need to set them as
constexpr as well! This was a bit weird for me, but you can figure it as
if the condition is constexpr, then the if (or else if)
is constexpr as well.
Overall, I'm really satisfied with the new if constexpr! This really makes the
code much nicer in many cases, especially if you abuse metaprogramming like
I do.
You may remember that I've coded a version of static if in the past with C++14 in the past. This was able to solve point 2, but not point 1 and was much uglier. Now we have a good solution to it. I've replaced two of these in the current code with the new if constexpr.
Fold expressions
For me, fold expressions is the second major feature of C++17. I wont' go into
too much details here, since
I've already talked about fold expression in the past
. But I'll show two examples of refactorings I've been able to do with this.
Here was the size() function of a static matrix in ETL before:
static constexpr size_t size() {
return mul_all<Dims...>;
}
The Dims parameter pack from the declaration of fast_matrix:
template <typename T, typename ST, order SO, size_t... Dims>
struct fast_matrix_impl;
And the mul_all is a simple helper that multiplies each value of the variadic
parameter pack:
template <size_t F, size_t... Dims>
struct mul_all_impl final : std::integral_constant<size_t, F * mul_all_impl<Dims...>::value> {};
template <size_t F>
struct mul_all_impl<F> final : std::integral_constant<size_t, F> {};
template <size_t F, size_t... Dims>
constexpr size_t mul_all = mul_all_impl<F, Dims...>::value;
Before C++17, the only way to compute this result at compilation time was to use
template recursion, either with types or with constexpr functions. I think this
is pretty heavy only for doing a multiplication sum. Now, with fold expressions,
we can manipulate the parameter pack directly and rewrite our size function:
static constexpr size_t size() {
return (Dims * ...);
}
This is much better! This clearly states that each value of the parameter should
be multiplied together. For instance 1,2,3 will become (1*2)*3.
Another place where I was using this was to code a traits that tests if a set of
boolean are all true at compilation-time:
template <bool... B>
constexpr bool and_v = std::is_same<
cpp::tmp_detail::bool_list<true, B...>,
cpp::tmp_detail::bool_list<B..., true>>::value;
I was using a nice trick here to test if all booleans are true. I don't remember
where I picked it up, but it's quite nice and very fast to compile.
This was used for instance to test that a set of expressions are all
single-precision floating points:
template <typename... E>
constexpr bool all_single_precision = and_v<(is_single_precision<E>)...>;
Now, we can get rid of the and_v traits and use directly the parameter pack
directly:
template <typename... E>
constexpr bool all_single_precision = (is_single_precision<E> && ...);
I think using fold expressions results in much clearer syntax and better code
and it's a pretty nice feature overall :)
As a note here, I'd like to mention, that you can also use this syntax to call
a function on each argument that you have, which makes for much nicer syntax as
well and I'll be using that in DLL once I migrate it to C++17.
Miscellaneous
There are also a few more C++17 features that I've used to improve ETL, but that
have a bit less impact.
A very nice feature of C++17 is the support for structured bindings. Often you
end up with a function that returns several parts of information in the form of
a pair or a tuple or even a fixed-size array. You can use an object for this,
but if you don't, you end up with code that is not terribly nice:
size_t index;
bool result;
float alpha;
std::tie(index, result, alpha) = my_function();
It's not terribly bad, but in these cases, you should be be hoping for something
better. With c++17, you can do better:
auto [index, result, alpha] = my_function();
Now you can directly use auto to deduce the types of the three variables at once
and you can get all the results in the variables at once as well :) I think this
is really nice and can really profit some projects. In ETL, I've almost no use
for this, but I'm going to be using that a bit more in DLL.
Something really nice to clean up the code in C++17 is the ability to declared
nested namespaces in one line. Before, you have a nested namespace
etl::impl::standard for instance, you would do:
namespace etl {
namespace impl {
namespace standard {
// Someting inside etl::impl::standard
} // end of namespace standard
} // end of namespace impl
} // end of namespace etl
In C++17, you can do:
namespace etl::impl::standard {
// Someting inside etl::impl::standard
} // end of namespace etl::impl::standard
I think it's pretty neat :)
Another very small change is the ability to use the typename keyword in place of
the class keyword when declaring template template parameters. Before, you had
to declare:
template <template <typename> class X>
now you can also use:
template <template <typename> typename X>
It's just some syntactic sugar, but I think it's quite nice.
The last improvement that I want to talk about is one that probably very few
know about but it's pretty neat. Since C++11, you can use the alignas(X)
specifier for types and objects to specify on how many bytes you want to align
these. This is pretty nice if you want to align on the stack. However, this
won't always work for dynamic memory allocation. Imagine this struct:
struct alignas(128) test_struct { char data; };
If you declare an object of this type on the stack, you have the guarantee that
it will be aligned on 128 bytes. However, if you use new to allocate it
on the heap, you don't have such guarantee. Indeed, the problem is that 128 is
greater than the maximum default alignment. This is called an over-aligned type.
In such cases, the result will be aligned on the max alignment of your system.
Since C++17, new supports aligned dynamic memory allocation of
over-aligned types. Therefore, you can use a simple alignas to allocate
dynamic over-aligned types :) I need this in ETL for matrices that need to be
aligned for vectorized code. Before, I was using a larger array with some
padding in order to find an aligned element inside, but that is not very nice,
now the code is much better.
Compilation Time
I've done a few tests to see how much impact these news features have on
compilation time. Here, I'm doing benchmark on compiling the entire test suite
in different compilation mode, I enabled most compilation options (all GPU and
BLAS options in order to make sure almost all of the library is compiled).
Since I'm a bit short on time before going to vacation, I've only gathered the
results with g++. Here are the results with G++ 7.2.0
|
debug |
release |
release_debug |
C++14 |
862s |
1961s |
1718s |
C++17 |
892s |
2018s |
1745s |
Difference |
+3.4% |
+2.9% |
+1.5% |
Overall, I'm a bit disappointed by these results, it's around 3% slower to
compile the C++17 version than the C++14 version. I was thinking that this would
a least be as fast to compile as before. It seems that currently with G++ 7.2,
if constexpr are slower to compile than the equivalent SFINAE functions.
I didn't do individual benchmarks of all the features I've migrated, therefore,
it may not be coming from if constexpr, but since it's the greatest
change by far, it's the more likely candidate. Once I'll have a little more
time, after my vacations, I'll try to see if that is also the case with clang.
Keep in mind that we are compiling the test suite here. The ETL test suite is
using the manual selection mode of the library in order to be able to test all
the possible implementations of each operation. This makes a considerable
difference in performance. I expect better compilation time when this is used in
automatic selection mode (the default mode). In the default mode, a lot more
code can be disabled with if constexpr. I will test this next with the
DLL library which I will also migrate to C++17.
Conclusion
This concludes this report on the migration of my ETL library from C++14 to
C++17. Overall, I'm really satisfied with the improvement of the code, it's much
better. I'm a bit disappointed by the slight increase (around 3%) in
compilation time, but it's not dramatic either. I'm still hoping that once it's
used in DLL, I will see a decrease in compilation, but we'll see that when I'll
be done with the migration of DLL to C++17 which may take some time since I'll
have two weeks vacation in China starting Friday.
The new version is available only through the master branch. It will be
released as the 1.3 version probably when I integrate some new features, but in
itself will not be released as new version. You can take a look in the
Github etl repository if you are interested.
