anon (spam.delete.delete@this.this.spam.com) on October 12, 2018 4:04 pm wrote:
> 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.

For security, ARM has the advantage of supposedly having thought of this stuff from the beginning (TrustZone/EL3, v8.3 PAC and v8.5 memory region signing). That's not dispositive; obviously other vendors CAN add it (and maybe MIPS has for their IoT stuff?) But ARM has it running already, they have proofs of concept (although they also have proofs that idiots can fsck up TrustZone if they don't really care what they are doing...). And don't discount the compiler work that needs to be done, which has been done already for ARMv8.3 and will presumably be done soon for ARMv8.5 (thanks Apple and Google!)

For turnaround, that's just a question of dollars. I mean, sure, brave little MIPS is doing its best but come on, seriously?
If you're doing this in the ARM space ALL you have to worry about is making your chip work well (and match what the market actually wants...) If you're doing it in any other space, it is ALSO your job to figure out the future roadmap, to maintain the compiler and OS, to optimize new algorithms, to write the JIT, to track and fix the security bugs, to make sure the crypto libs are safe, etc, etc, etc. Everyone except x86 (and now ARM) has twice the workload, along with a vastly smaller budget.