MikeMirzayanov's blog

PyPy 3-64 Is Released
By MikeMirzayanov, 3 years 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
  • +361
  • Vote: I do not like it

Comments Comments (13)
| Write comment?
»
3 years ago, # |
  Vote: I like it +31 Vote: I do not like it

Wow! Now using python will be more impressive.

→ Reply
»
3 years 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.

→ Reply
»
3 years 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!

→ Reply
»
3 years 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

→ Reply
  • »
    »
    3 years 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...

    → Reply
»
3 years ago, # |
  Vote: I like it +5 Vote: I do not like it

Yay !

I really like that !

→ Reply
»
3 years 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!

→ Reply
»
3 years 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).

→ Reply
»
3 years 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

→ Reply
»
3 years ago, # |
  Vote: I like it 0 Vote: I do not like it

When will this be available in Polygon?

→ Reply
»
3 years ago, # |
  Vote: I like it +4 Vote: I do not like it

Thanks MikeMirzayanov for the update, much appreciated!

I noticed some weird behaviors while using pypy3-64 during the last Codeforces Round #763 (Div. 2):

Problem: A. Robot Cleaner

Issue:

Seems to me more likely a bug rather than performance issue? Would appreciate if someone from the CF team could investigate for the sake of future contests.

→ Reply