Dummond D. Slow (mental.delete@this.protozoa.us) on November 18, 2020 3:17 pm wrote:
> Jon Masters (jcm.delete@this.jonmasters.org) on November 18, 2020 11:46 am wrote:
> > Dummond D. Slow (mental.delete@this.protozoa.us) on November 17, 2020 11:18 am wrote:
> >
> > > It's simple: SMT. Had Apple implemented it, it would run away in Cinebench.
> > > Lesson to the people saying it's a pointless/stupid/doomed feature.
> > > Seems Renoir is able to bridge its "worse single-thread" and "worse
> > > manufacturing node" disadvantage pretty much thanks to SMT.
> > >
> > > Which also tells you where the biggest threat from Apple is. It pretty much caught
> > > up with state of the art x86's single core performance AND has process advantage.
> > > It could shoot ahead in performance in two areas if it chose to:
> > > 1) SMT as discussed. Not having SMT leaves massive multithread performance
> > > gains (end energy efficiency gains, more importantly) on the table.
> >
> > SMT is a *terrible* idea for new designs. Sure, it gets you performance uplift, but it comes
> > at a cost, particularly in terms of side-channel exposure. That is a game of whack-a-mole that
> > doesn't end any time in the near future. Real cores that can be fed properly give you more
> > deterministic performance without all of the other downsides from sharing resources.
> >
> > Jon.
> >
>
> Everything has side channels, I stopped counting and stopped reporting on new attacks described. So I
> think it makes no sense to ditch SMT on the grounds of side channel vulns because there is 10-20x more
> in other parts of the CPU, discovered each year. You just sacrifice something good and then you find
> it didn't help in anything. The solution for that is to handle it in CPU scheduling (don't give two threads
> from one core to different VMs on server and so on + whatever more is needed for security).
> You don't want shared L3 cache or multicore CPUs being abandoned either, do you?

So now you're starting to concede my point.
If you're going to do SMT right, you don't share threads between unrelated entities.
That means
(a) you don't have to waste any effort worrying about security
(b) you don't have to worry at all about fairness

But then if the entities are related, why do you need the OS (except to do the context swapping correctly). Provide user-level primitives to launch, kill, and synchronize with the other thread. At which point
- the two threads are closely related, so resource contention is PROBABLY not an issue and
- the app is in control, so to the extent that contention is an issue, the app can choose not to launch a companion thread

There is a right way and a wrong way of doing things. The wrong way, in this case, is treating SMT as a fake core, rather than something like a "co-routine acceleration engine".