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. :(
orz sjc061031, you are a real legend.
。
stop it cnnfls_csy, you are a tzc___________________wk
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.
Something similar happened to me once. Blog
Auto comment: topic has been updated by sjc061031 (previous revision, new revision, compare).
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.
Moving
mp[a[i]]=1
to a separate loop after thecin>>a[i]
loop fixes TLThe issue seems to be independent of reading values from maps: if we fill one in the same loop as
cin>>a[i]
and later fill another, but use vectors for the actual solution, the issue persistsAdding any junk key to either of the two maps anywhere before the loop answering queries fixes TL
Clearing any of the two maps anywhere before the loop answering queries (but after filling it) fixes TL
Adding any junk key to
pm
before doing anything and immediately clearing it doesn't help, same when adding and clearing right after fillingmp
but before fillingpm
, but adding before fillingmp
and clearing only after that, but before fillingpm
, does fix TLThis 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
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.
possible integer overflows in (L+R)/2 and rt[ll-1]
I think not, the code passes (time >1.5s) with asserts checking for 0..2e5 range
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
I would also like to point out MrDindows's comments, because he had particularly great discoveries:
https://codeforces.net/blog/entry/99038?#comment-877977
https://codeforces.net/blog/entry/99038?#comment-878005
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