Vladosiya's blog

Codeforces Command Lines (2023-10-06)
By Vladosiya, history, 13 months ago, In English

Hello, Codeforces!

We've compiled a list of command lines that Codeforces uses to compile and run solutions in various languages and compilers.

It is up-to-date as of today (2023-10-06), and we will make efforts to keep it current in the future, but this is not guaranteed.

Language/Tool Bitness Compilation/Build Command Run Command
GNU GCC C11 5.1.0 32 gcc -std=c11 -static -DONLINE_JUDGE -fno-asm -lm -s -Wl,--stack=268435456 -O2 %1 run binary file
GNU G++14 6.4.0 32 g++ -static -DONLINE_JUDGE -Wl,--stack=268435456 -O2 -std=c++14 %1 run binary file
GNU G++17 7.3.0 32 g++ -static -DONLINE_JUDGE -Wl,--stack=268435456 -O2 -std=c++17 %1 run binary file
GNU G++20 11.2.0 (64 bit, winlibs) 64 g++ -Wall -Wextra -Wconversion -static -DONLINE_JUDGE -Wl,--stack=268435456 -O2 -std=c++20 %1 run binary file
GNU G++23 14.2 (64 bit, msys 2) 64 g++ -Wall -Wextra -Wconversion -static -DONLINE_JUDGE -Wl,--stack=268435456 -O2 -std=c++23 program.cpp -lstdc++exp %1 run binary file
Microsoft Visual C++ 2017 32 cl /std:c++17 /W4 /F268435456 /EHsc /O2 /DONLINE_JUDGE %1 run binary file
GNU G++17 9.2.0 (64 bit, msys 2) 64 g++ -static -DONLINE_JUDGE -Wl,--stack=268435456 -O2 -std=c++17 %1 run binary file
C# 8, .NET Core 3.1 64 dotnet.exe build -c:release [+DefineConstants:TRACE;ONLINE_JUDGE] && editbin64.exe /stack:67108864 run binary file
C# 10, .NET SDK 6.0 64 dotnet.exe build -c:release [+DefineConstants:TRACE;ONLINE_JUDGE] && editbin64.exe /stack:67108864 run binary file
C# Mono 6.8 32 mcs /r:System.Numerics.dll -sdk:4.7 -platform:x86 -define:ONLINE_JUDGE -o+ %1 run binary file
D DMD32 v2.105.0 32 dmd -L/STACK:268435456 -version=ONLINE_JUDGE -O -release -noboundscheck -i %1 run binary file
Go 1.22.2 64 go build %1 run binary file
Haskell GHC 8.10.1 32 ghc -XSafe -rtsopts --make -O2 %1 run binary file +RTS -K256m -A8m -RTS
Java 11.0.6 32 javac %1 {JAVA11_32_HOME}\bin\java -XX:+UseSerialGC -XX:TieredStopAtLevel=1 -XX:NewRatio=5 -Xms8M -Xmx{MEMORY_LIMIT_MB}M -Xss64M -DONLINE_JUDGE=true -jar %1
Java 17 64bit 64 javac %1 {JAVA17_64_HOME}\bin\java -XX:+UseSerialGC -XX:TieredStopAtLevel=1 -XX:NewRatio=5 -Xms8M -Xmx{MEMORY_LIMIT_MB}M -Xss64M -DONLINE_JUDGE=true -jar %1
Java 21 64bit 64 javac %1 {JAVA21_64_HOME}\bin\java -XX:+UseSerialGC -XX:TieredStopAtLevel=1 -XX:NewRatio=5 -Xms8M -Xmx{MEMORY_LIMIT_MB}M -Xss64M -DONLINE_JUDGE=true -jar %1
Kotlin 1.7.20 64 kotlinc %1 {JAVA17_64_HOME}\bin\java -XX:NewRatio=5 -Xms8M -Xmx{MEMORY_LIMIT_MB}M -Xss64M -DONLINE_JUDGE=true -jar %1
Kotlin 1.9.21 64 kotlinc %1 {JAVA11_32_HOME}\bin\java -XX:NewRatio=5 -Xms8M -Xmx${MEMORY_LIMIT_MB}M -Xss64M -DONLINE_JUDGE=true -Duser.language=en -Duser.region=US -Duser.variant=US -jar %1
OCaml 4.02.1 32 ocamlopt nums.cmxa str.cmxa -pp camlp4o -unsafe %1 run binary file
Delphi 7 32 dcc32 -Q -$M1048576,67107839 -DONLINE_JUDGE -cc %1 run binary file
Free Pascal 3.2.2 32 fpc -n -O2 -Xs -Sgic -viwn -dONLINE_JUDGE -Cs67107839 -Mdelphi -XS %1 run binary file
PascalABC.NET 3.8.3 32 pabcnetcclear %1 mono %1
Perl 5.20.1 32 perl -c %1 perl %1
PHP 8.1.7 64 php -l %1 php -n -d ONLINE_JUDGE=true -d display_errors=Off -d error_reporting=0 -d memory_limit=1G %1
Python 2.7.18 32 NA python %1
Python 3.8.10 64 NA python %1
PyPy 2.7.13 (7.3.0) 32 NA pypy %1
PyPy 3.6.9 (7.3.0) 32 NA pypy %1
PyPy 3.10 (7.3.15 64bit) 64 NA pypy %1
Ruby 3.2.2 64 ruby -c %1 export RUBY_THREAD_VM_STACK_SIZE=268435456 && ruby %1
Rust 1.75.0 (2021) 64 rustc --edition=2021 -O -C link-args=/STACK:268435456 --cfg ONLINE_JUDGE %1 run binary file
Scala 2.12.8 32 scalac %1 {JAVA8_32_HOME}\bin\java -XX:NewRatio=5 -Xms8M -Xmx{MEMORY_LIMIT_MB}M -Xss64M -DONLINE_JUDGE=true -jar %s
JavaScript V8 4.8.0 32 NA d8 %1
Node.js 15.8.0 64 node -c %1 node %1

