By: Doug S (foo.delete@this.bar.bar), November 19, 2020 10:19 am
Room: Moderated Discussions
Dummond D. Slow (mental.delete@this.protozoa.us) on November 18, 2020 3:12 pm wrote:
> Doug S (foo.delete@this.bar.bar) on November 18, 2020 2:59 pm wrote:
> > Dummond D. Slow (mental.delete@this.protozoa.us) on November 18, 2020 7:52 am wrote:
> > > Doug S (foo.delete@this.bar.bar) on November 18, 2020 7:44 am wrote:
> > > > rwessel (rwessel.delete@this.yahoo.com) on November 18, 2020 7:03 am wrote:
> > > > > Ignoring whether or not it makes sense for Apple to implement
> > > > > SMT, there appear to be a reasonable number of
> > > > > workloads that do work well with SMT. Commercial workloads,
> > > > > things like database engines, which net out to quite
> > > > > low effective IPCs compared to much of what's in SPEC. Hence IBM's fascination with SMT on POWER and Z.
> > > >
> > > >
> > > > Which are exactly the loads Apple doesn't care about since
> > > > unlike Intel and AMD they don't sell commercial servers.
> > > >
> > > > Which brings you back to the question that matters for Apple: How well SMT would do with
> > > > workloads that their customers will run, especially the sort of stuff they do with phones
> > > > and tablets (since that's what funds their leading edge core designs, not Macs)
> > > >
> > > > While it might not be too hard to make an argument that SMT would benefit the Mac Pro, that's well
> > > > under 1% of Apple's unit sales of phones/tablets/Macs. Given that the area penalty for adding SMT
> > > > to the big cores is minimal I suppose that doesn't matter - just leave it disabled on the mobile
> > > > stuff. But you're still incurring the design/verification cost (and potential additional support
> > > > and reputational cost for security holes that SMT opens) for that relatively small market.
> > > >
> > > > Moreover, do you get more "extra bang for the buck" spending power running a second thread
> > > > on the big cores via SMT, or bringing the little cores into the mix when you want to add
> > > > threads? Given what Andrei's figures show for the power draw of the M1's little cores,
> > > > I'm not convinced SMT is a net power wise. If it doesn't make sense power win.
> > > >
> > >
> > > I'm pretty sure the power spend on SMT is going to be lower than the performance boost. No data
> > > at hand though. You could take an AMD CPU and disable SMT and compare the performance in heavily
> > > MT tasks. Their chips pretty much always try to hit their PTT because of the open-loop opportunistic
> > > clock control so the power consumption tends to always be the same under load.
> > > If you performance will be better with SMT, it proves that SMT gives better power efficiency.
> > > I expect it to end up like that unless you cherry pick some task that has negative scaling.
> >
> >
> > You misunderstand my point. I know that SMT gains more speed than the extra power it requires.
> > The question is does it gain more speed per additional watt used than Apple's small cores
> > do. Given how little power they use, the situation for SMT is likely a wash at best.
> >
>
> It's possible that the little companions give better boost per watt but I would not take this for
> granted at all. My hunch would be the other side, though again, hard to say from the armchair.
>
> It would be useful to look at say the Ryzen CPU and check how much will the
> clock drop if you keep the same power limit and the same load but enable SMT.
> Which I sadly can't do since I use one of the cheapo SMT-less ones, alas.
Sure, but I think you'd agree that even if SMT has an advantage over the little cores it is likely to small. If you accept that, then why should Apple devote engineering resources to adding SMT to their big cores, when they already have an improvement in the same ballpark from their little cores - which provide other benefits in terms of allowing the big cores to shut down entirely during idle periods something that SMT does not provide.
And again, SMT has recently proven to be a minefield of security issues. We have no reason to believe that all potential attack vectors have been found. If something serious is found and a software mitigation is not possible, disabling SMT is the only option. That worry does not exist with the little cores.
> Doug S (foo.delete@this.bar.bar) on November 18, 2020 2:59 pm wrote:
> > Dummond D. Slow (mental.delete@this.protozoa.us) on November 18, 2020 7:52 am wrote:
> > > Doug S (foo.delete@this.bar.bar) on November 18, 2020 7:44 am wrote:
> > > > rwessel (rwessel.delete@this.yahoo.com) on November 18, 2020 7:03 am wrote:
> > > > > Ignoring whether or not it makes sense for Apple to implement
> > > > > SMT, there appear to be a reasonable number of
> > > > > workloads that do work well with SMT. Commercial workloads,
> > > > > things like database engines, which net out to quite
> > > > > low effective IPCs compared to much of what's in SPEC. Hence IBM's fascination with SMT on POWER and Z.
> > > >
> > > >
> > > > Which are exactly the loads Apple doesn't care about since
> > > > unlike Intel and AMD they don't sell commercial servers.
> > > >
> > > > Which brings you back to the question that matters for Apple: How well SMT would do with
> > > > workloads that their customers will run, especially the sort of stuff they do with phones
> > > > and tablets (since that's what funds their leading edge core designs, not Macs)
> > > >
> > > > While it might not be too hard to make an argument that SMT would benefit the Mac Pro, that's well
> > > > under 1% of Apple's unit sales of phones/tablets/Macs. Given that the area penalty for adding SMT
> > > > to the big cores is minimal I suppose that doesn't matter - just leave it disabled on the mobile
> > > > stuff. But you're still incurring the design/verification cost (and potential additional support
> > > > and reputational cost for security holes that SMT opens) for that relatively small market.
> > > >
> > > > Moreover, do you get more "extra bang for the buck" spending power running a second thread
> > > > on the big cores via SMT, or bringing the little cores into the mix when you want to add
> > > > threads? Given what Andrei's figures show for the power draw of the M1's little cores,
> > > > I'm not convinced SMT is a net power wise. If it doesn't make sense power win.
> > > >
> > >
> > > I'm pretty sure the power spend on SMT is going to be lower than the performance boost. No data
> > > at hand though. You could take an AMD CPU and disable SMT and compare the performance in heavily
> > > MT tasks. Their chips pretty much always try to hit their PTT because of the open-loop opportunistic
> > > clock control so the power consumption tends to always be the same under load.
> > > If you performance will be better with SMT, it proves that SMT gives better power efficiency.
> > > I expect it to end up like that unless you cherry pick some task that has negative scaling.
> >
> >
> > You misunderstand my point. I know that SMT gains more speed than the extra power it requires.
> > The question is does it gain more speed per additional watt used than Apple's small cores
> > do. Given how little power they use, the situation for SMT is likely a wash at best.
> >
>
> It's possible that the little companions give better boost per watt but I would not take this for
> granted at all. My hunch would be the other side, though again, hard to say from the armchair.
>
> It would be useful to look at say the Ryzen CPU and check how much will the
> clock drop if you keep the same power limit and the same load but enable SMT.
> Which I sadly can't do since I use one of the cheapo SMT-less ones, alas.
Sure, but I think you'd agree that even if SMT has an advantage over the little cores it is likely to small. If you accept that, then why should Apple devote engineering resources to adding SMT to their big cores, when they already have an improvement in the same ballpark from their little cores - which provide other benefits in terms of allowing the big cores to shut down entirely during idle periods something that SMT does not provide.
And again, SMT has recently proven to be a minefield of security issues. We have no reason to believe that all potential attack vectors have been found. If something serious is found and a software mitigation is not possible, disabling SMT is the only option. That worry does not exist with the little cores.
