This is why things like the Apple M Series feels so fast, because while they don't win the multi core performance especially when going up against a 80 core beast like this, they have single thread performance exactly were it is needed.

Maybe we will need 80 cores in future, that is cool but for daily home use it is still just way too much for what we need.

All he had to do was build some packages from source, right? It's really worth learning how to do this, since it removes a lot of constraints.

And the kernel patch should land in the kernel pretty soon, I hope? He won't have to run a patched kernel forever. Should be possible to get that in a release in a year or so?

I dont see this experiment as any kind of "failure". Something was learned, and OP is better off for it. Computing and science literature would be a lot better off if people, like OP, honestly documented where things went wrong.

> The “wooster” system stays powered on, churning through RISC-V package builds. It may be weak in single-thread, but it flies when it comes to multi-core load.

Feels vaguely hilarious that the ARM box didn't work out as a desktop, so instead it gets repurposed to cross-compiling RISC-V packages:)

So could you fix that with a new scheduler? Or you just need another SoC with better single core performance? I could imagine that the latter already exists, just not in soc with >16 cores. My naive view is that such high core count system comes with tradoff on core size and interconnect/memeory bus complexity.

And I mean.. my phone is a middle lower end device and for sure I can play youtube videos (maybe in a popup as well) and run the browser without noticing that much difference from my laptop.

how it helped to solve problems and search over git sources.

intresting what he would achieve mixing nixos and ai for patches.

It is called Apple Silicon.