Changes

  • 2024-23-08 GNU G++23 14.2 (64 bit, msys 2) added
  • 2024-22-04 PyPy 3.9.10 (7.3.9, 64bit) upgraded to PyPy 3.10 (7.3.15 64bit)
  • 2024-22-04 Go 1.19.5 upgraded to Go 1.22.2
  • 2024-01-16 Kotlin 1.9.21 added
  • 2024-01-16 Kotlin 1.6.10 removed
  • 2024-01-16 Java 1.8.0 removed
  • 2024-01-05 Python 3.12.1 reverted to 3.8.10
  • 2023-12-30 Python 3.8.10 upgraded to 3.12.1
  • 2023-12-30 Rust 1.72.0 upgraded to 1.75.0
  • 2023-11-10: Node.js upgraded to 15.8.0 64-bit
  • 2023-11-10: Free Pascal 3.0.2 upgraded to 3.2.2
  • 2023-10-06: Ruby 3 upgraded to 3.2.2 64-bit, added env. variable RUBY_THREAD_VM_STACK_SIZE=268435456
  • Vote: I like it
  • +316
  • Vote: I do not like it

Comments Comments (48)
| Write comment?
»
13 months ago, # |
  Vote: I like it +36 Vote: I do not like it

Hello, this is very useful, and I think it would be awesome to link to this on https://codeforces.net/help because that is where everyone used to look for this kind of information.

Other than that, I would politely ask for an increase in Ruby's stack size. Since a long time ago, Ruby's stack size has been bounded with the environment variable RUBY_THREAD_VM_STACK_SIZE. The default value is seemingly 1MiB, so using recursion in Ruby is a pain in the arse almost everywhere. By setting this environment variable (i.e. export RUBY_THREAD_VM_STACK_SIZE=268435456) this can be fixed. I hope you could consider this suggestion seriously.

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

