A7: Apple's custom 64-bit silicon embarrassed the industry | Hacker News Reader

A7: Apple's custom 64-bit silicon embarrassed the industry

appleinsider.com

83 pointsgeofox55 comments

There's a lot of editorial speculation in this article:

> it was widely held among Android Enthusiasts that Samsung was rising up to fight back against the iPhone establishment, a sort of patron saint for Android. That was crazy

Way to classify an entire group of people :/

> Apple also had clear insight into whether or not a 64-bit SoC would be beneficial in accelerating apps. Qualcomm didn't run an App Store and wasn't maintaining a consumer mobile operating system.

They couldn't have, as none of the apps could run on the platform yet.

> while an original intent of LLVM was to bring the Mac's Objective-C language up to par with other languages in compiler sophistication

Lol, it was to move away from GPL tooling…

> Apple shared the Clang LLVM front end compiler for C, C++, and Objective-C as an open-source project in 2007, but it wasn't 2012 that it started to be widely adopted by various Unix distributions. It didn't become the default compiler for Android until 2016. In part, that's because Google wasn't creating Android to be a great product, but rather to simply serve as a good enough product to facilitate the development of a mobile platform it could tap into as an advertising platform without any restrictions imposed by Microsoft or Apple.

…

Honestly, it reads like a strung-together exercise to prove that Apple is "the best".

>Honestly, it reads like a strung-together exercise to prove that Apple is "the best"…

That is what you expect from DED ( Its Author ) and Appleinsider.

Both should have no place on HN. The same goes for WccfTech.

"flag" is there for a reason.

And I did even before replying, but seeing it on Front page and currently sitting at the top hurts me.

It's gone now.

> Lol, it was to move away from GPL tooling

