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
<cfbolz>
But imo all these approaches don't solve the real problems of making dynamic languages fast
ronan has quit [Remote host closed the connection]
ronan has joined #pypy
<Dejan>
sure
<Dejan>
I can't even argue about these things as I am not competent enough, but I found the article interesting
<Dejan>
I can't even use GCC JIT legally as it is GPL licensed
<Dejan>
so from that perspective, it is a good thing to have some alternatives
<Dejan>
Also, I kinda disagree about digression that people should not invest in developing compilers, that GCC 8s 16% speedup is miniscule compared to GCC 3.1
<Dejan>
I think 16% is a lot
<Dejan>
because EVERYTHING is compiled with GCC and nowadays with Clang
<Dejan>
so EVERYTHING benefits from those microoptimizations
ambv has joined #pypy
<tos9>
cfbolz: which problems are those
<cfbolz>
tos9: late binding, boxing of primitives, high allocation rates, complicated semantics, branchy control flow
<Alex_Gaynor>
large number of hash table lookups
jcea has joined #pypy
vstinner has left #pypy [#pypy]
jcea has quit [Remote host closed the connection]
jcea has joined #pypy
adamholmberg has joined #pypy
dddddd has joined #pypy
Smigwell has joined #pypy
jvesely has quit [Quit: jvesely]
lritter_ has joined #pypy
lritter_ has quit [Remote host closed the connection]
lritter has joined #pypy
<antocuni>
ouch, the latest version of pip broke manylinux2010 wheels on pypy :(
<Dejan>
You will see my comment there too from 1-2h ago
<antocuni>
I can't find your comment
<antocuni>
but it seems a different kind of issue
<Dejan>
20.0.1 is broken, no doubt about it
<antocuni>
yeah, but I wonder if it's broken in many ways
<Dejan>
i went there because I got a weird import error
<Dejan>
trying to import a non-existent internal module
<Dejan>
so i immediately downgraded to 19.3 ;)
<antocuni>
yeah, that's what everyone is talking about. But here I have a different problem, which is that it doesn't recognize my wheel as valid, even if it is
<Dejan>
your problem seems like a different bug, indeed
<phlebas>
does pypy reimplement the reference cycle breaking from cpython for cpyext, or do you do something else?
<antocuni>
I fear we don't do anything at the moment
<antocuni>
there is the cpyext-gc-cycle branch, but I'm not sure what is its status
<phlebas>
aha, that's why i wasn't finding code related to that on tip :)
<antocuni>
the author is Stefan Beyer, I think he was working on this for his (master?) thesis, but I can't remember his IRC nickname right now :)
<phlebas>
btw, we finally have hpy running the ultrajson example you have running at the same performance as pypy - but warmup is much worse ;)
<antocuni>
wow, amazing
<antocuni>
are you compiling it with a custom hpy.h, or loading the universal .so?
<phlebas>
we're compiling with the same hpy.h, but we cannot load the universal so, because we need the bitcode. the `.so` we produce should work on PyPy, but not vice versa
<antocuni>
the llvm bitcode, I suppose?
<phlebas>
(the way we compile it is to tell llvm to embed the bitcode with the normal so - and when we run on graal it we just ignore the native parts)
<phlebas>
yes, llvm bitcode
<cfbolz>
antocuni: the are never running untrusted assembly
<cfbolz>
they
<antocuni>
ah, I missed this part
<antocuni>
so you convert llvm's bitcode to assembly on loading?
<phlebas>
no, we interpret it and JIT :)
<antocuni>
wow
<antocuni>
method jit?
<phlebas>
yes
<phlebas>
it takes a looong time to warm up
<cfbolz>
we need more oooooooooooooooooooooooooooooooooooooos
<antocuni>
:)
<phlebas>
its nice for small-ish C functions, because we can inline those
<phlebas>
for stuff like numpy, it doesn't really help, there's so much C code that is just too much to inline into the python caller
<antocuni>
can you also inline callbacks? I.e., calling a small C function which calls a small python callback?
<phlebas>
yes
<antocuni>
nice
<phlebas>
some of the cpyext api is implemented by calling back up into python, that's fairly fast
<phlebas>
s/the/our
<antocuni>
is the bitcode interpreter/JIT a generic part of GraalVM, or did you write it specifically for graalpython?
<cfbolz>
antocuni: it's generic
<cfbolz>
called 'sulong'
<antocuni>
we should do the same :)
infinite has quit [Read error: Connection reset by peer]
<phlebas>
antocuni: that would be interesting :) i'm not convinced anymore that llvm bitcode is the best abstraction for this, though. it's just not meant for an interpreter to consume. but implementing all of C (and the other stuff llvm supports) still seems even worse.
xcm has quit [Remote host closed the connection]
<cfbolz>
antocuni: supporting cython via some bytecode, or the new epython sounds more reasonable
xcm has joined #pypy
<phlebas>
i'm not sure i get the appeal of epython as a generic tool. as a replacement for cython, yes, but I read the proposal as a replacement for the c api
<phlebas>
isn't that just re-iterating cffi?
<antocuni>
cfbolz: yes, cython sounds like a good starting point for having the "correct" level of abstraction
<cfbolz>
phlebas: I don't get it completely either
<antocuni>
I think that the best summary for EPython is "a better cython"
<cfbolz>
it sounds like "just cython, with better technology"
<cfbolz>
but then why not refactor cython
<antocuni>
I think it's a possibility
<cfbolz>
might be that it's harder to find funding for that
<antocuni>
IIUC, EPython is still a "generic" project: they know what is the final goal, they haven't decided yet how to get there
_whitelogger has joined #pypy
oberstet has quit [Remote host closed the connection]
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
mattip has joined #pypy
<mattip>
fwiw, we did discuss the pip change from using pep425.py to packaging.tags in the issue
<mattip>
I guess I should have tried out a pip 20 release candidate before the release
<mattip>
that change was the reason I wanted to push forward with 7.3, especially on windows
<mattip>
the "python tag" changed from pp272 (where "pp2" is pypy 2.7 and "72" is the pypy version) to pp27 for python 2.7
<mattip>
one "solution" is to request that the few pypy packages on pypi and antonio's index release both pip19-compatible and pip20 compatible packages for a whiel
jvesely has quit [Quit: jvesely]
k1nd0f has joined #pypy
jvesely has joined #pypy
jvesely has quit [Quit: jvesely]
<antocuni>
mattip: ah, I didn't realize that the "7" in pp27 and pp272 were different kind of 7s :)
<mattip>
yeah, confusing
<antocuni>
yes, I think it is reasonable to build pip20 wheels
<mattip>
sorry for the mess, I think I only tried reaching out on IRC about the change, not on the mailing list
<antocuni>
not your fault, such things happen
<antocuni>
I was confused because I also tried to build&install a wheel locally, without using my wheels at all
<antocuni>
but probably I built it with pip19 and tried to install with pip20, so I didn't realize that you get different names even when you build
<mattip>
maybe. But maybe there really is an issue?
<antocuni>
what do you mean?
<mattip>
if you use latest pip and latest wheel does building a wheel locally work?
<antocuni>
let me try
<mattip>
thanks
<antocuni>
nope :(
<antocuni>
if I do "pip wheel psutil" with pypy2 7.3.0 and pip 20.1, I get "psutil-5.6.7-pp273-pypy_73-linux_x86_64.whl"
<antocuni>
note the pp273
<mattip>
:(
<mattip>
is the problem with wheel?
<antocuni>
I don't know who decides what is the filename
* antocuni
investigates
* antocuni
also wonders when/why he became one of the pypy guys taking care of packaging, a topic which he hates 🤷♂
<mattip>
heh
<antocuni>
and of course finding the place which decides the filename is a mess