M4357R0's blog

Why does my solution get TLE on g++17 but passes on g++23?
By M4357R0, history, 8 months ago, In English

Hey everyone,

I ran into something weird. I have a solution that

TLE on g++17 : 367366805

Accepted on g++23 : 367366517

Honestly, it feels a bit unfair that the exact same solution works on one compiler and not the other. I only found out about this by luck, I could’ve wasted so much time trying to come up with another solution, while mine is already correct.

Has anyone else experienced this? Any idea why the compiler version makes such a difference?

  • Vote: I like it
  • -1
  • Vote: I do not like it

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

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

→ Reply
»
8 months ago, hide # |
← Rev. 2  
Vote: I like it +1 Vote: I do not like it

It's caused by std::unordered_map/set hacks, but the problem's test cases doesn't include edge cases affecting g++23 since the compiler was added later than the problem.

→ Reply
  • »
    »
    8 months ago, hide # ^ |
     
    Vote: I like it 0 Vote: I do not like it

    the only thing that seems to make it work in g++17 was to fix the map size to 5000

    but i'm still not sure why

    → Reply
    • »
      »
      »
      8 months ago, hide # ^ |
      ← Rev. 3  
      Vote: I like it 0 Vote: I do not like it

      As I know, unordered_map's hash function depends on the size of the map. (A prime number or a power of two) If there is a hack targeting the normal hash function, it won't affect you when you fix the map size. That's what I think. You can check custom hashing if you're interested.

      → Reply
»
8 months ago, hide # |
 
Vote: I like it 0 Vote: I do not like it

well done

→ Reply