<cfbolz>
tldr: between 3.9 and 3.12 cpython made a change so that now the GIL gets released at a lot fewer places, which makes many code patterns look more atomic. they did this to fix some bug, and to speed up benchmarks (maybe). those code patterns break on pypy and will also break on cpy-nogil
<arigo_>
that blog post does not lead me to put any trust in the no-GIL python. some small example just crashes on it
<cfbolz>
arigo_: I'm not even interested in nogil, just annoyed that cpython randomly removed a lot of gil checks
<arigo_>
shrug and copy the removal of checks? it should not be hard
<cfbolz>
I suppose, yes
<cfbolz>
there's zero docs about any of this, obviously
<arigo_>
of course
<arigo_>
"request_id = self._next_id;
<arigo_>
self._next_id += 1" is atomic in some version of CPython, sometime between 3.9 and 3.13, someone close to the dev group guesses it's from 3.10.
<arigo_>
not exactly the level of detail you need to actually make use of that "feature"
<cfbolz>
yeah, I even gave stefan the PR that changed it before he published
<arigo_>
would be a cool exercice for the reader to figure out if we can write a very-long-running or infinite piece of code which doesn't call CHECK_EVAL_BREAKER now
<cfbolz>
arigo_: completely unrelated, but I really enjoyed this talk and I think you might like it too, an minimal visual programming thing that feels like 2d cellular automata: https://www.youtube.com/watch?v=cBYudbaqHAk&t=6701s (link with timestamp, it's ~30 min long)
<arigo_>
e.g. is CHECK_EVAL_BREAKER called on function returns with an exception? if not, you have an obvious example
<cfbolz>
want me to file a cpy bug? or are you doing it?
<arigo_>
I'll leave it to you (thanks)
<arigo_>
(reminds me of Windows 11, which came with my new laptop: it is stable, but they "enhanced" various things like the basic notepad, replacing them with pieces of software that are a bit buggy)
<cfbolz>
the second call really needs to be in the except block. if you put it afterwards it's "fine"
<arigo_>
uh? ok
<arigo_>
indeed, unsure why
<cfbolz>
who knows
<cfbolz>
Ah, maybe it's fixed in the repo already
<arigo_>
probably means it's more complicated to come up with an example
<cfbolz>
arigo_: yeah, my with (async) with or something
<cfbolz>
Maybe
<arigo_>
cfbolz: the 2d cellular automata talk is great
<cfbolz>
the ui takes a bit of getting used to
<cfbolz>
arigo_: I've spent all morning building stuff like "Langton's ant" in it
<arigo_>
:-)
<cfbolz>
arigo_: which one was the ulta-long running one you simulated very far?
<arigo_>
you can't do the game of life or anything that requires global time steps, I guess
<cfbolz>
arigo_: yeah, I was wondering the same, but didn't come up with a way
<arigo_>
uh, it was a simple variant like three cell colors instead of two
<cfbolz>
arigo_: right! (all three color variants are isomorphic anyway, I think?)
<arigo_>
yes, the "RLR" ant
<cfbolz>
ok
<cfbolz>
it's still unknown whether that ever goes into a regular pattern
<arigo_>
yes
<arigo_>
I would guess the "RLR" and the "LRR" ants are different
<arigo_>
and the "LLR" too
<arigo_>
(and now I'm thinking "now I know how to program GPUs, let's try!" and immediately afterwards "uh, but that won't benefit from a GPU")
<cfbolz>
arigo_: yeah, but cellpond would, right?
<arigo_>
yes, 100%
<cfbolz>
I also wonder whether a hashlife approach would help, but probably not due to the nondeterminism
<arigo_>
(might be a bit tricky to program, with the variable cell size, but you'd get huge speedups)
<arigo_>
yes, looks too random to use hashes
<cfbolz>
arigo_: I'm sure somebody figured out how to do octrees on the gpu
<arigo_>
yes
otisolsen70 has joined #pypy
<arigo_>
cfbolz: playing with https://cellpond.cool/, but I haven't figured out how to split cells yet