4 ms·

Absolutely. That ARM has been gnawing on the dominance of the x86 architecture (and by proxy Intel) first became obvious to me when Intel tried desperately to m

Absolutely. That ARM has been gnawing on the dominance of the x86 architecture (and by proxy Intel) first became obvious to me when Intel tried desperately to make an x86 chip that was competitive in the Android ODM space. I still have a Lenovo Android tablet with an Intel processor in it[1]. Intel's business model of being 30% of the BOM cost for the base board just doesn't fly in the phone/tablet world. If I were still at NetApp I would be all over a filer design based on 64 bit multi-core ARM architecture with a bespoke I/O architecture to support 1000+ drives per filer. The arrival of Intel (and AMD with the Opteron) on the TOP-500 supercomputer list demonstrated the importance of channel bandwidth (memory and I/O). [1] It sucks BTW, Android gave up trying to fix all of the byte ordering problems and so many of the apps fail to execute correctly.

floatboth 6y ago
> Android gave up trying to fix all of the byte ordering problems and so many of the apps fail to execute correctly What byte ordering problems could affect x86?? The only big endian platform Android was ported to was MIPS. Maybe what you're seeing is apps with native components that are only compiled for armv6/7.
gnufx 6y ago
> The arrival of Intel (and AMD with the Opteron) on the TOP-500 supercomputer list demonstrated the importance of channel bandwidth (memory and I/O). Top500 is based on the HPL benchmark. Its problems are specifically not being sensitive to memory and networking (specifically network latency). That's why half(?) of it is things like "cloud vendor", where you're not going to run typical HPC codes past three nodes.