That isn't how hyperthreading works...
It's completely dependent on the workload.
If your using the CPU core as efficiently as possible, you'd see no benefit from hyperthreading.
If your using it very poorly, you'd see a massive 2~x benefit.
If your using the CPU core as efficiently as possible, you'd see no benefit from hyperthreading.
If your using it very poorly, you'd see a massive 2~x benefit.
I find this statement tough to agree with. It depends on the kind of work your processors are doing: it is IO heavy work or are you running Math computations? There are other axes basically related to how much work can be done by the current thread while the other thread stalls waiting for data to be fetched (or other non-parallelizable dependencies to be available).
So if you're getting a high benefit you shouldn't necessarily feel embarrassed!
That said I did switch from Intel over to an Apple M1 anyway.
What I would find really, really interesting: a "single-process" compiler that has a global in-RAM cache for all source contents and intermediate outputs and can avoid the overhead of child processes... basically a model like Webpack or Parcel that has an inotify watcher and is constantly running. The JS world had no other choice with NodeJS/npm all but forcing the tooling to adapt to a lot of incredibly small source files, it's time for the "classic" world to adapt.