MikeMirzayanov's blog

Welcome GNU G++23 14.2 (64 bit, msys2)
By MikeMirzayanov, history, 4 months ago, In English

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!

  • Vote: I like it
  • +1505
  • Vote: I do not like it

»
4 months ago, # |
  Vote: I like it 0 Vote: I do not like it

Cool

→ Reply
»
4 months ago, # |
  Vote: I like it +80 Vote: I do not like it

clang diag when back

→ Reply
»
4 months ago, # |
  Vote: I like it 0 Vote: I do not like it

ha?

→ Reply
»
4 months ago, # |
  Vote: I like it 0 Vote: I do not like it

Finally the wait is over...[Hooray]

→ Reply
»
4 months ago, # |
  Vote: I like it +57 Vote: I do not like it

That's great! Thanks a lot!

→ Reply
»
4 months ago, # |
← Rev. 4   Vote: I like it 0 Vote: I do not like it

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

→ Reply
»
4 months ago, # |
  Vote: I like it +21 Vote: I do not like it

Cant use print :(

→ Reply
  • »
    »
    4 months ago, # ^ |
      Vote: I like it +2 Vote: I do not like it

    You can refer to this.

    → Reply
  • »
    »
    4 months ago, # ^ |
    ← Rev. 2   Vote: I like it -7 Vote: I do not like it

    Try this?

    #include <cstdio>
#include <format>

#define println(...) puts(std::format(__VA_ARGS__).c_str())

int main()
{
    println("Hello {} {}", "World", "!");
    println("Hello {:.2f}", 3.1415);
}

    And this should work in C++20.

    → Reply
  • »
    »
    4 months ago, # ^ |
      Vote: I like it +17 Vote: I do not like it

    It is fixed now. Please, try again.

    → Reply
»
4 months ago, # |
  Vote: I like it +62 Vote: I do not like it

Savior-of-Cross bro can finally rest after asking from last 5 months.

→ Reply
»
4 months ago, # |
  Vote: I like it +1 Vote: I do not like it

Oh finally!, it is amazing, thanks a lot!!!

→ Reply
»
4 months ago, # |
  Vote: I like it +3 Vote: I do not like it

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

→ Reply
  • »
    »
    4 months ago, # ^ |
      Vote: I like it +5 Vote: I do not like it

    Isn't std::format a C++20 feature?

    → Reply
    • »
      »
      »
      4 months ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      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.

      → Reply
»
4 months ago, # |
← Rev. 2   Vote: I like it +33 Vote: I do not like it

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.

→ Reply
  • »
    »
    4 months ago, # ^ |
    ← Rev. 2   Vote: I like it +4 Vote: I do not like it

    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)})$$$ ]

    → Reply
  • »
    »
    4 months ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    Screenshot-2024-08-23-02190234

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

    → Reply
    • »
      »
      »
      4 months ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      Please, check C++23 (GCC 14-64, msys2).

      → Reply
      • »
        »
        »
        »
        4 months ago, # ^ |
        ← Rev. 3   Vote: I like it 0 Vote: I do not like it

        yes i checked and it executed the same solution 3.3x slower than C++20 (14-64)

        → Reply
        • »
          »
          »
          »
          »
          4 months ago, # ^ |
            Vote: I like it +16 Vote: I do not like it

          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.

          → Reply
          • »
            »
            »
            »
            »
            »
            4 months ago, # ^ |
            ← Rev. 2   Vote: I like it +19 Vote: I do not like it

            Screenshot-2024-08-24-004810234

            Lesgo C++23 (GCC 14-64, msys2) is pretty fast. Thank you for adding this Mike!!!

            → Reply
  • »
    »
    4 months ago, # ^ |
      Vote: I like it +3 Vote: I do not like it

    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.

    > g++ -Wall -Wextra -Wconversion -static -DONLINE_JUDGE -Wl,--stack=268435456 -O2 -std=c++23 -g -msse code.cpp
