04:40 <shlomif> cfbolz: [and all] i'm back

05:41 <shlomif> cfbolz: i found https://github.com/pyutils/line_profiler on a google/SO search

05:41 <cfbolz> Did you try scalene by now?

05:42 <shlomif> cfbolz: no, not yet

05:58 <shlomif> cfbolz: i tried scalene now - seems better

05:59 <cfbolz> shlomif: the results need interpreting

05:59 <cfbolz> Scalene shows the loop statement itself taking a lot of time

05:59 <cfbolz> That's not quite correct, that's the time taken by the whole loop

06:14 <shlomif> cfbolz: ah

06:16 <cfbolz> But given that vmprof provides no line info at all...

07:00 <fijal> it does, somewhat

07:01 <fijal> but in pypy it's a lot to ask

07:01 <fijal> cfbolz: you sometimes get a lot of forcing at the end of the loop, whch means it shows as "loop"

08:13 <cfbolz> shlomif: you can get a significant improvement by using math.sqrt instead of ** 0.5

08:14 <cfbolz> I also tried the new math.isqrt, but it's much slower

08:55 <shlomif> cfbolz: yes, i noticed that - thanks

10:11 <shlomif> cfbolz: it is even faster after using https://en.wikipedia.org/wiki/Pythagorean_triple#Generating_a_triple but now there's a refactoring that slows down: https://www.shlomifish.org/Files/files/text/pypy3-slowdown-refactoring.txt

10:19 <cfbolz> shlomif: if you want me to look you need to paste the source again

10:20 <shlomif> cfbolz: sure

10:30 <shlomif> cfbolz: here: https://github.com/shlomif/pypy3-code--slowdown

12:03 <cfbolz> very early draft of my blog post on the new JIT thing: https://github.com/pypy/pypy.org/pull/31

12:10 <shlomif> cfbolz: "of simply disable": https://github.com/pypy/pypy.org/pull/31/files#diff-097a5c95a27afd1b52cbd717b3312840e33657f3ef80b2de03a2671d7a0d5204R59

12:10 <cfbolz> thx

12:11 <shlomif> cfbolz: you're welcome

16:14 <arigato> cfbolz: great that there is progress on jit compiling very long functions

16:16 <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

16:18 <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) ?

16:19 <arigato> We loose the virtuals and other optimizations, but on the plus side, it lets long control flow merge back

16:24 <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)

16:37 <cfbolz> arigato: yes, it's a good thing to explore

18:56 <cfbolz> arigato: I am also working on the 'promoting too many maps' problem again

22:46 <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.

22:46 <Hodgestar> s/want/what/

22:48 <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.