cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
<simpson>
I gather that there's a dichotomy of some sort, with (int, float) on one side, and (str, dict, object) on the other. But, how and what and why? Which side has e.g. set?
<cfbolz>
but imo pypy is also quite good at objecty code
<cfbolz>
and dicts and lists too, if they are type stable
<cfbolz>
anyway, we will see. I can believe that people would like a cpython that is consistently 2x faster more than pypy, which is anything between 0.5x and 50x faster
<simpson>
Hm. Okay. I accept this, but I want to know how it generalizes. Is this because of immutability? Pointer-chasing? How can language designers put more of their builtin types on the numericy side?
<cfbolz>
simpson: you can't ;-)
<cfbolz>
yes, pointer chasing is certainly an aspect
gef has quit [Ping timeout: 240 seconds]
<simpson>
Is it variable sizes? Like, are str and int really that different?
<simpson>
Sorry, I'm trying really hard to understand. I feel like I'm missing something blazingly obvious.
<cfbolz>
simpson: yeah! eg the primitive operations on str are still function calls, whereas on ints its cpu ops
<simpson>
Aha. So even if language designers try to change which types are composite types, we're still all forced to obey the CPU's idea of what is composite and what is primitive.
<cfbolz>
yes
<cfbolz>
anyway, I don't think this is super clearly delineated
<cfbolz>
feels more like a hunch
gef has joined #pypy
<simpson>
Yeah, but it's a hunch that would explain why the numericy side is so small. It does suggest that language designers could work harder to get composite types like set[int] to be lowered to efficient code.
<antocuni>
I think that one big reason of pypy speed is the very aggressive inlining/specialization/constant folding which happen automatically thanks to tracing
tsaka__ has quit [Ping timeout: 246 seconds]
<antocuni>
complex pieces of software tends to build abstractions over abstractions, and dynamic languages such as python adds layers of layers of more abstractions (e.g., "everything is an object/is boxed", and "everything has a __dict__", etc.)
<antocuni>
and the pypy JIT is often able to kill a large part of this overhead
gef has quit [Ping timeout: 265 seconds]
<antocuni>
by contrast, method-based JITs (which are the majority of other JITs for Python which I see/I saw around) cannot optimize too much across layers of abstraction
<antocuni>
but they can do a better job at numericy code which uses one or more big loop without too many calls, because they play essentially at the same level of a static compiler