cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | "the modern world where network packets and compiler optimizations are effectively hostile"
cloudyplain has quit [Read error: Connection reset by peer]
<kenaan>
cfbolz regalloc-playground baece8cd15d9 /rpython/jit/backend/x86/: adds hints for target registers of jumps as well
<kenaan>
cfbolz regalloc-playground 7a3cd6204340 /rpython/jit/backend/x86/: make allocation decisions in the LEA case a bit more flexible by freeing the argument
<kenaan>
cfbolz regalloc-playground 58247cb00737 /rpython/jit/backend/llsupport/: test and fix for corner case
<kenaan>
cfbolz regalloc-playground 7636f0eb120c /rpython/jit/backend/llsupport/test/test_regalloc.py: this one passes now
cloudyplain has joined #pypy
realitix has joined #pypy
<kenaan>
cfbolz regalloc-playground d4ec0e2656cd /rpython/jit/backend/x86/: fix for duplicate jump args
<cfbolz>
arigato: if you are around: help!
<cfbolz>
my problem is: two comments (and maybe the code) in x86/regalloc.py and llsupport/regalloc.py don't agree
<cfbolz>
specifically, in x86/regalloc.py:800 the comment about gc_level and in llsupport/regalloc.py:605 the comment about save_all_regs
<arigato>
cfbolz: hi, yes
<cfbolz>
in one case, gc_level=2 is supposed to save *all* regs, in the other, save_all_regs=1 is supposed to save all regs
<arigato>
llsupport/regalloc.py is correct
<cfbolz>
I suppose, but then read the logic in def _call in x86
<arigato>
I think that 'gc_level' in x86/ has a different meaning
<cfbolz>
there is a comment that says "we really should save all regs" and then passes in save_all_regs=2 to llsupport
<arigato>
right, but that's a comment about shadowstack, so it should really say "we save all the registers CONTAINING GC REFS for shadowstack and asmgcc for now"
<cfbolz>
no
<cfbolz>
it's also about non-shadowstack now
<cfbolz>
(which we maybe don't care about anyway?)
<arigato>
i.e. asmgcc
<arigato>
yes, we don't really care about that any more
<arigato>
I don't really understand the comment about distinguishing call sites
<cfbolz>
:-)
<cfbolz>
me neither
<arigato>
ah yes
<cfbolz>
arigato: anyway, it's still super confusing, because the only thing the code *does* with gc_level is complicated logic what to pass as save_all_regs
<cfbolz>
imo they should just use the same meaning
<arigato>
(it says that the asmgcc-specific metadata is dumb for jit-generated code, in a way that we can't easily say which call sites have pointers in which registers)
<arigato>
cfbolz: yes, agreed
<cfbolz>
ok, I might try to clean that up
<arigato>
thanks! maybe really create three constants in llsupport
<arigato>
but well, note also:
<cfbolz>
Yes, constants sounds good
<cfbolz>
Yes?
<arigato>
right now x86.py passes different values to save_all_regs in the two times it does call before_call()
<cfbolz>
Yes, I noticed
<cfbolz>
But it doesn't matter, because xrm stores no refs
<arigato>
ah right, passing 0 or 1 is the same for xrm.before_call()
<arigato>
no
<arigato>
0 or 2?
<cfbolz>
Yes
<arigato>
ok
<cfbolz>
See how it's confusing
<cfbolz>
;-)
<arigato>
yup :-)
vkirilichev has joined #pypy
exarkun has quit [Ping timeout: 260 seconds]
exarkun has joined #pypy
cstratak has joined #pypy
marr has joined #pypy
<krono>
hey
<krono>
arigato: do you have time for a rvmprof question?
<arigato>
I *think* that the pypy binary is really linked statically
<arigato>
I killed all libexpat.dll under the sun and it still loads
<mattip>
it is meant to be, there was a bug I fixed to make it more cpython-like
yuyichao_ has joined #pypy
<arigato>
right, but I have no clue why yesterday the very same executable produced correct results and now it produces incorrect ones, after I installed local5_8.zip
<mattip>
untranslated uses the dll, -A uses static compiled
<mattip>
strange, out of time, sorry. Feel free to leave it and I will try it in my windows build env with debugger next week
<arigato>
thanks
<arigato>
ok, probably solved the local mess and checked that libexpat.dll is still ok in local5_8.zip
tbodt has joined #pypy
<arigato>
maybe the static libexpat.lib isn't
forgottenone has joined #pypy
vkirilichev has joined #pypy
<kenaan>
asottile py_ssize_t 46c6c05fde4b /pypy/module/cpyext/api.py: Explicitly use Py_ssize_t as the Signed type in pypy c-api. The signature for the c-api uses Py_ssize_t for ...
<kenaan>
asottile py_ssize_t 44574602ff71 /pypy/module/cpyext/parse/cpyext_object.h: Add `#pragma once` include guard to cpyext_object.h In order to get the definition of `Py_ssize_t`, other he...
<kenaan>
arigo default ff810e9e706d /pypy/module/cpyext/: hg merge py_ssize_t PR #568 (asottile) Trying to use another "#define Signed", together with "#pragma once", to m...
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<arigato>
CPython is slowly discovering that Java's GC is well thought-out after all
<arigato>
specifically, I refer to PEP 556 which calls finalizers in a separate thread (yay)
tbodt has joined #pypy
Guest8550 has quit [Ping timeout: 248 seconds]
antocuni has quit [Ping timeout: 246 seconds]
oberstet has quit [Ping timeout: 240 seconds]
jamesaxl has joined #pypy
realitix has quit [Ping timeout: 260 seconds]
vkirilichev has joined #pypy
<cfbolz>
arigato: heh. They could just jump to the recommendation of the Java community to never use finalizer ;-)
vkirilichev has quit [Ping timeout: 248 seconds]
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
realitix has joined #pypy
adamholmberg has joined #pypy
tbodt has joined #pypy
adamholmberg has quit [Ping timeout: 240 seconds]
realitix has quit [Ping timeout: 248 seconds]
<fijal>
they are realizing that too I think
marvin has joined #pypy
marvin is now known as Guest11245
vkirilichev has joined #pypy
cstratak has quit [Ping timeout: 255 seconds]
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
tbodt has joined #pypy
tbodt has quit [Ping timeout: 248 seconds]
tbodt has joined #pypy
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
lritter has quit [Quit: Leaving]
tbodt has joined #pypy
vkirilichev has quit [Remote host closed the connection]
<kenaan>
rlamy py3.5 44ba82e7527f /lib-python/3/test/test_importlib/builtin/test_loader.py: Fix test for obscure difference with CPython (cf. test_builtin_reimport_mess() in pypy/module/imp/test/test_app.py)
<ronan>
^^^ well, that was a waste of time, who knew _imp.create_builtin() was so complicated?
<kenaan>
cfbolz default 7de7062d9526 /rpython/jit/backend/: use constants to make the code less confusing
jcea has quit [Ping timeout: 246 seconds]
dunpeal has joined #pypy
<dunpeal>
Hi. I tried to drop-in replace CPython 3 with the latest PyPy binary, and my performance dropped by a factor of 3x.
jcea has joined #pypy
<dunpeal>
Is this very unusual? Easy fix? I expected PyPy to be far faster instead.
<tos9>
Certainly would need to share something reproduceable or some information about it? There's nothing really to go on there.
<tos9>
Yes it's unusual, although for PyPy3 probably slightly less so.
michaelgreene has joined #pypy
forgottenone has quit [Quit: Konversation terminated!]
jamesaxl has quit [Quit: WeeChat 1.8]
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
tbodt has joined #pypy
jkbbwr has joined #pypy
vkirilichev has joined #pypy
yuyichao has joined #pypy
yuyichao_ has quit [Ping timeout: 248 seconds]
vkirilichev has quit [Ping timeout: 255 seconds]
<fijal>
dunpeal: ok, so the first question is "what C extensions do you use?"
<fijal>
dunpeal: second is "how long did your test run"
<fijal>
and I have more questions after that :)
<njs>
at least for now PEP 556 still only runs circular ref finalizers in a separate thread (and only if you opt in)
<fijal>
njs: it's not a terrible idea overall!
<fijal>
if you have multiple threads at least
<fijal>
njs: any thoughts about our discussion with haypo last night?
<fijal>
did you read it?
<njs>
fijal: yeah, I sent him an email saying basically "if you think of switching to the "new" API as being an incremental thing instead of an all-at-once thing then aren't you and they basically agreeing?"
<fijal>
I'm sorry I struggle to parse your sentence
<fijal>
njs: do you think it's feasible for cpython to avoid a-subset-of-cython approach?
<njs>
fijal: I suggested that if he goes through one function at a time deprecating/replacing instead of doing it as a big flag switch, then it basically is what you were saying ("let's kill these obvious things first") and in the long run also basically the same as what he wants to do
<njs>
fijal: eh, the subset-of-cython approach is clearly nicer than having a public C API if we can get there, but my magic wand is broken, so...
<fijal>
njs: well ok, let me rephrase it
<fijal>
do you think the numeric community would be ok with it?
vkirilichev has joined #pypy
<fijal>
if I came up with a working approach
jcea has quit [Remote host closed the connection]
<njs>
the numerical community would love to have a practical path towards good JIT performance
<njs>
and the Numba devs would also love to get out of the reimplementing-numpy business
<njs>
so yeah, if you can do that, great
<fijal>
ok, so that's a start of the conversation I guess
marky1991 has quit [Read error: Connection reset by peer]