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
<suhdonghwi>
I tried to find what `_attrs_` (RPython) is but it seems that there is no documentation for this property. What is this and how does it help optimization?
<cfbolz>
suhdonghwi: it's sort of like __slots__ in general python
<cfbolz>
it's a declaration of what fields are allowed in a class
gracinet has joined #pypy
Ashleee has quit [Remote host closed the connection]
Ashleee has joined #pypy
suhdonghwi has quit [Remote host closed the connection]
Guest33 has joined #pypy
ronan has joined #pypy
fangerer_ has joined #pypy
suhdonghwi has joined #pypy
tsaka__ has joined #pypy
ronan has quit [Remote host closed the connection]
ronan has joined #pypy
ronan has quit [Remote host closed the connection]
ronan has joined #pypy
suhdonghwi has quit [Remote host closed the connection]
lritter has joined #pypy
suhdonghwi has joined #pypy
ronan has quit [Remote host closed the connection]
ronan has joined #pypy
<suhdonghwi>
I tried using `virtualizable` feature in my JIT code. It builds successfully without error but it shows this warning: `ignoring hint {'access_directly': True, 'fresh_virtualizable': True}` Is this warning safe to ignore?
<cfbolz>
suhdonghwi: yes, that warning can sometimes happen without it being a problem
<cfbolz>
suhdonghwi: is your code online somewhere?
<suhdonghwi>
it is `Frame` class which i tested virtualizable feature
<cfbolz>
suhdonghwi: right, that's the intended use
<cfbolz>
suhdonghwi: does it help performance?
<suhdonghwi>
No, it does not. It rather decreases performance.
<cfbolz>
then you need to start looking at traces
<cfbolz>
do you know how to get traces from the JIT?
<suhdonghwi>
yes, but what part should i look at to check if virtualizable feature is working?
<cfbolz>
suhdonghwi: if you compare traces before and after, there should be no operations reading from the frame any more
<cfbolz>
suhdonghwi: ah, the stack should maybe be also on the frame, and also be immutable. but that means you need to make it fixed-size and compute the maximum stack depth
<suhdonghwi>
aha, that maybe would help performance. i'll try it. thank you!
xcm has quit [Ping timeout: 255 seconds]
xcm has joined #pypy
<cfbolz>
suhdonghwi: I just built your vm, any program I should try?
<cfbolz>
ah, there is a checked in log file
<cfbolz>
I looked at that, it seems to do stack handling
<cfbolz>
suhdonghwi: all the stack.append(...) and stack.pop() calls in the Interpreter.run method
<cfbolz>
so if you do what I said above things should become faster: (move the stack into the frame, use a fixed-size list and precompute the maximum stack depth)
<cfbolz>
makes sense?
<suhdonghwi>
hmm, i am trying to understand, what does `cond_call(i25, ConstClass(_ll_list_resize_hint_really_look_inside_iff__listPtr_Signed_Bool), p5, i23, 1, descr=<Callv 0 rii EF=5>` )
<cfbolz>
suhdonghwi: that's what the append and the pop turns into
<cfbolz>
suhdonghwi: Frame.load should not be elidable
<suhdonghwi>
ohh, that's right i forgot to comment it out
<suhdonghwi>
but what actually happens when i mark not-elidable function as elidable?
<cfbolz>
suhdonghwi: the code will behave incorrectly
<cfbolz>
suhdonghwi: I opened a pull request that fixes a problem in the virtualizable declaration
gracinet has joined #pypy
fangerer_ has quit [Quit: Connection closed for inactivity]
<suhdonghwi>
this helps me a lot! i really appreciate it
<suhdonghwi>
i'll check and study it now thank you again!
<cfbolz>
cheers
<cfbolz>
there's still stuff to be improved ;-)
<cfbolz>
suhdonghwi: but if you look at the trace now, some bytecodes produce zero operations
<suhdonghwi>
hmm, does that mean it is optimized away?
<cfbolz>
yes
<suhdonghwi>
well it definitely is a huge leap of an optimization :) i'll keep try to optimize it more
ronan has quit [Remote host closed the connection]
ronan has joined #pypy
<cfbolz>
suhdonghwi: further things to look at: the base class Constant should have no attributes! Right now ConstantInteger also has an unused 'doubleval' field (etc)
<cfbolz>
suhdonghwi: also, calls are really expensive right now, with lots of list manipulation going on
xcm has quit [Remote host closed the connection]
<suhdonghwi>
ah yes, calls are very expensive. that is because the language i am currently uses named parameter and partial application by default
<suhdonghwi>
i think i should optimize that part harder
<cfbolz>
that's not a problem as such
<cfbolz>
but the current implementation needs improvement
xcm has joined #pypy
<suhdonghwi>
yes! and about Constant class' attributes,
<suhdonghwi>
i added `_attrs_` to Constant because when i remove it it shows an error like
<suhdonghwi>
`ConstInteger has _attrs_, but not its base class`
<suhdonghwi>
how should i deal with this error correctly?
<cfbolz>
suhdonghwi: the _attrs_ of Constant should be ['type'], I suppose?
tsaka__ has joined #pypy
ronan has quit [Remote host closed the connection]
tsaka__ has quit [Ping timeout: 255 seconds]
ronan has joined #pypy
<suhdonghwi>
hmm, there's a code where it accesses fields such as `intval` or `doubleval` without downcasting(?) Constant object. so compilation error is thrown at that point.
<cfbolz>
suhdonghwi: you downcast by saying "assert isinstance(obj, ConstantInteger)"
<cfbolz>
suhdonghwi: or you could replace the "other.type == TYPE_INTEGER" tests by "isinstance(other, ConstantInteger)"
<suhdonghwi>
oh, is that conditional statement automatically recognized by RPython translator?
<cfbolz>
yes
<suhdonghwi>
wow, compiler is smarter than i thought