-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compilation of extension/dynamic_image/apply_operation_base.hpp takes ages with GCC 7 or 8 #131
Comments
I can only confirm your observations match my own - compilation times increases with every new GCC version:
Finally, you can see exactly the same trend in Boost.GIL builds on Circle CI. Check the currently latest workflow with GCC & clang builds at https://circleci.com/workflow-run/c6b11033-65cb-4f2c-a4f9-c2e43ee4fb9b . For convenience, here is CircleCI screenshot with compilers/versions and build times for GIL core tests only: Although I'd like to know, I have not tried to investigate why GCC becomes slower with every new version. |
I found this similar bug: |
I found the code that triggers this bad behaviour with gcc. It is in file
This single macro generates a line of 2701372 characters (nearly 3 millions)! Note that clang generates the exact same extra long line. |
I was able to make a minimal example that does not depend any more on
Then we could also remove part of the lines as we probably do not need the 99 generated structs to show the problem. |
If we just keep the |
Good effort and interesting findings! Regarding MPL, I've started removing it from GIL, but it's still long way to go #107 We definitely aim to replace as many Boost dependencies with C++11 as possible. NOTE: The PR #107 has got broken by recent master vs develop shuffles before the 1.68 release Here I made a new version of PR #107 but against old develop from before 1.68 release |
OK, I see. This is a difficult job. Meanwhile, I have been able to make a minimal standalone example (no boost dependency) that I think I can submit to the gcc team. Because it is still a good thing if gcc can be improved for speed. On my computer clang++ 6.0 is 53x quicker than g++ 8.2:
|
Submitted to the gcc team: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87107 |
@kivadiu good stuff! Thank you. I've added myself to CC in the GCC bug. I've forwarded your bug report to Boost ML: https://lists.boost.org/Archives/boost/2018/08/242919.php Do you agree to close this issue as delegated to GCC developers? |
Are you sure the |
Good question. Let me think, or @chhenning & @stefanseefeld in case they're available to chime in. Let's keep it open then. |
I am impacted by this issue as well and unfortunately I see no progress on the GCC front. Boost 1.68
Boost 1.67
I guess you are not going to like this, but could we reintroduce the old I/O extension as an option? |
(I'd suggest to open an issue with suggestion/request) IMHO: I see no problem in hosting the old I/O v1 in the Boost.GIL source tree, iff:
If we re-introduce it and it stops passing its own tests, and nobody chimes in to maintain it, it probably will remain as an abandoned artefact in the GIL source tree. I personally have no interest in Regardless of my personal opinion, I will delegate and leave the decision to maintainers of higher seniority, to @stefanseefeld and @chhenning. |
I just had a look at the implementation of |
I am very very close to start actually replacing all Boost.MPL with Boost.MP11 (I've set myself a deadline until end of the Feb). |
Sounds good! I use Boost.Hana in some projects and have zero experience with Boost.MP11. Do you think importing the newer |
To me, everything that has potential to improve GIL is worth a try. Especially if there is an actual user who would benefit from such improvement, you :-) It's just that I'm judging that particular one as layman - I have not looked into that code (too busy right now), so you have to judge if the potential is real/you can take risk of wasting time, etc. However, I appreciate your help @sdebionne ! |
I read the Boost.Variant code too fast, MPL was actually introduced with the C++14 |
Personally, I'd welcome jump to C++17. @stefanseefeld Comments? |
I can confirm that Boost.Variant does not trigger the GCC bug (using the code in #231):
|
The jump from GIL's variant to |
The compilation speed up is very good news! Thanks |
Adds support C++11 decltype(auto) Fixes #131
The compilation of the io jpeg extension takes ages with g++ (boost 1.68.0):
Minimal Working Example (in C++)
Actual behavior
compiles on my x86_64 linux system:
-O2 -DNDEBUG -Wall -Wextra -Wnon-virtual-dtor -Werror=delete-non-virtual-dtor -pipe -march=native -std=c++14 -DBOOST_DISABLE_ASSERTS
-g3 -Wall -Wextra -Wnon-virtual-dtor -Werror=delete-non-virtual-dtor -pipe -march=native -std=c++14
But it is very fast with clang 5.0.2
-O2 -DNDEBUG -Wall -Wextra -Wnon-virtual-dtor -Werror=delete-non-virtual-dtor -pipe -march=native -std=c++14 -DBOOST_DISABLE_ASSERTS
-g3 -Wall -Wextra -Wnon-virtual-dtor -Werror=delete-non-virtual-dtor -pipe -march=native -std=c++14
-ftime-report gives the following time breakdown:
So it is mostly template instantiation although nothing is instantiated.
Expected behavior
I would hope that such file compile within a few seconds.
Environment
Fedora 27 x86_64 linux
All relevant information like:
<boost/version.hpp>
): 1.68.0Is there anything that can be done to improve the compile time with g++?
The text was updated successfully, but these errors were encountered: