Rating changes for the last round are temporarily rolled back. They will be returned soon. ×

MikeMirzayanov's blog

By MikeMirzayanov, 5 days ago, In English

Hey! I'm happy to report that Pypy3 is supported. Please test that it works as expected. Thanks!

P.S. I remember about GCC 11, it is in the progress. See you soon.

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

»
5 days ago, # |
  Vote: I like it +31 Vote: I do not like it

Wow! Now using python will be more impressive.

»
5 days ago, # |
  Vote: I like it +15 Vote: I do not like it

Thanks MikeMirzayanov for sharing the good news about the coming support of GCC 11.

»
5 days ago, # |
  Vote: I like it +113 Vote: I do not like it

Quick test:

MOD = 10 ** 9 + 7
N = 10 ** 4
total = 0
for x in range(10 ** 9 - N, 10 ** 9):
    for y in range(10 ** 9 - N, 10 ** 9):
        total += x * y % MOD
        total %= MOD
print(total)

Before: Used: 7190 ms, 3580 KB

With 64 bit: Used: 467 ms, 2372 KB

Yay!

»
5 days ago, # |
  Vote: I like it +21 Vote: I do not like it

"You cannot [up]vote twice. You have already [up]voted for this topic before."

Looks good on the issue of sorting gratuitously large ints as seen in 1539/C - Stable Groups and 1574/C - Slay the Dragon.

I/O looks about the same or better but I really should avoid using 1543/D1 - RPD and Rap Sheet (Easy Version) for anything, really (interactive, adaptive-of-adaptive grader which only guarantees that there'll be a lot of I/O, but not a consistent amount). Side thought: any chance on increasing the input limit of custom invocation to match the more ridiculous problems out there?

Untested/todo/esoterica: find good parameters for thread-parameter-stack-space kludge for the sake of extremely deep recursion...? Been a while since I tried, but I remember it being passable on python but memory-splosive on pypy.

Haven't run into as far as I can tell: tuples bad, somehow?

Thanks for all you do... not sure what the endgame is re: libraries, but I'll hold off on the 'numba precompiler when?' talk for now :P

  • »
    »
    4 days ago, # ^ |
      Vote: I like it +4 Vote: I do not like it

    Memory usage is different, but that's expected. Unfortunately, I suspect the class of problems I typically solve in-contest flies below running into such issues...? fwiw my horrid upsolve/AC on 1574D - Strongest Build got nudged into MLE by switching to pypy3-64.

    Fingers crossed for consistently thorough (max) pretests, I guess...

»
4 days ago, # |
  Vote: I like it +12 Vote: I do not like it

Yaayy! Is pajenegod's Fast IO template or any of the other fast IO stuff required now?

  • »
    »
    4 days ago, # ^ |
      Vote: I like it +4 Vote: I do not like it

    short answer: still gotta do io stuff, pretty much anything is better than vanilla input() though...

    slightly longer answer: 1543D was an extreme case that highlighted a weakness in the popular BytesIO copypasta at the time. One desperate workaround was to revert to pypy2, but pajenegod was able to get non-pathological results out of skipping the middlemen and using os.read/write.

    For non-interactive problems, an optimistic approach is to minimize the significance of whatever you use by reading all input at once and then working through it however you like (iterator, generator, or popping tail items off a reversed split list etc.).

    so my comment on IO above should read more like 'no unexpected pathological results found, looks about the same (known pathological results are still pathological)' give or take a placebo effect due to the unreliable test I happened to fixate on...

»
4 days ago, # |
  Vote: I like it +5 Vote: I do not like it

Yay !

I really like that !

»
4 days ago, # |
  Vote: I like it -6 Vote: I do not like it

That is great! Although I haven't learned Python yet, I heard that PyPy 3 will bring a better experience to Python programmers. Happy for them!

Also, looking forward to the release of GCC 11!

»
4 days ago, # |
  Vote: I like it +18 Vote: I do not like it

This is great! Seems like solutions dealing with int-64s run a lot faster! Now problems like 1466E - Apollo versus Pan can be solved in PyPy3 without splitting a bigger number into 2 integers (int-32).

»
4 days ago, # |
  Vote: I like it +10 Vote: I do not like it

Found out about this by (pleasant) surprise. Same Python code for 710E DP problem was TLE on both Python 3 & PyPy 3 but AC on PyPy3-64