Winlibs is two times slower than MSYS2 #152
Comments
|
I have the impression it's slower too. I will try to make a build without the following linker flags to see if it makes a difference: |
|
Just a question: what exactly is slow?
|
|
I have a small project: 1 **.rc* file and 2 **.cpp* files (Windows desktop
application using C++, WinAPI and GDI+)
At first, I invoke *windres.exe* with VS code json args:
"args": [
"-J",
"rc",
"-O",
"coff",
"-i",
"${workspaceFolder}\\*.rc",
"-o",
"${workspaceFolder}\\resources.res"
]
then *g++.exe*
"args": [
"${workspaceFolder}\\*.cpp",
"${workspaceFolder}\\*.res",
"-o",
"${workspaceFolder}\\a.exe",
"-fdiagnostics-color=always",
"-Wall",
"-Wextra",
"-pedantic-errors",
"-O2",
"-s",
"-static",
"-mwindows",
"-lkernel32",
"-luser32",
"-lgdi32",
"-lgdiplus",
"-lcomctl32"
]
But I think, g++ compiling is slow, not windres.exe. Unfortunately, there
is no way to check right now. The fact that winlibs is slow I noticed a
month ago.
Le mar. 23 mai 2023 20:49, Brecht Sanders ***@***.***> a
écrit :
… Just a question: what exactly is slow?
- Compiling a single source (C and/or C++)?
- Linking?
- Invoking many commands to compile and link?
—
Reply to this email directly, view it on GitHub
<#152 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A56USXFPFZKRBGMXG64FFETXHUBFBANCNFSM6AAAAAAYL47MEA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
I also feel it's mostly g++ being slow. The build without the flags mentioned earlier is ready (only MSVCRT build for now): Can you try if that makes any difference in speed for you? |
|
I failed to do what you asked.
I got an error while compiling with
[winlibs-x86_64-mcf-seh-gcc-13.1.0-mingw-w64msvcrt-11.0.0-r2] toolchain:
g++.exe: fatal error: cannot execute ...x86_64-w64-mingw32/bin/as.exe
At the same time, I was able to compare the project building times of the
other two ucrt compilers:
10 s -> mingw-w64-ucrt-x86_64-gcc from MSYS2
30 s -> winlibs-x86_64-mcf-seh-gcc-13.1.0-mingw-w64ucrt-11.0.0-r1
Le jeu. 25 mai 2023 11:27, Brecht Sanders ***@***.***> a
écrit :
… I also feel it's mostly g++ being slow.
In the past there were issues with precompiled headers, maybe that's
related.
The build without the flags mentioned earlier is ready (only MSVCRT build
for now):
https://github.com/brechtsanders/winlibs_mingw/releases/tag/13.1.0-11.0.0-msvcrt-r2
Can you try if that makes any difference in speed for you?
—
Reply to this email directly, view it on GitHub
<#152 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A56USXCQDFVWPFDW7MZIIALXH4QZBANCNFSM6AAAAAAYL47MEA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
I'm stress testing this latest release now and as.exe works find. Your error may indicate there is something in That may even be the cause of your issues. When building with winlibs can you try to add |
|
Hi, There is a problem with this release, there are several void EXEs (all bytes are 0): mingw\bin\windmc.exe And all the files in mingw64\x86_64-w64-mingw32\bin. winlibs-x86_64-mcf-seh-gcc-13.1.0-mingw-w64msvcrt-11.0.0-r2.7z
|
|
You are right, there is an issue with the 64-bit toolchain in release https://github.com/brechtsanders/winlibs_mingw/releases/13.1.0-11.0.0-msvcrt-r2/ Quite possibly my antivirus ate some files, but I need to investigate. |
|
Since the slowness is with g++ in particular I will try to build with libbacktrace hasn't released an actual release version, so using it may have been a bad idea. |
|
Ok, please try this release: https://github.com/brechtsanders/winlibs_mingw/releases/tag/13.1.0-11.0.0-msvcrt-r3 |
|
I confirm that the error is gone, but compilation is still slow.
30 sec : winlibs gcc-13.1.0-mingw-w64msvcrt-11.0.0-r3
30 sec : winlibs gcc-13.1.0-mingw-w64ucrt-11.0.0-r3
10 sec : msys2 mingw-w64-ucrt-x86_64-gcc
Le sam. 27 mai 2023 15:25, Brecht Sanders ***@***.***> a écrit :
…
Ok, please try this release: https://github.com/brechtsanders/winlibs_mingw/releases/tag/13.1.0-11.0.0-msvcrt-r3
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.[image]Message ID: ***@***.***>
|
¿Are GCC and Binutils binaries from winlibs being built without optimization flags at all? According to https://github.com/msys2/MSYS2-packages/blob/master/pacman/makepkg_mingw.conf#L32, mingw packages from msys2 are built with some optimization flags passed to both
|
|
Can you try one of the following builds which I made with those optimization flags? |
I have done some compile time tests with both 32-bit and 64-bit builds of winlibs-x86_64-posix-seh-gcc-13.1.0-mingw-w64msvcrt-11.0.0-r1winlibs-x86_64-posix-seh-gcc-13.1.0-mingw-w64msvcrt-11.0.0-r4bwinlibs-i686-posix-dwarf-gcc-13.1.0-mingw-w64msvcrt-11.0.0-r1winlibs-i686-posix-dwarf-gcc-13.1.0-mingw-w64msvcrt-11.0.0-r4bIn both 32-bit and 64-bit tests, compilation times are ~3x faster when using the optimized GCC binaries. According to the release notes, only GCC was built with optimization flags. I would expect some additional speed gains once Binutils gets built with optimization flags as both assembler ( As a side note, you should use for any future builds the linker flag |
|
What exactly is the benefit of the Are your measured speeds better/same/worse than MSYS2's gcc? |
The Useful to avoid situations such as the Binutils binaries from both
Here is the compile time test done with the 64-bit msvcrt version of MSYS2's gcc (GCC 13.1.0 - Binutils 2.40 - Mingw-w64 11.0.0) mingw-w64-x86_64-gccLooks like that MSYS2's GCC compile speed is similar to WinLibs' optimized GCC build ( |
|
Okay, the latest builds (my computer has been busy tonight) include linker flag
Does it do what you expect it to do now? |
I have tested both 32-bit and 64-bit msvcrt builds but gcc and binutils binaries still come with their PE file header date/time stamp set to non-zero (as shown in the The weird thing is that all other linker flags passed to
--
-- |
|
About the compilation speed issue, I have done some more tests by compiling ccache 4.7.4 (2 make jobs, no redis support, tests disabled). Compilation speeds are practically the same in both WinLibs' 64-bit |
|
About About ccache: what's the difference with ccache 4.8.1 that I included? |
I tested GCC by building xz-utils (which - like GCC and Binutils - uses autoconf as its buildsystem) with the compiler and linker flags shown at Looks like that this bug lies in GCC/Binutils buildsystem as it is way more complex (e.g. the main configure script launches secondary configure scripts and so on) than the one present in xz-utils which has only one configure script. Either GCC or Binutils build logs can help here.
There is no need to remove hiredis support. I opted to omit hiredis (as it is an optional dependency unlike libzstd) as well as the testing stuff from the compilation speed test in order to maintain the number of files to compile as low as possible. |
|
I'm not convinced the CFLAGS/CXXFLAGS/LDFLAGS from building gcc are intended to specify it's default build flags. What would be a good way to tell gcc to always use specific compiler and/or linker flags, independent of build system? Could |
|
I'd set/export CFLAGS/CXXFLAGS/LDFLAGS as environment variables. Or, if you're using CMake, I'd try setting "set(CMAKE_C_FLAGS_RELEASE "...")", etc, after the project command in "CMakeLists.txt".
|
|
I build thousands of projects from source, that would be a lot of work. What I really want to know if we can tell gcc to use certain flags by default, so they don't need to be specified every time. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am using the VS code editor with C++ extension.
I have tested the following g++ compilers:
i compiled the same code, the winlibs version compiled almost twice as slow
Why such difference?
The text was updated successfully, but these errors were encountered: