itamarst has quit [Quit: Connection closed for inactivity]
xcm_ has joined #pypy
dmalcolm_ has joined #pypy
larstiq_ has joined #pypy
xcm has quit [Ping timeout: 245 seconds]
LarstiQ has quit [Ping timeout: 245 seconds]
dmalcolm has quit [Ping timeout: 245 seconds]
pjenvey has quit [Ping timeout: 245 seconds]
pjenvey has joined #pypy
lehmrob has joined #pypy
[Arfrever] has quit [Ping timeout: 272 seconds]
[Arfrever] has joined #pypy
[Arfrever] has quit [Ping timeout: 248 seconds]
[Arfrever] has joined #pypy
lehmrob has quit [Quit: Konversation terminated!]
jcea has joined #pypy
jcea has quit [Ping timeout: 248 seconds]
itamarst has joined #pypy
<arigato>
korvo: yes, that's also my understanding. So in pypy we would list all "resoperations" generated by the JIT, write some C code for each of them, and use LLVM to generate ahead of time many "stencil" variants for each bit of code
<arigato>
you'd just have to re-run LLVM if you make changes or if you want the stencils generated for a different platform
<arigato>
what's cool is that it opens the door to more experiments, like measuring sequence of operations that appear often in practice, and asking LLVM to generate super-stencils for these
<arigato>
ultimately, this could be done by the user: she runs her program producing dumps of produced resops, and then runs a program that will identify big super-stencils and compile them with LLVM, so that next time her program runs faster
derpydoo has joined #pypy
<korvo>
Mm, makes sense. Super-stencils remind me of super-shaders for GPUs. When GL 2.0 came out, GPU drivers started adding GL 1.4 support via shaders that had parameters for the classic rendering pipeline.
<korvo>
Super-shaders are only efficient because GPU bandwidth is so expensive that it is cheaper to not upload a new shader on every draw. Otherwise it normally wouldn't be worth it.