[tooltalk]

why? Did Apple achieve something that was difficult or unexpected?

IIRC, it was Apple who asked Samsung to collaborate with Intrinsity, most known for their FAST tech, to develop the Hummingbird core which was used in both Samsung and Apple's AP's. Only after having tested Intrinsity's tech, Apple acquired it -- so it's a bit stretch to agree with your narrative Samsung didn't see what was coming. Apple also took their time developing and releasing their own first AP about 4 years later. It also seems like while Apple is focusing on the single-core performance as their marketing point, Qualcomm and others are focusing on power-saving, having first implemented multi-core, then octo-cores on their chips. I'm not sure if that's a surprise or unexpected, since Apple's AP remained a single-core AP for a while.

As for the 64bit, was there any compelling reason to go 64bit mobile? I remember when I used to work for wall street banks in the 1990's, the shortcomings of the 32bit arch limited our ability to scale and SUN's UltraSPARC which was widely used by in the industry came to relieve that problem.

[simonh]

I don't think Intrinsity's tech had much to do with 64 bit, all their work before the acquisition was on 32-bit architectures.

The main attraction for 64-bit ARM is, apart from the obvious future proofing, it has a redesigned and much more efficient ISA. It also has the optional secure enclave feature which Apple used for TouchID and now FaceID. That feature doesn't actually require 64-bit per se, but it is only a feature of the 64-bit ARM architecture. As an aside, is anyone else using it for anything? I'm only aware of Apple using it, but technically it's not an Apple exclusive feature.

Your 'focused on power saving' point is correct as far as it goes, that was their intent, but unfortunately the power saving benefits of BIGLittle turned out to be much more modest and full of caveats than hoped. It turns out that a fast efficient single core that can complete an instruction in less time, then quickly shut down into a power saving mode, is more efficient in power terms for most cases than a slower lower powered core taking longer. As a result Apple's fewer faster cores approach turned out to actually offer better power efficiency as well. Since then Apple has also adopted BIGLittle, it's not a failed technology, it's just that the inflection point when it becomes worth doing was at a very different point than previously realised. Whether thats down to luck or judgement on Apple's part is moot.

[IBM]

I'm pretty sure the Secure Enclave is an Apple technology. It's similar to ARM's TrustZone but not the same thing.

[simonh]

It started off as an implementation of TrustZone but has likely diverged significantly from it since. In any case 64bit ARM had architectural features to support the implementation if such technology. Doing so on 32 bit ARM would have been a huge amount of work, and really not feasible.

[astrange]

The Secure Enclave never used TrustZone. It's a physically separate processor. (Not that this matters.)

[tooltalk]

No, Intrinsity acquisition was in 2000, years ahead of Apple's first 64-bit release.

> The main attraction for 64-bit ARM is, apart from the obvious future proofing ...

ok

> unfortunately the power saving benefits of BIGLittle turned out to be much more modest and full of caveats than hoped ... As a result Apple's fewer faster cores approach turned out to actually offer better power efficiency as well.

Sure, I'm guessing you are comparing some very early implementation of bigLITTLE by Samsung in 2012 versus Apple's single core. Or are you denying the power efficiency benefit of multi-core architecture in mobile processors (or non-mobile processor for that matter)? It's one thing to criticize Samsung's very early, first and second iterations of big.LITTLE chips in 2012, which was highly workload dependent, but it's completely another to claim Apple's single-core superiority over multi-core power-efficiency, including those non-octo core Samsung AP's. Perhaps you can substantiate this with some references?

[jsjohnst]

> No, Intrinsity acquisition was in 2000, years ahead of Apple's first 64-bit release.

You are off by a decade[0] on the date of the acquisition.

[0] https://en.m.wikipedia.org/wiki/Intrinsity

[simonh]

Were talking about the same thing, this is a historical discussion about the evolution of these processors that lead to this point. How can you suggest that I'm denying the advantages of multi-core when I pointed out Apple has now also adopted a variation of big.LITTLE?

[jrs95]

Even if they’re focused on power saving, the devices their chips end up are still less efficient than an iPhone AND they have lower performance. This might mostly be a software issue, but it still speaks to how far ahead Apple is by most metrics.

I use my phone relatively heavily, and I still get better battery life with an iPhone because the passive energy usage is just so damn low.

[xenadu02]

64-bit ARM has similar advantages as 64-bit x86. It cleans up some cruft but more importantly it doubles the number of registers.

[tooltalk]

Sure, I get that. What I'm asking is if there were any technical challenges (even to this date) in mobile computing that necessitated a 64-bit mobile chip.

[xenadu02]

I guess it depends on your perspective. Is performance a technical challenge? IMHO I say yes.

64-bit enables a number of other things. It has a better ABI for argument passing. It allows more extensive use of tagged pointers (the ObjC runtime can fit many common 11-char or shorter strings in a single tagged pointer). It's also a chance to make any other ABI-breaking changes you want to make in the runtime.

If you're forward looking you might say that mobile devices will exceed the 2GB/4GB limit soon enough so why not make the change now rather than waiting for it to become a problem? You'd get all the performance benefits listed above and a future-proof foundation on which to build.