UPDATE: Some time ago, there was news here that we supported C++23 by installing GCC 14 from the Winlibs project. It turned out that with this method of supporting C++23, some compatibility issues lead to significant performance drops in certain submissions. So, I tried another distribution for GCC 14: the MSYS2 project. It seems that this problem does not occur with it, and now there are no unexpected performance drops. Let's test this C++23 support option together!
Hello, Codeforces!
Together with Vladosiya, we've added support for the 64-bit g++14 C++23. You can find it under the name GNU G++23 14.2 (64 bit, msys2)
.
If you're using Windows, you can easily install it via our minimalistic package manager, PBOX, by running the command pbox install gcc14-64-msys2
.
Thanks to the MSYS2 project! We used the distribution from the official package manager.
Your solutions will be compiled using the following command line: g++ -Wall -Wextra -Wconversion -static -DONLINE_JUDGE -Wl,--stack=268435456 -O2 -std=c++23 program.cpp -lstdc++exp
.
Now you can start using C++23 features!
Please note that support for GNU G++23 14.2 (64 bit, msys2)
is currently experimental. We invite you to join in the testing and experimentation process. Share your thoughts and experiences in the comments!
Cool
clang diag when back
ha?
Finally the wait is over...[Hooray]
That's great! Thanks a lot!
I'd just tried to use new compiler in this submission [submission:277680488], got TLE
but previously absolutely same solution [submission:277680737] (1 char difference to be able to submit it again) gave me AC
MikeMirzayanov please pay attention on it
yeah and i get tle
I'm a big fan
Me too
i like you :)<3
What about me ?!
I'm a BIG fan.
and you and all who's rate up me don't sad my friend:)
Cant use print :(
You can refer to this.
Try this?
And this should work in C++20.
It is fixed now. Please, try again.
Savior-of-Cross bro can finally rest after asking from last 5 months.
Oh finally!, it is amazing, thanks a lot!!!
Thank you.
std::format will be very useful to make many output statements cleaner for those not using printf style format strings.
Before:
std::cout << a << " + " << b << " = " << a+b << '\n';
After:
std::cout << std::format("{} + {} = {}\n", a, b, a+b);
Isn't
std::format
a C++20 feature?Yes, I thought that it didn't work on Codeforces C++20 but I just tried it and it works already. So instead I should have mentioned std::print and std::println which are simply shortcuts for outputting std::format. My bad.
Quick benchmarking got really weird: an $$$\mathcal{O}(n \log^2{n})$$$ code on 1991C - Absolute Zero used like double runtime in C++23 compared to C++20:
Was it a bug, or was it intended that way...?
Extra: trying to use
set
in that approach yielded 1500ms for C++20 (TL=2s), and instant TLE for C++23.Extra #2: The runtime difference is seven-fold for $$$\mathcal{O}(n \log{n})$$$ ? [more precisely, $$$\mathcal{O}(n \log{\left( \max{a_i} - \min{a_i} \right)})$$$ ]
Same code but different compiler versions, Solutions: C++20 and C++23 . The submission by C++20 was noticeably faster.
I used unordered_map, i though C++23 will execute it faster but ... :)
Please, check
C++23 (GCC 14-64, msys2)
.yes i checked and it executed the same solution 3.3x slower than
C++20 (14-64)
Please read my update. I completely switched the GCC-14 distribution to another one, and I haven't seen any indication that you've tried it yet.
Lesgo
C++23 (GCC 14-64, msys2)
is pretty fast. Thank you for adding this Mike!!!I compared generated code with previous version of the compiler (gcc13-64-winlibs) and it looks like new version uses very conservative set of CPU instructions. Trying to force SSE/AVX resulted in compilation failure inside of one of the STL headers.
IIRC for Codeforces GCC13-64-winlibs already experienced failures when forcing SSE/AVX to vectors, so it's not something of novelty for GCC14 in this case.
Please, check
C++23 (GCC 14-64, msys2)
.Looks much better for now, thank you for your hard work.
Benchmarking on 1991C - Absolute Zero again:
As of now, C++23 is not in the best shape, but when GCC will finally implement it, it will go hard.
Mainly for competitive programming, a C++23 gold nugget is
std::print
.Finally clunky output with
std::cout
goes away in favor of elegant:"Oh, nice printing, cool" you might think, but it gets better:
std::cout
orprintf
(so maybe fast io hack won't be as used)Also additional cool things are
std::flat_set
andstd::flat_map
that are basically(very roughly speaking) more cache-friendly counterparts ofstd::set
andstd::map
. Will it be better thanstd::set
andstd::map
for competitive programming? Time will tell, right now they are not even implemented in GCC.Also there's
deducing this
which makes recursive lambdas not as weird (i am a certified lambda glazer, which means that deducing this is epic and cool)Summarizing, C++23 adds great features for competitive programming. In theory. In reality, GCC 14.2 doesn't implement most features that folks on codeforces would find interesting
As someone that has played around a ton with fastIO stuff in the past, I really doubt that this claim is true. Nothing low-level has fundamentally changed. The bottleneck is still the same.
By "fast IO hack" I meant
ios_base::bla_bla_bla(false)
stuff almost everyone has. Didn't mean to say that it will be better than monstrous IO templates some folks use. Butfmt::print
is faster than my regular way of printing out stuff, so I can keep hopingflat_map and flat_set are essentially sorted lists, so they have linear insertion time. They're not replacements for map or set.
oh damn, I am sorry for misinformation then :(
when i was reading some site, it said "slower insert and delete" and I thought "Oh, so worse constant, right? Right?". Again, my apologies!
Amazing! No more cout (=
Thank you very much for the effort put into making c++23 available!
Thanks a lot!!!!!
genuine question: why are we naming it G++23, not C++23?
G++ specifies that it is the gnu compiler for c++. It's always been named like that for codeforces. It's similar to how theres python and pypy to choose from, even though they're both python. I remember you could also choose clang so it makes sense for them to differentiate between the two. Idk why clang isnt a compiler option anymore though.
So does the MSC++ (MSVisualC++), which has disappeared since the MSVCRT event.
G++23 is GNU version of c++ compiler which supports C++23, C++23 is the C++ standard published in 2023.
Unexpected news. But thanks!
I encountered a significant difference in execution time between two submissions that used the same code but different compiler versions, Solutions: C++20 and C++23 . The submission by C++20 was noticeably faster.
Why C++23 is slower in my case???
is there any plan on update on GCC? C11 5.10 is quite outdated imo
Wow! Is
std::print
available now?Also, is codeforces the first onlinejudge which have GCC14?
Update: Emm, seems there are still some problems with
std::print
. :(Update 2: Now the problems with
std::print
is fixed, thanks Mike. :)No, https://judge.yosupo.jp have GCC 14 for a few months now.
Thanks
Cool update,but hope MikeMirzayanov can notice this about C[loud]F[are] we concerned about.
Finally, it happened.
auto!
when zig? when nim?
Please upgrade to 14.3 when it releases, dynamic_bitset is fixed in that version.
Thrilled to see G++23 now supported on Codeforces! Ready to leverage the latest C++ features. <3
COOOOOL! Does c++23 have constant optimization for
stl
orpbds
?Thats great but how can i find the new features of c++23?
Is the support for C++23 features incomplete in this compiler version? For example, is print still not usable. The following code will result in compilation errors:
Please, check
C++23 (GCC 14-64, msys2)
.Yes, problems are solved now! Thanks.
Well, there exist another problem. It is about
#pragma
. The following code gets compilcation error.When deleting the first two lines, it is ok. Maybe the problem is about the optimize, but in fact if I use
cout
instead ofprint
, it gets correct too.Adding '-march=native' also solve the compilation error, at least on my computer.
Do you mean
#pragma GCC optimize("-Ofast,fast-math,-inline,-march=native")
? It does not work on custom test.Cool LOL
After 40 years, c++ finally has print() function
It seems slow, and not able to use
std::print
andstd::println
for nowUPD1: Thank to mike that
std::print
andstd::println
are available.UPD2: Sometime it's faster or slower, but within an acceptable range.
It's more likely to cause Runtime error than other g++ compiler for now. In
C++20 (GCC 13-64)
some code with boundary issues got Accept, but Runtime error inC++23 (GCC 14-64, msys2)
. It might have stricter boundary detection when usingC++23 (GCC 14-64, msys2)
.I fixed the print issue,
but performance is still poor in some casesperformance is fixed too.If you are getting errors like parsing errors or missing arguments, it is because the powershell is recognizing ',' as some special charachter.
Try this instead in that case:
to compile the file, and since any name is not given in, the exe should be names to
a.exe
or something similar by default, and you can run that file byOr, if you are an only-IDE person
All along, your code for compiling and running altogether will be
cd "PATH_TO_YOUR_WORKING_DIRECTORY" ; if ($$$?) { g++ -std=c++23 -Wall -Wextra -Wconversion -static -DONLINE_JUDGE -Xlinker --stack=268435456 -O2 .\program.cpp } ; if ($$$?) { .\a }
Just quote
-Wl,--stack=268435456
. In vscode + code runner, it is like:"cpp": "cd $dir && g++ --std=c++23 -Wall -Wextra -Wconversion -static \"-Wl,--stack=268435456\" -O2 $fileName -o $fileNameWithoutExt && $dir$fileNameWithoutExt"
after using that command it still shows that gcc version is 13.2.0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C:\ProgramData\pbox\temp\65617\gcc14-64-winlibs$14.2.0-1>rd /S /Q gcc14-64-winlibs INFO [2024-08-23 14:52:28,631] Set environment variable 'GCC_14_64_WINLIBS_HOME=C:\Programs\gcc14-64-winlibs'. INFO [2024-08-23 14:52:28,631] Starting 'setx.exe GCC_14_64_WINLIBS_HOME C:\Programs\gcc14-64-winlibs /M'. INFO [2024-08-23 14:52:33,509] Successfully set environment variable 'GCC_14_64_WINLIBS_HOME=C:\Programs\gcc14-64-winlibs'. INFO [2024-08-23 14:52:40,241] Package 'gcc14-64-winlibs$14.2.0-1' installed to the 'C:\Programs\gcc14-64-winlibs'.
C:\Windows\System32>gcc --version gcc (MinGW-W64 x86_64-ucrt-mcf-seh, built by Brecht Sanders, r3) 13.2.0 Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I installed via pbox as suggested and in my case it is fine:
Restart cmd session to reload environment variables. Also check your PATH variable for another gcc before this.
G++23 may cause some magical RE.
Submission using G++23: RE on #1 277773823
Submission using G++20: Accepted 277773900
UPD: Solved, I reversed the order
You calling rotate with middle greater than last?
https://en.cppreference.com/w/cpp/algorithm/rotate
template< class ForwardIt > ForwardIt rotate( ForwardIt first, ForwardIt middle, ForwardIt last );
Your middle is greater than last
This release also includes
Clang/LLD/LLDB 18.1.8
, which might not meet the performance downgrade. Would we have a chance to test the clang compiler?Also, it is easy to make the Clang use existing MSVC toolkits, by passing
--target=x86_64-pc-windows-msvc
and it would search and use MSSTL.Some time ago, there was news here that we supported C++23 by installing GCC 14 from the Winlibs project. It turned out that with this method of supporting C++23, some compatibility issues lead to significant performance drops in certain submissions. So, I tried another distribution for GCC 14: the MSYS2 project. It seems that this problem does not occur with it, and now there are no unexpected performance drops. Let's test this C++23 support option together!
Since you've chosen MSYS2 as the distribution for installing GCC, why not try installing
pacman -S mingw-w64-ucrt-x86_64-clang
while you're at it? The clang installed this way will default to using the libstdc++ library thatmingw-w64-ucrt-x86_64-gcc
uses and benefiting from LLVM's optimization capabilities, it might offer better performance, especially in terms of time consumption.However, the
mingw-w64-ucrt-x86_64-toolchain
does not support sanitisers. In my local experiments, I found that if you want to restore "clang diagnostics" without upgrading MS Visual C++ 2022, you can use another branch under MSYS2:mingw-w64-clang-x86_64-toolchain
. This clang will utilize the libc++ library and allow you to use-fsanitize=address,undefined
for diagnostic hints. The only downside seems to be the lack of the precompiled header file "bits/stdc++.h".Thanks.
mingw-w64-clang-x86_64-toolchain
looks good. Another issue: %Lf doesn't work with long double for scanf/printf (libc++ specifics?). But maybe we can live without it.I'm sorry I forgot to test this earlier. Indeed,
%Lf
doesn't work withlong double
, nor doesstd::int
andstd::cout
. At least thelong double
type works fine for computations and usage; it is a functioning extended floating-point type. When outputting, converting it todouble
seems to work just fine.However, when I tested other environments that use libc++, such as Ubuntu 24.04 with
libc++-dev
installed viaapt install libc++-dev
, no issues were inputting/outputtinglong double
types when specifying-stdlib=libc++
for clang. So it's a mingw-libc++-specific issue I guess.I wonder if the slow down bug still exists.
After my test, the bug doesn't exist. :)
ok, now please remove older versions of c++ as it creates confusion among participants
Nah
Why is my code slower in the C++23 compilation environment than in C++20? QAQ
I passed with the same code in C++23.
How to get it in my local environment? How can I get the PBOX? Thanks.
Thanks a lot finally
Where can we find the implementation of it?
For some reason, I am still seeing a submission gets much slower when submitted as C++23, it is mainly doing operations on
std::set
:C++23 (GCC 14-64, msys2) 2733 ms 284726189
C++20 (GCC 13-64). 983 ms 284731239
Hunches:
std::set
is slow, but I tried some small tests in custom test and didn't notice substantial differences, maybe need a specific size or operation sequence to trigger this if it's the caseputs
in custom test, the time is similarinline
and it slightly reduced to 2499 ms 284734309 still a large gapAlso tried to reproduce locally with gcc 13.2 and 14.2 from docker and random data, but didn't observe differences.