AnonSoft (a.delete@this.anonsoft.com) on January 30, 2023 4:34 pm wrote:
> hobold (hobold.delete@this.vectorizer.org) on January 30, 2023 11:39 am wrote:
> > AnonSoft (a.delete@this.anonsoft.com) on January 30, 2023 10:01 am wrote:
> >
> > [...]
> > > Intel cannot do much till the better fab
> > > processes come along. It's not like software where the bits are essentially free to replicate.
> > >
> >
> > Well, Intel's switch to BIG.little was a pretty genius way of squeezing lemon juice out of the
> > lemon that their 10nm process is, compared to the TSMC silicon that AMD's Zen is made of. That
> > move was creativity winning over brute force shrinking. It didn't solve all problems, but allowed
> > Intel to sort of keep up, despite their fundamental disadvantage in transistor density.
>
> Meh ... I'm not a big fan considering the extra complexity in OS software support and it being restricted
> to Windows 11. For my use cases, I'd prefer the simplicity and predictability of similar cores.

But we mostly haven't gotten similar cores for years. Instead we've had cores where once more than half of them are occupied, performance tanks.

Of course, if the solution so far has been to only run one thread per physical core, and is now changed to only running one thread per big core (none for E cores), a lot of performance will be left on the table. But performance was probably left on the table by ignoring SMT too. Personally I don't consider E cores and asymmetry to be a particular problem any more than SMT has been. If the algorithm scales, then good. Just run on every thread. If it doesn't, it's a secondary problem whether there are eight or ten (big) cores.

-JLarja