sjc061031's blog

By sjc061031, history, 16 months ago, In English

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

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

»
16 months ago, # |
  Vote: I like it +43 Vote: I do not like it

orz sjc061031, you are a real legend.

»
16 months ago, # |
  Vote: I like it +10 Vote: I do not like it

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.

»
16 months ago, # |
Rev. 2   Vote: I like it +10 Vote: I do not like it

Something similar happened to me once. Blog

»
16 months ago, # |
  Vote: I like it -10 Vote: I do not like it

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

»
16 months ago, # |
  Vote: I like it +9 Vote: I do not like it

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
  • »
    »
    16 months ago, # ^ |
    Rev. 2   Vote: I like it +10 Vote: I do not like it

    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

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

      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
  • »
    »
    16 months ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

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

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

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

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

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

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

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