...
In file included from C:/Programs/gcc14-64-winlibs/include/c++/14.2.0/string:43,
                 from C:/Programs/gcc14-64-winlibs/include/c++/14.2.0/bitset:52,
                 from C:/Programs/gcc14-64-winlibs/include/c++/14.2.0/x86_64-w64-mingw32/bits/stdc++.h:52,
                 from code.cpp:5:
C:/Programs/gcc14-64-winlibs/include/c++/14.2.0/bits/allocator.h: In destructor 'constexpr std::_Vector_base<int, std::allocator<int> >::_Vector_impl::~_Vector_impl()':
C:/Programs/gcc14-64-winlibs/include/c++/14.2.0/bits/allocator.h:182:7: error: inlining failed in call to 'always_inline' 'constexpr std::allocator< <template-parameter-1-1> >::~allocator() noexcept [with _Tp = int]': target specific option mismatch
  182 |       ~allocator() _GLIBCXX_NOTHROW { }
      |       ^
In file included from C:/Programs/gcc14-64-winlibs/include/c++/14.2.0/vector:66,
                 from C:/Programs/gcc14-64-winlibs/include/c++/14.2.0/functional:64,
                 from C:/Programs/gcc14-64-winlibs/include/c++/14.2.0/x86_64-w64-mingw32/bits/stdc++.h:53:
C:/Programs/gcc14-64-winlibs/include/c++/14.2.0/bits/stl_vector.h:132:14: note: called from here
  132 |       struct _Vector_impl
      |              ^~~~~~~~~~~~
    → Reply
    • »
      »
      »
      4 months ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      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.

      → Reply
  • »
    »
    4 months ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    Please, check C++23 (GCC 14-64, msys2).

    → Reply
»
4 months ago, # |
  Vote: I like it +74 Vote: I do not like it

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:

std::println("The meaning of the {} is {}", "universe" 42); // prints "The meaning of the universe is 42"

"Oh, nice printing, cool" you might think, but it gets better:

