Hyperthreads aren't real CPU cores, claiming that your 48 hyperthreads were "only" 50% utilized means all the real cores under the hood are fully utilized.
I can't think of a good principled reason to say SMT cores aren't "real".
I'm assuming the answer isn't "because they share some computing stuff". What I think you'd call "real" cores also share resources like L2/L3 caches, sometimes DMA engines, etc.
And IIRC, each Intel SMT (hyper-thread) unit has its on instruction pointer and (non-SIMD?) register set.
I believe the SMTs share the register rename storage, which I'd say is the register set more than the 'architectural registers'
But I'd say the reason they're not real is because they don't increase the maximum instructions per clock. With many loads, they do increase the average instructions per clock, but they don't let you do anymore work if you've got a fully tuned load that uses all the computing resources.
If cache contention weren’t a problem, and it was just a matter of jumping into previously unseen instructions and data (cold cache), you’d expect to see 50-300% numbers from hyperthreading, precisely because of how long the stalls are.
So "real" or not but from my experience HT does work to the benefit.
And in these days of post-Dennard scaling, you have thermal throttling, so idle cycles aren’t actually idle, they’re allowing the heat sink to catch up with heat production.
It really depends on your definition of "real", yes you can treat them like "real" independent cores but that's not ideal for performance because under the hood they're not actually independent. Your operating system is aware of this and will often avoid scheduling two tasks onto the same physical core unless it has to. If you have 20 logical cores (10 physical ones with hyperthreading) and 10 tasks to execute, the OS scheduler will usually allocate one task to each physical core and leave the other logical core idle.
I had just upgraded to an i7-3770K (8 threads, 4 cores) from a Core 2 Quad (4 threads, 4 cores). I did a POV-Ray render several times using 1, 2, 4, and 8 threads. 2 was nearly double the speed of 1, 4 was nearly double the speed of 2, but 8 was only about 15% faster than 4.
To ensure I wasn't bottlenecking RAM at that level, I tried again with 2 threads, but forced both threads onto a single core, and it was only 15% faster than 1 thread.
That was all the proof I needed of how you really can't treat two CPU threads as two cores.
That said, I've never personally found an instance where allowing a processes to span all CPU threads actually reduced performance, and I'm not sure I've ever seen a real-world case where it does. It's usually something contrived.
I liked the idea of the i7 because without HT you have a real picture of how utilized your CPU is. If it says 100% on a core it's 100%. I ended up going with the i9 though when a promotion was too good to pass up.
When I got it I ran Cinebench both with and without HT enabled in the BIOS and it made a decent impact so I left it on.
SMT is designed to hide memory load latency. In this use case it is completely brilliant. You will get 2x speedups with hyperthreading when randomly accessing memory.
...unlesss you access so much memory (while doing relatively little compute on each piece) that hyperthreading just causes more cache invalidation.
This slowdown of each thread may not matter, or it may lead to increased latency.
TL;DR - when both hyperthreads in a core are in use it is highly likely that each one is running significantly slower than if only one was in use.
HT is an opimization to context switching but if your code running on both utilizes different parts of core (say one loads some memory while others does some math), you can get speedup that's above savings from not having to context switch.
But early on it wasn't really that well optimized so you might've had OS put 2 threads on 2/1 HT/core while other core sits idle