antocuni changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | "PyPy: the Gradual Reduction of Magic (tm)"
danieljabailey has quit [Quit: ZNC 1.6.4+deb1 - http://znc.in]
<kenaan>
antocuni extradoc 8eccb15f4dd9 /blog/draft/2017-10-how-to-make-80x-faster.rst: syntax highlighting, and a tweak
<kenaan>
antocuni extradoc 03cc5eb071c6 /blog/draft/2017-10-how-to-make-80x-faster.rst: remove the reference to list strategies: it's not true, since self.data items are of type numpy.float64. Bah.
<kenaan>
antocuni extradoc c2f10979b271 /blog/draft/2017-10-how-to-make-80x-faster.rst: another tweak
alex__ has joined #pypy
spapanik has quit [Ping timeout: 240 seconds]
Guest38536 has quit [Ping timeout: 240 seconds]
adam_ has joined #pypy
adam_ has left #pypy [#pypy]
thisch has quit [Ping timeout: 255 seconds]
alex__ has quit [Read error: Connection reset by peer]
spapanik has joined #pypy
adam_ has joined #pypy
alex__ has joined #pypy
thisch has joined #pypy
adam_ has quit [Ping timeout: 260 seconds]
magniff has joined #pypy
<cfbolz>
antocuni: cool
Joannah has quit [Quit: Page closed]
<magniff>
hey there folks, I`ve been wondering where exactly jit bytecode is stored inside a pypy binary?
<cfbolz>
magniff: it's a static C stringjh
<cfbolz>
string
<magniff>
right, but is should a part of something?)
<magniff>
0000000002ef2632 t pypy_g_PyFrame_dispatch
<magniff>
how about this one?
raynold has quit [Quit: Connection closed for inactivity]
<cfbolz>
magniff: I doubt that it is findable on this level
<cfbolz>
What are you trying to do?
<magniff>
Basically just demonstrate to myself that this is a real entity at the first place)
<cfbolz>
I don't think the jit bytecode is stored under a nice symbol name. it's probably just in a table somewhere
<cfbolz>
we try hard not to have to debug on the C level
<magniff>
Heh, I got you
<magniff>
thanks
<cfbolz>
magniff: if you want to dig into C, it would be easier to translate a smaller interpreter
alex__ has quit [Quit: WeeChat 1.9.1]
<magniff>
did i get it correclty - when built with -Ojit the user interpreter is translated to jit bytecode and this is the only representation of the user`s interpreter into final binary?
<magniff>
like no tricks involved here - plain oldschool interpretation of interpreter
<magniff>
and only after critical amount of ticks jit machine actually starts to trace
<cfbolz>
no
<cfbolz>
not quite
<magniff>
throw me a bone)
<cfbolz>
it also exists as regular C functions
<cfbolz>
in addition to as JIT code
<magniff>
so it starts running as a regular function right? and then if loop detected and if this loop is hot JIT machine starts interpreting bytecode version of the function?
<cfbolz>
yes
nikar has left #pypy [#pypy]
<magniff>
so you manage to keep in sync C version and completelly different beast - JIT bytecode and corresponding runtime
<cfbolz>
yes
<cfbolz>
(which is a bit of a pain, but has been a stable component for a while)
<magniff>
does the JIT runtime (the interpreter) falls nicely into some known VM architectures, say stack machine?
ronan has quit [Quit: Ex-Chat]
ronan has joined #pypy
<cfbolz>
register machine
spapanik has quit [Quit: spapanik]
spapanik has joined #pypy
<magniff>
cool, thanks
exarkun has joined #pypy
<magniff>
ohhh, right, the fact the JIT runtime is a register machine is obvious from the implementation of MIFrame class
antocuni has quit [Ping timeout: 260 seconds]
ronan has quit [Quit: Ex-Chat]
ronan has joined #pypy
cstratak_ has joined #pypy
cstratak has quit [Ping timeout: 255 seconds]
thisch has quit [Ping timeout: 258 seconds]
lumbric has quit [Ping timeout: 260 seconds]
ronan has quit [Ping timeout: 240 seconds]
ronan has joined #pypy
thisch has joined #pypy
<cfbolz>
magniff: right
<cfbolz>
magniff: it's not really that important though
<cfbolz>
The JIT interpreter is very slow anyway
<magniff>
did i get you correct - you are saying that current incarnation of jit is not based on partial evaluation (at least the doc says that prev versions were and the reader should assume that current arent)
<magniff>
but clearly pyjitpl5 is partial evaluator
<magniff>
not static, but still
<cfbolz>
magniff: yesish
<magniff>
it takes an interpreter and the user program and yields another program - partially evaluated superposition of former two
<cfbolz>
Very much depends on your definition
<cfbolz>
It's a strange dynamic partial evaluator
<cfbolz>
It only follows one path
<magniff>
isnt it JUST a dynamic partial evaluator
<magniff>
not a strange one
<magniff>
and the fact that it only takes one path - is kind of implementation detail kind of thing
<cfbolz>
Maybe, but very few PEs do that
<cfbolz>
Because they run ahead of time
<cfbolz>
So they can't
<cfbolz>
Be lazy
<magniff>
yes, exactly
<magniff>
cool, I am not a PE theory savy, you should apologize me)
<cfbolz>
No worries
<arigato>
pyjitpl5 is *also* a regular interpreter that produces an answer
<arigato>
this alone means it is not just a PE
<cfbolz>
Yes
<cfbolz>
It's a PE that is guided by one concrete execution
<arigato>
or, it's a regular interpreter that builds a trace as a side-effect, and that trace could be regarded as the result of PE
<cfbolz>
Indeed ;-)
<cfbolz>
(great observations, btw)
<cfbolz>
We should have written a paper, I suppose
infernix has quit [Ping timeout: 258 seconds]
adamholmberg has joined #pypy
spapanik has quit [Quit: spapanik]
spapanik has joined #pypy
<thisch>
Is anyone working on the hashlib import problems in the py3.6 branch, if not I'll work on it.
<magniff>
>>> and that trace could be regarded as the result of PE
<magniff>
great one
<magniff>
btw i started to realize that the actual interpretation of what is going on is way more fun than technical details
spapanik has quit [Quit: spapanik]
<kenaan>
spapanik py3.6 4a3e6bc30cc8 /pypy/module/cmath/: Add inf and nan to cmath This also adds the corresponding complex constants.
<kenaan>
mattip buildbot bf6e08ac46ee /bot2/pypybuildbot/master.py: revert part of 2336f92eb562 that tries to run rpython tests on non-default branch Instead we should have a commi...
<mattip>
the trigger for rpython builds on non-default didn't work, it needs another HgPoller(... branch=py3.5), but I think that is the wrong approach
<mattip>
IMO we should not be getting rpython changes via py3.5 or py3.6, they should commit on default then merge
<fijal>
yep
marky1991 has quit [Ping timeout: 240 seconds]
oberstet has quit [Ping timeout: 240 seconds]
lritter has joined #pypy
glyph has quit [Remote host closed the connection]
forgottenone has quit [Quit: Konversation terminated!]
glyph has joined #pypy
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
drolando has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
drolando has joined #pypy
tbodt has joined #pypy
antocuni has quit [Ping timeout: 240 seconds]
drolando has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cstratak_ has quit [Ping timeout: 255 seconds]
drolando has joined #pypy
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
tbodt has joined #pypy
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
kipras`away is now known as kipras
redj has joined #pypy
infernix has joined #pypy
tbodt has joined #pypy
adamholmberg has joined #pypy
adamholm_ has quit [Ping timeout: 248 seconds]
yuyichao has quit [Ping timeout: 248 seconds]
yuyichao_ has joined #pypy
exarkun has quit [Ping timeout: 258 seconds]
marky1991 has joined #pypy
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
raynold has quit [Quit: Connection closed for inactivity]