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.
№ | Пользователь | Рейтинг |
---|---|---|
1 | tourist | 4009 |
2 | jiangly | 3823 |
3 | Benq | 3738 |
4 | Radewoosh | 3633 |
5 | jqdai0815 | 3620 |
6 | orzdevinwang | 3529 |
7 | ecnerwala | 3446 |
8 | Um_nik | 3396 |
9 | ksun48 | 3390 |
10 | gamegame | 3386 |
Страны | Города | Организации | Всё → |
№ | Пользователь | Вклад |
---|---|---|
1 | cry | 167 |
2 | Um_nik | 163 |
3 | maomao90 | 162 |
3 | atcoder_official | 162 |
5 | adamant | 159 |
6 | -is-this-fft- | 158 |
7 | awoo | 157 |
8 | TheScrasse | 154 |
9 | Dominater069 | 153 |
9 | nor | 153 |
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