GPL was a factor, but Apple didn’t move to LLVM just to avoid open-sourcing their tools (in fact, they’ve open-sourced nearly all of their LLVM-backed tooling). GCC is not very extensible and difficult to integrate into other tools (and IIRC Stallman rejected patches that tried to change this because he didn’t want non-GPL tools to be able to interact with GCC). Clang/LLVM on the other hand has a very modular design that enables e.g. seamless IDE integration for syntax highlighting/code completion (see https://en.wikipedia.org/wiki/Clang#Design).

The flexibility of LLVM is evident if you look Apple’s programming language history: a few years after hiring Chris Lattner and moving to LLVM, Apple developed Xcode 4 (which included massive improvements to the source editor because of Clang integration), quite a few extensions to Objective-C (such as automatic reference counting), LLDB, the Metal shading language, and Swift. Most of these projects are open source.

That being said, I agree with your conclusion that the author seems to be trying to prove “Apple is the best”.

It's because of the GPL3 and the "tivoization" clause. Apple was stuck on GCC 4.2, the last GPL2 version, for a very long time because subsequent versions made the move to GPL3. LLVM and Clang were the way Apple could move past having an obsolete toolchain.

Based on what happened with Apple and PowerPC in the '90s, I have to assume that if the roles were reversed now and Android phones had the processor performance lead, it would be continuously trumpeted by every pro-Android outlet in the same way.

Oh, they certainly did talk about benchmarks back when they had a lead. It doesn't make it all that useful…

Don't forget the part where they said Samsung is Darth Vader fighting against Apple.

Hard to take an article seriously with that kind of hyperbole.

what a joke.

really?

While I agree with the general thrust of the article that the 64bit A7 blindsided the rest of the industry, the way the article is written seems overly partisan. I find it kind of hard to cut through the cheerleading to get to the meat of the article.

the way the article is written seems overly partisan

I don't disagree. But it's to be expected from Apple Insider. It's a well-known fanboi blog, it's not journalism. It would be nice if people would stop posting links to it on HN and stick to more thoughtful publications.

This one is egregiously bad.

The author has been regarded as a blowhard even within the Apple ecosystem for well over a decade. He started his rise to fame with the roughlydrafted blog.

I think it would be a lot quicker and easier to just start off the post with a meme of "the Virgin Samsung Android phone vs. the CHAD iPhone" and then to stop beating us with Apple cheerleading for paragraph after paragraph.

One thing I've found with this particular author is that there typically isn't much meat to get to. The articles tend to be a verbose celebration of Apple's greatness commingled with speculation.

The whole phone industry for years has been a "me too" Android industry following in Apple's footsteps and by that I mean phone manufacturers doing half-assed versions of what Apple had.

There was a great talk at Google about how the Nexus 5X was the worst phone they ever made. It was a postmortem and actually really informative. Like the thermals were bad (eg hot components together) such that the CPU had to go in low power mode when using the camera or the thing would overheat. Part of it was they just happened to use a bad die process (20nm IIRC).

The interesting part was how Apple's announcement of a 64 bit CPU totally shook the industry. Roadmaps were thrown out and half-assed 64 bit CPUs were put into the market essentially for marketing purposes (the "64 bit" bullet point).

Apple's ARM chips are actually pretty amazing and have mostly been at a sweet spot for performance vs battery life.

To be fair, I think Apple has gone off the rails in the last few years. The examples are numerous:

- The 2015 MBP butterfly keyboard (rumour has it this only happened to shave 0.5mm off the laptop height)

- The loss of Magsafe

- USB-C

- Force Touch (from a company that famously once eschewed the right mouse button for lack of discoverability)

- Face ID (what I'd give for Touch ID on the back of the phone). This was purely to make a bigger screen. As much as they talked about the false positive rate of Touch ID being too high the false negative rate of Face ID is way too high, particularly on an iPad.

- The Touch Bar

I really do think where Apple design went wrong was when there was no longer a Steve Jobs to say "no" to Johnny Ive. A lot of the more ridiculous design fails seem to come directly from Ive (like the 12" Macbook).

But the CPU part of Apple is cutting edge.

I’m with you on every single point except Face ID. I just got my first Face ID device and it is so much handier than Touch ID. It has worked instantly every single time, and I love not having to move my fingers to the button to sign in somewhere or unlock the phone.

Although MagSafe 2 was garbage and USB-C is an upgrade. The original MagSafe was indeed something to morn.

Likewise was skeptical about FaceID, but it is really much nicer to have than TouchID. I'm not a sweaty person at all, but whenever I picked up a DualShock controller for a minute and put it down, my hands were too moist for TouchID to work.

I think USB-C isn't just negative, and I do like the touchbar, even though I have to admit that it's rarely helpful in practice. For the rest, I think you're right: Apple has lost its way forward. I fear the day the accountants will see a lucrative deal and split macOS from the phones, app and music biz is closer than ever.

> The interesting part was how Apple's announcement of a 64 bit CPU totally shook the industry.

I don't think so. The move to 64-bit compute on mobile platforms was inevitable and hardly surprising; Apple's announcement might have pushed it forward by a few years at most.

>Apple's announcement might have pushed it forward by a few years at most.

In the technology world, pushing an advance forward by a few years is shaking the industry.

He meant because it was much sooner than everyone expected.

So now people are complaining that Apple is using an industry standard port - USB-C - instead of something proprietary?

What the 64bit ISA did was move the discussion about who had the best chip design team away from performance numbers, which are always messy and arguable, and towards core engineering skill and capability.

Everyone in the ARM works knew the 64bit ISA was a huge deal. It was a fundamental reimagining of the ARM ISA, laying down the foundations for the future direction of ARM design. Nobody else was even trying to tackle this. Nobody thought anybody else had even begun either.

It was a problem only Apple was really poised to handle thanks to its vertical integration. The rest of the industry was stuck in the chicken and egg situation where the chip builders didn't own the software stack--the people doing the software were in different companies.

The transition only works well if both the software and hardware are upgraded in tandem. For Apple this is no problem, but for the rest of the industry you have to be willing to put a lot of work into a product that won't do anything until the other side catches up. It's much more risky. The general sense seemed to be that they were waiting for memory sizes to grow large enough to force the issue until Apple just went ahead and quietly pulled the trigger.

What is less forgivable is just how much of a performance gap the Android market is seemingly willing to tolerate between the latest A* series chip and whatever the fastest Android chip is. How is Qualcomm not terminally embarrassed to announce brand new chips that are two years behind what Apple is currently shipping?

Because the competition in the ARM mobile/SoC vendor area is thin. There are Samsung, Qualcomm and Mediatek plus a few underdogs no one cares about (Nvidia, Intel). Apple is no competition as they don't sell to outsiders which means there is no competitive pressure to improve. Look at the utter shit that Mediatek dares to sell (ever looked at one of their BSPs? I'm surprised there are not daily CVEs!) and yet they're highly profitable.

Plus, AWS/Google are also actively gobbling up silicon design talent to fight Intel and AMD on the server area, which is a problem as designing powerful server cores is way easier than designing SoCs for mobile devices.

How is Qualcomm not terminally embarrassed to announce brand new chips that are two years behind what Apple is currently shipping?

If we assume Qualcomm is trying as hard as they can, what's their alternative? Ship nothing? Commit corporate suicide in shame?

Engineer better and faster chips? It's not like Apple has some insurmountable process node advantage here or an ISA advantage. Everything is still some flavor of ARM.

I guess I'm saying that it doesn't seem like Qualcomm is putting in as much effort as they should. It should be embarrassing for them.

There's no incentive for Qualcomm to catch up. The flagship handset manufacturers have nowhere else to go and really only competing with each other.

Faster chips also mean more expensive chips, which would erode their price competitiveness against the iPhone especially since they don't have the volumes of the iPhone. In particular A series chips have huge and higher spec caches compared to the Qualcomm chips, which take a lot of die space, which is the prime factor in chip costs.

Finally, for Qualcomm to bring out a super-premium A series killer they would have to know, for a fact, that all the Android manufacturers would adopt it. If they didn't the per-unit costs would make them prohibitively expensive. They just don't have the guaranteed volumes. If enough manufacturers passed, the project would be a financial disaster. It's just too risky.

Check out Samsung who had 290 people designing custom ARM cores... that were no better than stock ARM cores. I suspect there's some cultural or organizational reason why Qualcomm or Samsung could spend infinite money and still end up worse.

Why should they? The high end Android market is minuscule. It’s all a race to the bottom.

> It was a problem only Apple was really poised to handle thanks to its vertical integration. The rest of the industry was stuck in the chicken and egg situation where the chip builders didn't own the software stack--the people doing the software were in different companies.

Isn't open source supposed to solve for this? What was stopping them from updating the OS along with their hardware? The only reasons I can think of are unkind enough that I'll not list them, but I'd love to hear if there's a good reason I missed.

Perhaps there could be an alternate history where Android is collaboratively developed by phone vendors, but in practice Google does almost all the work and phone vendors port it and add some proprietary customization. Because of that same dynamic, no one phone or SoC vendor could have afforded to unilaterally add ARM64 support to Android.

IIRC, Jim Keller was one of the lead engineers behind this chip, which is why when I heard he was at AMD working on their new Zen architecture in 2015, I knew it would be a success. He seems to create amazing processors then is off to do it again at another company.

Yes, industry insiders know that the success of a microarchitecture is largely determined by the work of a single person.

Can't tell if sarcasm.

It almost certainly is.

One thing I do remember about this period is that Apple's stock actually got fairly cheap compared to its earnings. Its PE got to like 12, which is fairly amazing for a tech company with the kind of barriers to competition Apple has. Investors really thought the iPhone might get undermined by Android phones in the way PCs undermined the Macintosh.

You can say this article has a lot of opinion and speculation, but I think the history of stock price shows that it is a retelling of conventional wisdom at the time and today.

The innovators dilemma talks about a similar situation with storage. Every x years a new, smaller format would arrive and everybody would brush it aside until after some time the benefits would be noticeable and everybody would scramble to jump into the new format.

This process would go on to repeat itself, not always the innovators of introducing a new format would be able to replicate this shift, mainly because they would be victims of their own success and had to keep up with expected revenue and margins.

I do remember the talk why ArmV8 took so long for fabless vendors.

Nobody wanted to pay more for cores with no software support. They would've either had to pull their own Android forks, and be sure that no game would support them, or wait till ARM will release a core with both V8 and V7 support, and let marketing to feed people an idea that 32 bit code somehow runs better on 64 bit cpu.

<i>Nobody wanted to pay more for cores with no software support.</i>

This is just the general backwardness of many of the SOC providers. ARMv8 has a 32-bit compatibility mode (aarch32) designed to run 32-bit software. So any core produced would have run any of the existing android/etc OS's and applications just fine with a path forward to 64-bit. Since all the major players had their own core teams they could have been tasked with making armv8 cores, but instead were doing the minimum required. Its only after they got broadsided by apple did they scramble to license ARM's cortex designs since they didn't have any of their own.

edit: Just to add to this, despite the article, ARM was doing just fine in the smartphone market selling a 32-bit architecture against mips & x86 which had a 64-bit architectures. The articles comments about the additional registers fail to note that 32-bit arm had a pretty generous register layout (16 GPRs) and wasn't at all register starved in relation to something like 32-bit x86. Similarly with NEON/etc. QC/etc were right that 64-bit didn't bring much to the smartphone market at that time except for a path forward. To this day there are a lot of applications that fail to gain any benefit from going to 32-bit which is why x32 and the arm64 ilp32 ABI exist.

> ARMv8 has a 32-bit compatibility mode (aarch32) designed to run 32-bit software.

It did until Apple dropped it ¯\_(ツ)_/¯

The danger is releasing a more expensive chip that is no faster at running existing 32-bit code and having no phone manufacturers opt to use it.

But this isn't really how it works. The chips were getting faster, so you just do it along with the planned uplift changes. Most people didn't buy Athlon64s because they were 64-bit (except for us computer geeks) they bought them because they were the next evolution of a better processor than the competition at the time.

That was fine and dandy in the early-2000's when Moore's Law was still in full swing. Chip makers aren't practically guaranteed a compelling speed and efficiency boost just because a year or two have passed since the last gen, where it was a no-brainer to toss in 64 bitness since process improvements would gloss over any deficiencies or regressions.

Why to have extra functionality for more $ when you can use just standard one? They are counting cents on those chips, margins are horrible...

Because, tech industry business 101: If your not moving forward your getting left behind. That is unless your colluding with everyone else in the space to slow innovation. The second ARM announced there would be a 64-bit version of their architecture, every single player should have been planning a migration with the knowledge that their competitors probably were.

> aarch32

But aarch32 adds a whopping 0.8 mm^2 to the core! sarcasm

It's not enough to just run existing code. You need new code to run.

It's a chicken and egg problem. No serious gamedev company is going to invest in code that is capable of taking advantage of new stuff when there is not a single one device on the market (and the issues of the first generation known and work-aroundable), and no chipmaker is going to invest into radical modernizations if there is no demand.

And you get that code by giving developers hardware to run it on. Outside of some hardcore early bring-up guys just about no one develops software on models and emulators.

You lost me at "PC". That term died decades ago.

Reply on news.ycombinator.com