3 ms·

"whether the chip is dual or multicore, 32-bit or 64, you can bet Apple has it all tightly woven together" I don't get it. Any device maker has multiple option

"whether the chip is dual or multicore, 32-bit or 64, you can bet Apple has it all tightly woven together" I don't get it. Any device maker has multiple options in those four configurations. All mobile chip makers seek to optimize "performance per Watt". What parameters are Apple going to tweak to make it "exactly fit" rather than suffer the heartbreak of a "generic design compromise"?

tcas 13y ago
Reading over the article, it doesn't really say anything of technical content other than "Apple has complete control and can vertically integrate, applications have different needs per thread, if you can tightly couple hardware and software, it'll be fast." Computer architects have known that for decades by now. Apple isn't custom designing the IPCores for the processor or graphics. I'm willing to bet that almost all of this chip is off the shelf stuff. What they can do is choose parameters like number of cores, cache sizes, CPU options (like you said, stuff that is available with existing suppliers) and also include additional units that they can license separately (e.g. earSmart) The blog post mentions stuff like Frameworks and Apps. Unless I am very out of touch with SoC offerings these days, you don't get a MapKit.framework accelerator. You get things like H264 encoding/decoding and AES, or DSP functions which these frameworks can use. However, the faster performance you want with one function, the more locked in you get. An example of this is comparing encryption speeds on an Intel processor with AES-NI. AES is an order of magnitude faster than just about everything else. Everything else however, uses the same vector extension set that were designed specifically to speed up sub operations of common algorithms. The other advantage they get by doing an in house chip is that they can choose the on board peripherals they want (possibly remove some chips that would normally be external), and the exact number of external busses they need for all the external peripherals, which can lead to a smaller, cheaper, more power efficient chip.
aortega 13y ago
Unlike Android, Apple needs 900000+ third-party apps binary compatibility so they can't tightly weave anything, except perhaps extract a little more power savings from the kernel/CPU interface.
- engrenage 13y ago
  Only if you ignore the gigantic set of APIs that Apple also controls through which those binary apps get the vast majority of their work done.

tcas 13y ago

Reading over the article, it doesn't really say anything of technical content other than "Apple has complete control and can vertically integrate, applications have different needs per thread, if you can tightly couple hardware and software, it'll be fast." Computer architects have known that for decades by now. Apple isn't custom designing the IPCores for the processor or graphics. I'm willing to bet that almost all of this chip is off the shelf stuff. What they can do is choose parameters like number of cores, cache sizes, CPU options (like you said, stuff that is available with existing suppliers) and also include additional units that they can license separately (e.g. earSmart) The blog post mentions stuff like Frameworks and Apps. Unless I am very out of touch with SoC offerings these days, you don't get a MapKit.framework accelerator. You get things like H264 encoding/decoding and AES, or DSP functions which these frameworks can use. However, the faster performance you want with one function, the more locked in you get. An example of this is comparing encryption speeds on an Intel processor with AES-NI. AES is an order of magnitude faster than just about everything else. Everything else however, uses the same vector extension set that were designed specifically to speed up sub operations of common algorithms. The other advantage they get by doing an in house chip is that they can choose the on board peripherals they want (possibly remove some chips that would normally be external), and the exact number of external busses they need for all the external peripherals, which can lead to a smaller, cheaper, more power efficient chip.

aortega 13y ago

Unlike Android, Apple needs 900000+ third-party apps binary compatibility so they can't tightly weave anything, except perhaps extract a little more power savings from the kernel/CPU interface.

engrenage 13y ago
Only if you ignore the gigantic set of APIs that Apple also controls through which those binary apps get the vast majority of their work done.