By: Maynard Handley (name99.delete@this.name99.org), November 18, 2020 1:54 pm
Room: Moderated Discussions
xyz (xyz.delete@this.xyz.xyz) on November 18, 2020 12:14 pm 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.
>
>
> SMT cores are bigger and leak more hence waste more power when SMT is not used, which is bad
> in a mobile context. On the other hand the potential security issues with SMT only apply with
> hypervisor virtualized co-located server workloads, so do not affect Apple's customers.
>
> (But considering that Apple's cores are very wide and have more unused slots
> and entries, it could be that they'd gain more from SMT than the x86 cores.)
To repeat:
"
These analyses of SMT continue to ignore why Apple does so well in IPC and energy!
SMT is a decision to swap something that is cheap and plentiful (space for an *independent* core on the die) with something that is expensive and in extremely short supply (the SRAM that feeds the predictors and caches that give you all that IPC for a particular core).
"
If you do not understand the point I am making, without trying to be rude let me suggest that you need to understand it if you want to appreciate why Apple is making the decisions it is.
> 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.
>
>
> SMT cores are bigger and leak more hence waste more power when SMT is not used, which is bad
> in a mobile context. On the other hand the potential security issues with SMT only apply with
> hypervisor virtualized co-located server workloads, so do not affect Apple's customers.
>
> (But considering that Apple's cores are very wide and have more unused slots
> and entries, it could be that they'd gain more from SMT than the x86 cores.)
To repeat:
"
These analyses of SMT continue to ignore why Apple does so well in IPC and energy!
SMT is a decision to swap something that is cheap and plentiful (space for an *independent* core on the die) with something that is expensive and in extremely short supply (the SRAM that feeds the predictors and caches that give you all that IPC for a particular core).
"
If you do not understand the point I am making, without trying to be rude let me suggest that you need to understand it if you want to appreciate why Apple is making the decisions it is.