Skip to content
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

Open
DeveloperKev opened this issue Nov 17, 2022 · 21 comments
Open

which version is faster? #125

DeveloperKev opened this issue Nov 17, 2022 · 21 comments

Comments

@DeveloperKev
Copy link

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.

@brechtsanders
Copy link
Owner

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.

@DeveloperKev
Copy link
Author

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?

@DeveloperKev
Copy link
Author

i've tested both before and after the compilation, also changed <bits/stdc++.h> to "bits/stdc++.h".
same as before.

@DeveloperKev
Copy link
Author

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>
      |                        ^

@DeveloperKev
Copy link
Author

@brechtsanders up?

@brechtsanders
Copy link
Owner

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) ?

@DeveloperKev
Copy link
Author

DeveloperKev commented Nov 22, 2022

slower and -Winvalid-pch shows no error only and if only it is executed with the same commands that were used to compile header

@ghost
Copy link

ghost commented Nov 25, 2022

In my experience, the earlier the version, the faster the compile speed. I'm using GCC 7.5.0.

@brechtsanders
Copy link
Owner

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?

@ghost
Copy link

ghost commented Nov 26, 2022

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.

@brechtsanders
Copy link
Owner

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.

@DeveloperKev
Copy link
Author

how do i make use of nasm?
i added the bin folder to path, still cant access.

@ghost
Copy link

ghost commented Nov 27, 2022

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.

@ghost
Copy link

ghost commented Nov 27, 2022

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).

@brechtsanders
Copy link
Owner

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?

@ghost
Copy link

ghost commented Nov 27, 2022

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.

@brechtsanders
Copy link
Owner

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?

@DeveloperKev
Copy link
Author

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.

@brechtsanders
Copy link
Owner

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

@DeveloperKev
Copy link
Author

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>
      |

@brechtsanders
Copy link
Owner

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants