Блог пользователя wsc2008qwq

Автор wsc2008qwq, история, 8 месяцев назад, По-английски

Gone crazy while solving problem 1874E - Jellyfish and Hack. I optimized my solution with best effort, and its execution time decreased from 20s at first to about 6s now (locally), but it got TLE on codeforces (time limit 8s).

When I was wondering how small the constant could be to pass the problem, I realized that I submitted with C++17(32), and I wanted to switch the language into C++17(64), but where is it???

What's more annoying is that almost all accepted submissions to this problem used C++17(64), mostly with an execution time longer than half of the time limit, so I think this problem can hardly be passed without C++17(64).

When can we have our C++17(64) back?

  • Проголосовать: нравится
  • +132
  • Проголосовать: не нравится

»
8 месяцев назад, # |
  Проголосовать: нравится +18 Проголосовать: не нравится

I would also like to add that many people wait for recent problems' ratings to be updated

»
8 месяцев назад, # |
  Проголосовать: нравится -26 Проголосовать: не нравится
  • »
    »
    8 месяцев назад, # ^ |
      Проголосовать: нравится +1 Проголосовать: не нравится

    But the standard code given by the editorial can't get accepted. https://mirror.codeforces.com/contest/1874/submission/251112344

    This solution used fast interpolating algorithm based on FFT so of course it's much more quicker. What I focus on is whether the intended solution can pass.

    Anyway, thanks for your reply and explanation.

    • »
      »
      »
      8 месяцев назад, # ^ |
      Rev. 2   Проголосовать: нравится +8 Проголосовать: не нравится

      LL operations in the 32-bit environment are much slower than expected because there is no x64 CPU instruction nor registers to use. In that case, the 32-bit compilers could only simulate the x64 code by taking the data apart (high 32 bits and low 32 bits), calculating those parts individually (without efficient instructions either), and putting it back together.

      If the code depends heavily on LL type, it could highly TLE as those operations aforementioned are too slow. Also, this TLE on the editorial reflects that the proposer of this question may not have thought about other programming languages (especially those non-compile-based). They were too focused on the details of efficient algorithms and ignored the constant-level effects of the environment/different languages.

      Fun fact: LL type in 32-bit compilers may be a typedef of __int64.

»
8 месяцев назад, # |
Rev. 4   Проголосовать: нравится -9 Проголосовать: не нравится

We need 64-bit C++

»
8 месяцев назад, # |
  Проголосовать: нравится +64 Проголосовать: не нравится

Why can the comments on this blog be so unrelated to the topic?

I think Codeforces should at least fix it before hosting any rated contest, or avoid problems that use 64-bit integer calculations, otherwise it may be unfair.

Of course, I can understand that this kind of bug must be very difficult to fix. So the above is just a beautiful wish of mine and some friends.

»
8 месяцев назад, # |
  Проголосовать: нравится +11 Проголосовать: не нравится

Yes, we need C++17/20(64) back

»
8 месяцев назад, # |
Rev. 3   Проголосовать: нравится +64 Проголосовать: не нравится

I finally got AC with your code! 251136206

It took 30 submissions to go from 20185ms to 7956ms, optimizations used:

»
8 месяцев назад, # |
  Проголосовать: нравится +3 Проголосовать: не нравится

Make the 64-bit version greater again!