cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | insert pithy quote here
shlomif has joined #pypy
glyph has quit [*.net *.split]
ambv has quit [*.net *.split]
daubers has quit [*.net *.split]
ammar2 has quit [*.net *.split]
lastmikoi has quit [*.net *.split]
tazle has quit [*.net *.split]
dustinm has quit [*.net *.split]
tazle has joined #pypy
dustinm has joined #pypy
glyph has joined #pypy
ammar2 has joined #pypy
ambv has joined #pypy
daubers has joined #pypy
lastmikoi has joined #pypy
jryans has quit [*.net *.split]
the_drow has quit [*.net *.split]
pjenvey has quit [*.net *.split]
vstinner has quit [*.net *.split]
habnabit_ has quit [*.net *.split]
vstinner_ has joined #pypy
habnabit_ has joined #pypy
pjenvey has joined #pypy
the_drow has joined #pypy
jryans has joined #pypy
<shlomif> cfbolz: [and all] i'm back
<shlomif> cfbolz: i found on a google/SO search
<cfbolz> Did you try scalene by now?
<shlomif> cfbolz: no, not yet
<shlomif> cfbolz: i tried scalene now - seems better
<cfbolz> shlomif: the results need interpreting
<cfbolz> Scalene shows the loop statement itself taking a lot of time
<cfbolz> That's not quite correct, that's the time taken by the whole loop
<shlomif> cfbolz: ah
<cfbolz> But given that vmprof provides no line info at all...
<fijal> it does, somewhat
<fijal> but in pypy it's a lot to ask
<fijal> cfbolz: you sometimes get a lot of forcing at the end of the loop, whch means it shows as "loop"
glyph has quit [Quit: End of line.]
glyph has joined #pypy
vstinner_ is now known as vstinner
vstinner has quit [Changing host]
vstinner has joined #pypy
<cfbolz> shlomif: you can get a significant improvement by using math.sqrt instead of ** 0.5
<cfbolz> I also tried the new math.isqrt, but it's much slower
lritter has joined #pypy
slav0nic has joined #pypy
<shlomif> cfbolz: yes, i noticed that - thanks
lritter has quit [Ping timeout: 268 seconds]
<shlomif> cfbolz: it is even faster after using but now there's a refactoring that slows down:
<cfbolz> shlomif: if you want me to look you need to paste the source again
<shlomif> cfbolz: sure
fijal has quit []
fijal has joined #pypy
amaury has quit [Ping timeout: 252 seconds]
amaury has joined #pypy
otisolsen70 has joined #pypy
<cfbolz> very early draft of my blog post on the new JIT thing:
<cfbolz> thx
<shlomif> cfbolz: you're welcome
ctismer has quit []
ctismer has joined #pypy
slav0nic has quit [Remote host closed the connection]
otisolsen70 has quit [Quit: Leaving]
stkrdknmibalz has quit [Quit: WeeChat 3.0.1]
amaury has quit [Ping timeout: 268 seconds]
amaury has joined #pypy
mattip has left #pypy [Leaving]
amaury has quit [Ping timeout: 268 seconds]
amaury has joined #pypy
stu has joined #pypy
stu has quit [Client Quit]
Atque has quit [Quit: ...]
<arigato> cfbolz: great that there is progress on jit compiling very long functions
<arigato> But I wonder: the solution you did keeps the whole very long function (or loop) as a tree, so it doesn't help if it branches in many different patterns
<arigato> Wouldn't it be better, instead of just making always failing guards, to instead (or additionally) add merge points in the middle of the Python bytecode (or equivalent) ?
<arigato> We loose the virtuals and other optimizations, but on the plus side, it lets long control flow merge back
greedom has joined #pypy
<arigato> If we want to be advanced it can be driven by language specific hints, e.g that measures how good an idea it would be to merge here (if it's just after a non-nested if, then high)
<cfbolz> arigato: yes, it's a good thing to explore
shlomif has quit [Ping timeout: 252 seconds]
amaury has quit [Ping timeout: 268 seconds]
<cfbolz> arigato: I am also working on the 'promoting too many maps' problem again
stkrdknmibalz has joined #pypy
amaury has joined #pypy
stkrdknmibalz has quit [Read error: Connection reset by peer]
greedom has quit [Remote host closed the connection]
amauryfa has joined #pypy
amaury has quit [Ping timeout: 252 seconds]
<Hodgestar> cfbolz: Re cycle finding -- maybe want you implemented is already good enough or includes this idea, but sometimes with practical cycle finding the observation that every cycle must include a back-edge in a spanning tree can be helpful since the back-edges can be found quickly. Knowing what to do once one has one edge from every cycle is then a bit problem dependent though.
<Hodgestar> s/want/what/
<Hodgestar> Maybe you don't need to actually find all cycles though but only certain points on each cycle? I don't know where the stack checks go.