-
Notifications
You must be signed in to change notification settings - Fork 44
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
which version is faster? #125
Comments
Do you have objective facts about speed? 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?
what can go wrong? |
i've tested both before and after the compilation, also changed |
|
@brechtsanders up? |
There have been precompiled header issues with GCC on Windows in the past. |
slower and |
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?
|
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 #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. |
how do i make use of nasm? |
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. |
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? |
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): 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? |
i'm getting this,
|
I have tried to patch the PCH issue according to MSYS2's patches. |
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.
The text was updated successfully, but these errors were encountered: