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

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

My submission 184727292 in contest got Time Limit Exceeded on test 30.

When I submit this solution in C++14 184832244 , it passes in 592ms.

Then I change the map into vector 184832165 , and it passes in 296ms.

So it seems that the map runs too slow, and in test 30, $$$N=23355$$$, which means there are only $$$7e4$$$ operations of map, but strangely it costs more than $$$1s$$$.

Map should run in exactly $$$O(nlogn)$$$ , so what could possibly be the problem?

UPD: Thanks to beep_boop and Perpetually_Purple , a similar problem occurred in this blog.

The solution 184859925 is to read all the elements first then add them to the map.

I still have no idea why map behaves so strange in this case. :(

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

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

orz sjc061031, you are a real legend.

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

perhaps the 64-bit is acting against you?

I don't know how exactly that would come into play in your code but my submission with c++17 and submission with c++17 64-bit show the same results you presented.

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

Something similar happened to me once. Blog

»
23 месяца назад, # |
  Проголосовать: нравится -10 Проголосовать: не нравится

Auto comment: topic has been updated by sjc061031 (previous revision, new revision, compare).

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

I tried to figure out what's going on but it's just absurd. I guess either there's an UB in your code (which I can't find) or there's a bug in GCC versions corresponding to C++17-64 and C++20-64 on codeforces.

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

    This issue seems to be dependent on the size of the set/map, which seems to match with your conclusions. I don't wanna get into this rabbit hole again but this might be something you wanna test

    • »
      »
      »
      23 месяца назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится

      Yes, it seems so. Although not exactly: the last point contradicts it, inserting a unique key and clearing I kept the eventual size as it was, but TL disappeared.

      I did some more testing with weird results. g++-9.4.0 and g++-11.1.0 I have installed locally on Linux don't have this problem, so it might be specific to Windows GCC ports used by codeforces. The issue manifests on stringstream too. With stringstream I tried pre-filling the set with several values before starting reading, inserting several values between consecutive stream operations or reading several values between insertions. Sometimes the slowdown is present, sometimes not, with no clear pattern except the last case.

      Code
  • »
    »
    23 месяца назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    possible integer overflows in (L+R)/2 and rt[ll-1]

    • »
      »
      »
      23 месяца назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится

      I think not, the code passes (time >1.5s) with asserts checking for 0..2e5 range

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

Oh wow, it's kind of funny that the same thing from my blog happened again.

After not finding convincing reason to why this happens, I thought this issue would be too specific to matter. But since it actually happened in contest it may be interesting for MikeMirzayanov or someone else on headquarters to take a look (specially at my blog, since mee and a bunch of people tested a lot of different things).

It's also interesting that the issue is not tied only to set, but also to map, which I did not test when it initially happened (even though it makes a lot of sense considering they both use an rb tree).

This behaviour is a really weird interaction which I hope can eventually reach closure if the right person tackles the issue. We could also change the distribution of the 64 bit compiler and never worry about that again, tho :P

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

Interestingly, the exact same thing happened to me in the same test case during the contest (compiler: GNU C++20 (64))! 184797545

And the same code passes in GNU C++17.184805970