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.
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.
Wow! Now using python will be more impressive.
Thanks MikeMirzayanov for sharing the good news about the coming support of GCC 11.
Quick test:
Before:
Used: 7190 ms, 3580 KB
With 64 bit:
Used: 467 ms, 2372 KB
Yay!
That's great!
"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
and1574/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
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...
Yay !
I really like that !
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!
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).
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
When will this be available in Polygon?
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:
The same code gets AC with pypy3-32 and python3, and TLE with pypy3-64
Runtime difference is stark: 155 ms (pypy3-32) vs 1000+ ms (pypy3-64)
A slightly rewritten version (same logic) manages to AC using pypy3-64
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.
Same thing happened with me for problem C,:(
AC in PyPy3
TLE in PyPy3-64