By: anon (spam.delete.delete@this.this.spam.com), October 12, 2018 4:04 pm
Room: Moderated Discussions
Maynard Handley (name99.delete@this.name99.org) on October 12, 2018 3:37 pm wrote:
> Simon Farnsworth (simon.delete@this.farnz.org.uk) on October 12, 2018 11:51 am wrote:
> > Maynard Handley (name99.delete@this.name99.org) on October 12, 2018 10:33 am wrote:
>
>
> > > - Finally (and CF are very careful how they say this, but I think the message is obvious,
> > > especially when you get to the comments) QC was, uh, not an optimal partner...
> > > Essentially QC and Falkor showed the DESIRABILITY of an ARM64 throughput server, but not one from ARM.
> >
> > Well, it showed the desirability of a high thread count throughput server with just
> > enough single threaded compute. ARM64 is a mirage here - as shown by them jumping
> > to a high thread count Intel chip once Intel was willing to offer them one.
> >
> > Equally, they'll happily move to ARM64, MIPS, PowerPC, or any other ISA to get the chips they want
> > - they've got no legacy hangups about staying with x86 if there's a good design out there.
>
> I'd agree with that phrasing.
> One could assert that, once these baseline metrics are met (performance parity in the ways CF demands) ARM64
> PROBABLY has (or can more easily be made to have) other properties that CF might care about, things like
> - better security (broadly defined, but could mean smaller attack surface, faster turnaround
> to fix known HW bugs, HW root of trust that works + associated non-vulnerable BMC, ...) OR
Why would ARM64 have better security than MIPS, POWER, RISC-V, SPARC or whatever CAPITALIZED ISA you can come up with?
Why would it have faster turnaround to fix known HW bugs?
> - better memory capabilities in ways that CF wants but Intel won't offer for strategic reasons (like
> more memory controllers, or some sort of wide memory support, or non-Optane NVMe support).
Again, why would ARM64 specifically make it any easier to add more memory controllers? Also AMD already does that. In the end you don't care if it was difficult or not, if a vendor offers what you want it doesn't matter.
> Simon Farnsworth (simon.delete@this.farnz.org.uk) on October 12, 2018 11:51 am wrote:
> > Maynard Handley (name99.delete@this.name99.org) on October 12, 2018 10:33 am wrote:
>
>
> > > - Finally (and CF are very careful how they say this, but I think the message is obvious,
> > > especially when you get to the comments) QC was, uh, not an optimal partner...
> > > Essentially QC and Falkor showed the DESIRABILITY of an ARM64 throughput server, but not one from ARM.
> >
> > Well, it showed the desirability of a high thread count throughput server with just
> > enough single threaded compute. ARM64 is a mirage here - as shown by them jumping
> > to a high thread count Intel chip once Intel was willing to offer them one.
> >
> > Equally, they'll happily move to ARM64, MIPS, PowerPC, or any other ISA to get the chips they want
> > - they've got no legacy hangups about staying with x86 if there's a good design out there.
>
> I'd agree with that phrasing.
> One could assert that, once these baseline metrics are met (performance parity in the ways CF demands) ARM64
> PROBABLY has (or can more easily be made to have) other properties that CF might care about, things like
> - better security (broadly defined, but could mean smaller attack surface, faster turnaround
> to fix known HW bugs, HW root of trust that works + associated non-vulnerable BMC, ...) OR
Why would ARM64 have better security than MIPS, POWER, RISC-V, SPARC or whatever CAPITALIZED ISA you can come up with?
Why would it have faster turnaround to fix known HW bugs?
> - better memory capabilities in ways that CF wants but Intel won't offer for strategic reasons (like
> more memory controllers, or some sort of wide memory support, or non-Optane NVMe support).
Again, why would ARM64 specifically make it any easier to add more memory controllers? Also AMD already does that. In the end you don't care if it was difficult or not, if a vendor offers what you want it doesn't matter.