[multiprecision] Help needed with strange constexpr slowdown
Folks I have a very strange issue that I need help with understanding, it comes from https://github.com/boostorg/multiprecision/issues/32 but in summary: Given: #include <iostream> #include <boost/multiprecision/cpp_int.hpp> using namespace std; using namespace boost::multiprecision; int main() { __int128_t i =0; __int128_t j =0; int256_t sum =0; for (; i <1e9; i +=19, j +=13) { int256_t diff = j; sum += i * diff; } std::cout <<"Result: " << sum << std::endl; return 0; } There is a 20-30% slowdown when compiled in C++11 or later compared to C++03 with gcc 5.x or 6.x. I've tracked this down to the constexpr default constructor for int256_t (which is called inside operator* to create a temporary for the result), if I make the default constructor non-constexpr by removing BOOST_CONSTEXPR from any of: number.hpp:44 (number()) cpp_int.hpp:1077 (cpp_int_backend()) cpp_int.hpp:501 (cpp_int_base()) cpp_int.hpp: 435 (cpp_int_base::data_type()) Then the slowdown disappears. All the line numbers refer to current develop BTW. gcc-7 is better, but I notice it still generates different code if the constructor is constexpr - that greatly surprises me to be frank - is there something I'm missing about constexpr-ness that could cause this? Confused yours, John. --- This email has been checked for viruses by AVG. http://www.avg.com
Hi John,
On 31. Dec 2017, at 20:50, John Maddock via Boost <boost@lists.boost.org> wrote:
Folks I have a very strange issue that I need help with understanding, it comes from https://github.com/boostorg/multiprecision/issues/32 but in summary:
There is a 20-30% slowdown when compiled in C++11 or later compared to C++03 with gcc 5.x or 6.x.
I am not able to answer you, I just also want to say it is weird. I thought that making things constexpr should not change run-time code emitted by the compiler at all. Best regards, Hans
compared to C++03 with gcc 5.x or 6.x.
May be related: About a year ago I wrote a constexpr-string library for myself. The idea was to provide string manipulation functions like search, replace, etc at compile time. This would then allow me to build and express SQL queries in type-safe code and tie them to program logic (i.e. the queries could be expressed as chains of constexpr functions). I was testing on apple clang. Initially all went well. Intermediate strings where never produced in the assembler output and when the compiler needed the address of the resulting string, it would place the parts of the resulting string in data sections. Perfect. Then I tested with gcc. This was a disaster. Whenever a constexpr string was used, the compiler would build it on the stack, explicitly initialising it. I actually found that gcc produced better code when string literals were static const and not constexpr. What I took away from this was either, 1. I was pushing beyond the intended boundaries of constexpr and clang was just happy to oblige, or 2. gcc's code generation involving constexpr objects is a little suspect. On 2 January 2018 at 09:24, Hans Dembinski via Boost <boost@lists.boost.org> wrote:
Hi John,
On 31. Dec 2017, at 20:50, John Maddock via Boost <boost@lists.boost.org> wrote:
Folks I have a very strange issue that I need help with understanding, it comes from https://github.com/boostorg/multiprecision/issues/32 but in summary:
There is a 20-30% slowdown when compiled in C++11 or later compared to C++03 with gcc 5.x or 6.x.
I am not able to answer you, I just also want to say it is weird. I thought that making things constexpr should not change run-time code emitted by the compiler at all.
Best regards, Hans
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
I actually found that gcc produced better code when string literals were static const and not constexpr.
Thanks for everyone who's commented here or on the bug tracker. What's clear is that pre-gcc-7 there is a very noticeable slowdown for functions where a temporary with a constexpr constructor relies on the named-return-value-optimisation. Even with gcc-7 there are non-trivial changes to the assembly produced, where I would have expected them to be identical (given that the temporary is constructed in a non-constexpr context). Still, at least the performance is the same. In any case, it's clear that these new features can have strange unintended consequences. Best, John. --- This email has been checked for viruses by AVG. http://www.avg.com
participants (3)
-
Hans Dembinski -
John Maddock -
Richard Hodges