57417erlp2GPq9cYqEX's blog

Does any version of GNU C++ deliver lower running times on average?
By 57417erlp2GPq9cYqEX, 3 years ago, In English

The GNU C++ options available on Codeforces are:

  1. GNU G++11 5.1.0

  2. GNU G++14 6.4.0

  3. GNU G++17 7.3.0

  4. GNU G++17 9.2.0 (64 bit, msys 2)

The features in the newer C++ standards don't seem to matter for a competitive programmer but what does matter is whether the solution fits in the time limit. The variation in the running times can be over 50% for the exact same code and there is no option that always beats the others. Basically we have a rock paper scissors scenario.

If you average over say 50 rounds does any option perform better? Has anyone performed this kind of analysis?

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

Comments Comments (5)
| Write comment?
»
3 years ago, # |
  Vote: I like it +7 Vote: I do not like it

The features in newer standards are actually super useful, I'd definitely recommend C++17. I think the 64-bit version typically is faster, especially if you need 64-bit ints as intermediates.

Plus, if you're writing C++ code with "intended" or close-to-intended solutions and use the fast-IO flags, all 4 of these should pass very comfortably.

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

C++14 is faster as I have noticed. C++17(64) gives TLE while C++14 solution passes with 784ms (afaik for some problems)

I wrote a similar blog a couple weeks ago. Loads of downvotes :(

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

    But you provided zero examples both here and in your blog. And this makes it almost worthless. Please provide links to some real examples, which support your claim.

    A 64-bit version may be sometimes somewhat slower if it uses a lot of pointers. Because pointers are twice wider, occupy twice more space in RAM and this may cause more CPU cache misses. But in many other cases the 64-bit version should be faster if it uses a lot of 64-bit calculations.

    Also a buggy solution may sometimes TLE if it happens to enter an infinite loop. And reproducibility of such bugs may be sensitive to various things. Including, but not limited to the platform bit width.

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

      It's funny that this blog says something else : Link

      Also as far as the examples are concerned, here you go!

      AC : Link

      TLE : Link

      This blog has some more solutions with huge time differences.

      (I"m sorry I'm unable to find more, but I'm pretty sure I saw a couple solutions which had the same issue, and then I made a blog about it)

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

        I don't know how I missed your comment earlier. New versions of compilers are usually generating better code on average, but this is not guaranteed. And it's always possible to encounter an oddball example demonstrating a performance regression. This is especially true if the compiler is targeting a wide variety of different processors rather than focusing on a single processor model (via -march=/-mtune= option). People are much more likely to blog about oddball examples, because they are surprised. While getting better performance with a new compiler in many other cases is usually taken for granted.

        Also competitive programming solutions tend to be small and may be dominated by just a single performance critical loop. Even a one cycle penalty because of a single compiler mistake in a short 5-cycle loop would mean a rather big ~20% slowdown. It's much harder to see significant performance variations in larger real world applications.

        → Reply