Conversation

Notices

1. Embed this notice
   ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Thursday, 01-May-2025 18:37:07 JST ✧✦Catherine✦✧

   wtf

   i have a 12-core CPU that is occupied with basically nothing

   simply moving my mouse between two windows is causing an IO-bound task to drop ~20% in performance

   ... but only if i use pypy. if i use cpython it's stable

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Thursday, 01-May-2025 18:41:13 JST ✧✦Catherine✦✧

     in reply to

     • Tobias
     • CF Bolz-Tereick

     @krono @cfbolz in general on this workload (libusb via ctypes + some array mangling + asyncio) pypy is doing a lot worse than cpython; worse latency even when warm, worse CPU%, worse throughput when handling lots of small packets

     i'm surprised. unfortunately not easy to reproduce since you need (commercially available) custom hardware

   • Embed this notice
     Tobias (krono@toot.berlin)'s status on Thursday, 01-May-2025 18:41:14 JST Tobias

     in reply to

     • CF Bolz-Tereick

     @whitequark /cc @cfbolz

   • Embed this notice
     Timon 🛠 (timonsku@mastodon.social)'s status on Thursday, 01-May-2025 19:29:54 JST Timon 🛠

     in reply to

     @whitequark Is the task itself USB related? Or does it really only happen when the Mouse interacts with these two specific windows?

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Thursday, 01-May-2025 19:32:57 JST ✧✦Catherine✦✧

     in reply to

     • Timon 🛠

     @timonsku USB related; the mouse is Bluetooth. I think it happens when graphics stuff occurs because just looking at an animated gif in a browser does the same

     but also, why is cpython not susceptible to it

   • Embed this notice
     Timon 🛠 (timonsku@mastodon.social)'s status on Thursday, 01-May-2025 19:39:52 JST Timon 🛠

     in reply to

     @whitequark Hm ok, there is a chance it still interacts with USB packet processing depending on OS but that seems unlikely the issue then.
     Wild though and yea that they perform differently makes it more absurd. Feels RAMy if its happening in these situations and these two environments performing so vastly different.

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Thursday, 01-May-2025 21:23:36 JST ✧✦Catherine✦✧

     in reply to

     • Jann Horn

     @jann almost certainly yes

   • Embed this notice
     Jann Horn (jann@infosec.exchange)'s status on Thursday, 01-May-2025 21:23:37 JST Jann Horn

     in reply to

     @whitequark does one of the two implementations involve more thread switches, where you have lots of "thread A wakes thread B, then thread A goes to sleep"? AFAIK the kernel already can't handle those particularly well (https://youtu.be/KXuZi9aeGTw?t=611), and I imagine adding more noise to the scheduler could make things worse?

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Thursday, 01-May-2025 21:27:22 JST ✧✦Catherine✦✧

     in reply to

     • Jann Horn

     @jann part of a CPU but i don't think it bumps into TDP limits... don't *think*

   • Embed this notice
     Jann Horn (jann@infosec.exchange)'s status on Thursday, 01-May-2025 21:27:23 JST Jann Horn

     in reply to

     @whitequark is the GPU part of a CPU that enforces a combined TDP limit or are those things completely separate?

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Monday, 05-May-2025 11:40:49 JST ✧✦Catherine✦✧

     in reply to

     • Tobias
     • CF Bolz-Tereick

     @cfbolz @krono oh, that's interesting! in my case, I use asyncio almost entirely to talk to my own code (libusb asyncio bridge), which may skew the results somewhat

   • Embed this notice
     CF Bolz-Tereick (cfbolz@mastodon.social)'s status on Monday, 05-May-2025 11:40:50 JST CF Bolz-Tereick

     in reply to

     • Tobias

     @krono @whitequark we are probably kind of bad at asyncio. We never had a great benchmark based on that, and thus never focused on it. Maybe I should find some program that relies heavily on async, and try to profile it.

   • Embed this notice
     Tobias (krono@toot.berlin)'s status on Monday, 05-May-2025 11:40:51 JST Tobias

     in reply to

     • CF Bolz-Tereick

     @whitequark @cfbolz meh.
     If this workload is somewhat interpreter style, then I have seen such things before. Also pypy would be somewhat more happy with cffi than ctypes, as far as I recall.

     Regarding the sudden drop, It *might* be that pypy just found that one speculation did not hold and has to look at the "new" trace. but if that happens repeatedly, thats no good.