10:08 <antocuni> speaking of webassembly, I just found this (although it looks a bit old): https://github.com/kanaka/warpy

10:08 <antocuni> a webassembly interpreter in RPython

10:09 <antocuni> it would be a nice experiment to integrate it with pypy and JIT through it

11:12 <j4at_> Trained a very basic proof of concept AI to do in-runtime jit parameters tuning only 7 parameters (threshold, function_threshold, trace eagrness, decay, trace_limit, max_retrace_guards) got x1.2 speed up in sqlalchemy_declarative and sqlalchemy_imperative, the AI was trained on them so that's kinda cheating but it's a proof of a concept, I also run them together instead of separately to make the code longer and then used the geometric mean. And I used only

11:12 <j4at_> It got x2 speed up when I trained it first but the tests took only 2 secs(4 secs without the speed) and It didn't do well in longer tests so had to retrain it to do good in the long run.

11:12 <j4at_> the informations provided by `get_stats_snapshot()`!

11:14 <fijal> j4at_: note that "cheating" here might be ok

11:14 <fijal> you often are in a setup where you can train the parameters on something, but you are going to be running it repeatedly

11:15 <fijal> like, your tests or your *cough* production

11:15 <fijal> j4at_: JIT tests are a good target btw

11:15 <fijal> there is also very interesting data point that sqlalchemy is something I thoroughly failed to optimize away, it seems to me that it's a crazy target for the JIT

11:18 <j4at_> fijal: yeah probably. I was going to use bm_mdp too but noticed that it takes a lot of time because of this? https://foss.heptapod.net/pypy/pypy/-/issues/3787

11:18 <j4at_> So a lot of those benchmarks are hard to optimize bc of "bugs".

11:19 <j4at_> I mean the ones pypy doing bad at.

11:19 <j4at_> I decided that for now that stoping retracing and tuning jit parameters is enough, the hooks doesn't expose enough to do inlining. I'm planning to use the `sys.settrace()`, and pypyjit hooks to gather informations.

11:19 <j4at_> But needs more hooks exposed, needs `set_before_compile_hook()` `stop_retracing_in_a_loop()` `enable_retracing_in_a_loop()` and `get_stats_snapshot()` but with stats of every loop/guard! All of them should work with built-ins functions too.

11:24 <nimaje> isn't the "cheating" there similar to profile guided optimisation?

11:28 <j4at_> yes. But i want to make it generalise and to be in-runtime ;)

11:30 <j4at_> If i can make it get x1.2 consistently according all tests that will be a huge boost

11:30 <j4at_> consistently in* all tests

11:55 <j4at> I will apprecicate it, If anyone wants to implement the hooks mentioned above :)

11:55 <j4at> atleast the stop retracing one.

12:04 <fijal> I can probably help you implement them?

12:04 <fijal> I don't think I have the capacity to look into that today

12:38 <j4at> fijal: Yeah take your time, I appreciate your help :)

13:59 <mgorny> > i386 is not supported anymore, skip tests

13:59 <mgorny> i get the point but still a bit sad-face

16:15 <cfbolz> mgorny: oh, where is that?

16:15 <mgorny> cfbolz: the tip of default branch

16:16 <cfbolz> mgorny: that's on for mac os and i386

16:16 <mgorny> oh

16:17 <cfbolz> linux and x86 is safe for a bit longer ;-)