GCC compiler options difficulty #688
Replies: 4 comments 6 replies
-
|
Let’s discuss this in a zoom call next week?
Am 15.02.2024 um 18:08 schrieb Dominik Mokriš - work account ***@***.***>:
Today, I would like to share with you my recent difficulties with gcc options, because it is not the first time I ran into them.
When I run CMake for the first time, the gismo/cmake/OptimizeForArchitecture.cmake script attempts quite vigorously to find the compiler settings to squeeze the best possible performance out of the current CPU. On my computer, the result typically looks like this
make VERBOSE=1
[...]
[ 0%] Building CXX object src/CMakeFiles/gsParallel.dir/gsParallel/gsOpenMP.cpp.o
cd /path/to/gismo/tdm/tst/src && /usr/bin/c++ -Dgismo_EXPORTS -I/path/to/gismo/tdm/gismo/src -I/path/to/gismo/tdm/gismo/external -I/path/to/gismo/tdm/tst -I/path/to/gismo/tdm/gismo/optional -Wall -Wno-long-long -Wunused-variable -Wno-unknown-pragmas -march=skylake-avx512 -mmmx -mavx -mavx2 -mfma -msse2 -msse3 -msse4.1 -msse4.2 -msse -mssse3 -mavx512bw -mavx512cd -mavx512dq -mavx512f -mavx512vl -maes -mbmi2 -mf16c -mfsgsbase -mpclmul -mpku -mpopcnt -mrdrnd -mabm -mbmi -mno-sse4a -mno-avx5124fmaps -mno-avx5124vnniw -mno-avx512er -mno-avx512ifma -mno-avx512pf -mno-avx512vbmi -mno-avx512vpopcntdq -mno-adx -mno-fxsr -mno-lzcnt -mno-movbe -mno-mpx -mno-prfchw -mno-prefetchwt1 -mno-rdpid -mno-rdseed -mno-rtm -mno-sha -mno-xsavec -mno-xsaveopt -mno-xsaves -mno-clflushopt -mno-clwb -O3 -DNDEBUG -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -std=c++14 -MD -MT src/CMakeFiles/gsParallel.dir/gsParallel/gsOpenMP.cpp.o -MF CMakeFiles/gsParallel.dir/gsParallel/gsOpenMP.cpp.o.d -o CMakeFiles/gsParallel.dir/gsParallel/gsOpenMP.cpp.o -c /path/to/gismo/tdm/gismo/src/gsParallel/gsOpenMP.cpp
For reasons out of my direct control, the CPU information passed to the script is not 100% accurate in our environment and it can activate unsuitable flags. In practice this means that call to G+Smo that worked perfectly well two weeks ago can suddenly start crashing with signal 4 (Illegal instruction) in a seemingly random spot.
What's worse, the problem is difficult to debug: re-compiling in Debug mode and using GDB finds no problem at all; in fact, the program runs perfectly well, because the optimization script is active only in Release mode. This leaves you guessing in the dark.
A dear colleague of mine helped me find a way around this: start with a fresh build-folder and configure with
cmake /path/to/gismo -DARCHITECTURE_CXX_FLAGS=BAKE_MORE_CAKE
Setting the CMake variable ARCHITECTURE_CXX_FLAGS to anything (it does not seem to matter what) deactivates the script (cf. gismo/cmake/gsConfig.cmake), leading to slower but more reliable code. This can be again checked when asking for a verbose make:
make VERBOSE=1
[...]
[ 0%] Building CXX object src/CMakeFiles/gsParallel.dir/gsParallel/gsOpenMP.cpp.o
cd /path/to/gismo/tdm/tst/src && /usr/bin/c++ -Dgismo_EXPORTS -I/path/to/gismo/tdm/gismo/src -I/path/to/gismo/tdm/gismo/external -I/path/to/gismo/tdm/tst -I/path/to/gismo/tdm/gismo/optional -Wall -Wno-long-long -Wunused-variable -Wno-unknown-pragmas -Wall -Wno-long-long -Wunused-variable -Wno-unknown-pragmas -O3 -DNDEBUG -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -std=c++14 -MD -MT src/CMakeFiles/gsParallel.dir/gsParallel/gsOpenMP.cpp.o -MF CMakeFiles/gsParallel.dir/gsParallel/gsOpenMP.cpp.o.d -o CMakeFiles/gsParallel.dir/gsParallel/gsOpenMP.cpp.o -c /path/to/gismo/tdm/gismo/src/gsParallel/gsOpenMP.cpp
Any thoughts? I guess that @mmoelle1<https://urldefense.com/v3/__https://github.com/mmoelle1__;!!PAKc-5URQlI!7lgUiLoAcK1vTFwd-2uEVhs-mvvkjSK3Cb0xUmlSdNU7fh3fXLG5Qj0M0deB--EHtVahW9v3bx1t9dwP4YVWpIvqWag$> has quite some experience in the area.
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/gismo/gismo/discussions/688__;!!PAKc-5URQlI!7lgUiLoAcK1vTFwd-2uEVhs-mvvkjSK3Cb0xUmlSdNU7fh3fXLG5Qj0M0deB--EHtVahW9v3bx1t9dwP4YVWFRgjmjw$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AAPGPI5PJQ7WOY4QRUQAT2LYTY6ITAVCNFSM6AAAAABDKUEPW2VHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWGIZDGMBSG4__;!!PAKc-5URQlI!7lgUiLoAcK1vTFwd-2uEVhs-mvvkjSK3Cb0xUmlSdNU7fh3fXLG5Qj0M0deB--EHtVahW9v3bx1t9dwP4YVWL0f2-CI$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
After quite some time spent learning, discussing and testing I have found where I had made the mistake. I share it here in the hope of helping the others to avoid the same pitfall. The problem, which was manifesting itself with the Very similar problem would happen even when simply setting A solution is described in Out of curiosity, I did some benchmarking, measuring the runtimes of This was surprising for me: I would have expected the HTH! |
Beta Was this translation helpful? Give feedback.
-
Personally, I think this is not worth the effort. The |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Update: a solution is below.
Today, I would like to share with you my recent difficulties with gcc options, because it is not the first time I ran into them, cf. #566 (comment) .
When I run
CMakefor the first time, thegismo/cmake/OptimizeForArchitecture.cmakescript attempts quite vigorously to find the compiler settings to squeeze the best possible performance out of the current CPU. On my computer, the result typically looks like thisFor reasons out of my direct control, the CPU information passed to the script is not 100% accurate in our environment and it can activate unsuitable flags. In practice this means that call to G+Smo that worked perfectly well two weeks ago can suddenly start crashing with
signal 4 (Illegal instruction)in a seemingly random spot.What's worse, the problem is difficult to debug: re-compiling in
Debugmode and using GDB finds no problem at all; in fact, the program runs perfectly well, because the optimization script is active only inReleasemode. This leaves you guessing in the dark.A dear colleague of mine helped me find a way around this: start with a fresh build-folder and configure with
Setting the
CMakevariableARCHITECTURE_CXX_FLAGSto anything (it does not seem to matter what) deactivates the script (cf.gismo/cmake/gsConfig.cmake), leading to slower but more reliable code. This can be again checked when asking for a verbosemake:Any thoughts? I guess that @mmoelle1 has quite some experience in the area.
Beta Was this translation helpful? Give feedback.
All reactions