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

### MikeMirzayanov's blog

By MikeMirzayanov, 5 days ago,

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.

• +344

 » 5 days ago, # |   +31 Wow! Now using python will be more impressive.
 » 5 days ago, # |   +15 Thanks MikeMirzayanov for sharing the good news about the coming support of GCC 11.
 » 5 days ago, # |   +113 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 KBWith 64 bit: Used: 467 ms, 2372 KBYay!
•  » » 4 days ago, # ^ |   +1 That's great!
 » 5 days ago, # |   +21 "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, # ^ |   +4 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, # |   +12 Yaayy! Is pajenegod's Fast IO template or any of the other fast IO stuff required now?
•  » » 4 days ago, # ^ |   +4 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, # |   +5 Yay !I really like that !
 » 4 days ago, # |   -6 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, # |   +18 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, # |   +10 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