Based on this article, it doesn't sound like Bloomberg has enough information to distinguish between Apple being committed to a transition, or Apple developing chips to improve their negotiating position with Intel. It's also very unlikely to happen on such a fast timetable; given the IP situation, it's unlikely Apple could make an x86_64 chip, and any move away from x86_64 is going to require significant work by third parties outside Apple who haven't even heard of the possibility of this happening until today.
> Apple developing chips to improve their negotiating position with Intel
Not necessary. They only need to ship one model of Mac Mini or any small desktop lineup with Ryzen to improve their negotiating position while still being compatible with the existing x86_64 ecosystem.
So no, this is not merely a negotiation jibe. There are definite long-term prospects.
We're already moving to a mobile-first design and approach world. Having those mobile/tablet apps expand automatically to desktop is the next logical conclusion. As an app developer, there is nothing better than write-once-run-everywhere, and the cascading effects of that on the whole Apple ecosystem and future consumer audience is hard to understate. Keeping aside power, efficiency, device prices, opportunity costs and much more.
> significant work by third parties outside Apple who haven't even heard of the possibility of this happening until today.
Definitely not today. Its been speculated for many years now ever since the A4 chips, and its still not official news. Usual "people who don't want to be identified". If or when this becomes official news, most partners would be like about time, because everyone is in one way or another working on convergence and multi-device. Adobe and Microsoft are examples of pivoting many of their desktop businesses successfully to cloud and apps already.
> ... I've always thought this is a bad idea ... A finger is not a mouse
There are no good or bad ideas :) Its all about time, place, knowledge of tradeoffs, execution, business, marketing, taking into account all stakeholders (user is one of them) and everything holistic :)
What you say is true, a finger is not a mouse. But we're now a decade past the release of iPhone, and by this time, the industry in general (and Apple in particular) have deep knowledge about all the tradeoffs involved here. 5 years before and this can be considered a reckless bet that requires a Steve Jobs to pull out. Now, its just natural evolution. Responsive design has been around for even longer, and changing interactions based on screen and form factors is a pretty mature problem domain now.
To be very specific:
- whether its a finger or mouse can be a runtime decision, not necessarily a compile-time or clean-slate/distribution decision for different platforms
- those decisions are already standardized enough based on existing knowledge that you can let the platform/framework (or 3p libraries) handle it out-of-the-box for you and just register multiple possibilities. instead of debating finger vs mouse - think finger and mouse
i.e. different interactions requiring entirely different apps - is not necessarily true for all of them. for a 2D application, some amount of standardization is actually good, otherwise it doesn't really help all the interaction patterns and may instead stagnate them.
Its easy to succed when you have the monopoly in PC operating systems so success of Win 8 proves absolutely nothing. Touchscreen in PC is about as useful as a waterproof towel
I'm also surprised that no one (of significant voice) has voiced enough to pressure Apple to think about their developer user population. Everywhere I go I see devs using mac. I'm sure the reason behind this is 2 folds: supported hardware, x64 + Unix platform. So if they make the transition, say, in 2020, the dev world must be prepared by the end of 2019, I mean, from every toolchain to dev Apps. And this would seem quite a big endeavour, not that devs world moves slowly but the amount of work...
Apple did a pretty decent job when they transitioned from PPC to x86_64, it has Rosetta to translate PPC to x86. Microsoft and partners released ARM based Windows Laptops this year that can run Win32 apps in emulation.
What's stopping Apple from shipping Macbooks with a custom SoC that can run existing Apps in emulation until developers can recompile? I would argue that most Air and Macbook owners aren't developers and probably don't have many apps that didn't ship with their system.
Yep. Just to put this into perspective: tiny NeXT shipped NeXTStep on 4 architectures. M68K, Intel, PA-RISC and SPARC. They had at least two more in the lab, M88K and PPC.
Compiling for different architectures was a checkbox in ProjectBuilder (after you took care of endian issues, once). Much easier than in Xcode today.
My favorite was that they apparently shipped an additional architecture by accident: the developer tools came with one of the aforementioned architectures long after it had been officially dropped.
That’s a popular line around here but it doesn’t line up with the reality. When they’ve done architecture changes in the past they’ve reached out to large developers for feedback before committing to the changes being made. The original very OpenStep like OS X did not ship en mass because it lacked a bridge library to support developers and Adobe and others cried foul. That’s how Carbon came about. When 64bit Carbon was shelved some 10 years ago, the “sky is falling” was proclaimed but Adobe came along for the ride and everything was fine. Are Technica did a great write up summarizing both the genesis and end of Carbon development [0]
The PPC transition and Intel Transition both had emulators, fat binary support, and for the Intel transition, early access to developer hardware [1]. I’m not sure how much more you can ask of Apple. The current iOS simulator compiles to native Intel code and then builds for deployment use the appropriate CPU target. The tooling is mature and the execution know.
Apple can certainly do better in a lot of areas, i.e. Swift examples that are either missing or are too old to compile. This is something they’re competent at.
Apple spent a lot of effort with each transition trying to make it as smooth for customers as possible while still pushing forward with the new system.
I have no doubt some customers were caused pain by the transitions, and some left the Apple world entirely, but characterizing them as being "fucked over" seems a bit over the top.
It’s true that Apple fumbled 68k —> PPC as far as MPW went but it’s also true that creating fat binaries was a total non-issue with CodeWarrior. Apple had learnt from that mistake for PPC —> x86
The difference is that the x86 chips were so much faster than what they had for PPC, that they could still emulate it without customers feeling like they were going backwards.
If you are changing CPU architecture, you have three options with respect to backwards compatibility.
1) Old programs don't work, because it is a different CPU architecture.
2) Old programs work, but in a VM, so it can't take full advantage of the hardware.
3) Old programs must be recompiled to work on new architecture.
The last one is the preferred option, but is only possible for open source software. If options 1 or 3 are taken for proprietary software, the customer needs to buy a new version of the software.
You go through some mental gymnastics to make it seem like #3 is only possible for open source.
Look - Apple or any other vendor isn't beholden to one CPU architecture. Such expectations breed monopolies - like Intel in PC CPUs.
None of your arguments prove that Apple is fucking over customers or developers. If anything, this opens up the market for newer, more nimble companies that'll fill the gaps left by slow moving, irrelevant apps/software.
I'm looking at it from the point of view of the customer. If I don't have the source code, I cannot recompile the code, end of story. The company that sold the binary executable might recompile it for the new architecture, but they're probably not going to give the recompiled binary away for free. That is why I say that #3 is, for the user, only possible for open source.
I agree that vendors are not beholden to a CPU architecture, but let's not pretend that switching is immediately beneficial to the user. What you call "opening up the market", I call adding unnecessary obsolescence to programs that chose not to add planned obsolescence in the first place.
If anything, I would take this as further evidence that software should be sold as source code, because the utility of mere build artifacts can be taken away.
You can conjure up fictitious reasons, but the manufacturer never guaranteed the buyer that future hardware versions would use the same CPU.
Then there's your contrived reason to obtain source code - another bogus, non-sensical reason that'll never fly with devs.
You always have the choice of staying with an older model, or better, using Linux on your custom hardware. Don't push your socialism/communism on one of the most capitalistic companies on Earth (Apple)
It's not powerful/faster that sells chips, it's power and speed relative to envelope. Maybe the iMac pro continues to ship with Xeons, the iMac with Core i5 and i7 depending on configuration.
But compare the Intel Core m3 to the Apple A11, and a completely different story will emerge. The A11 is already comparable to relatively recent Macbooks in terms of performance.
The point is, if we're going to bring up what an 'easy' time Apple has had transitioning from one architecture to another, it's worth remembering each transition came with a big performance jump. This made the new platform desirable and emulation bearable. If they are considering a transition again, 'bearable emulation' is not as much of a given.
While single core performance may not be higher, I could see Apple adding more cores than their current Intel offerings have, and still fall within an acceptable power envelope (thermal, battery life, etc).
My memory is that the PPC -> x86 jump was due to PPC supply issues and the fact that the PowerPC 970 / G5 was too power hungry for laptops. I could be wrong, but I administered labs of mixed x86 / PPC Macs during the transition and the performance jump seemed just like the normal difference between successive generations.
Keep in mind that while you don’t see much 68k outside embedded these days, you still see POWER in supercomputer rankings, and it also appeared in game consoles.
They were a lot faster, especially the laptops. And that was really the consumer proposition in both cases - you put up with our switch in exchange for a faster, better, stronger computer.
If Apple ends up doing it, the proposition would almost certainly be different and it seems very unlikely it would involve things like running your x86_64 macOS apps on your brand new Mac except three times slower. Thinking about this in terms of previous changes (or in terms of PPC history details) just seems obviously wrongheaded to me.
People assume that everyone who uses a Mac is running Photoshop or developing advanced AI but they're not. There are a lot of professionals using Apple products but they avoid the low end like the plague. Apple is a lifestyle brand these days and much of the user base has no demand for anything beyond the core Apple Apps.
The Macbook Core i3 is barely enough to run Safari or iTunes and Apple could probably replace the CPU without many of those users ever noticing.
I'd expect a huge performance jump when the new ARM-based Macs come out, both in Single-core (they can ramp up the clocks and increase cache and execution units) and Multi-core (they can add more cores to fit new power budgets as well).
The current A11 chips for iPhones are within 10% of Intel's top mobile chips on Geekbench, and within about 30% on their top desktop CPUs.
It's entirely possible for chip architectures to see 2x-3x speeds when moving from mobile power budgets to desktop power budgets.
An Intel Pentium 4410Y Kaby Lake running at 4.5-6 Watts gets about 1800 single-core on Geekbench, while an Intel Core i7-7700K Kaby Lake running at 115 Watts gets 5600 single-core on Geekbench.
> The current A11 chips for iPhones are within 10% of Intel's top mobile chips on Geekbench
No, they aren't. iPhone X's multithreaded geekbench score is 10k. The 15" macbook pro is 15k. That's a lot more than 10%. It's only close if you look at the lower end Intel chips, the dual core ones (which is what Apple ships in the 13" macbook pro).
Those are multi-core numbers, not the single-core numbers.
What do you think is the most important for 250million desktop users? Because the vast majority of them are sitting idle waiting for interaction tasks, like on your system now.
> Because the vast majority of them are sitting idle waiting for interaction tasks, like on your system now.
My dual Xeon E5-2690 v4 regularly loads all its cores and benefits greatly from them, but keep making assumptions by all means.
But if all you want is a chromebook competitor then sure, A11-class works fine. I'm going to guess that the people using Mac Pros tend to care a bit more about just running Chrome/Safari, though. Maybe Apple is just going to completely give up on their historically strong content creation market.
Maybe the first few hardware revisions it won't be as performant. Its probably going to be an Armbook that will have the form factor of the Air or the Macbook but with A12 chips. The current A11s are in striking distance for performance.
The current A-series SoC’s were also designed around the power and thermal requirements of a mobile phone. In a laptop or desktop they would have a lot more wiggle room.
I don't think we can make that assumption here. I would be very surprised if the ARM chips they put in desktops are identical to the ones they put in phones.
For one, the power budget is going to be a lot larger (even for a notebook), and power is roughly equivalent to speed.
Apple's ARM chips compare favorably to the crap that is in most laptops. Those Intel Core i3 6100U or Core i5 6200U chips? The midrange and low end will be greatly served from ARM chips.
They will not compete at the high end against the Core i7s with 6 cores running at 3.8GHz (12 with HT) though.
4217 for Apple A11 @ 2.4Ghz vs 5683 for Intel Core i7-7700K @ 4.2GHz
Of course, microbenchmarks don't mean much. But the margins are thin enough for users to notice already. Add in more power, more cores, more Ghz, better optimized instruction set, more vertically integrated system, and who knows.
geekbench scores look impressive because they are very very short bursts to prevent power/thermal throttling on iphones, iphones are able to scale up/down preformance wise very quickly, x86 CPUs less so, so what is really being tested is how fast can a cpu jump from idle to full speed.
Geekbench is not at all a reliable benchmark that tells you anything about real preformance.
Its a total farce to suggest that a CPU with a power budget that is 10x to 20x larger, on a modern process, with modern archtecture is somehow just as fast or slower.
Indeed, we have every indication that Apple can already do both of these things. Go look at Geekbench 4 single-core scores for the current iPhone and iPad vs. the current MacBook Pro. Apple is already beating Intel on speed in a design that uses MUCH less power.
I guess that Apple would have the resources and knowledge to create an extended ARM architecture that could match x64 in the same power envelope, if they really really wanted.
The market segment isn't that large though so it seems tough to get it done within the laptop budget. Still, it could benefit the other devices and streamline the hardware development, so maybe they think it's worthwhile.
Will it be that simple? Apple's own Logic Pro ships with a lot of legacy products from Emagic days. I know they've re-skinned a few with the last couple releases, but I'm guessing a lot of the DSP code is still the same.
Creatives who want hardware optimized Adobe apps to continue to be fast will care. I wouldn't count on emulation of vectorized code to work all that well.
Yep, I think people tend to gloss over how smooth these transitions really were. From a creative professional perspective, they were huge short-term PITA until Adobe etc had everything ported over. Also Excel lost VBA support for several years.
At least for me "professional Excel users" sent out stuff that I could not open, and that is not good for the for the platform.
"Spreadsheet macros" were like hot personal computing shit in 1983. Really not good if you cannot create them in 2008.
,
(Few complaints about the current Mac MS Office, FWIW) I'm just saying that breaking old stuff often takes year to fix.
No, I get it. I just think that, in general, people who spend a big chunk of most of their work days using Excel kind of consider anything other than Windows MS Office Excel a non-starter.
Adobe's transition was somewhat rough because they took the Carbon route, and then had to do it again to switch over to Cocoa. I expect that now that all their apps are built on Cocoa, the transition will be relatively breezy.
emulating x86 on ARM with any kind of real preformanceis additionally tricky because the x86 archetechure has very strong memory gaurentees (dosent matter if memory is aligned, dosent matter when in the instruction pipeline you access it, etc) that ARM isnt even close to matching.
Emulating that requires a massive performance hit, because you essentially have to check every single memory access to make sure its not doing something invalid on ARM.
From what I've heard, x86 to PPC or ARM emulators are doing dynamic recompiling and instrumentation. It catches the illegal memory accesses and rebuilds the code responsible to add paths with slower code with alignment compensation.
A lot of x86 code is aligned for speed already so it's a pretty safe bet to assume alignment and fix it up if wrong.
Apple has an architectural license. I would expect that allows them to add instructions (assuming modern ARM still has the concept of instruction set extensions)
If alignment fault checking is enabled (the A bit in CP15 c1 is set), the MMU generates an alignment fault on any data word access if the address is not word-aligned, or on any halfword access if the address is not halfword-aligned, irrespective of whether the MMU is enabled or not. An alignment fault is not generated on any instruction fetch or any byte access.”
As much as Apple made a big deal marketing "Rosetta", behind the scenes it was a product from Transitive called QuickTransit. QuickTransit is gone now, absorbed by IBM. In comparison the 68k to PowerPC emulation was very primitive and slow and mostly appeared to work because of how unbelievably slow 68ks were vs PPC.
> It's also very unlikely to happen on such a fast timetable
the article (thin as it is) claims a multi-step transition. Apple almost certainly has a version of Mac OS that can run on their iPad hardware - the transition path that makes the most sense to me is a 12" MacBook that runs essentially the same internal hardware as an iPad pro, and a MacOS that can run iOS apps. There would be a great consumer market for a MacBook that runs iOS apps, and it would serve as a hardware test bed for developers to get their MacOS applications ported over to ARM before transitioning the MacBook Pro lineup away from x86.
>We feel strongly that customers are not really looking for a converged Mac and iPad, because what that would wind up doing, or what we’re worried would happen, is that neither experience would be as good as the customer wants. So we want to make the best tablet in the world and the best Mac in the world. And putting those two together would not achieve either. You’d begin to compromise in different ways.
Of course this is from 2015, and it’s possible they’ve been prototyping for years and think they can overcome the fear of a subpar device.
But as a former Surface Pro owner who now has an iPad Pro, I don’t see that happening. The iPad is immeasurably better as a tablet when you have tablet-oriented software available. And when you don’t, obviously the Surface’s compromise of “have a crappy desktop experience too” is usable if you need to have that option. But it’s not good compared to stuff designed for a tablet.
Similarly, the chunks of Windows 10 that are clearly designed for touchscreens (like the new Settings app) are not great on a desktop compared to the older and still more powerful control panel. More consistent, sure, as any ground-up redo would be, but the information density of things like the Add or Remove Programs list is awful compared to what it was before.
I don’t think Apple is going to make those compromises. They might do a more converged developer backened for Mac and iOS to make it easier to target both platforms, but they won’t shove the frontends together.
> I don’t think Apple is going to make those compromises. They might do a more converged developer blackened for Mac and iOS to make it easier to target both platforms, but they won’t shove the frontends together.
This, I think, is the most accurate picture of future iOS / Mac convergence. Universal binaries that present either a desktop, tablet, or phone UI based on where they're running.
Microsoft's mistake was trying to converge the desktop and tablet UIs.
They already have one App Store where a single purchase gives you a cross platform app with a different frontend across iPhone, iPad, Apple Watch, and Apple TV.
Unifying the Mac frontend into that ecosystem just seems like the obvious conclusion.
I don't know that they'd strictly be the same executable, but at least as far as the user is concerned they would be the same piece of software. From a developer perspective, multiple UIs built with slightly different flavors of AppKit depending on the UI paradigm, including the Mac which is currently targeted by AppKit.
I don't see it taking over for everything necessarily, but there are a lot of places it would help. Like Paprika Recipe Manager, which costs $5 for the iPhone/iPad universal app, but if I wanted the Mac version it's $30. Part of that is a "because I can" pricing, the market will bear it because there's just not that much competition compared to iOS apps. Another part is "because I have to," it's a much smaller market and a bunch of additional work to make the Mac version, so the price has to cover those costs with fewer users.
If it didn't need a totally separate UI framework, ports like this would take less effort and more apps would do it. Maybe you can't sell it for 6x the cost any more, but a comparatively small amount of work gives you a leg up on the competition.
Twitter is another example. They killed the native Mac client earlier this year and said "For the full Twitter experience on Mac, visit Twitter on web."
Microsoft has been trying convergence for years and have been awful at it, but there are finally some real implemented concepts like modifying the task bar based on tablet/desktop modes.
Realized at scale I still think this strategy could work and with Apple's tight control over the iOS software landscape there is some hope of having iOS as a second-, class citizen on mac OS.
Apple has a long history of being strongly against things right up until they actually do them. And i think there's a significant difference between a converged iPad and MacBook, and a MacBook that is still primarily a laptop that runs MacOS, but can run iOS apps as a sort of bonus feature and consolation prize for incompatibility with existing Mac apps.
It's also worth noting that when he said that, Chromebooks didn't run android apps.
They may never release it but no doubt they have it. There are iMacs in Cupertino running macOS on ARM and there are iPads running macOS. During the PPC transition it was pretty obvious that Apple had been building OS X to work on Intel for a while secretly.
If apple uses its own chips, I would assume that they would be aarch64 and not x86_64. Also, Microsoft has some magics for executing x86_64 binaries on aarch64 with good performance, so Apple may have a similar technology. We could end up with another situation similar to the Power->x86 transition that happened back in 2006.
Or it could be nothing. This is a pretty thin article.
> If apple uses its own chips, I would assume that they would be aarch64 and not x86_64. Also, Microsoft has some magics for executing x86_64 binaries on aarch64 with good performance, so Apple may have a similar technology.
They definitely do have OSX running on ARM64, they had OSX running on x86 for years before the switch (in fact they had OSX running on x86 before it even was OSX, NeXT ran on x86, SPARC, PA-RISC and 68k, PPC is the one Apple had to add), they've already gone through two architectural migrations (68k -> PPC and PPC -> x86) and by all accounts the iOS core is very much shared with OSX, it wouldn't make sense not to port OSX along the way.
> they had OSX running on x86 for years before the switch (in fact they had OSX running on x86 before it even was OSX
Although NeXTStep ran on x86, the MacOS build on x86 was John Scheinberg's personal skunkworks project until it became Marklar in 2001 (and then kept under the hood for another four years). Mind, Darwin was always written to be portable, but it wasn't a deliberate strategy to take it to Intel. This time around though, I too reckon that they have already a MacBook running on an A10X in the labs.
What I'm really curious about is what they've still maintained: what they publicly ship now is all little-endian; are they still maintaining any big-endian port? Do they have a big-endian ARM port? Have they preserved the big-endian PPC port?
> ...Microsoft has some magics for executing x86_64 binaries on aarch64 with good performance...
I was just listening to a Windows Weekly podcast about that, and its limited to 32-bit x86 binaries only, no 64-bit support. They also said its "unusable" for 32-bit apps (in particular Chrome), because you can watch the system drawing the windows of x86 apps on the screen.
Watching the video, they seem to be exaggerating a bit with "unusable", but Chrome does look sluggish, and the startup of "DrRacket" and its window redraw does look very slow too.
Ahh that is a bummer. I only read about the translation stuff when it was first announced, before there was much info on the details.
Edit: After watching the video, that didn't seem too bad. Perhaps it would work well enough on top of a beefier ARM processor? Of course the lack of x86_64 support is another issue that may not have a reasonable solution.
> Also, Microsoft has some magics for executing x86_64 binaries on aarch64 with good performance, so Apple may have a similar technology.
I'm reminded of the patent-sharing agreement between the two. Or, given MS' diversification, they may be willing to directly license the tech. Making the x64 -> aarch64 translation as robust as possible has benefits for both companies, and they're not nearly the bitter enemies they used to be.
> High Sierra is the last macOS release to support 32-bit binaries
"Without compromise". We'll see what this means later, but most likely it'll mean that macOS won't ship with a 32-bit runtime and you'll be able to download as you do with Java.
To be fair, their PPC-on-Intel emulation that let old versions run of apps (and the entirety of OS9, IIRC) was a technical marvel on a number of levels - especially considering the hardware limitations of the early chips.
Mac OS 9 never ran on Intel. That was a separate migration path, where Mac OS X would run a Mac OS 9 VM, but this "Classic" experience never made it past PPC.
On PPC you could either dual-boot or run OS9 (and 8?) apps seamlessly on an OSX desktop, which was pretty impressive.
The seamless emulation of OSX-PPC apps on an Intel processor was extremely impressive though. I remember the majority of stuff working surprisingly well with little slowdown (though this might now be rose-tinted).
Mac OS 9 could run apps written for anything from System 7 onwards, and sometimes even System 6 apps though that was hit or miss. It could even run 68k binaries.
Mac OS 9 inside of “Classic” (the VM that ran OS 9 inside of OS X) wasn’t especially seamless, but what was seamless was “Carbon”, a transitional API that allowed developers to build apps that ran natively on both Mac OS 9 and Mac OS X. It didn’t take nearly as long to port code from OS 9 to Carbon as it would have taken to port to Cocoa, so many early OS X apps were Carbon ports.
> significant work by third parties outside Apple who haven't even heard of the possibility of this happening until today
I dunno, I feel like the writing has been on the wall for Apple to switch to their own ARM chips, for 3 or 4 years now. At first it was "yeah maybe someday", but by this point, I'm just surprised they're waiting until 2020. I was hoping the first ARM Macbooks would be this summer. (Really, last summer, if I'm being honest).
Agree this was obviously something that was going to happen. My prediction was 2019 tough. My thoughts was that they probably wanted to get more developers over to using bitcode first as well as ARM being almost at desired performance but not quite there yet.
In 2020 I doubt anyone will see any problems with ARM performance on a desktop or laptop.
I remember Chris Lattner giving some details to bitcode a while ago and according to him it's not possible to recompile an app for a different architecture having only the so called bitcode.
The article doesn't say that Intel will be gone in 2020, just that Apple will be shipping macs with their own chips starting in 2020. It will likely start with one or two models available for devs, then a launch that covers more of the platform.
Doesn't all have to happen at once, and Apple has been though this before in the PPC-Intel switch, which went rather well.
The fact that Apple develops and ships hundreds of millions of ARM processors every year, which are widely regarded to be the best ARM processors made, and they design and ship no X86 processors?
That alone doesn't make it "obvious" as applied _to a Mac_, which is a very different kind of device that caters to a different audience that often has special needs. See our other discussion threads elsewhere.
That is what I explain in the link. I saw this move coming two years ago when I wrote that article. I noticed how regular users were using iPhones and iPads for almost everything they do. I noticed how office apps like Pages, Keynote and Numbers worked without any performance issues on iPad.
I concluded ARM was fast enough for 90% of users. Once you don't have the restriction of battery life and small enclosure it is not hard to imagine that Apple could beef up ARM a lot for their desktops and laptops.
Why run multiple CPU architectures when one does the job and is much cheaper?
I've been thinking hard about what kind of workload ARM can't handle and I can't think of anything. Ok... there is one 1st person shooter games. But iOS is a more successful gaming platform than Mac.
And cost. Making something you can license to others and/or sell to 250000 users each year has a completely different cost compared to something you use only on your 20000 machines (source: [1]).
Macs are already overpriced, I don't know how much Apple could sustain an in-house production of proprietary chips without hitting their users; they're probably going to ARM.
I think you might have misread the table at the page you linked. Above the table, it says "Shipments are in thousands of units." According to the table, Apple shipped 20 million notebooks and desktops last year, not 20 thousand.
It could be that they are just trying to improve their negotiating position. Even if that's true, I'd wager that it is just the short-term contingency of an investment with a long-term view. I bet they have their eye on the end-game.
When I say that, I'm thinking of the old TED Talk by Amory Lovins called "Winning the Oil Endgame". I feel like there's some parallel one could draw between peak oil and process improvements. Intel has slowed down now that it's more difficult to extract increased performance with each iteration. I'm guessing someone at Apple is thinking about where they'd like to be positioned when the well runs dry.
> third parties outside Apple who haven't even heard of the possibility of this happening until today
This announcement is hardly a surprise. The writing has been on the wall for at least the last 5 years since LLVM replaced GCC in XCode. It became even more obvious when Apple started compiling to "Bitcode" so that they could deliver optimized binaries to devices. What that replacement meant is that it would ease Apple's transition away from any particular architecture - developers shouldn't have to do much if the app is installed from the App Store.
> The writing has been on the wall for at least the last 5 years since LLVM replaced GCC in XCode. It became even more obvious when Apple started compiling to "Bitcode" so that they could deliver optimized binaries to devices.
These weren't clear signs of an upcoming ARM switch:
• Apple has been purging software that's under the GPL for quite a while now, and GCC was probably high on the list since Apple (NeXT) had been bitten by its license before[1].
• The Intel switch in 2006 was extremely smooth even using GCC.
• Bitcode is not enabled on macOS, and even if it were, it's not abstract enough to recompile an x86 app for ARM[2].
Yeah. There are only three extant architectural license holders (Intel, AMD and VIA) and they're basically in a circular firing squad of patents.
To make their own chips, they'd need to either license from an existing holder (which wouldn't let them tinker unless it was a partnership or they acquired the license) or they'd need to make something so incredibly great the other three would trip over themselves to use it, and bind themselves in the process.
I’m not sure they can for this purpose. I remember people talking about the idea of buying AMD but it’s possible the license terms may say it doesn’t survive a purchase; making AMD or Via worthless for that purpose.
Unless the licensing terms are extremely lopsided, they'd still own AMD64 patents which EM64T is based on, and intel would need to strike a new deal. VIA's situation should be similar, but with other technologies.
I wonder if "non-transferable" covers tricks like Apple loaning AMD the cash for AMD to buy Apple. Then renaming the new AMD to Apple. Then it would pay itself back for the loans.
I vaguely remember that the licensing agreement between Intel and AMD (Intel licenses x86 to AMD, AMD licenses x86_64 to Intel) expires if AMD gets bought. Apple could renegotiate, but it would not be straightforward, I think.
> If they wanted to go x86 they would just buy VIA?
In theory, but then VIA is a subsidiary of Formosa Plastics Group, so they'd need to either negotiate the sale with an entity with which they've locked horns in the past or buy an entire petrochemical group???
Yes. Everything since the Pentium is still encumbered. Intel and AMD have extensive cross licensing agreements. Anyone want to build an x86_64 chip would need to either purchase a company that already had licenses or negotiate with both AMD and Intel.
Apple has been trying to chase power users and professionals off of their platform for years. A switch to ARM is an opportunity to rid themselves of the few remaining holdouts and focus 100% on high-end consumer electronics.
I would say that is more about the boxes they use than CPU. The difficulty of adding your own hard drives, memory, graphics cards etc to a Mac is the biggest problem I think.
What pro task, really requires high single thread performance? I imagine Apple could match intel by simply using more cores on their ARM CPUs.
And what are your processing times like? I use my Mac for video editing, but I have never had any problems doing that smoothly even on much weaker Macs.
Only issue I have on Mac is compiling large programs.
The issue is with live streams of audio or virtual instruments with CPU heavy effects with very small amount of buffering (typically 64 samples @ 48kHz, which is 0.75ms). Also processing of instruments and effects for one track (+ relevant busses) has to be in series so more cores doesn't help a resource hungry signal chain. But of course they do greatly help overall effect/instrument count over many tracks.
True, I miss the old Powermac towers: Workstation class machines, but with low-end configurations for those of us on a budget. When I was faced with the choice between:
- an iMac that didn't really meet my needs
- a ridiculously unaffordable Mac Pro tower
I jumped over to Linux running on commodity PC hardware.
Oh good, I see the downvotes are rolling in now (I was concerned after receiving a wave of upvotes yesterday). I've found there is no more reliable method to collect downvotes on HN than to say something critical about Apple.
No, the Xcode workflow is set up to make applications CPU-agnostic by default, but there's nothing about the Mac App Store that requires it. The executables are ordinary x64 binaries.
It'd be perfectly valid to write an application for the MAS in x64 assembly, if you want, as long as it's sandboxed and doesn't touch any private APIs.