std::vector<std::pair<int, std::string>> vec = { {0, "hii"}, {1, "arul"} };
std::print("{}", vec); // prints [(0, "hii"), (1, "arul")]
// or not, they are not implemented yet :p
  • It is faster than std::cout or printf (so maybe fast io hack won't be as used)

Also additional cool things are std::flat_set and std::flat_map that are basically(very roughly speaking) more cache-friendly counterparts of std::set and std::map. Will it be better than std::set and std::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

→ Reply
  • »
    »
    4 months ago, # ^ |
      Vote: I like it +6 Vote: I do not like it

    It is faster than std::cout or printf (so maybe fast io hack won't be as used)

    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.

    → Reply
    • »
      »
      »
      4 months ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      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. But fmt::print is faster than my regular way of printing out stuff, so I can keep hoping

      → Reply
  • »
    »
    4 months ago, # ^ |
      Vote: I like it +46 Vote: I do not like it

    flat_map and flat_set are essentially sorted lists, so they have linear insertion time. They're not replacements for map or set.

    → Reply
    • »
      »
      »
      4 months ago, # ^ |
        Vote: I like it +15 Vote: I do not like it

      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!

      → Reply
»
4 months ago, # |
  Vote: I like it +1 Vote: I do not like it

Amazing! No more cout (=

Thank you very much for the effort put into making c++23 available!

→ Reply
»
4 months ago, # |
  Vote: I like it 0 Vote: I do not like it

Thanks a lot!!!!!

→ Reply
»
4 months ago, # |
  Vote: I like it +7 Vote: I do not like it

genuine question: why are we naming it G++23, not C++23?

→ Reply
  • »
    »
    4 months ago, # ^ |
      Vote: I like it +35 Vote: I do not like it

    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.

    → Reply
    • »
      »
      »
      4 months ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      So does the MSC++ (MSVisualC++), which has disappeared since the MSVCRT event.

      → Reply
  • »
    »
    4 months ago, # ^ |
      Vote: I like it -11 Vote: I do not like it

    G++23 is GNU version of c++ compiler which supports C++23, C++23 is the C++ standard published in 2023.

    → Reply
»
4 months ago, # |
  Vote: I like it 0 Vote: I do not like it

Unexpected news. But thanks!

→ Reply
»
4 months ago, # |
← Rev. 2   Vote: I like it 0 Vote: I do not like it

Screenshot-2024-08-23-02190234

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

→ Reply
»
4 months ago, # |
  Vote: I like it +3 Vote: I do not like it

is there any plan on update on GCC? C11 5.10 is quite outdated imo

→ Reply
»
4 months ago, # |
← Rev. 3   Vote: I like it +9 Vote: I do not like it

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

→ Reply
»
4 months ago, # |
  Vote: I like it +73 Vote: I do not like it

Thanks

→ Reply
»
4 months ago, # |
  Vote: I like it -11 Vote: I do not like it

Cool update,but hope MikeMirzayanov can notice this about C[loud]F[are] we concerned about.

→ Reply
»
4 months ago, # |
  Vote: I like it 0 Vote: I do not like it

Finally, it happened.

→ Reply
»
4 months ago, # |
  Vote: I like it 0 Vote: I do not like it

auto!

→ Reply
»
4 months ago, # |
  Vote: I like it 0 Vote: I do not like it

when zig? when nim?

→ Reply
»
4 months ago, # |
  Vote: I like it +69 Vote: I do not like it

Please upgrade to 14.3 when it releases, dynamic_bitset is fixed in that version.

→ Reply
»
4 months ago, # |
  Vote: I like it 0 Vote: I do not like it

Thrilled to see G++23 now supported on Codeforces! Ready to leverage the latest C++ features. <3

→ Reply
»
4 months ago, # |
  Vote: I like it 0 Vote: I do not like it

COOOOOL! Does c++23 have constant optimization for stl or pbds?

→ Reply
»
4 months ago, # |
  Vote: I like it 0 Vote: I do not like it

Thats great but how can i find the new features of c++23?

→ Reply
»
4 months ago, # |
  Vote: I like it 0 Vote: I do not like it

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:

#include <print>
#include <string>
#include <vector>

int main()
{
	std::string val = "hello";
	std::print("{}", val);
}
→ Reply
  • »
    »
    4 months ago, # ^ |
      Vote: I like it +6 Vote: I do not like it

    Please, check C++23 (GCC 14-64, msys2).

    → Reply
    • »
      »
      »
      4 months ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      Yes, problems are solved now! Thanks.

      → Reply
    • »
      »
      »
      4 months ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      Well, there exist another problem. It is about #pragma. The following code gets compilcation error.

      #pragma GCC optimize("-Ofast,fast-math,-inline")
#pragma GCC target("avx,avx2,sse,sse2,sse3,sse4")
#include <string>
#include <iostream>
#include <vector>
#include <print>
int main()
{
    std::string res = "hello";
    std::println("{}", res);
}

      When deleting the first two lines, it is ok. Maybe the problem is about the optimize, but in fact if I use cout instead of print, it gets correct too.

      → Reply
      • »
        »
        »
        »
        4 months ago, # ^ |
          Vote: I like it +11 Vote: I do not like it

        Adding '-march=native' also solve the compilation error, at least on my computer.

        → Reply
        • »
          »
          »
          »
          »
          4 months ago, # ^ |
            Vote: I like it +5 Vote: I do not like it

          Do you mean #pragma GCC optimize("-Ofast,fast-math,-inline,-march=native")? It does not work on custom test.

          → Reply
»
4 months ago, # |
  Vote: I like it +6 Vote: I do not like it

Cool LOL

→ Reply
»
4 months ago, # |
  Vote: I like it +15 Vote: I do not like it

After 40 years, c++ finally has print() function

→ Reply
»
4 months ago, # |
← Rev. 4   Vote: I like it +17 Vote: I do not like it

It seems slow, and not able to use std::print and std::println for now

UPD1: Thank to mike that std::print and std::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 in C++23 (GCC 14-64, msys2). It might have stricter boundary detection when using C++23 (GCC 14-64, msys2).

→ Reply
  • »
    »
    4 months ago, # ^ |
    ← Rev. 2   Vote: I like it +25 Vote: I do not like it

    I fixed the print issue, but performance is still poor in some cases performance is fixed too.

    → Reply
»
4 months ago, # |
  Vote: I like it 0 Vote: I do not like it

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:

g++ -std=c++23 -Wall -Wextra -Wconversion -static -DONLINE_JUDGE -Xlinker --stack=268435456 -O2 .\program.cpp

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 by

.\a

Or, 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 }

→ Reply
  • »
    »
    4 months ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    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"

    → Reply
»
4 months ago, # |
  Vote: I like it 0 Vote: I do not like it

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.

→ Reply
  • »
    »
    4 months ago, # ^ |
      Vote: I like it +3 Vote: I do not like it

    I installed via pbox as suggested and in my case it is fine:

    C:\Programs\gcc14-64-winlibs\bin>gcc --version
gcc (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders, r1) 14.2.0
Copyright (C) 2024 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.
    → Reply
  • »
    »
    4 months ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    Restart cmd session to reload environment variables. Also check your PATH variable for another gcc before this.

    → Reply
»
4 months ago, # |
← Rev. 2   Vote: I like it -8 Vote: I do not like it

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

→ Reply
»
4 months ago, # |
← Rev. 2   Vote: I like it 0 Vote: I do not like it

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.

→ Reply
»
4 months ago, # |
  Vote: I like it +49 Vote: I do not like it

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!

→ Reply
  • »
    »
    4 months ago, # ^ |
      Vote: I like it +16 Vote: I do not like it

    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 that mingw-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".

    → Reply
    • »
      »
      »
      4 months ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      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.

      → Reply
      • »
        »
        »
        »
        4 months ago, # ^ |
          Vote: I like it +16 Vote: I do not like it

        I'm sorry I forgot to test this earlier. Indeed, %Lf doesn't work with long double, nor does std::int and std::cout. At least the long double type works fine for computations and usage; it is a functioning extended floating-point type. When outputting, converting it to double seems to work just fine.

        However, when I tested other environments that use libc++, such as Ubuntu 24.04 with libc++-dev installed via apt install libc++-dev, no issues were inputting/outputting long double types when specifying -stdlib=libc++ for clang. So it's a mingw-libc++-specific issue I guess.

        → Reply
»
4 months ago, # |
  Vote: I like it +8 Vote: I do not like it

I wonder if the slow down bug still exists.

vector<vector<int>> TLE(7,vector<int>(40000));
→ Reply
»
4 months ago, # |
  Vote: I like it -73 Vote: I do not like it

ok, now please remove older versions of c++ as it creates confusion among participants

→ Reply
»
4 months ago, # |
← Rev. 2   Vote: I like it +18 Vote: I do not like it

Why is my code slower in the C++23 compilation environment than in C++20? QAQ

→ Reply
  • »
    »
    4 months ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    I passed with the same code in C++23.

    → Reply
»
4 months ago, # |
  Vote: I like it 0 Vote: I do not like it

How to get it in my local environment? How can I get the PBOX? Thanks.

→ Reply
»
4 months ago, # |
  Vote: I like it 0 Vote: I do not like it

Thanks a lot finally

→ Reply
»
3 months ago, # |
  Vote: I like it 0 Vote: I do not like it

Where can we find the implementation of it?

→ Reply
»
2 months ago, # |
← Rev. 2   Vote: I like it 0 Vote: I do not like 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 case
  • I/O is slow, which doesn't seem to be the case from test 29, also tried massive puts in custom test, the time is similar
  • bad inline decision for those small functions, tried adding inline and it slightly reduced to 2499 ms 284734309 still a large gap

Also tried to reproduce locally with gcc 13.2 and 14.2 from docker and random data, but didn't observe differences.

→ Reply