dysfun@treehouse.systems ("gaytabase") wrote:
spin loops are everywhere in real concurrency code. usually around locks, but not just. and we just do it like we're never going to get swapped out for literally milliseconds.
to me, part of the promise of async was that we could get away from all this locking and the associated spinning. but when you go look at e.g. rust async, async primitives that need to lock are just spinning forever and hoping that the slow case won't be too slow.
i can't really do anything to make the slow case faster, but i can just not burn cpu for a few milliseconds by filling it with other work.





![[codspeed benchmarking comment saying that one PR that rewrites some of the core logic in rust will increase performance across our benchmarks by 37%. each of the tests are a processing graph run in different ways - a synchronous runner just calls the graph... synchronously.. in order, and a ZMQ runner is a multiprocess runner that runs each node concurrently, swapping events over zeromq. i figure the details are probably not important to anyone but me, but if you are curious about the actual numbers in the table, HTML is probably easier for screenreaders and tables than i can render here, so that's over here: https://github.com/miniscope/noob/pull/243#issuecomment-4977387758 ]](https://files.mastodon.social/cache/media_attachments/files/116/922/572/322/326/782/original/ebd1794cb8d3d583.png)
![[benchmarks that i ran locally on just the part that was swapped out - regular graphs are scheduled 4-5x faster than before, and large graphs are more like 10x]](https://files.mastodon.social/cache/media_attachments/files/116/922/572/396/894/397/original/58348c8898a8fdd1.png)