<squeaky_pl>
Would this approach make any sense for PyPy interpreter speed (running without the JIT)?
<cfbolz>
squeaky_pl: yes, it's a possibility
<cfbolz>
squeaky_pl: basically there's a mid-sized research project waiting for somebody to investigate how much it makes sense to do this kind of stuff in pypy
<squeaky_pl>
Completely unrelated area: is there any possibility that using tagged pointers could speed up PyPy? My first instinct tells me that extra branches to check if a pointer is tagged that would need to be put in place would ruin it, but of course I am just speculating.
<squeaky_pl>
Is/was anybody researching it?
<cfbolz>
squeaky_pl: we tried a long time ago
<cfbolz>
before the jit
ronan has quit [Quit: Leaving]
<cfbolz>
squeaky_pl: your intuition is pretty on point, i think
<cfbolz>
the tag check costs
fotis has quit [Ping timeout: 245 seconds]
<squeaky_pl>
Out of curiosity, were there any practical memory savings?
<cfbolz>
squeaky_pl: maybe, but nowadays a lot of integers on the heap are anyway unboxed
ronan has joined #pypy
<cfbolz>
squeaky_pl: eg lists of ints are unboxed, or instances with many integer fields
<squeaky_pl>
What about short strings, I mean the ones that would fit architecture word, let's say 7 byte on x86_64 and then storing the tag and length in the 8th byte. Was this researching somewhere?
<squeaky_pl>
researched*
<cfbolz>
squeaky_pl: not in the pypy context, no
<cfbolz>
squeaky_pl: I think some of the JS VMs do that
Dejan has joined #pypy
<Dejan>
Good job with 3.8, now I can create venv with latest build
<Dejan>
I got "undefined symbol: _PyDict_GetItemStringWithError" when trying to build numexpr but I guess you guys know about this already
<cfbolz>
Dejan: nope, not yet
<mattip>
Dejan: that is a new interface for 3.8, and is declared as an internal function
<smarr>
cfbolz: yes, my question was in the context of the JIT. I only have smallish benchmarks. so, I don't measure any benefit. but perhaps I am missing a trick
<cfbolz>
smarr: no way to know without looking at traces
<cfbolz>
smarr: basically virtualizables make it possible to store the content of a frame object in an unboxed way
<smarr>
cfbolz: within a trace, or across traces? I see overhead when they need to be materialized, but don't see gain when they don't need to be. perhaps in my cases it's trivial for the compiler and it figures things out without it?
<cfbolz>
smarr: yes, in trivial cases the regular optimizations can achieve similar effects, within a trace
<cfbolz>
but:
<cfbolz>
why do you need to materialize your frames?
<smarr>
cfbolz access to outer scopes
fotis has quit [Ping timeout: 244 seconds]
<cfbolz>
smarr: ah. then they may indeed not be a good fit
<cfbolz>
smarr: in python, the outer scopes never need to be accessed
<smarr>
cfbolz: in these cases, the frames are store in block objects. and I got a loop, so, there's a call between traces.
<cfbolz>
smarr: why a call and not inlined?
<smarr>
yeah, well, I had an optimizations that avoids much of it, which is very effective (essentially identifying the outer variables, putting them in a cell, and handing them down to the block/frame that needs them). But in an attempt to align implementations between the Truffle and RPython versions I looked into removing that optimization. I may want to keep it
<cfbolz>
but yes, the model doesn't match perfectly
<cfbolz>
smarr: right, I think the optimization is what makes virtualizables do something good for you
<smarr>
cfbolz: various benchmarks have multiple nested loops, so, there's a call from the outer to the inner loop
<cfbolz>
ok
fotis has joined #pypy
Julian has quit [Ping timeout: 272 seconds]
Wombatzus has quit [Ping timeout: 252 seconds]
squeaky_pl has quit [Ping timeout: 245 seconds]
fotis has quit [Ping timeout: 272 seconds]
squeaky_pl has joined #pypy
fotis has joined #pypy
Dejan has quit [Quit: Leaving]
Dejan has joined #pypy
Julian has joined #pypy
squeaky_pl has quit [Ping timeout: 272 seconds]
fotis has quit [Ping timeout: 245 seconds]
squeaky_pl has joined #pypy
Julian has quit [Ping timeout: 252 seconds]
fotis has joined #pypy
Julian has joined #pypy
Julian has quit [Ping timeout: 272 seconds]
Julian has joined #pypy
bdk has quit [Quit: Client closed]
Julian has quit [Quit: leaving]
fotis has quit [Ping timeout: 272 seconds]
fotis has joined #pypy
squeaky_pl has quit [Ping timeout: 245 seconds]
fotis has quit [Ping timeout: 268 seconds]
stkrdknmibalz has quit [Ping timeout: 252 seconds]
squeaky_pl has joined #pypy
fotis has joined #pypy
lritter has joined #pypy
squeaky_pl has quit [Ping timeout: 244 seconds]
squeaky_pl has joined #pypy
fotis has quit [Ping timeout: 252 seconds]
lesshaste has joined #pypy
Dejan has quit [Quit: Leaving]
<lesshaste>
hi
fotis has joined #pypy
fotis has quit [Ping timeout: 245 seconds]
Eclipse2212 has quit [Quit: WeeChat 3.1]
lesshaste has quit [Quit: Leaving]
lesshaste has joined #pypy
fotis has joined #pypy
squeaky_pl has quit [Ping timeout: 245 seconds]
squeaky_pl has joined #pypy
<mattip>
I wonder if we could just remove the cffi hack from pypy/goal/targetpypystandalone.py, and declare package.py a required step
fotis has quit [Ping timeout: 244 seconds]
fotis has joined #pypy
stkrdknmibalz has joined #pypy
<squeaky_pl>
mattip, I would check what upstream packagers do. Also maybe somebody translating by themselves might not be aware/not want to package. Not sure.
<mgorny>
mattip: remove as in require us to do some additional step during build?
<mgorny>
i'm not using package.py as i want more control over what's happening
<mattip>
mgorny: do you expect lib_pypy/pypy_tools/build_cffi_imports.py to be run as part of translation?
<mattip>
I meant build_cffi_imports and/or package.py in my comment above
<mgorny>
i'm actually doing that manually
<mgorny>
i have pypy split into two packages: one containing the interpreter executable + headers only, the other one with stdlib and everything elese
<mgorny>
so i can patch stdlib and other stuff without having to run translation again
fotis has quit [Ping timeout: 264 seconds]
squeaky_pl has quit [Ping timeout: 264 seconds]
fotis has joined #pypy
squeaky_pl has joined #pypy
squeaky_pl has quit [Remote host closed the connection]
squeaky_pl has joined #pypy
squeaky_pl has quit [Ping timeout: 244 seconds]
otisolsen70 has joined #pypy
otisolsen70 has quit [Ping timeout: 245 seconds]
fotis has quit [Ping timeout: 245 seconds]
habnabit_ has joined #pypy
habnabit_ has joined #pypy
habnabit_ has quit [Changing host]
habnabit_ has quit [Client Quit]
habnabit_ has joined #pypy
habnabit_ has joined #pypy
habnabit_ has quit [Changing host]
habnabit_ has quit [Client Quit]
habnabit_ has joined #pypy
fotis has joined #pypy
dmalcolm has quit [Remote host closed the connection]
dmalcolm has joined #pypy
dmalcolm has quit [Remote host closed the connection]