02:42 <belm0> cfbolz: with the change "make locals use an instance dict", is it still necessary to remove calls to `locals()`?

03:58 <belm0> I confirmed that removing locals() / frame.f_locals() from trio eliminated the corresponding "force quasi-immut" aborts.  But app CPU use only improved slightly, still on the order of 2x slower.  The new problem is "trace too long" aborts.  I expect it's due to the async + tracing JIT issue I mentioned.  And a simple async app that does one

03:58 <belm0> thing (like http server benchmark or the websocket client / server) wouldn't exhibit this problem.

05:55 <cfbolz> belm0: trace too long is not a problem any more, really

05:55 <cfbolz> How long are you running your benchmarks btw?

06:19 <belm0> maybe 20-30 seconds, the log gets rather long

06:23 <belm0> I mean 20-30 seconds for capturing a log.  When measuring performance, I run until it seems to reach steady state, perhaps a minute or less.

06:24 <belm0> I haven't heard the counterargument about why async + tracing JIT is expected to work fine.

06:25 <belm0> (work fine -> perform  fine)

06:51 <fijal> belm0: ok, what's your argument?

06:51 <fijal> why it should be bad

06:52 <fijal> I can probably write a bunch of async code that will be infinitely faster in pypy than in cpython

06:53 <belm0> sure, a case where the async app is doing only one thing, like serving websocket, and almost all the coroutines are running the same function

06:54 <fijal> and do you mean specifically in python or async in principle?

06:54 <fijal> if you already know what example I will come up with, why are we having discussion in the first place? do you want to understand how pypy works or do you already know it's shit and you are just complaining?

06:55 <fijal> I'm largely saying "it's more complex than you think"

06:55 <belm0> That's a very constrained application case for async.  An async app can have 1000's of concurrent tasks, all running different functions, and ideally (for a near-realtime app) no code runs longer than a few hundred microseconds before yielding.

06:56 <fijal> are you digging deeper in an example that I have not written and you know it?

06:56 <belm0> it's not theory-- it's my application (which is top-level control of a robot, running CPython 3.8 and Trio)

06:59 <fijal> ok

06:59 <fijal> can you write an async example that you want to profile that does not involve trio?

07:01 <belm0> do you mean you'd like to find a specimen of a Python, open source, async, highly-concurrent app with a heterogenous workload? (that's not Trio?)

07:02 <belm0> hopefully there is something out there, but I don't know offhand

07:02 <fijal> no

07:03 <fijal> I mean that as far as I'm aware and I might be wrong, it looks like trio will be hard to optimize

07:03 <fijal> and it'll be hard to optimize for reasons that are unrelated to async and related to how trio is written

07:03 <belm0> today I'll try pyston on our app and see what happens.  But from the latest blog post, it sounds like pyston-full (which promises like 30% speedups) is being retired.  There will only be pyston-lite, which I'm not sure is much faster than Python 3.11.

07:04 <fijal> there are some things in python async which make it hard, but they're unrelated to method jits or tracing jits and related to how python implemented that

07:04 <fijal> belm0: anyway, it really does not seem like you particularly care what I have to say, good luck with pyston! I hope it works for you

07:05 <belm0> It's not what I think.  I appreciate the help I've had from pypy devs and others on the channel.

07:07 <belm0> cfbolz: I didn't understand this.  Do you mean the high trace-too-long abort counts and huge aborted traces seen in the logs aren't actually affecting the app performance?

07:07 <belm0> > trace too long is not a problem any more, really

07:13 <fijal> they affect the time it takes to warm up, but the stable performance should not deteriorate much because of trace too long aborts

07:13 <fijal> or at least it's less of a problem than it used to be

07:30 <cfbolz> belm0: how huge is huge?

07:34 <belm0> I looked at one aborted trace that was about 6,000 lines in the log.  I shouldn't say it was huge, because I don't know if that's relatively large.

07:35 <cfbolz> belm0: 6000 is the trace limit

07:35 <cfbolz> So that's what you would get, yes

09:41 <cfbolz> https://dl.acm.org/doi/pdf/10.1145/3568973

09:41 <cfbolz> an experiment to switch CPython to a register VM

10:21 <ronan> welp, I hadn't seen https://blog.pyston.org/2022/09/29/announcing-3-7-3-10-support-and-a-new-direction/

10:22 <ronan> I guess faster-cpython killed the let's-fork-CPython-to-make-it-faster cottage industry

10:23 <fijal> "Download counts can be misleading, and in our case it seems like most of the downloads are driven by a single project’s CI system, but we think the difference is still quite meaningful."

10:24 <fijal> what is pyston-light?

10:24 <fijal> I'm too lazy to look it up I guess

10:27 <ronan> pyston-lite is some of their JIT code repackaged as a psyco-like CPython extension

15:07 <cfbolz> dum, dum dum, another one bites the dust

16:47 <fijal> cfbolz: no, common, they're the new psyco

17:06 <lesshaste> hi