Totally sounded like Star Trek. LOL. I imagined Mr. Scott yelling something about the transporters not being able to lock onto the antimatter.

Agreed on horses for courses. Different people have different tolerances. And yea, all things being equal, faster is better, but they are almost never equal. If you don’t mind me asking, what does “too slow” mean for you in this context? Do you have a particularly complex setup? And what do you use now as an alternative and how has that impacted the update speed?

This feels like a solution looking for a problem. I have a couple hundred brew packages on my system and I’ve never sat there thinking “If this was only 2 seconds faster…” while doing an update. I’m sure the Homebrew folks could mine this for a few ideas of how to further optimize brew, but I don’t think I’ll be adopting it anytime soon. Compatibility is more important than speed in this case.

I’ve read this multiple times over the years and this post is still the most interesting and informative piece describing the problem of making a fast grep-like tool. I love that it doesn’t just describe how ripgrep works but also how all the other tools work and then compares the various techniques. It’s simultaneously a tutorial and an expert deep dive. Just a beautiful piece of writing. In a perfect world, all code would be similarly documented.

How is the QoS communicated to the scheduler? Is there a mark on the binary or does the code do it at thread startup?

For laptops at least, I appreciate not having fans that sound like a helicopter. I guess for Mac Mini and Mac Studio having more fan noise is acceptable (maybe a switch would be nice). One of the things that I love about my Air is there is zero fan noise all the time. Yes, it throttles, and 99% of the time I don’t notice and don’t care. Yes, I know there are workloads where it would be very noticeable and I would care, but I don’t personally run too many CPU bound tasks.

Does anyone have any insight into the MacOS scheduler and the algorithm it uses to place threads on E vs. P cores? Is it as simple as noting whether a thread was last suspended blocking on I/O or for a time slice timeout and mapping I/O blockers to E cores and time slice blockers to P cores? Or does the programmer indicate a static mapping at thread creation? I write code on a Mac all the time, but I use Clojure and all the low level OS decisions are opaque to me.

Itanium wasn’t a turd. It was just not compatible with x86. And that was enough to sink it.