cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | so many corner cases, so little time
otisolsen70 has joined #pypy
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
<LarstiQ> cfbolz: very neatly set out blog post, thanks!
Atque has quit [Remote host closed the connection]
<cfbolz> Corbin: can you paste a link to the JIT loop?
<Corbin> cfbolz: Here's an example loop. I'm embarrassed, but that's life.
<cfbolz> Corbin: where's the interpreter source?
<cfbolz> Corbin: I would definitely add a 'get_printable_location'
<cfbolz> It should help a lot
<mattip> in the 2018 sprint work was done to make cpyext faster than CPython for some microbenchmarks around empty function calls
<mattip> s/2018/2017/
<mattip> with the conclusion
<mattip> "Ideally, we would like to reach a point in which cpyext-intensive programs run at worst at the same speed of CPython"
<mattip> another project for the TODO list
greedom has joined #pypy
slav0nic has joined #pypy
lritter has joined #pypy
greedom has quit [Remote host closed the connection]
<Corbin> cfbolz: Sorry, fell asleep. The core of the interpreter is The first batch of classes is a tagged union for values; the second batch is components of programs. There's two JIT drivers, one for each type of loop.
<Corbin> I agree that a printable location would help. The main obstacle there is that Cammy programs don't have locations at all.
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
<cfbolz> Corbin: why not?
<cfbolz> Corbin: anyway, you can pretty-print the ast, that would also help
<Corbin> I never bothered to define locations when I laid out the parser. I was *very* lazy.
greedom has joined #pypy
<cfbolz> Corbin: so subclasses of Arrows are part of the program, and Elements are values that the program operates on?
<cfbolz> anyway, I'd say having location printing would help you a whole lot
<cfbolz> (also I can't deal with all the single letter varnames ;-( )
<Corbin> Yeah, sorry.
<cfbolz> Corbin: I think it's an interesting thing to think about, what are the actual loops in your programs? are there any?
<cfbolz> eg the fold, that is a loop over the list, isn't it?
<Corbin> Yeah, there's folds over lists, and primitive recursion over natural numbers. (I know primitive recursion is slow, and will eventually jet some common cases with special instructions.)
<cfbolz> the fold_driver.jit_merge_point call is really in the wrong place then
<cfbolz> it should be in the for loop
<cfbolz> in
<cfbolz> that would turn it into an actual loop
<Corbin> Oh, interesting.
<cfbolz> PrimRec does that correctly
<Corbin> I wonder why I did that. I'm guessing that the translation process broke if I inlined driveFold().
<cfbolz> try and show me the error?
<cfbolz> ah, I probably know
<cfbolz> it can't deal with the for loop
<cfbolz> you can get around that by saying reds='auto'
<cfbolz> in the driver construction
<cfbolz> the same is true for the sample_jitdriver, fwiw
<Corbin> "[translation:ERROR] Exception: The variable self_0 of type <* GcStruct cammylib.arrows.Fold { super, inst__c, inst__n }> was not explicitly listed in _forcelink. This issue can be caused by a jitdriver.jit_merge_point() where some variable containing an int or str or instance is actually known to be constant, e.g. always 42."
<Corbin> Trying again with autoreds.
<cfbolz> Corbin: hm, wait
<cfbolz> Corbin: the self should be a green variable
<cfbolz> Corbin: can you tell me what an "H" is?
<cfbolz> ah, I get it
<Corbin> H is "hom"; it's a curried function which wants to be applied to a pair, but only the first value is available.
<cfbolz> right
<cfbolz> Corbin: so I wonder whether H.apply should promote self._f for calling "run" on it
<Corbin> Ah, kind of a defunctionalization. Tricky.
<cfbolz> wouldn't you expect that most call sites of an H call the same thing in practice?
<cfbolz> we certainly do exactly this in say pycket
<cfbolz> Corbin: I mean, there's an alternative point of view: in every "run" method, you should start with "promote(self)"
<cfbolz> in order to execute self, the JIT should know what "self" is
<Corbin> This all makes a lot of sense. I'll test it out and see what happens.
<cfbolz> ok, final question tonight ;-)
<Corbin> I think that the JIT translation has gotten far enough to say that it's gonna work. I added "self" to greens *and* changed reds to "auto".
<cfbolz> cool :-)
<cfbolz> Corbin: do it for the sample driver too
<cfbolz> anyway, my question is why there are so many call_assemblers
<cfbolz> what is the example program actually computing?
<Corbin> The example program is computing the Burning Ship fractal. It should look like a trace of a Mandelbrot.
<cfbolz> ok
<cfbolz> yeah, some of the float operations appear further down in the trace
<cfbolz> yeah, we need to get rid of the getfields (and I suspect we will lose some with the promotes that I mentioned)
<cfbolz> and then later the call_assembler (maybe hard, bit unclear)
* cfbolz zzzz
<Corbin> Sweet, thanks. Many things to work on. Have a good night.
slav0nic has quit [Remote host closed the connection]
slav0nic has joined #pypy
slav0nic has quit [Remote host closed the connection]
slav0nic has joined #pypy
lritter has quit [Quit: Leaving]
otisolsen70 has quit [Quit: Leaving]
greedom has quit [Remote host closed the connection]
slav0nic has quit [Ping timeout: 260 seconds]
glyph has quit [Quit: End of line.]
glyph has joined #pypy