What's the Arm? First Apple laptop to ditch Intel will be 13.3" MacBook Pro, proclaims reliable soothsayer Apple will confirm its transition to Arm this week at the virtual Worldwide Developers Conference (WWDC), says Ming-Chi Kuo – the analyst widely regarded to be the most accurate when it comes to Cupertino's movements. Kuo's latest report comes via an investment note sent to clients of TF International Securities, and echoes …
If they do announce a migration to ARM I'm going to be really interested to see how they manage the transition:
- Porting support
- How long they say they will support X86 binaries on the ARM platform
- How the prices compare
This is all about Apple having full control over the chip set, so they get the packaging they want, the power consumption they want and the performance they want. The idea of having a machine that could completely power down some parts of the hardware because it isn't needed is pretty interesting.
How long they say they will support X86 binaries on the ARM platform
Presumably about as long as they supported Big-Endian binaries on the X86 platform when they switched over
How the prices compare
Probably slightly cheaper to begin with, but will creep up as the Intel based machines are discontinued. Why charge less when the customer is going to buy it anyway?
There are two lines of thought possible here:
1) Apple is going ARM in order to control hardware outcomes, TDP, power usage,and performance.
2) Apple is going ARM in order to control software outcomes, creating a walled garden for its Mac line from which they can take their 30% App Store cut from sales of software to their now exclusive hardware.
Guess which one I believe to have been a primary motivator, with the second option being simply a very convenient, perfect solution of the the means to the end?
re: your 1) above,
It is clear that being dependent upon Intel for the CPU's worked in the beginning but in recent years... Intel's performance has clearly sucked big time.
I see that as the initial motivation for them to shift now. The raw CPU performance of their recent SOC's has been shown to outperform a lot of what Intel is offering.
We shall have to wait and see what transpires today (if anything) especially wrt price.
They won't announce anything to do with price now, they are just announcing the transition to developers and will get some prerelease hardware into their hands so they can begin the porting process so there is less x86 only code for them to worry about when the real announcement comes in 6-9 months.
But I think it is probably a safe bet the price will be exactly the same as the x86 machines they replace, but they will have better performance and better battery life. Apple haters will whine that they aren't passing any of the savings from dropping Intel along to their customers, their customers won't care because they will be getting something with better performance and better battery life.
Why not both? Though Apple doesn't need to change CPU architecture for the second one. But you also forgot: margins. Intel chips are not cheap. If Apple can use the same chips in desktop devices as phones and tablets then it has even more margin to play with.
Why does the pragmatist in me believe that this move is only another way to lock users into an Apple-only supply ecosystem? Will third party developers go fully ARM, or are we looking at an expectation of Apple's App Store being expected to supply most necessary applications (for the usual fees, of course...!).
I truly don't understand this logic. Not for one second do I think Apple would mandate that you could *only* install apps from the app store... And due to that, I believe it renders your argument null and void.
For example, whilst you can download Office apps from the Apple App store, Apple sees not one penny of any office licenses.
Netflix: You can happy sign up outside of the iOS app, should you feel strong enough about it
Before the app store, app distribution was a complete mess. And now, as a developer, you don't have to worry for a second about distribution, updates, content hosting, metrics, billing, etc, etc. It's all done for you. And if you are going to charge for your app, then isn't it fair that Apple gets a cut, given you get all of the above included?
Now, if Apple mandated that the ONLY way to get a subscription for something was through the app, then I think everyone would have a valid argument. Whilst you can spend your monies outside of the app, then, well...
These guys know much more about this than I do but it seems off that the first transition will be the Macbook Pro and iMac - or to put it differently, the first to iron out the issues will be the creative professionals who use high end equipment for their work.
I would have thought that a transition using the Air range would have made more sense as this plays to battery life and cooling plus the target user is more likely to sit in coffee shops using a browser so are less reliant on the system being 100%
Maybe the online rants of 1000's of fanbois who are having minor problems watching youtube is seen as worse PR than a few 100 upset professionals who cannot meet deadlines? As I say, I am not in marketing.
Definitely not... (hfP?)
This has been planned for a long time - at senior management level, their internal roadmap would have shown the Intel transition to ARM for the last 2 years so they can have everything in place for the end of this year. The decision to replace MBP was not because they updated MBA this year - the decision was to update MBA on Intel instead of moving it to ARM...
This is not move fast and break things territory, this is carefully planned corporate strategy. The question is still relevant as someone senior in Marketing made the decision to transition the 'professional' model(s) before the 'consumer' models It seems odd to me but, that's why I don't get paid big bucks for making the decision :)
If you're a 'professional' still using your 'boxed non-cloud x86 CS6' then, to be fair, you need your head testing. Your customers aren't going to like you grinding to a halt or throwing a tantrum just because of some relatively minor software cost in the grand scheme of your profession and income.
Pushing the 'pro' path first - or at least quickly - puts pressure on Microsoft and Adobe to ship their respective software suites for the new platform quicker. Once those two juggernauts have done that, you're basically home and dry for everyone.
This is admittedly a very (very) simplified view, but it's the essence of things. Apple has form on chip transitions, several times of course. Edge cases aside, once Microsoft and Adobe are onboard it's all over and a (relatively) quiet transition lies ahead (again).
I don't think Apple would make this move unless they were fully committed to replace their whole lineup top to bottom, including the most high end Mac Pro workstations. Half-measures like only doing the low end of laptops first is not their style. They could have made that move years ago, the older A-series chips were more than capable. Apple will not want to split their Mac lineup between 2 different architectures.
A pretty good one too. All posix code should compile and run on it including Xwin code if you have Xquartz installed. The only downside from a dev POV is that to use the MacOS GUI direct rather than through X is you need to code in the horror show that is Objective C or alternatively Swift. Neither of which is ideal for C/C++ devs like me. Why Apple didn't go down the C++ route is a mystery to me as modern C++ is no longer the dogs dinner it was in the 90s.
No mystery: it was good old internal politics. NeXT vs Apple, and NeXT won. NeXTStep, rechristened as "Cocoa", won as the application environment of choice for MacOS X. However, a lot of the libraries that enabled it were written in C++. From my hazy memories of that time, Quartz, ATS (the font renderer) and IOKit were C++ codebases, to which you can add all of QuickTime, and any other library or application that was ported directly over from MacOS 9.
Oddly, there was such a thing as ObjectiveC++ (basically C++ with the added at-signs and SmallTalk-y brackets syntax to let you interact with the ObjC runtime), which was fully supported by Apple's tooling, but received zero publicity in developer documentation and training. It's a shame, really, because the "C" part of the original MacOS X ObjectiveC was a creaky pre-ANSI dialect that felt like a real trip back in time (as in having to define all your variables up front at the head of a function again...).
I really don't understand why Swift needs to exist, except to make Apple platform skills non-transferrable, but Apple has always had an unhealthy impulse towards proprietary approaches. The irony of course is that without OS X embracing so many open standards, there wouldn't be an Apple today.
I agree, I think they will have even the Mac Pro replaced within two years or so. They needed to wait this long because they need their per core performance to be able to beat that of the x86 Macs that are being replaced and that's only recently become possible.
It makes sense to start at with the 'lesser' machines both because they are an easier target to beat x86 performance since they use lower spec'ed chips (for the Mac Pro they will need some type of multi chip solution like AMD's chiplets which will take longer to develop/test) and because the kind of high end high dollar applications people run on a Mac Pro will require more time to port to ARM and fully test.
As a developer I'm very keen not to be labelled as a "creative", thank you. Management hear the c word and will think I can design newsletters and logos and corporate templates and rebrand stuff and if you've seen my level of design skills, you'll know that nobody wants this to happen. The results are, literally, not pretty.
I tried apple. I really wanted to love it. I hated it.
If you spent loads of money keeping hardware and software bang up to date you could get about 1/4 the performance of anything running Linux or windows.
This will be the death knell of Apple as a power workstation machine. Unless they keep intel for that.
It's more about battery powered toys for consumers
OSX is much, much faster than Windows for some workloads.
I doubt that. If the application code is well written then it should be running as fast as possible on the same CPUs. There are always edge-cases relating to I/O speed, networking, etc. but in most cases the OS no longer makes much difference and, indeed for things like video-encoding, Windows is easier to get hardware acceleration working.
Where MacOS generally shines is the integration of tools for certain workflows. For me, as a developer, I find the posix side of MacOS just so much more convenient, not least because of the path names.
Time for another look at Windows. Running my preferred Linux distro on WSL is superior to running BSD on MacOS, and now that the new default Windows terminal is finally better than Terminal.app, there's nothing that I miss from Macs.
I do like BSD, and I think its codebase is so much better than Linux's (the Linux networking stack... dear god!). However, nobody has ever asked me to write a product that targets BSD.
"If you spent loads of money keeping hardware and software bang up to date you could get about 1/4 the performance of anything running Linux or windows."
Really? I get infinitely more performance out of a system that works than one that doesn't.
Bearing in mind it's many years since I ran anything from Redmond.
A factor of four is rather unlikely, though I'll readily concede that you get more power if you get a decent free OS. But you also, in my experience, spend more time playing with that rather than your day job.
Clearly punished by the computer gods...
the Mac rebooted on me yesterday... Hasn't happened in a long while (not at all since I sorted the eGPU issue*)
* The eGPU wasn't actually drawing enough power to keep the power brick entertained, so it would occasionally just power down, and the mac wasn't overly happy about it being randomly disconnected.
When I realised I could power the laptop through the eGPU it suddenly became happy, the power brick hasn't powered it down again since.
Ah yes. That brings back fond* memories of the original iMac puck mouse - so gloriously round that it didn't matter which way you grabbed it, it always seemed to move the mouse cursor in an unexpected direction!
Also, I fully agree that holding balls in your hand is easy and comfortable - though, for some reason, the staff in Marks & Sparks take a completely opposite point of view...
* for negative quantities of "fondness", of course!
I still remember the road bumps caused when Apple went from 680x0 to PowerPC and later to Intel x86. And also from MacOS 9 to OS X. I used to have a lovely Power Mac G4 at the time which migrated through one of these transition periods. But at least in those earlier cases, the new architecture was sufficiently powerful that the emulation worked pretty well and smoothed the transition.
I don't see that being true in this case at all. We already know from Windows on Arm that x86 emulation is abysmally slow and that assumes Apple even provide emulation. And either way Macbook owners can kiss goodbye to Boot Camp and the ability to run Windows 10. I can't see much if any benefit in this to end users at all really. It might save Apple some money but that's small consolation to Macbook users who suffer detrimentally from it.
It will be interesting to see what they offer here. Given that they control the silicon, they may be able to produce something that's up to the job.
Bootcamp has never been a "must have" to me, as running a Windows 10 VM has always been perfectly acceptable to me. And you can have multiple VMs running at the same time.
Virtualization may be tricky, but it isn't impossible. It would require the VM companies to recompile their applications for ARM, which probably isn't easy but it is what they do so they can manage it with time. Most VM hosts do not in any way emulate a different processor short of disabling a few things for older OSes, so ARM-specific builds of Windows or Linux will be needed. In the best case scenario, the VM host is recompiled, the application running in the VM is also recompiled for ARM, and everything runs the same as before. The worst case scenario is ARM-compatibility layer virtualizes X86, VM host runs in X86, tries to run another OS in X86, and probably screeches to a halt before the application can even be started. It will depend a lot on the companies producing VM software.
Native booting, on the other hand, is likely to be problematic. It's not so much the OS itself--someone can compile a version for the architecture. It's the rest. ARM devices tend not to have a standard boot mechanism like X86 does. That's why, although we can compile a mobile OS for any architecture we want, we have to manually rebuild it for every phone in order to run it. There's also the issue of hardware drivers. If Apple doesn't consider natively running another operating system to be important, and their customer base is probably mostly in agreement, they may not bother to compile drivers for ARM Windows let alone Linux. Linux might have some chance of finding suitable replacements, but that will likely take some time. If you need native booting of something else, I'd advise caution about getting an ARM-based product for quite a while until someone else has figured out the details.
Maybe they'll take a leaf from Acorn's book, at least for a machine such as the Pro. The RiscPC had two processor slots, and while the "main" processor was always ARM, the other one could be x86. In Acorn's case installing Windows was a bit like installing in a VM ("drive c" was a file on RiscOS's HDD) but it ran on a physically separate processor. The "graphics card" was a driver that passed graphics ops to RiscOS, for example.
One of the arguments people are making for Apple moving from Intel to ARM is cost, and another is power use. If ARM isn't quite powerful enough for full emulation, could you get away with a very low-end Intel processor as a "second processor" for hardware acceleration purposes? When the machine is running OSX the x86 can be completely powered-down unless an x86-compiled app needs to run, when it can be woken up to perform the heavy lifting. If the ARM is running the OS and the x86 is only running one or two apps you'd probably only need a low-end dual-core Celeron (do they do any without integrated graphics?) for decent performance. They could even swap to a low end AMD processor, which would be cheaper.
You could dual-boot as normal, but make do with a low-end processor, or you could boot into OSX and run Windows in something akin to a VM.
Too complicated? Maybe, but fun to consider :-)
And then there's my idea of ditching OSX altogether for a desktop version of iOS :-)
M.
"Maybe they'll take a leaf from Acorn's book, at least for a machine such as the Pro. The RiscPC had two processor slots, and while the "main" processor was always ARM, the other one could be x86. In Acorn's case installing Windows was a bit like installing in a VM ("drive c" was a file on RiscOS's HDD) but it ran on a physically separate processor. The "graphics card" was a driver that passed graphics ops to RiscOS, for example."
Which is exactly how the BBC Master 512 worked. Internal 80186 co-pro and Dos Plus 2.1. Throw a hard disk into the mix and it creates a 10-30MB file labelled - funnily enough - DRIVE_C. As far as the co-pro was concerned, it was a 10-30MB hard disk and would boot from it.
"The worst case scenario is ARM-compatibility layer virtualizes X86, VM host runs in X86, tries to run another OS in X86, and probably screeches to a halt before the application can even be started. It will depend a lot on the companies producing VM software."
Err, I think you're talking about emulation, and it's pretty old hat now... See SoftPC (late 80s), FX!32 (mid 90s), simh etc.
FX!32 made a big impression - it was a emulator layer for Windows NT on the DEC Alpha that ran x86 binaries as quick on a (very low end bargain basement) 166MHz Alpha as they ran on a very expensive maxed out 200MHz Pentium Pro box. IIRC it translated code on the fly & cached the translations - so you didn't pay the translation penalty over and over again - like Sun's HotSpot JVM.
The mini/mainframe vendors also shipped emulators for their legacy lines - some implemented in hardware, some software and some a mix of the two.
You are quite right. I'm talking about emulation, and the pain that would happen when what you're emulating is a virtual machine host. That's not a small program, and it has lots of little hooks into hardware. When you emulate it, your emulator better be really good so it doesn't realize that it's being emulated. But what is worse is what that VM host is going to be sending through the emulator: Windows 10. That's not a light program. Translating all of Windows's instructions from X86 and X86-64 to ARM will require a lot of emulation, and it will either take a lot of processing (meaning it runs slowly) or require a massive cache of pretranslated instructions as you have mentioned, meaning long delays during that translation processing and a lot of extra storage). Remember that Windows 10 weighs in at eight gigabytes, a lot of which is X86 binaries. Then keep in mind that whatever the user is going to run on that is going to be even more needing emulation at the same time. That's why the ideal scenario would be not emulating a different instruction set for a large, processing-hungry operating system. Windows on ARM is the clear solution here, and it's already available. What we need to run it will be ARM-native VM hosts.
"You are quite right. I'm talking about emulation, and the pain that would happen when what you're emulating is a virtual machine host."
Oddly enough that is exactly the problem that has been solved many times over from the 80s to the current day. Even today's common-or-garden VMs emulate (a surprising amount of) PC hardware sufficiently to host Windows 10.
While I it doesn't belong in the "trivial" bracket, emulating the CPU isn't as hard as you may think - as evidenced by the last 40 years or so, and Windows 10 and it's apps don't require cycle accurate emulation for everything either - as evidenced by the fact they run under VMs - even with PCI(e) passthrough quite happily.
"ranslating all of Windows's instructions from X86 and X86-64 to ARM will require a lot of emulation, and it will either take a lot of processing (meaning it runs slowly) or require a massive cache of pretranslated instructions as you have mentioned, "
I have to respectfully disagree with you on that point - based on what I saw over 20 years ago with NT x86 binaries running quicker on an Alpha box - and the current state of the art with respect to VMs and JVMs. :)
"Remember that Windows 10 weighs in at eight gigabytes, a lot of which is X86 binaries. "
Another way to look at this is modern CPUs have a certain amount of cache - and a very high penalty for accessible data in the DIMMs. Windows 10 like all other software executing on modern CPUs, has to be kind to those caches to get close to acceptable performance, this means that the code is tuned to make those caches effective, which in turn helps you if you're loading up caches with translated instructions.
Additionally - most, if not all AMD & Intel processors are actually RISC style machines under the covers - they have a front end that decodes (aka translates) x86 CISC instructions into micro-ops... The emulator would be doing something similar...
In summary I don't think it's a stretch for Apple to make on the hoof translation work - but I think (very pragmatically) they've taken the approach of generating fat binaries instead.
Virtualization also goes bye bye.
VMs do not convert the underlying CPU architecture, they are still running the VM guest's code natively.
The VM hypervisor is merely enforcing barriers between to ensure the guests don't touch each other's memory, and provides virtual IO (disk/network etc)
Emulation is needed to run amd64 on ARM (or vice-versa), and emulation has comparatively abysmal performance.
They won't have to kiss goodbye to Bootcamp or Parallels, Windows 10 runs on ARM already.
Yes it will be slow if people have x86 only Windows applications they need to run, but all the basic stuff like Office, Outlook, and some third party stuff like SAP clients is already ported. If you need to boot into Windows to run some sort of CAD application that may never get ported because there aren't any good Windows PCs with ARM CPUs to run it on, I guess that would take future Macs off your list. But if you need to run Windows just to run stuff your employer has standardized on in Windows, it shouldn't be a problem.
Apple might be who saves Windows on ARM - it needs a bigger user base to get more developers interested in porting their applications, the additional momentum from Apple users who run Windows can only help.
Partly. I believe only 32-bit though, to date. I expect that MS will likely have fully ARMed versions of Windows 10 in the not too distant future, as they too want to sell low power high performance gadgets.
My MacBook Pro is very powerful, but it runs hot as hell when it’s busy. I imagine the fans would spin a bit less with an ARM chip installed.
I've often wondered why Apple don't just buy AMD and a semiconductor manufacturer. No more need for Intel.
No idea whether they could actually extract a tax from Intel for using the x64 technology AMD came up with actually, I'm totally clueless on that point, but I bet you Apple's M&A department know the answer to that question already.
Volume. They don't use enough (laptop) parts unless they are being sold else where as well.
The advantage of ARM is you can license the IP, customize it to do exactly what you want and then have it made at a very large fab (TMSC and the likes) without being tied to a specific foundry, process or regime - economy of scale is much lower as you don't have a very, very expensive silicon fab running on low volumes.
If the last 20 years have told us anything, they've told us that Intel is the only company that manages CPU desing and manufacturing effectively and even then it's become increasingly difficult. This is why contract manufacturing from TSMC, Samsung, etc. where the enormous capital can be spread out making CPUs, GPUs, memory for phones, routers, PCs, TVs.
I think the AMD Intel thing exists as a result of an agreement to share after a bunch of court cases and AMD being an original x86 licensee. I think. It’s kinda complicated.
It’s also possible that AMD would lose their x86 license if they’re taken over. If so, Apple wouldn’t get what they’d need. Whether that’d need that, or just do a pure x64 chip (if such a thing were possible), I don’t really know. Going an ARM route is probably cheaper anyway...
It wouldn't need for much for them to be able to cream off the higher end Windows users. Currently, similarly specc'd Intel notebooks are similarly priced whether they're from Apple, Dell, Lenovo or HP. Microsoft has a far higher investment in the x86 software stack than Apple. But let's wait and see what is actually announced.
From the article
Similarly, will Apple offer discrete graphics on par with the current Radeon cards found on its premium laptops and desktops?
There’s no particular reason why they can’t just keep using Radeon cards, surely? It’s just a matter of getting drivers rebuilt, mostly. They’re still going to have a PCIe bus, and the bulk of OSX will simply recompile too.
I'm sure their lower end stuff like use their built in graphics (so Linux drivers might be hard to come by for those unless Apple decides to write them...) but they will never get rid of discrete graphics in higher end stuff.
Drivers won't be a problem, they probably already support them on Windows/ARM. They won't be as well optimized as Windows drivers, but neither were Apple's x86 Radeon drivers...
So now we know: Rosetta 2 translation. Universal binaries. Two year transition period. Developer hardware available this week - using the A12 from ipad pro in Mac Mini format. Microsoft Office ported and all of MacOS. Demos of Linux running in Parallels - hello Debian.All tools you need are in XCode.
Nice teaser that all the earlier apps demos for Big Sur were being run on the ARM Macpro.
Sucks if you've invested in Intel macpros. Nothing for the big enterprise. It's the apps, stupid - and a closed ecosystem. _maybe_ a couple more Intel boxes up ahead but its dead otherwise.
Another thing they're touting is running iOS apps better than macOS does currently but then what will the real difference be between an ARM Mac and an iPad? It's just the form factor.
So looking forward to a future of iOSified apps downloaded from a closed-walled garden on a Mac and running on an iOSified macOS (check out the 'features' which have made it across in Big Sur).
...to stay relevant is drop their pricing accordingly. They've barely dropped any prices in a meaningful way...most of their desktop stuff should be cheaper than AMD right now...but its not, so it looks like really poor value for money.
Its not just whack per dollar either. Intel sat on Thunderbolt for way too long and its cost them in terms of leading tech too. Sure there's no real use for PCIe gen 4 yet...but still if you go AMD you can have it. Sure you can't have TB3, but who cares, there's hardly any kit worthwhile for TB3. There will be a shit ton of PCIe gen 4 stuff within a year.
ARM processors and x86 processors are completely different. They use different instruction sets, different pipeline configurations, everything. Intel processors are powerful and fast because they have more advanced instructions for complicated processes, not to mention totally different clock speeds etc.
If you think that you will get the exact same performance per watt from an ARM based computer you are deluding yourself. The trick for Apple will be tuning these ARM based processors for very very specific workloads so that they *seem* to be as fast as an Intel chip when doing certain tasks. That will be fine for an iPod or a phone, but the ramifications for "PCs" is far worse.
If ARM based computers were so desirable, why haven't ARM based servers taken off? Answer: because they are not as competitive as Intel based servers. I am no 'lover' of Intel, but the market speaks for itself.
ARM is taking off. ARM processors are available for cloud computing and servers because they do sometimes offer more compute power per watt. Apple has been pumping a lot of money into their flavor of ARM and some reports say it's faster than the low power Intel processors that Apple uses.
Developers probably aren't impacted much. Changing the CPU is trivial compared to the work of when Apple changes the OS. Anyone adverse to regularly rewriting non-portable code has already left.
If it's faster, I look forward to someday having a work laptop that can apply a minor software update in less than 35 minutes.
Intel processors are powerful and fast because they have more advanced instructions for complicated processes
Intel's CISC instruction set is internally translated into RISC. ARM doesn't have a translation layer and the compiler generates RISC code instead. There's no difference, except the amount of bloat on Intel's chips.
https://www.bbc.co.uk/news/technology-53142989 (22 June 2020)
Apple has confirmed it will transition its Mac laptop and desktop computers to its own ARM-based processors.
The move means that Macs will run on the same type of chips as the firm's iPhones and iPads, rather than Intel's.
Intel had faced problems manufacturing its own designs, leading it to issue a public apology to computer-makers.
Apple's challenge will be to carry off the transition smoothly and convince third-party developers to update their apps accordingly.
"We expect to ship our first Mac with Apple silicon by the end of the year," said chief executive Tim Cook, adding that it would likely be two years before its full product line had made the jump.
(article continues)
Briefly back to 2018 when Jim Keller joined Intel. Who he?
https://venturebeat.com/2018/07/16/why-rock-star-chip-architect-jim-keller-finally-decided-to-work-for-intel/
[time passes ... Intel still fails to be a player in any significant market outside the IT director's domain, in particular in mobile, IoT, and other Windowless consumer and professional electronics...]
https://venturebeat.com/2020/06/11/intels-loses-veteran-chip-designer-jim-keller/
"Intel announced that veteran chip designer Jim Keller has resigned from the company effective immediately due to personal reasons.
Keller is the rare chip architect who has been involved in several of the most groundbreaking chip designs of modern electronics, leading teams that revolutionized chip performance at companies such as Apple and Advanced Micro Devices. He joined Intel’s Silicon Engineering Group as a senior vice president in 2018 in an attempt to help turn around Intel’s lagging designs."
...
"In 1998, he moved to AMD, where he worked on the Athlon (K7) processor and led the K8 project that disrupted Intel’s 64-bit Itanium chips and gave AMD its first foothold in the lucrative market for server chips. Then, in 1999 — as the dotcom bubble was growing — he left for startup SiByte, which Broadcom acquired in 2000 for $2 billion in stock. When the bubble collapsed, so did the value of that deal and Broadcom’s own hypergrowth.
In 2004, Keller moved on to head engineering at P.A. Semi, a startup focused on mobile processors. Then he moved to Apple in early 2008. Apple also bought the P.A. Semi team, which went to work on the A series processors for iPhones. That was part of Steve Jobs’ strategy to become independent from chip makers, and it turned out to be a brilliant move that saved Apple billions of dollars.
In 2012, Keller sensed a shift coming again. Advances in PC processors were slowing. He rejoined AMD to lead a new microarchitecture, dubbed Zen. AMD launched the first chips based on Zen in 2017, and for the first time in years the company is rapidly gaining share on Intel. In 2015, Keller left AMD and joined Tesla to work on autopilot engineering for the company’s electric cars."
[then he left Tesla ...]
go read the original articles please
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
