brechtsanders
which version is faster?
I've checked several builds and all i could find is it is slower than mingw 9.2.0 kindly tell one fastest build for windows.
Do you have objective facts about speed? What exactly is slow? Compiling (C/C++)? Linking?
I don't write the software (gcc, binutils, ...) myself, I just compile it for Windows, but in general each new versions of gcc has new improvements, either to produce more optimal binaries or to run faster.
Since I always compile each new version with itself, optimizations in the compiler output will also result in a more optimally running compiler.
doesnt gcc 11.3.0 (c++20) allow precompiled headers? because even with precompiled headers, i'm gettng 'x' with other headers as output.
C:\Users\Home\Desktop\cp>g++ -H yo.cpp
x c:\mingw64\include\c++\11.3.0\x86_64-w64-mingw32\bits\stdc++.h.gch
....more headers....
what can go wrong?
i've tested both before and after the compilation, also changed <bits/stdc++.h> to "bits/stdc++.h".
same as before.
g++ -std=c++20 -Winvalid-pch yo.cpp -o yo.exe
yo.cpp:1:24: warning: c:\mingw64\include\c++\11.3.0\x86_64-w64-mingw32\bits\stdc++.h.gch: not used because `__OPTIMIZE__' not defined [-Winvalid-pch]
1 | #include<bits/stdc++.h>
| ^
There have been precompiled header issues with GCC on Windows in the past. Do you have issues with the latest version (GCC 12.2.0) ?
slower and -Winvalid-pch shows no error only and if only it is executed with the same commands that were used to compile header
In my experience, the earlier the version, the faster the compile speed. I'm using GCC 7.5.0.
The question is: which part exactly is slower in newer versions?
- Is GCC slower?
- Is binutils slower?
- Is MinGW-w64 slower?
- Is it a dependency of any of the above that is slower?
- Is it because GCC precompiled headers have issues?
The code I compile doesn't use PCH. To answer some of your questions: both GCC and binutils are slower. I don't know the cause of this, maybe it's MinGW-w64 related or not. But it's really slower. I have noticed this long before started to use your MinGW builds. I guessed it's later GCC versions default to higher C++ standards that make the compilation slower. But now I'm not very sure about this. Because binutils is also slower. With GCC 7.5.0 I could have ld to link the dynamic library even though it's already very slow (much much slower than on Linux), with GCC 12.2.0 ld is unable to complete linking of the dynamic library and I have to cancel the build because it took too much time. Please note that it's not that it's draining the resource on my computer, the system is mostly idle when ld is running, it took about 80% of memory but that is not much, I can still open firefox without lagging, ld's disk usage is low and cpu usage is almost none. I have the same experience as the OP of https://github.com/brechtsanders/winlibs_mingw/issues/118 issue but I'm not as lucky as him, lld even though is much faster but failed to link the dynamic library because of other errors, it's not fully compatible and a drop-in replacement to GNU ld.
You can't compare linking PE images on Windows with ELF images on Linux. Also I was told linking is hard to parallelize so it tends to be come down to one CPU thread doing all the work. For ELF images (on Linux) there is the gold linker, but there appear to be no plans to make something like gold for Windows PE images.
how do i make use of nasm? i added the bin folder to path, still cant access.
how do i make use of nasm? i added the bin folder to path, still cant access.
nasm is at the root of the directory (mingw64), not the bin folder. so you will have to add the root directory to path too.
You can't compare linking PE images on Windows with ELF images on Linux. Also I was told linking is hard to parallelize so it tends to be come down to one CPU thread doing all the work. For ELF images (on Linux) there is the gold linker, but there appear to be no plans to make something like gold for Windows PE images.
I know what I'm doing. The code used to be possible to compile and link on Windows albeit slower than Linux (of course, everything on Linux is faster than Windows), as I recall GCC version 10.2 is the last version it worked with acceptable performance. Later GCC versions are much slower to compile and too slow to link the dynamic library (I would call it's a bug rather than simply slow). I have to cancel the compilation because it's unacceptably slow. The higher C++ standard being used on later GCC is not something to blame, as I hardcoded the C++ version to be C++17 on cmake (it's c++1z on GCC 7.5.0 and c++17 on latest GCC, so I'm not really sure if they are the same, there maybe changes on later versions, maybe more matured C++17 support of libstdc++ that could contribute to the slower compilation speed, but as I said: compilation speed is never a problem for me, linking speed is more serious a problem).
I just found a bug in my script to build the distribution archives, which caused nasm to be only included when llvm was included.
I am to understand only C++ is slower in newer versions, or C as well?
I just found a bug in my script to build the distribution archives, which caused nasm to be only included when llvm was included.
I am to understand only C++ is slower in newer versions, or C as well?
C is not affected as I recall. But C library are always small. They can never be as big as C++ library to cause trouble for the linker. Btw I also found nasm and other binaries usually at the top of the mingw64 dir is not available on later 7z, but I think it's your intention to do so.
For speed testing purposes I have just made this release (it reverts binutils back to the previous version): https://github.com/brechtsanders/winlibs_mingw/releases/tag/12.2.1-snapshot20221126-10.0.0-msvcrt-r1
Can you try if this version works faster for you?
For speed testing purposes I have just made this release (it reverts binutils back to the previous version): https://github.com/brechtsanders/winlibs_mingw/releases/tag/12.2.1-snapshot20221126-10.0.0-msvcrt-r1
Can you try if this version works faster for you?
actually i find it slower, if precompiled headers can be fixed, it'd be opposite.
I was able to build the version with precompiled headers enabled. Can you compare speed again? https://github.com/brechtsanders/winlibs_mingw/releases/tag/12.2.1-snapshot20221126-10.0.0-msvcrt-r2
i'm getting this,
C:\Users\Home\Desktop\cp>g++ -std=c++20 -Winvalid-pch yo.cpp
yo.cpp:1: sorry, unimplemented: PCH allocation failure
1 | #include<bits/stdc++.h>
|
I have tried to patch the PCH issue according to MSYS2's patches. Can you please check if the new release fixes any PCH and/or C++ compilation speed issues?