Open RoyalXXX opened 1 year ago
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:
-Wl,--dynamicbase -Wl,--high-entropy-va -Wl,--nxcompat -Wl,--tsaware
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 https://github.com/brechtsanders/winlibs_mingw/issues/152#issuecomment-1559966668, 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. 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?
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 https://github.com/brechtsanders/winlibs_mingw/issues/152#issuecomment-1562581607, 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 PATH
that makes it load dependencies from the wrong place.
That may even be the cause of your issues.
When building with winlibs can you try to add mingw64/bin
from within the folder where you extracted winlibs are added at the beginning of PATH
?
Hi,
There is a problem with this release, there are several void EXEs (all bytes are 0):
mingw\bin\windmc.exe mingw\bin\windres.exe
And all the files in _mingw64\x8664-w64-mingw32\bin.
_winlibs-x8664-mcf-seh-gcc-13.1.0-mingw-w64msvcrt-11.0.0-r2.7z
I'm stress testing this latest release now and as.exe works find.
Your error may indicate there is something in
PATH
that makes it load dependencies from the wrong place.That may even be the cause of your issues.
When building with winlibs can you try to add
mingw64/bin
from within the folder where you extracted winlibs are added at the beginning ofPATH
?
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 --disable-libstdcxx-backtrace
instead of --enable-libstdcxx-backtrace
.
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: @.***>
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
@brechtsanders
¿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 CFLAGS
and CXXFLAGS
:
-march=nocona -msahf -mtune=generic -O2
(MINGW64 case)
-march=pentium4 -mtune=generic -O2
(MINGW32 case)
Can you try one of the following builds which I made with those optimization flags?
Can you try one of the following builds which I made with those optimization flags?
* https://github.com/brechtsanders/winlibs_mingw/releases/tag/13.1.0-11.0.0-ucrt-r4b * https://github.com/brechtsanders/winlibs_mingw/releases/tag/13.1.0-11.0.0-msvcrt-r4b
I have done some compile time tests with both 32-bit and 64-bit builds of
13.1.0-11.0.0-msvcrt-r4b
release and13.1.0posix-16.0.3-11.0.0-msvcrt-r1
release. Here are the results:
In 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
) and linker (ld
) come from Binutils.
As a side note, you should use for any future builds the linker flag -Wl,--no-insert-timestamp
in order to make binaries more deterministic. I tell that as Binutils binaries from both 13.1.0-11.0.0-msvcrt-r4b
and 13.1.0posix-16.0.3-11.0.0-msvcrt-r1
releases have the same file size, differing only in their PE timestamp.
What exactly is the benefit of the -Wl,--no-insert-timestamp
flag?
Are your measured speeds better/same/worse than MSYS2's gcc?
What exactly is the benefit of the
-Wl,--no-insert-timestamp
flag?
The -Wl,--no-insert-timestamp
linker flag is useful to get reproducible builds on Windows.
Useful to avoid situations such as the Binutils binaries from both 13.1.0-11.0.0-msvcrt-r4b
and 13.1.0posix-16.0.3-11.0.0-msvcrt-r1
releases differing only in their PE file header date/time stamp.
Are your measured speeds better/same/worse than MSYS2's gcc?
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)
Looks like that MSYS2's GCC compile speed is similar to WinLibs' optimized GCC build (13.1.0-11.0.0-msvcrt-r4b
release), at least for the 64-bit msvcrt case (winlibs-x86_64-posix-seh-gcc-13.1.0-mingw-w64msvcrt-11.0.0-r4b
)
Okay, the latest builds (my computer has been busy tonight) include linker flag -Wl,--no-insert-timestamp
both when building GCC and binutils:
Does it do what you expect it to do now?
Okay, the latest builds (my computer has been busy tonight) include linker flag
-Wl,--no-insert-timestamp
both when building GCC and binutils:* https://github.com/brechtsanders/winlibs_mingw/releases/tag/13.1.0-16.0.5-11.0.0-msvcrt-r5 * https://github.com/brechtsanders/winlibs_mingw/releases/tag/13.1.0-16.0.5-11.0.0-ucrt-r5
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 Time/Date
field from objdump.exe -p gcc.exe
output) despite gcc -v
output showing -Wl,--no-insert-timestamp
linker flag being passed to LDFLAGS
.
The weird thing is that all other linker flags passed to LDFLAGS
are being applied as expected (see the DllCharacteristics
field from objdump.exe -p gcc.exe
output).
gcc.exe -v
output:--
objdump.exe -p gcc.exe
output:--
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 13.1.0-16.0.5-11.0.0-msvcrt-r5
and Msys2's mingw-w64-x86_64-gcc
cases (~190 seconds), way faster in comparision with the unoptimized gcc/binutils binaries (WinLibs' 64-bit 13.1.0posix-16.0.3-11.0.0-msvcrt-r1
case) where the same compilation takes ~480 seconds.
About -Wl,--no-insert-timestamp
, if it doesn't work than maybe that's a GCC bug?
About ccache: what's the difference with ccache 4.8.1 that I included? I did build it with hiredis support. Should I remove that?
About
-Wl,--no-insert-timestamp
, if it doesn't work than maybe that's a GCC bug?
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 gcc -v
output being passed to the configure script. Both the shared library (liblzma-5.dll) and the xz.exe utility were generated with their PE file header date/time stamp set to zero as expected.
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.
About ccache: what's the difference with ccache 4.8.1 that I included? I did build it with hiredis support. Should I remove that?
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 .spec
files be the answer? Or is there another way?
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'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
.spec
files be the answer? Or is there another way?
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.
I am using the VS code editor with C++ extension. I have tested the following g++ compilers: 1) g++ from GCC + MinGW-w64 (UCRT version) downloaded from winlibs 2) g++ from UCRT64 downloaded from MSYS2 (package mingw-w64-ucrt-x86_64-gcc) i compiled the same code, the winlibs version compiled almost twice as slow Why such difference?