Hello. May I ask when will C++20 be supported on Polygon? Sometimes I find out that testers write C++20 code but when added the solution to Polygon, I need to convert some of them manually.

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

    And C++23

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

      I am hoping that this also happens when there is much more support (if not complete) for C++23 by modern compilers — for both Codeforces and Polygon. C++20 was added when there were quite a few features still not implemented by major compilers (like std::format), and as a result, the current C++20 compiler on Codeforces is still stuck on a very old version which doesn't have many useful C++20 features. However, I do appreciate Mike's decision of adding C++20 support to Codeforces very promptly, a lot, since it allowed people to use the latest language features that were implemented at the time.

      I feel like now is a good time to do the following things:

      • Update the C++20 compiler to use the latest GCC version, since the latest version has essentially complete support for things that the Codeforces version is sorely missing. The only things missing from GCC 13.2 seem to be complete support for modules, calendar and timezone (there is partial support for all these things, and the lack of complete support for these should not alter a competitive programmer's experience on Codeforces).
      • Add a preliminary C++23 compiler, which should definitely be updated in the future, since currently compilers lack support for the following useful features (but still have cool functionality that is too good to pass up):
        • deducing this — this will make recursive lambdas and class definitions for pre-written code very easy
        • minor bugfixes
        • better consteval support
        • stacktraces (!)
        • better ranges support (ranges::to, newer kinds of ranges, more places to use ranges in the standard)
        • std::mdspan, flat_map, flat_set — these will make linear algebra and constant optimization (respectively) much easier
        • std::print (!)
        • better std::format

      Note: to enable experimental stacktrace support for the current GCC version, it is recommended to link with the library mentioned in this.

      A very useful link to keep track of which C++ language/library features are present in which compilers is this.

      The link to the latest GCC version (as of now) is here.

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

        In my opinion, the compiler "Microsoft Visual C++ 2022" and "Clang-cl 16" are nice to take the role of "preliminary C++23 compiler", or even, replace the 32-bit compiler "Microsoft Visual C++ 2017".

        The MSC++2022 compiler has implemented the full features of C++20 so early, far away from other compilers. What's more, it has built-in Signed128 and a precompile-header "__msvc_all_public_headers.hpp" just like those GNU compilers did, and of course, bugfixes and performance optimizations. It also supports legacy C++17 mode.

        Furthermore, upgrading MSC++ to the 2022 version will also benefit the compiler Clang-cl, which has the most stable support of C++20 and C++23 (see aforementioned support list). Currently, the clang-cl aka "Clang diagnostics" doesn't support any c++20 headers as the MSC++2017 lacks support for these headers, which makes it bearly usable.

        By the way, the winlibs.com build also has a Mingw64-clang version, packed up with latest stable GCC build (13.2), and it would be great if this clang compiler and the clang-cl compiler are set side-by-side; In that case, one participant can freely choose which STL that clang compiler using:

        • The clang using msSTL (clang-cl) would have the latest C++23 STL and language support. However, aside from VLAs, clang-cl doesn't support extended float types like float128, and other GNU dialects.

        • The clang using libstdc++ (mingw64) would be compatible with codes written for those GNUC++ compilers, and in many cases, would have a better runtime performance.

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

          Thanks for the suggestions! I would agree that having multiple compilers updated to the latest versions would be really cool, especially the ones with all language features.

          However, I believe that there is a fundamental issue in how compilers are managed on Codeforces. A new "rolling release" set of compilers being supported on Codeforces (to be more conservative about preserving verdicts, this set should be separate from the current compilers), auto-updating whenever there is a compiler update, would be the best solution for finding latest language features.

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

          Could you tell me more about signed int128 in Visual C++? As far as I know, they still don't even have non-trivial long double, and no int128 as well.

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

            In Visual C++ 2019 or later versions, you can use the header #include <__msvc_int128.hpp>. This header brings two class types, std::_Signed128 and std::_Unsigned128, which also come with operands like +-*/ and some bitwise operators.

            If you take a peek into this header, you will see the line:

            uint64_t _Word[2];

            and that's how they store an int128 number.

            It seems that there is no built-in conversion function for these class types, so you may have to use _Word[x] to "truncate" half of it.

            This thread from the MS developer community discussed the VC++ support for 128-bit integer type, and after this port, you can add it with any supported C++ standards. Source code of this header.

            About non-trivial floating-types, the C++23 standard header #include <stdfloat> in Visual C++ 2022 says:

            // We don't support any optional extended floating-point types, but we do need to provide an empty `namespace std`.
// We don't need to `export` it for modules, as the other headers will implicitly do so (N4950 [module.interface]/2.1).

            However, according to the standards, these headers and other extended floating-types are supposed to be optional. Oops.

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

        Very well said sir

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

Perl is seriously out of date (the latest stable is v5.38). It is useful for regex-heavy problems, and it's really inconvenient if we want to use modern features (like signatures, etc.). Please consider upgrading Perl.

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

for java 21 , use

javac --release 21 --enable-preview

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

Thank you, this is very useful.

I have one question though, why -O2 instead of -O3? Does -O3 give some kind of unfair advantage to C/C++ folks?

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

    I don't think so because you can add #pragma GCC optimise("O3") to compile with O3.

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

      I believe there's a typo here. It should be #pragma GCC optimize("O3"). Additionally, we can utilize #pragma GCC optimize("Ofast") to achieve even faster performance than with O3.

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

        As far as I know, Ofast might change the behavior of a well-formed program by changing the way the floating point operations are performed, which may result in a different verdict. I believe such option as Ofast should only be added witn an explicit action performed by the author of the submission.

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

Hi, thanks for the list! I'm wondering what's the status of F#? It was available at one time (https://codeforces.net/blog/entry/79), but looking at other old posts (https://codeforces.net/blog/entry/23311), it somehow disappeared. In terms of performance, it can be as fast as C#, so I believe it's more relevant to competitive programming than e.g. PHP and JavaScript.

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

Node.JS is really out-of-date, the latest is 20.8.0 and 21 is releasing soon. Please consider upgrade it, thanks!

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

    We updated the version of Node.js, but unfortunately, we couldn't upgrade to the latest version due to compatibility issues with Windows 7. Therefore, we updated to the latest compatible version.

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

I wonder if it is possible to "open" the process of language updates. Creating API for community to create their own runners (personal), and than have community vote to promote certain runners to "allowed in competition" level.

Docker comes to mind as most universal solution, but really any way to implement and "pack" a runner by community would be ok.

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

Recent changes:

  • 2023-11-10: Node.js upgraded to 15.8.0 64-bit
  • 2023-11-10: Free Pascal 3.0.2 upgraded to 3.2.2
→ Reply
»
11 months ago, # |
  Vote: I like it +3 Vote: I do not like it

Recent changes:

  • 2023-12-30 Python 3.8.10 upgraded to 3.12.1
  • 2023-12-30 Rust 1.72.0 upgraded to 1.75.0
→ Reply
»
11 months ago, # |
  Vote: I like it 0 Vote: I do not like it

Can we ask for updates to some compiler versions?

I want to practice OCaml with CF.

However, the OCaml version extremely outdated (4.02 instead of 5.x) and lacking basic primitives like List.init.

Thanks in advance!

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

C++ 23

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

Hi! Can we get support for Common Lisp as well? There was a blog where a comment explains how to add it (and there is a relevant PR on the GitHub repo too).

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

Recent changes:

  • 2024-01-05 Python 3.12.1 reverted to 3.8.10
→ Reply
  • »
    »
    10 months ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    Is there a reason why for this Vladosiya? This breaks type hints for Python (like writing def func(a: list[int]) which is only valid in 3.9 onward.

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

      It turned out that with 3.12.1 the code may sometimes run 1.5 times slower than with 3.8.10. Most likely, newer standards will be added separately rather than replacing 3.8.10.

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

64-bit C compiler when?

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

Recent changes:

  • 2024-01-16 Kotlin 1.9.21 added
  • 2024-01-16 Kotlin 1.6.10 removed
  • 2024-01-16 Java 1.8.0 removed
→ Reply
  • »
    »
    10 months ago, # ^ |
    ← Rev. 7   Vote: I like it 0 Vote: I do not like it

    Hi, please, do not remove Kotlin 1.6.10.

    You can safely remove Kotlin 1.7 (and keep the previous 1.6 and 1.9) instead, if the decision is simply based on having three language versions are too much. (Previous) Kotlin 1.9 (as it currently stands on codeforces) is a strictly superior version of 1.7.

    It had serious implications about how competitive Kotlin is. It already got hit by TL occasionally, but this change may make it no longer safe to pass intended solutions in general, and I would be forced fluently code both C++ and Kotlin to remain competitive at this level.

    I wrote a whole blog here link, along with simple examples where 1.7/1.9 are slow.

    UPD: If the intention was to replace the old 1.6 by 1.9 using the exact same build method: It seems that 1.9 command is exactly same as the 1.6 command, except that somehow it stayed 64bits even though JAVA11_32 was used? I am just guessing that making sure Kotlin 1.9 runs on 32 bits would be enough to make it faster than the old 1.6.

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

"Pypy3.10" has been released for a while now, and there are lot of useful Python 3.10 features. When are we getting the upgrade?

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

can you update the ocaml compiler?

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

Please consider adding support for Lua language.

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

hi @Vladosiya

Any chance to add J support here? There is one for testing purposes. When having script.ijs one can invoke it like this:

cat input.txt | /Applications/j9.5/bin/jconsole script.ijs

Thanks and cheers, Pawel

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

Could you add scala 3 pls?

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

Recent changes:

  • 2024-22-04 PyPy 3.9.10 (7.3.9, 64bit) upgraded to PyPy 3.10 (7.3.15 64bit)
  • 2024-22-04 Go 1.19.5 upgraded to Go 1.22.2
→ Reply
»
7 months ago, # |
  Vote: I like it 0 Vote: I do not like it

Please consider upgrade to C#12, thanks!

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

Hi! Could you please consider incorporating Lua as an interpreted language? Lua is a combination of flexibility, efficiency, simplicity and portability. It consists of only four files, totaling 374.0 kB, and is really powerful. Here are some interpreter options I would recommend:

LuJIT: https://luajit.org/install.html

Luvit: https://luvit.io/install.html

Lua: https://www.lua.org/download.html

Lua (binaries): https://sourceforge.net/projects/luabinaries/files/5.4.2/Tools%20Executables/

By downloading the binaries, you simply need to navigate to the folder where Lua is installed and run: lua54.exe file.lua (if your VM is windows)

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

Great, Go is updated

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

Can you please add F#?

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

I believe something is wrong with pure C compiler.

I ran the following code using "Custom invocation":

#include <stdio.h>
int main() {
    for (int i = 0; i < 1000000; i++) {
        char ch = (char)('a' + i % 26);
        printf("%c", ch);
//        putchar(ch);
    }
    return 0;
}

It takes 3500 ms on "GNU GCC C11 5.1.0" !

If I replace printf("%c") with putchar, then 0 ms time is reported.

It takes 72 ms on "GNU G++17 7.3.0" with either function (printf/putchar does not matter).

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

Recent changes:

  • 2024-23-08 GNU G++23 14.2 (64 bit, msys 2) added
→ Reply
»
5 weeks ago, # |
  Vote: I like it 0 Vote: I do not like it

please update Rust compiler

→ Reply