31 ms·

Commenters here seem dubious. I’ll take the contra-position. This feels to me like it’s going to be great; a big win for consumers and developers. Current A12z

Commenters here seem dubious. I’ll take the contra-position. This feels to me like it’s going to be great; a big win for consumers and developers. Current A12z chips are highly performant; Apple is roughly one chip cycle ahead on perfomance/watt from any other manufacturer. I presume their consumer hardware will launch with an A13Z, or maybe an A14 type chip. Apple has consistently shipped new chip designs on time; Intel’s thrashing has cost them at least two significant update cycles on the macbook line in the last six years. Search this fine site for complaints about how new mac laptops don’t have real performance benefits over old ones —- those complaints are 100% down to being saddled with Intel. Apple has a functional corporate culture that ships; adding complete control of the hardware stack in is going to make for better products, full stop. Apple has to pay Intel and AMD profit margins for their mac systems. They are going to be able to put this margin back into a combination of profit and tech budget as they choose. Early days they are likely to plow all this back into performance, a win for consumers. So, I’m predicting an MBP 13 - 16 range with an extra three hours of battery life+, and 20-30% faster. Alternately a Macbook Air type with 16 hours plus strong 4k performance. You’re not going to want an Intel mac even as of January of 2021, unless you have a very unusual set of requirements. I think they may also start making a real push on the ML side in the next year, which will be very interesting; it’s exciting to imagine what Apple’s fully vertically integrated company could do controlling hardware, OS and ML stack. One interesting question I think is outstanding - from parsing the video carefully, it seems to me that devs are going to want ARM linux virtualized, vs AMD64. I’m not highly conversant with ARM linux, but in my mind I imagine it’s still largely a second class citizen — I wonder if systems developers will get on board, deal with slower / higher battery draw intel virtualization, or move on from Apple. Languages like Go with supremely simple cross architecture support might get a boost here. Rust seems behind on ARM, for instance; I bet that will change in the next year or two. I don’t imagine that developing Intel server binaries on an ARM laptop with Rust will be pleasant.

kllrnohj 6y ago
> Apple is roughly one chip cycle ahead on perfomance/watt from any other manufacturer. Eh? This is a flimsy claim. AMD's performance/watt is extremely impressive right now. Apple is ahead of Intel for sure, but Intel isn't the only other player here. > So, I’m predicting an MBP 13 - 16 range with an extra three hours of battery life+, and 20-30% faster. Alternately a Macbook Air type with 16 hours plus strong 4k performance. A slightly more efficient CPU doesn't get you this. You need significant efficiency improvements across a variety of aspects, including those Apple has already been optimizing for years like the display.
- StillBored 6y ago
  AMD is tiny compared to intel, the fact that they are besting them goes to show how they have been stuck for ~5 years. The real problem though, is that apple is actually designing a core 100% focused on the target market. Unlike intel, for whatever reason, and AMD which didn't have the funds to run a dedicated design team for laptop/desktops. So, I would expect the engineering tradeoffs for said laptop/desktop processor to show. AKA, things like hyperthreading are quite a win for servers, but at best are a wash for a desktop use case focused on extremely high single thread perf at the expense of throughput.
  - moooo99 6y ago
    > AMD which didn't have the funds to run a dedicated design team for laptop/desktops. Given the extremely impressive performance of the 4800H notebook cpus, I'd assume that might be a thing of the past. > AKA, things like hyperthreading are quite a win for servers, but at best are a wash for a desktop use case focused on extremely high single thread perf at the expense of throughput. This might be true for devices like the MacBook Air which are designed for relatively light usage like Office, but I don't see that argument working with their "Pro" lineup, including the iMac Pro and the MacBook Pro. These are devices specifically targeted to a professional audience like graphics designers, 3d artists, software developers or video editors. All of those tasks can be done with decent single-threaded performance, but lots of those tasks also benefit from multithreading. I haven't owned a single MacBook so far and I doubt that'll change anytime soon. Nevertheless, its exciting to see Apple do this move and it'll be interesting how good their CPUs can compare to mobile processors by Intel and AMD.
    - ebg13 6y ago
      > Given the extremely impressive performance of the 4800H notebook cpus, I'd assume that might be a thing of the past. The TDP on those is, what, 3-4x the A12Z?
      - sudosysgen 6y ago
        With twice the cores at a higher per-core speed, yes. And also with a much more powerful GPU.
moduspol 6y ago
Agreed on all points. I saw speculation elsewhere that this change, along with AWS's addition of Graviton-based (their own ARM processors) instances at much more competitive price points relative to x86, are bound to spearhead the change to "ARM by default." If your devs are already using ARM, and ARM's notably cheaper in the cloud, that's a compelling case. If you're already using Kubernetes / Docker heavily, you're probably already 80% of the way there. Linuxes that aren't supporting ARM as a "first class citizen" will soon, and undoubtedly that will be a speed bump at worst. I'm interested to see the specs relative to the x86 Macs, but the only open question to me was whether or not we'd see the x86 emulation layer. Well, we did, and it may not be perfect but it certainly looks like they put a lot of effort into it. If it works as well as it looks, I think this transition is borderline inevitable. I think I've bought my last x86 hardware.
- kllrnohj 6y ago
  This claim doesn't really hold up. The problem here is the vast majority of non-Apple laptops & desktops that are in use. THOSE will still all be x86 for the foreseeable future as ARM CPUs not made by Apple all have terrible per-core performance. Graviton2 compensates by just throwing 64 cores at the problem, but that's not going to do anything for your Electron-based text editor that struggles to use 2 CPU cores in the first place. Or for a typical webpage, which struggles to use more than a single CPU core. But otherwise as a developer-focused example the 32-core Epyc Rome compiles Build2 faster than the 64-core Graviton 2: https://openbenchmarking.org/embed.php?i=2006047-PTS-EPYC2EC201&sha=fd75564&p=2 https://openbenchmarking.org/embed.php?i=2006047-PTS-EPYC2EC... That's going to matter when a company is spec'ing out workstations to buy, which are unlikely to have an Apple option on the table at all in the first place, and Amazon isn't going to sell you Graviton2 CPUs to put under your desk, either. This _could_ be the start of a bigger focus on ARM, definitely, but to really make inroads into what devs use you'll need someone other than Apple to step up to the plate. Or for Apple to become vastly larger than they are in the desktop space. Otherwise we'll all just keep cross-compiling like we have been for the last decade of mobile app development.
  - klelatti 6y ago
chooseaname 6y ago
> So, I’m predicting an MBP 13 - 16 range with an extra three hours of battery life+f I predict they'll have the same battery life. Any savings will be used to reduce the battery size.
- abhorrence 6y ago
  I think without Ive they'll take the battery life and market it as the incredible win of moving away from Intel.
  - snazz 6y ago
    Agreed. I think this is especially likely given their decision to increase the battery size in the iPhone 11 lineup last year.
zitterbewegung 6y ago
I agree with you but I think we are going to see at least one A12Z consumer product (other than the iPad) probably going to be a rereleased MacBook with a better keyboard.
justinfrankel 6y ago
> I’m not highly conversant with ARM linux, but in my mind I imagine it’s still largely a second class citizen IMO ARM linux is great, the real thing lacking is good hardware to run it.
- dfox 6y ago
  You mean all the Android handsets? The history of Linux on ARM is colorful, full of corporate missteps and giant brands (namely HTC and to lesser extent Samsung) that were created from that.
  - imtringued 6y ago
    None of them come close to the performance Apple achieves on their chips.
- swebs 6y ago
  Yeah, I tried out a Raspberry Pi 4 as a desktop replacement and pretty much everything is supported except for proprietary stuff like games.
  - geerlingguy 6y ago
    Eh... that was not my experience: https://www.jeffgeerling.com/blog/2020/i-replaced-my-macbook-pro-raspberry-pi-4-8gb-day https://www.jeffgeerling.com/blog/2020/i-replaced-my-macbook... (Unless you're speaking almost entirely of webapps, which mostly run fine even on the measly 1.5 GHz 4-core Pi ARM processor.)
    - timthorn 6y ago
      I think most of the gripes described are really issues that come from moving from a MacOS desktop to try a Linux desktop; if you were moving from a x86 Linux desktop to the Pi the experience would have been much less painful.
    - aduitsis 6y ago
Q6T46nT668w6i3m 6y ago
Apple doesn’t control their machine learning stack. The models they ship are likely created and trained on PCs running Linux and NVIDIA GPUs. It’s entirely possible they’ll extend the Neural Engine to be useful for training but they’d still need to contribute or convince others to contribute to the existing tooling.
- nojito 6y ago
  The enduser doesn't care about training. iOS devs just care about APIs that Apple has built for them.
  - tanilama 6y ago
    What about developers developing those models? I think some worries are warranted.
- zitterbewegung 6y ago
  You can do some refinement right now already (from WWDC 2019). But yes, most models are trained on NVIDIA GPUs that are deep learning. All of the other model types can already be trained on regular CPUs. https://machinethink.net/blog/coreml-training-part1/ https://machinethink.net/blog/coreml-training-part1/
jl6 6y ago
Here's an analogy to help explain the skepticism: ants have amazing efficiency - they can lift multiples of their own body weight. So why can't an ant lift my car? Well, because it's too small. So let's just take the same ant design and scale it up? Unfortunately, it doesn't work like that. A creature capable of lifting my car wouldn't be much like an ant. There is no guarantee that a phone-scale CPU can just become 4x faster by 4x'ing the power/TDP/die area. If it were that easy, Intel would already have done it (and no, the x86 architecture isn't so terribly inefficient that they are leaving triple-digit percentage improvements on the table). What I expect we'll see are ARM chips that are power and performance competitive with x86 chips only for specific curated use cases. Apple will extract an advantage by putting custom hardware acceleration into them, to cater for those specific tasks. They will not be able to achieve general purpose performance improvements wildly beyond what Intel can already do. This is how the current iDevices achieve their excellent performance and battery life. Not through raw general-purpose CPU horsepower, but by a finely tuned synergy between hardware and software. Apple are taking their desktop down the same route. This will be the ultimate competitive advantage for their own software - they will be able to move key software components into hardware, and make it look like magic. But as a developer, you won't be able to participate in this unless you target Apple-blessed hardware instructions/APIs. Your Python script isn't going to start running 4x faster unless you can convince Apple to implement its inner loop in custom silicon. I have no doubt that Apple will be leaning hard into ASIC territory as they build out their new CPUs. The endgame? Every software function you need, baked into perfectly optimised silicon by the monovendor.
- eanzenberg 6y ago
  They already have a mobile chip that is as fast as an active-thermally cooled notebook chip.
  - fock 6y ago
    so could you provide some actual, open-source basic benchmarks. And not strange, opaque geekbench results... I guess AMD is fine for me (as is my old Intel-notebook) and I'll just wait for POVray, GROMACS and Co. EDIT: And well, I noticed, supposedly Anandtech ran SPECint2006 on the A13 (and numerous other chips) - they ran it with WSL for x86 (because running on a dozen Android things is easier than running a standard benchmark on Linux/Windows ofc). You find the results here: https://images.anandtech.com/doci/14892/spec2006-global-overview.png https://images.anandtech.com/doci/14892/spec2006-global-over... - I guess (not sure, because it's for some reason not cleary marked and mentioned...) these are SPECint2006-results. So, let's check them for validity (because WSL is no problem and it matches Linux ofc); just looking at an i7-6700K (which is a little bit behind the i9-9900K they supposedly ran on): https://www.spec.org/cpu2006/results/res2016q1/cpu2006-20160108-38634.html https://www.spec.org/cpu2006/results/res2016q1/cpu2006-20160... - marginal worse performance than @anandtech in some benchmarks, but that's with an older CPU and an older arch! And then there are the 3 or 4 benchmarks which are just way off. Makes one wonder, what they really did (because of course, installing CentOS and running SPEC on native Linux is too much of a hassle, when running and compiling on 8 ARM-platforms!?) EDITEDIT: it's even worse for SPECfp2006: https://www.spec.org/cpu2006/results/res2016q1/cpu2006-20160107-38616.html https://www.spec.org/cpu2006/results/res2016q1/cpu2006-20160... [well, here the old 6700K suddenly sometimes is twice as fast as the 9900K and 3x as fast as the A13 (and yeah the story of the 2.8GHz-low-power-chip drawing circles around a 4.5GHz-HF-part just didn't sound convincing in the first place...)]
ianhowson 6y ago
> So, I’m predicting an MBP 13 - 16 range with an extra three hours of battery life+, and 20-30% faster. I'm predicting the opposite: you won't actually see any difference. Once you look closely at power profiles on modern machines you'll see that most energy is going into display and GPU. CPUs mostly run idle. Even if you had a theoretical CPU using zero energy, most people are not going to get 30% battery life gains [1]. Not one thing that they demoed requires any meaningful CPU power. Similarly, while ARM parts are more efficient than x86 per compute cycle, it's not a dramatic change. The big changes, I think, are more mundane: - Apple is going to save $200-$800 cost per Mac shipped - Apple can start leaning on their specialized ML cores and accelerators. They will probably put that stuff in T2 for Intel Macs. If they're already shipping T2 on every machine, with a bunch of CPU cores, why not just make those CPU cores big enough for the main workload? Doubling CPU perf is meaningless if you can ship the right accelerators that'll do 100x energy/perf for video compression, crypto and graphics. [1] for a regular web browsing type user; obviously if you're compiling stuff this may not apply; if that is true you're almost certainly better off just getting a Linux desktop for the heavy lifting
- an_opabinia 6y ago
  > Apple is going to save $200-$800 cost per Mac shipped Whom is Apple going to sell binned A14s to? Where does everyone think margin comes from in the chip business?
  - Reason077 6y ago
    Apple will simply use different bins in different products. The A12X is arguably a "binned" A12Z, after all. Higher bins for pro lines, lower bins for consumer lines.
    - AnthonyMouse 6y ago
      Apple doesn't have the lineup for that. The CPU in the Mac Pro isn't the same silicon as the CPU in the Mini. It has more cores, bigger caches, more memory channels. It's not just the same chip binned differently. In theory they could offer the Mini with eighteen different CPU options, but that's not really their style.
old-gregg 6y ago
I'll bite. > Current A12z chips are highly performant; Apple is > roughly one chip cycle ahead on perfomance/watt from > any other manufacturer. We haven't been able to compare them. Micro-benchmarks do not count because mobile versions of Apple chips haven't been designed for desktop requirements. People love comparing CPU cores with micro-benchmarks, but the hardest thing for a modern desktop/server chip is to feed data to many cores while maintaining cache coherence. > So, I’m predicting an MBP 13 - 16 range with an > extra three hours of battery life+, and 20-30% faster. Before agreeing with your estimates, I want to play with a true 8-core Apple CPU with a large multi-level cache first. Building the Linux kernel with -J16 will be a fun exercise. Look, AMD is not stupid, and they're on the same node Apple will be using, and they're not 30% faster than even a 5y.o. Skylake. > Apple has to pay Intel and AMD profit margins for > their mac systems. They are going to be able to put > this margin back into a combination of profit and > tech budget as they choose. I wonder how their conversations with TSMC go. With Intel, at least they had AMD to use as a bargaining chip. With TSMC there's no alternative. > One interesting question I think is outstanding - > from parsing the video carefully, it seems to me > that devs are going to want ARM linux virtualized > vs AMD64. That's the big one. The world's software is built for and runs in data centers, not laptops. Our machines are increasingly becoming nothing but thin clients, remote displays that happen to run Javascript. CPUs do not matter. And I suspect that's the real reason they're switching. But from the developers perspective, it's incredibly convenient to use the same platform (OS + instruction set) as the machine they're targeting, even for interpreted languages. Linus Torvalds wrote a well-articulated email about this a while ago, IIRC he was commenting on POWER, but I think his points are valid. At my company, devs keep struggling with Docker on a Mac. Add to that the ARM pain, and I wonder how many will finally get a Thinkpad. Developers will switch to ARM when majority of AWS instance types goes ARM. P.S. I love how "old-tech" HN is, but for the love of god, give us a decent way to "reply with quote".
- pier25 6y ago
  > Look, AMD is not stupid, and they're on the same node Apple will be using Could you elaborate? What do you mean with the "same node"?
rkagerer 6y ago
it’s exciting to imagine what Apple’s fully vertically integrated company could do controlling hardware, OS and ML stack So true! But from a market dominance perspective, it's also a bit terrifying.
- 2OEH8eoCRo0 6y ago
  Replace Apple with Google or Microsoft and it would get shit on around here. Apple gets a pass
  - skohan 6y ago
    Apple's market share is still low enough for this to be a relative non-issue.
    - harmonicgf2 6y ago
      Apple's marketcap however ($1.5 trillion) has me worried.
ChrisMarshallNY 6y ago
I think it will work out fine. Apple has an absolutely top-shelf team, designing chips. By hand (Qualifier: Not sure if they still do, but they did, while everyone else was using automation). They also have a great deal of experience in repaving the highway while traffic is running at capacity. They mentioned it in their keynote. They've done it three times. I have been there, for each of those times. I was also there for the one time they completely pooched it (Can anyone say "Copeland"? Drop and give me twenty!). It will be moderately painful. Not too bad. Quite manageable, and it will take at least a couple of years to transition. I am in no hurry for one of those dev kits, though. They will be quite rough, and I have no compelling reason to use them. I am looking forward to an entirely new Xcode. The current one is getting crashier every day. I'd also like to have one that can run on my iPad.
- grandmczeb 6y ago
  > By hand Not using automation isn’t “badass”, it’s a sign of a deeply screwed up engineering culture. It’s on par with forcing software developers to program exclusively in machine code. Luckily, Apple uses the standard EDA tools pretty extensively so I don’t really think this applies to them. I also agree that Apple hardware engineers are generally extremely good.
  - ChrisMarshallNY 6y ago
    Toe-May-Toe, Toe-Mah-Toe. Some site that does tear downs (not iFixit) tore open one of their chips, once, and defecated masonry. They said the chip design was obviously hand-designed, and stood head and shoulders above other ARM architectures. They have done OK. Sorry if I offended you. None was meant. I’ll edit that out.
    - grandmczeb 6y ago
      The article likely meant they did a custom implementation of the architecture, not that they didn’t use automation during the design process. At least that’s what I’d assume without reading it (I’d be interested to read if you have link). It’s basically the difference between optimizing your application by rewriting the performance critical parts (good idea) and never using a compiler (bad idea). Also, I don’t think what you wrote is offensive in any way - no need to edit unless you feel compelled to.
Delk 6y ago
> I’m not highly conversant with ARM linux, but in my mind I imagine it’s still largely a second class citizen In terms of distros maybe yes. Most distros are targeted at laptops, desktops or servers, and few of those have ARM processors. In terms of architectural support by the kernel and low-level infra, I see no reason for that to be true at all. Open source kernels and (at least lower-level) userspace have for decades paid more attention to compatibility with various hardware architectures than proprietary operating systems. Of course you'll have fewer drivers for hardware associated with a particular architecture if there's less interest for the hardware, or if the hardware is less available in form factors that most developers are interested in. But that applies at least equally to non-open source platforms. If MS or Apple don't have a commercial interest in maintaining support for a particular platform (and they usually have only one or two in mind), nobody's going to do it.
- Gibbon1 6y ago
  > Most distros are targeted at laptops, desktops or servers, and few of those have ARM processors. I wouldn't bet my farm on that without a bunch of research and cross checking because embedded linux is really common. Consider manufacturers are producing very large numbers of embedded ARM micro's with external memory interfaces. I think the majority of those are running linux.
  - Delk 6y ago
    That's a fair point. I was referring to "most" distros in terms of the plain number of distros with reasonable mainstream visibility (and therefore possibly the majority focus from mainstream userspace developers), as a kind of a generous argument. The number of embedded Linux deployments is undoubtedly huge.
csjr 6y ago
Agree with you on some points, I’m really excited to see what’s next. I’m also betting on a new, and faster, MacBook maybe with a discounted price to incentive the migration? About the virtualization, they will probably make it more efficient, resource wise? Some cloud providers are also offering ARM so... Anxious to check the GPU performance too! To add: Control Center on macOS and some other UI improvements hints for Mac w/ touchscreen? Could we finally see a true BYOD, like Dex or using the improvements in Handoff?
looping__lui 6y ago
“Apple’s own pro apps will be updated to support the company’s new silicon in macOS Big Sur, and the company is hoping developers will update their apps. “The vast majority of developers can get their apps up and running in a matter of days,” claims Craig Federighi, Apple’s senior vice president of software engineering. []... Microsoft is working on Office updates for the new Mac silicon, and Word and Excel are already running natively on the new Mac processors, with PowerPoint even using Apple’s Metal tech for rendering. Apple has also been working with Adobe to get these pro apps up and running on these new chips.“ So the bottom line is: “your previous tools won’t work, will have to be rewritten, the burden is on the developers so we can rake in more cash” Great, customer focused, and completely altruistic move back in the days when they killed Nvidia cards on high-performance rendering and simulation machines (and everywhere else). So, Apple has performance libraries that are better than what Intel has to offer? So, cross-platform applications are now again “passe”? I don’t use my iPhone for working. Why would I want iOS Apps on my computer? So I can install Apple Mail instead of Outlook
- colejohnson66 6y ago
  > So the bottom line is: “your previous tools won’t work, will have to be rewritten, the burden is on the developers so we can rake in more cash” Did you miss the part where there’s going to be a “Rosetta 2” AOT/JIT translation layer?
  - looping__lui 6y ago
    You are aware that you will (most likely) lose all those pretty amazing optimisations that you tend to rely on if you develop software that is a bit more “sophisticated” (e.g., parallel programming leveraging IPP etc.). Can’t wait to see how fast that translation layer will be for my FFTs that have been super optimised for Intel chips. I wonder: when I observed 20+% performance loss for high compute intensive scientific tasks Intel vs. AMD because I relied on IPP - how much performance loss will we see for the x86 to Arm? For your average Text application you may not care about performance loss. But I bet you, that for video, image editing, science etc. you are easily 20+% worse off than before. So what exactly is the benefit for the customer or the developer community? So I can play Angry birds on my Mac?
Teknoman117 6y ago
Why do feel that Rust is behind on ARM? I can't comment on the performance, but everything that I used that was purely written in Rust compiled and ran perfectly on my PineBook Pro. (with the exception of alacritty, but that's because PBP doesn't support OpenGL 3.x) Go does have the (platform) advantage (?) of preferring the "rewrite everything in Go" approach, so those just transition when the tooling supports a new architecture. Rust is intentionally going with a interop design, rather than telling people the only answer to to rewrite all their favorite libraries.
- steveklabnik 6y ago
  Rust and ARM is just fine. For example, Cloudflare famously keeps their entire stack cross-compilable to ARM, and even ships Rust on iPhones. There's two areas where I believe you could call it second-class at the moment, though: 1. There is no ARM targets in Rust's "Tier 1" platform support. 2. std::arch doesn't have ARM intrinsics in stable. For 1, ARM targets are in a weird space; they aren't Tier 1, but they're closer than most of the other Tier 2 targets. Several ARM targets are Tier 1 for Firefox, for example, so they get a bunch of work done there. For 2, well, there hasn't been as much demand before. I expect that to change because of this. ... we'll see what the future holds :)
  - sroussey 6y ago
    Sounds like this will cost Mozilla some time and money, but they will have to support it.
    - steveklabnik 6y ago
      I’m not sure why. As I said, they’ve been using Rust on ARM (as part of Firefox) for a long time; I’m not aware of them being unsatisfied with the current state. I expect that the Rust project will end up benefiting from the extra interest though, and improving on the things above.
      - fork-bomber 6y ago
stjohnswarts 6y ago
I'm not sure I agree with you on most of this, but I think more competition in the cpu biz is always a good thing.
leonidasv 6y ago
Apple chips are fast mostly because they have a lot of cache to spare. Take for example the A12Z. It has 8MB of L2 (not L3, it's L2!) cache. An Intel Core i7-1068NG7 present in the latest Macbook Pros (that performs akin to the A12Z according to Geekbench) has only 2MB of L2 cache. No other ARM CPU has this level of L2 cache. Apple chips are not "magical", Apple just can afford packing up lots and lots of cache because they are not in the silicon "race to the bottom" like Qualcomm and Intel are, for example. L2 cache is very expensive and Apple is just hacking its way up by packing as much L2 cache as they can. Don't take me wrong, it's not that Apple is "right" or "wrong" by doing it. They just can and did it. However, it's needless to say that their CPUs are not so different from other ARM ones, they just happen to have a budget and a business model that let's them ignore the price/performance ratio when designing chips in order to achieve the maximum performance.
- kllrnohj 6y ago
  > Take for example the A12Z. It has 8MB of L2 (not L3, it's L2!) It's not really that clear cut. You could also argue that the A12Z has 8MB of L3 and 0MB of L2. The L2 in the A12Z is shared while the L2 in the Intel CPU is not. Similarly the latency of the A12Z's L2 is a lot higher than the latency of Intel's L2, but also then still lower than Intel's L3. https://images.anandtech.com/doci/13661/A12X-lat.png https://images.anandtech.com/doci/13661/A12X-lat.png & https://images.anandtech.com/doci/14664/ICLlat.png https://images.anandtech.com/doci/14664/ICLlat.png So it's not "traditional" L2 as you're familiar with it, it's more like an L2.5 or something. Although still accurately called L2 as it is the second level of cache, it's just that Apple went with a rather different cache hierarchy & latency structure than Intel did. But it's really not at all accurate to compare the 8MB of L2 on the A12Z to the 2MB of L2 on Ice Lake. Those are very different caches.
  - leonidasv 6y ago
    Latency increases as cache size increases. That's well a well known fact.
- hn_check 6y ago
  Why do you quote magical as if someone said that. Further, your point is that Apple chips are faster because of easily replicated reasons. Intel is charging hundreds of dollars for their chip -- you should charge them some consulting fees and tell them how easy this is to boost their performance! This isn't even considering that your whole analysis is flawed to begin with and you're comparing apples and oranges.
jlarocco 6y ago
> One interesting question I think is outstanding - from parsing the video carefully, it seems to me that devs are going to want ARM linux virtualized, vs AMD64. I’m not highly conversant with ARM linux, but in my mind I imagine it’s still largely a second class citizen — I wonder if systems developers will get on board, deal with slower / higher battery draw intel virtualization, or move on from Apple. Somewhat ironically, I think it's mostly the languages trying to be safer alternatives to C that are most behind on supporting ARM. I've done a little bit of Lisp development on my Raspberry Pi (with SBCL and Emacs/Slime), and in most cases I don't have to change anything moving between my AMD64/Linux desktop, Intel/OSX MBP, and ARM64/Linux Raspberry Pi. And that's even when using CFFI bindings to C libraries. I'm not sure SBCL's ARM backend is at the same level as the x86 backends, but it works well, and there's on going work on it.
jimnotgym 6y ago
> those complaints are 100% down to being saddled with Intel. And yet the new Macbook pro base models feature an 8th Gen Core i5. That is 2 generations behind the bleeding edge. I think some people might be experiencing the speed problems you described because their machine has an old gen processor in a shiny new box
- pathartl 6y ago
  Not to mention that Apple setting a standard of throttling at 100c and not giving the machines adequate cooling affects performance in a non-trivial fashion.
tolmasky 6y ago
I haven't felt particularly constrained from CPU in a long time. My main issues have been with RAM (thankfully the new MacBooks finally started supporting 32GB of RAM), and GPU, which ever since Apple has been in a fight with NVIDIA has been miserable. It's not just that Apple doesn't use NVIDIA, it's that they won't allow them to ship their own drivers for it. I just want to plug in an eGPU to an RTX 2080 card. Instead, you have this incredibly limited set of officially supported cards the are also hyper expensive. Black Magic stopped making their eGPU Pro, so even if money is no object you can't get a great laptop GPU extension that supports their XDR displays. Now, you might be saying, if you want a great GPU why are buying a laptop? Well, 1) even if I were to get the one model of Mac that allows me to do something interesting with GPUs (Mac Pro), I still can't install the NVIDIA cards I want. And 2) laptop + great eGPU is a great setup that is supported in the non-Mac space, so it is not a bizarre request. All of this to say: the ARM stuff is fine, but it won't really move the needle for me, and doesn't address any of my performance issues, and I would argue a lot of the performance issues a lot of people actually have (especially graphics artists).
Sleaker 6y ago
Wont this move result in more software compatibility issues from developer side though? Like why would you buy the update if the developers don't want to move to the new platform or determine it's too big of a change now?
larozin 6y ago
> One interesting question I think is outstanding - from parsing the video carefully, it seems to me that devs are going to want ARM linux virtualized, vs AMD64. Hahaha, look for a user-agent at 1:44:26 :) They use old Intel Mac for a virtualization demo.
rkhassen9 6y ago
Paid for by Apple?
pcwalton 6y ago
Rust isn't behind on ARM, except for SIMD intrinsics on stable, which are not things most languages (e.g. Java, Go) have at all for any architecture.
kovek 6y ago
I think MacBooks can run heavy ML processes, but why not run those on separate devices with specific hardware for that? I'm thinking any kind of job you'd want to run on the GPU.
celloductor 6y ago
it's easy to resign iphone models every year. it's not as easy to increase chip performance every year. there's a lot of R&D involved, i think in the long run it'll be better but Apple will have to devote more resources into it. you can't just wish for specs. the manufacturers actually get the hard job of trying to make it.
nooneknowswhy 6y ago
This is not enough for a Pro consumer. There are a wide range of development-related softwares/tools that are not compatible with ARM. And they do not usually come with huge user base. So there will not be any ARM port. They are free to try it on Macbook or Air. But MBPs? They are simply giving the market to Windows.
jrobn 6y ago
The main thing Apple has done to improve their A-series chips has been massive L2 caches. I still major advantages of putting a A-series chip into a MacBook Pro. 1) There will be a much larger thermal and power draw envelope available to new A-series chip. I suspect we will see insane “boosting” clock speeds. 2) Incredible “at idle” performance well beyond what X86 can provide with on did GPU cores, which means a bit better battery life for that screen. 3) More opportunity for tightly integrated acceleration chips On die for codec, ML, and other hardware acceleration methods for Apple only software libraries. 4) Easy porting between iOS and macOS, and tvOS. #3 will be the most significant.
- imtringued 6y ago
  I don't want to repeat myself so I'll just link to my previous comment. https://news.ycombinator.com/item?id=23612245 https://news.ycombinator.com/item?id=23612245
9fathom 6y ago
> One interesting question I think is outstanding - from parsing the video carefully, it seems to me that devs are going to want ARM linux virtualized, vs AMD64. I’m not highly conversant with ARM linux, but in my mind I imagine it’s still largely a second class citizen — I wonder if systems developers will get on board, deal with slower / higher battery draw intel virtualization, or move on from Apple. It's in fairly good shape, and has an active community. With the current proliferation of IoT devices, both the kernel and userland are well-maintained, and plenty of distros are available. The kernel also benefits from much of the work done for Android and Chromebooks as well. All of the usual FOSS software is ported and runs well. As of this moment, you could easily take your pick from any of Debian, Ubuntu, Fedora, Arch, Manjaro, Slack, or Alpine just for starters, plus a whole mess of specialty distros. Many of those offer both 32- and 64-bit ARM versions. Also bear in mind that recent ARM CPUs do support hardware-assisted virtualization as well. KVM and Xen are both available for ARM today, and I'd be shocked if Apple's Hypervisor.framework doesn't roll out with ARM support in the new macOS version as well. (I'm writing this from Firefox in Manjaro ARM on a PineBook Pro, that I use as my daily driver)
greggman3 6y ago
I'm excited. My #1 wish is a 16" MacBook Pro that ways 3 lbs or less. Take an iPad Pro, make it 16" instead of 12, add a keyboard, run MacOS. LG already makes 15.6" intel notebooks that weigh 3 lbs. Apple can do it too!
rock_artist 6y ago
> Apple has a functional corporate culture that ships; Well we've already seen things gets delayed and even canceled (AirPower). Cook's Apple is more about supply chain (where he excels), so if indeed the silicon design works, they would be able to 'ship'.
tdsamardzhiev 6y ago
Not a fan of Apple, but x86 is a mess and I'd love to see companies pushing for its replacement.
- skohan 6y ago
  What's the issue with x86? Genuinely asking
  - imtringued 6y ago
    It's compatible with all the software I own. Using proton is already a hassle. Adding emulation will just make it worse.
    - tdsamardzhiev 6y ago
      Software compatibility will obviously be the main problem to resolve, but I'm an optimist.
  - tdsamardzhiev 6y ago
    It has a lot of historical baggage, most notably implicit interdependencies that make it hard/impossible to optimize and reorder stuff. We're entering an era of many-core processors, and IMHO we'll absolutely have to move to a RISC architecture, and the sooner we get that box checked, the better.
geesejuggler 6y ago
> Languages like Go with supremely simple cross architecture support might get a boost here. Go's crypto libraries are heavily optimized on x86, not so on arm (see Phoronix Graviton2 benches). We will have to wait and see how much of Apple's halo effect will contribute positively to optimized arm code.
ksec 6y ago
I am predicting the opposite. Apple isn't about the extend its Mac for Performance or Battery sake. They are going about expanding its marketshare. There are close to 1 Billion iPhone users, most of them have never used a Mac. We will need a 2nd Devices for some of those task. And that will either be a iPad or Mac. Out of the 1.5B total PC Market, Apple has 100M Mac users. I will say it is not too far fetched to say Apple wants to double the number of Mac users to 200M. For every $100 dollar going to Intel, Apple could knock $200 off its Retail price while getting the same margin. A $799 MacBook ( the same starting price of iPad Pro ) will be disruptive, the premium is now small enough over the ~$500 PC Notebook price. In the longer term I think Apple is trying to reach 2 Billion Active Devices. And it certainly cant do this with iPhone alone. There are plenty of Market Space for the Mac to disrupt.
- thewileyone 6y ago
  > For every $100 dollar going to Intel, Apple could knock $200 off its Retail price while getting the same margin. They're not going to change their retail price. It'll be the same, but "better"/"different" ... that's how they'll market it.
  - dannyw 6y ago
    I suspect it'll allow them to put OLEDs on the Macs. That would be a GIGANTIC unique differentiator for the Macs. Once you see it, you won't be able to tolerate a non-OLED display. ever again. I'm just thinking about my development environment background, Terminal, etc in pure black and off... Wow.
thewileyone 6y ago
> Apple has a functional corporate culture that ships; adding complete control of the hardware stack in is going to make for better products, full stop. One word, Catalina.
mlindner 6y ago
> Rust seems behind on ARM, for instance; I bet that will change in the next year or two. I don’t imagine that developing Intel server binaries on an ARM laptop with Rust will be pleasant. Umm what? Rust supports ARM as a first class citizen as does LLVM. They only list ARM as second class because it's not a desktop platform generally. https://forge.rust-lang.org/release/platform-support.html https://forge.rust-lang.org/release/platform-support.html
willtim 6y ago
You've missed off possibly the biggest advantage of ditching Intel. A perfectly usable machine without jet engine fans and a scolded lap. I don't use Mac's, but I see this as good for the industry.
secondcoming 6y ago
I'm not sure virtualising ARM on Intel platforms will ever be performant enough to be usable. They will probably have to ship an emulator, and even then there will be issues as it'll be very difficult to emulate the strictness of ARM CPUs on non-ARM architectures, for things like unaligned memory accesses and replicating the memory model.
deleted 6y ago
[deleted]

kllrnohj 6y ago

> Apple is roughly one chip cycle ahead on perfomance/watt from any other manufacturer. Eh? This is a flimsy claim. AMD's performance/watt is extremely impressive right now. Apple is ahead of Intel for sure, but Intel isn't the only other player here. > So, I’m predicting an MBP 13 - 16 range with an extra three hours of battery life+, and 20-30% faster. Alternately a Macbook Air type with 16 hours plus strong 4k performance. A slightly more efficient CPU doesn't get you this. You need significant efficiency improvements across a variety of aspects, including those Apple has already been optimizing for years like the display.

StillBored 6y ago
AMD is tiny compared to intel, the fact that they are besting them goes to show how they have been stuck for ~5 years. The real problem though, is that apple is actually designing a core 100% focused on the target market. Unlike intel, for whatever reason, and AMD which didn't have the funds to run a dedicated design team for laptop/desktops. So, I would expect the engineering tradeoffs for said laptop/desktop processor to show. AKA, things like hyperthreading are quite a win for servers, but at best are a wash for a desktop use case focused on extremely high single thread perf at the expense of throughput.
- moooo99 6y ago
  > AMD which didn't have the funds to run a dedicated design team for laptop/desktops. Given the extremely impressive performance of the 4800H notebook cpus, I'd assume that might be a thing of the past. > AKA, things like hyperthreading are quite a win for servers, but at best are a wash for a desktop use case focused on extremely high single thread perf at the expense of throughput. This might be true for devices like the MacBook Air which are designed for relatively light usage like Office, but I don't see that argument working with their "Pro" lineup, including the iMac Pro and the MacBook Pro. These are devices specifically targeted to a professional audience like graphics designers, 3d artists, software developers or video editors. All of those tasks can be done with decent single-threaded performance, but lots of those tasks also benefit from multithreading. I haven't owned a single MacBook so far and I doubt that'll change anytime soon. Nevertheless, its exciting to see Apple do this move and it'll be interesting how good their CPUs can compare to mobile processors by Intel and AMD.
  - ebg13 6y ago
    > Given the extremely impressive performance of the 4800H notebook cpus, I'd assume that might be a thing of the past. The TDP on those is, what, 3-4x the A12Z?
    - sudosysgen 6y ago
      With twice the cores at a higher per-core speed, yes. And also with a much more powerful GPU.

moduspol 6y ago

Agreed on all points. I saw speculation elsewhere that this change, along with AWS's addition of Graviton-based (their own ARM processors) instances at much more competitive price points relative to x86, are bound to spearhead the change to "ARM by default." If your devs are already using ARM, and ARM's notably cheaper in the cloud, that's a compelling case. If you're already using Kubernetes / Docker heavily, you're probably already 80% of the way there. Linuxes that aren't supporting ARM as a "first class citizen" will soon, and undoubtedly that will be a speed bump at worst. I'm interested to see the specs relative to the x86 Macs, but the only open question to me was whether or not we'd see the x86 emulation layer. Well, we did, and it may not be perfect but it certainly looks like they put a lot of effort into it. If it works as well as it looks, I think this transition is borderline inevitable. I think I've bought my last x86 hardware.

kllrnohj 6y ago
This claim doesn't really hold up. The problem here is the vast majority of non-Apple laptops & desktops that are in use. THOSE will still all be x86 for the foreseeable future as ARM CPUs not made by Apple all have terrible per-core performance. Graviton2 compensates by just throwing 64 cores at the problem, but that's not going to do anything for your Electron-based text editor that struggles to use 2 CPU cores in the first place. Or for a typical webpage, which struggles to use more than a single CPU core. But otherwise as a developer-focused example the 32-core Epyc Rome compiles Build2 faster than the 64-core Graviton 2: https://openbenchmarking.org/embed.php?i=2006047-PTS-EPYC2EC201&sha=fd75564&p=2 https://openbenchmarking.org/embed.php?i=2006047-PTS-EPYC2EC... That's going to matter when a company is spec'ing out workstations to buy, which are unlikely to have an Apple option on the table at all in the first place, and Amazon isn't going to sell you Graviton2 CPUs to put under your desk, either. This _could_ be the start of a bigger focus on ARM, definitely, but to really make inroads into what devs use you'll need someone other than Apple to step up to the plate. Or for Apple to become vastly larger than they are in the desktop space. Otherwise we'll all just keep cross-compiling like we have been for the last decade of mobile app development.
- klelatti 6y ago

chooseaname 6y ago

> So, I’m predicting an MBP 13 - 16 range with an extra three hours of battery life+f I predict they'll have the same battery life. Any savings will be used to reduce the battery size.

abhorrence 6y ago
I think without Ive they'll take the battery life and market it as the incredible win of moving away from Intel.
- snazz 6y ago
  Agreed. I think this is especially likely given their decision to increase the battery size in the iPhone 11 lineup last year.

zitterbewegung 6y ago

I agree with you but I think we are going to see at least one A12Z consumer product (other than the iPad) probably going to be a rereleased MacBook with a better keyboard.

justinfrankel 6y ago

> I’m not highly conversant with ARM linux, but in my mind I imagine it’s still largely a second class citizen IMO ARM linux is great, the real thing lacking is good hardware to run it.

dfox 6y ago
You mean all the Android handsets? The history of Linux on ARM is colorful, full of corporate missteps and giant brands (namely HTC and to lesser extent Samsung) that were created from that.
- imtringued 6y ago
  None of them come close to the performance Apple achieves on their chips.
swebs 6y ago
Yeah, I tried out a Raspberry Pi 4 as a desktop replacement and pretty much everything is supported except for proprietary stuff like games.
- geerlingguy 6y ago
  Eh... that was not my experience: https://www.jeffgeerling.com/blog/2020/i-replaced-my-macbook-pro-raspberry-pi-4-8gb-day https://www.jeffgeerling.com/blog/2020/i-replaced-my-macbook... (Unless you're speaking almost entirely of webapps, which mostly run fine even on the measly 1.5 GHz 4-core Pi ARM processor.)
  - timthorn 6y ago
    I think most of the gripes described are really issues that come from moving from a MacOS desktop to try a Linux desktop; if you were moving from a x86 Linux desktop to the Pi the experience would have been much less painful.
  - aduitsis 6y ago

Q6T46nT668w6i3m 6y ago

Apple doesn’t control their machine learning stack. The models they ship are likely created and trained on PCs running Linux and NVIDIA GPUs. It’s entirely possible they’ll extend the Neural Engine to be useful for training but they’d still need to contribute or convince others to contribute to the existing tooling.

nojito 6y ago
The enduser doesn't care about training. iOS devs just care about APIs that Apple has built for them.
- tanilama 6y ago
  What about developers developing those models? I think some worries are warranted.
zitterbewegung 6y ago
You can do some refinement right now already (from WWDC 2019). But yes, most models are trained on NVIDIA GPUs that are deep learning. All of the other model types can already be trained on regular CPUs. https://machinethink.net/blog/coreml-training-part1/ https://machinethink.net/blog/coreml-training-part1/

jl6 6y ago

Here's an analogy to help explain the skepticism: ants have amazing efficiency - they can lift multiples of their own body weight. So why can't an ant lift my car? Well, because it's too small. So let's just take the same ant design and scale it up? Unfortunately, it doesn't work like that. A creature capable of lifting my car wouldn't be much like an ant. There is no guarantee that a phone-scale CPU can just become 4x faster by 4x'ing the power/TDP/die area. If it were that easy, Intel would already have done it (and no, the x86 architecture isn't so terribly inefficient that they are leaving triple-digit percentage improvements on the table). What I expect we'll see are ARM chips that are power and performance competitive with x86 chips only for specific curated use cases. Apple will extract an advantage by putting custom hardware acceleration into them, to cater for those specific tasks. They will not be able to achieve general purpose performance improvements wildly beyond what Intel can already do. This is how the current iDevices achieve their excellent performance and battery life. Not through raw general-purpose CPU horsepower, but by a finely tuned synergy between hardware and software. Apple are taking their desktop down the same route. This will be the ultimate competitive advantage for their own software - they will be able to move key software components into hardware, and make it look like magic. But as a developer, you won't be able to participate in this unless you target Apple-blessed hardware instructions/APIs. Your Python script isn't going to start running 4x faster unless you can convince Apple to implement its inner loop in custom silicon. I have no doubt that Apple will be leaning hard into ASIC territory as they build out their new CPUs. The endgame? Every software function you need, baked into perfectly optimised silicon by the monovendor.

eanzenberg 6y ago
They already have a mobile chip that is as fast as an active-thermally cooled notebook chip.
- fock 6y ago
  so could you provide some actual, open-source basic benchmarks. And not strange, opaque geekbench results... I guess AMD is fine for me (as is my old Intel-notebook) and I'll just wait for POVray, GROMACS and Co. EDIT: And well, I noticed, supposedly Anandtech ran SPECint2006 on the A13 (and numerous other chips) - they ran it with WSL for x86 (because running on a dozen Android things is easier than running a standard benchmark on Linux/Windows ofc). You find the results here: https://images.anandtech.com/doci/14892/spec2006-global-overview.png https://images.anandtech.com/doci/14892/spec2006-global-over... - I guess (not sure, because it's for some reason not cleary marked and mentioned...) these are SPECint2006-results. So, let's check them for validity (because WSL is no problem and it matches Linux ofc); just looking at an i7-6700K (which is a little bit behind the i9-9900K they supposedly ran on): https://www.spec.org/cpu2006/results/res2016q1/cpu2006-20160108-38634.html https://www.spec.org/cpu2006/results/res2016q1/cpu2006-20160... - marginal worse performance than @anandtech in some benchmarks, but that's with an older CPU and an older arch! And then there are the 3 or 4 benchmarks which are just way off. Makes one wonder, what they really did (because of course, installing CentOS and running SPEC on native Linux is too much of a hassle, when running and compiling on 8 ARM-platforms!?) EDITEDIT: it's even worse for SPECfp2006: https://www.spec.org/cpu2006/results/res2016q1/cpu2006-20160107-38616.html https://www.spec.org/cpu2006/results/res2016q1/cpu2006-20160... [well, here the old 6700K suddenly sometimes is twice as fast as the 9900K and 3x as fast as the A13 (and yeah the story of the 2.8GHz-low-power-chip drawing circles around a 4.5GHz-HF-part just didn't sound convincing in the first place...)]

ianhowson 6y ago

> So, I’m predicting an MBP 13 - 16 range with an extra three hours of battery life+, and 20-30% faster. I'm predicting the opposite: you won't actually see any difference. Once you look closely at power profiles on modern machines you'll see that most energy is going into display and GPU. CPUs mostly run idle. Even if you had a theoretical CPU using zero energy, most people are not going to get 30% battery life gains [1]. Not one thing that they demoed requires any meaningful CPU power. Similarly, while ARM parts are more efficient than x86 per compute cycle, it's not a dramatic change. The big changes, I think, are more mundane: - Apple is going to save $200-$800 cost per Mac shipped - Apple can start leaning on their specialized ML cores and accelerators. They will probably put that stuff in T2 for Intel Macs. If they're already shipping T2 on every machine, with a bunch of CPU cores, why not just make those CPU cores big enough for the main workload? Doubling CPU perf is meaningless if you can ship the right accelerators that'll do 100x energy/perf for video compression, crypto and graphics. [1] for a regular web browsing type user; obviously if you're compiling stuff this may not apply; if that is true you're almost certainly better off just getting a Linux desktop for the heavy lifting

an_opabinia 6y ago
> Apple is going to save $200-$800 cost per Mac shipped Whom is Apple going to sell binned A14s to? Where does everyone think margin comes from in the chip business?
- Reason077 6y ago
  Apple will simply use different bins in different products. The A12X is arguably a "binned" A12Z, after all. Higher bins for pro lines, lower bins for consumer lines.
  - AnthonyMouse 6y ago
    Apple doesn't have the lineup for that. The CPU in the Mac Pro isn't the same silicon as the CPU in the Mini. It has more cores, bigger caches, more memory channels. It's not just the same chip binned differently. In theory they could offer the Mini with eighteen different CPU options, but that's not really their style.

old-gregg 6y ago

I'll bite. > Current A12z chips are highly performant; Apple is > roughly one chip cycle ahead on perfomance/watt from > any other manufacturer. We haven't been able to compare them. Micro-benchmarks do not count because mobile versions of Apple chips haven't been designed for desktop requirements. People love comparing CPU cores with micro-benchmarks, but the hardest thing for a modern desktop/server chip is to feed data to many cores while maintaining cache coherence. > So, I’m predicting an MBP 13 - 16 range with an > extra three hours of battery life+, and 20-30% faster. Before agreeing with your estimates, I want to play with a true 8-core Apple CPU with a large multi-level cache first. Building the Linux kernel with -J16 will be a fun exercise. Look, AMD is not stupid, and they're on the same node Apple will be using, and they're not 30% faster than even a 5y.o. Skylake. > Apple has to pay Intel and AMD profit margins for > their mac systems. They are going to be able to put > this margin back into a combination of profit and > tech budget as they choose. I wonder how their conversations with TSMC go. With Intel, at least they had AMD to use as a bargaining chip. With TSMC there's no alternative. > One interesting question I think is outstanding - > from parsing the video carefully, it seems to me > that devs are going to want ARM linux virtualized > vs AMD64. That's the big one. The world's software is built for and runs in data centers, not laptops. Our machines are increasingly becoming nothing but thin clients, remote displays that happen to run Javascript. CPUs do not matter. And I suspect that's the real reason they're switching. But from the developers perspective, it's incredibly convenient to use the same platform (OS + instruction set) as the machine they're targeting, even for interpreted languages. Linus Torvalds wrote a well-articulated email about this a while ago, IIRC he was commenting on POWER, but I think his points are valid. At my company, devs keep struggling with Docker on a Mac. Add to that the ARM pain, and I wonder how many will finally get a Thinkpad. Developers will switch to ARM when majority of AWS instance types goes ARM. P.S. I love how "old-tech" HN is, but for the love of god, give us a decent way to "reply with quote".

pier25 6y ago
> Look, AMD is not stupid, and they're on the same node Apple will be using Could you elaborate? What do you mean with the "same node"?

rkagerer 6y ago

it’s exciting to imagine what Apple’s fully vertically integrated company could do controlling hardware, OS and ML stack So true! But from a market dominance perspective, it's also a bit terrifying.

2OEH8eoCRo0 6y ago
Replace Apple with Google or Microsoft and it would get shit on around here. Apple gets a pass
- skohan 6y ago
  Apple's market share is still low enough for this to be a relative non-issue.
  - harmonicgf2 6y ago
    Apple's marketcap however ($1.5 trillion) has me worried.

ChrisMarshallNY 6y ago

I think it will work out fine. Apple has an absolutely top-shelf team, designing chips. By hand (Qualifier: Not sure if they still do, but they did, while everyone else was using automation). They also have a great deal of experience in repaving the highway while traffic is running at capacity. They mentioned it in their keynote. They've done it three times. I have been there, for each of those times. I was also there for the one time they completely pooched it (Can anyone say "Copeland"? Drop and give me twenty!). It will be moderately painful. Not too bad. Quite manageable, and it will take at least a couple of years to transition. I am in no hurry for one of those dev kits, though. They will be quite rough, and I have no compelling reason to use them. I am looking forward to an entirely new Xcode. The current one is getting crashier every day. I'd also like to have one that can run on my iPad.

grandmczeb 6y ago
> By hand Not using automation isn’t “badass”, it’s a sign of a deeply screwed up engineering culture. It’s on par with forcing software developers to program exclusively in machine code. Luckily, Apple uses the standard EDA tools pretty extensively so I don’t really think this applies to them. I also agree that Apple hardware engineers are generally extremely good.
- ChrisMarshallNY 6y ago
  Toe-May-Toe, Toe-Mah-Toe. Some site that does tear downs (not iFixit) tore open one of their chips, once, and defecated masonry. They said the chip design was obviously hand-designed, and stood head and shoulders above other ARM architectures. They have done OK. Sorry if I offended you. None was meant. I’ll edit that out.
  - grandmczeb 6y ago
    The article likely meant they did a custom implementation of the architecture, not that they didn’t use automation during the design process. At least that’s what I’d assume without reading it (I’d be interested to read if you have link). It’s basically the difference between optimizing your application by rewriting the performance critical parts (good idea) and never using a compiler (bad idea). Also, I don’t think what you wrote is offensive in any way - no need to edit unless you feel compelled to.

Delk 6y ago

> I’m not highly conversant with ARM linux, but in my mind I imagine it’s still largely a second class citizen In terms of distros maybe yes. Most distros are targeted at laptops, desktops or servers, and few of those have ARM processors. In terms of architectural support by the kernel and low-level infra, I see no reason for that to be true at all. Open source kernels and (at least lower-level) userspace have for decades paid more attention to compatibility with various hardware architectures than proprietary operating systems. Of course you'll have fewer drivers for hardware associated with a particular architecture if there's less interest for the hardware, or if the hardware is less available in form factors that most developers are interested in. But that applies at least equally to non-open source platforms. If MS or Apple don't have a commercial interest in maintaining support for a particular platform (and they usually have only one or two in mind), nobody's going to do it.

Gibbon1 6y ago
> Most distros are targeted at laptops, desktops or servers, and few of those have ARM processors. I wouldn't bet my farm on that without a bunch of research and cross checking because embedded linux is really common. Consider manufacturers are producing very large numbers of embedded ARM micro's with external memory interfaces. I think the majority of those are running linux.
- Delk 6y ago
  That's a fair point. I was referring to "most" distros in terms of the plain number of distros with reasonable mainstream visibility (and therefore possibly the majority focus from mainstream userspace developers), as a kind of a generous argument. The number of embedded Linux deployments is undoubtedly huge.

csjr 6y ago

Agree with you on some points, I’m really excited to see what’s next. I’m also betting on a new, and faster, MacBook maybe with a discounted price to incentive the migration? About the virtualization, they will probably make it more efficient, resource wise? Some cloud providers are also offering ARM so... Anxious to check the GPU performance too! To add: Control Center on macOS and some other UI improvements hints for Mac w/ touchscreen? Could we finally see a true BYOD, like Dex or using the improvements in Handoff?

looping__lui 6y ago

“Apple’s own pro apps will be updated to support the company’s new silicon in macOS Big Sur, and the company is hoping developers will update their apps. “The vast majority of developers can get their apps up and running in a matter of days,” claims Craig Federighi, Apple’s senior vice president of software engineering. []... Microsoft is working on Office updates for the new Mac silicon, and Word and Excel are already running natively on the new Mac processors, with PowerPoint even using Apple’s Metal tech for rendering. Apple has also been working with Adobe to get these pro apps up and running on these new chips.“ So the bottom line is: “your previous tools won’t work, will have to be rewritten, the burden is on the developers so we can rake in more cash” Great, customer focused, and completely altruistic move back in the days when they killed Nvidia cards on high-performance rendering and simulation machines (and everywhere else). So, Apple has performance libraries that are better than what Intel has to offer? So, cross-platform applications are now again “passe”? I don’t use my iPhone for working. Why would I want iOS Apps on my computer? So I can install Apple Mail instead of Outlook

colejohnson66 6y ago
> So the bottom line is: “your previous tools won’t work, will have to be rewritten, the burden is on the developers so we can rake in more cash” Did you miss the part where there’s going to be a “Rosetta 2” AOT/JIT translation layer?
- looping__lui 6y ago
  You are aware that you will (most likely) lose all those pretty amazing optimisations that you tend to rely on if you develop software that is a bit more “sophisticated” (e.g., parallel programming leveraging IPP etc.). Can’t wait to see how fast that translation layer will be for my FFTs that have been super optimised for Intel chips. I wonder: when I observed 20+% performance loss for high compute intensive scientific tasks Intel vs. AMD because I relied on IPP - how much performance loss will we see for the x86 to Arm? For your average Text application you may not care about performance loss. But I bet you, that for video, image editing, science etc. you are easily 20+% worse off than before. So what exactly is the benefit for the customer or the developer community? So I can play Angry birds on my Mac?

Teknoman117 6y ago

Why do feel that Rust is behind on ARM? I can't comment on the performance, but everything that I used that was purely written in Rust compiled and ran perfectly on my PineBook Pro. (with the exception of alacritty, but that's because PBP doesn't support OpenGL 3.x) Go does have the (platform) advantage (?) of preferring the "rewrite everything in Go" approach, so those just transition when the tooling supports a new architecture. Rust is intentionally going with a interop design, rather than telling people the only answer to to rewrite all their favorite libraries.

steveklabnik 6y ago
Rust and ARM is just fine. For example, Cloudflare famously keeps their entire stack cross-compilable to ARM, and even ships Rust on iPhones. There's two areas where I believe you could call it second-class at the moment, though: 1. There is no ARM targets in Rust's "Tier 1" platform support. 2. std::arch doesn't have ARM intrinsics in stable. For 1, ARM targets are in a weird space; they aren't Tier 1, but they're closer than most of the other Tier 2 targets. Several ARM targets are Tier 1 for Firefox, for example, so they get a bunch of work done there. For 2, well, there hasn't been as much demand before. I expect that to change because of this. ... we'll see what the future holds :)
- sroussey 6y ago
  Sounds like this will cost Mozilla some time and money, but they will have to support it.
  - steveklabnik 6y ago
    I’m not sure why. As I said, they’ve been using Rust on ARM (as part of Firefox) for a long time; I’m not aware of them being unsatisfied with the current state. I expect that the Rust project will end up benefiting from the extra interest though, and improving on the things above.
    - fork-bomber 6y ago

stjohnswarts 6y ago

I'm not sure I agree with you on most of this, but I think more competition in the cpu biz is always a good thing.

leonidasv 6y ago

Apple chips are fast mostly because they have a lot of cache to spare. Take for example the A12Z. It has 8MB of L2 (not L3, it's L2!) cache. An Intel Core i7-1068NG7 present in the latest Macbook Pros (that performs akin to the A12Z according to Geekbench) has only 2MB of L2 cache. No other ARM CPU has this level of L2 cache. Apple chips are not "magical", Apple just can afford packing up lots and lots of cache because they are not in the silicon "race to the bottom" like Qualcomm and Intel are, for example. L2 cache is very expensive and Apple is just hacking its way up by packing as much L2 cache as they can. Don't take me wrong, it's not that Apple is "right" or "wrong" by doing it. They just can and did it. However, it's needless to say that their CPUs are not so different from other ARM ones, they just happen to have a budget and a business model that let's them ignore the price/performance ratio when designing chips in order to achieve the maximum performance.

kllrnohj 6y ago
> Take for example the A12Z. It has 8MB of L2 (not L3, it's L2!) It's not really that clear cut. You could also argue that the A12Z has 8MB of L3 and 0MB of L2. The L2 in the A12Z is shared while the L2 in the Intel CPU is not. Similarly the latency of the A12Z's L2 is a lot higher than the latency of Intel's L2, but also then still lower than Intel's L3. https://images.anandtech.com/doci/13661/A12X-lat.png https://images.anandtech.com/doci/13661/A12X-lat.png & https://images.anandtech.com/doci/14664/ICLlat.png https://images.anandtech.com/doci/14664/ICLlat.png So it's not "traditional" L2 as you're familiar with it, it's more like an L2.5 or something. Although still accurately called L2 as it is the second level of cache, it's just that Apple went with a rather different cache hierarchy & latency structure than Intel did. But it's really not at all accurate to compare the 8MB of L2 on the A12Z to the 2MB of L2 on Ice Lake. Those are very different caches.
- leonidasv 6y ago
  Latency increases as cache size increases. That's well a well known fact.
hn_check 6y ago
Why do you quote magical as if someone said that. Further, your point is that Apple chips are faster because of easily replicated reasons. Intel is charging hundreds of dollars for their chip -- you should charge them some consulting fees and tell them how easy this is to boost their performance! This isn't even considering that your whole analysis is flawed to begin with and you're comparing apples and oranges.

jlarocco 6y ago

> One interesting question I think is outstanding - from parsing the video carefully, it seems to me that devs are going to want ARM linux virtualized, vs AMD64. I’m not highly conversant with ARM linux, but in my mind I imagine it’s still largely a second class citizen — I wonder if systems developers will get on board, deal with slower / higher battery draw intel virtualization, or move on from Apple. Somewhat ironically, I think it's mostly the languages trying to be safer alternatives to C that are most behind on supporting ARM. I've done a little bit of Lisp development on my Raspberry Pi (with SBCL and Emacs/Slime), and in most cases I don't have to change anything moving between my AMD64/Linux desktop, Intel/OSX MBP, and ARM64/Linux Raspberry Pi. And that's even when using CFFI bindings to C libraries. I'm not sure SBCL's ARM backend is at the same level as the x86 backends, but it works well, and there's on going work on it.

jimnotgym 6y ago

> those complaints are 100% down to being saddled with Intel. And yet the new Macbook pro base models feature an 8th Gen Core i5. That is 2 generations behind the bleeding edge. I think some people might be experiencing the speed problems you described because their machine has an old gen processor in a shiny new box

pathartl 6y ago
Not to mention that Apple setting a standard of throttling at 100c and not giving the machines adequate cooling affects performance in a non-trivial fashion.

tolmasky 6y ago

I haven't felt particularly constrained from CPU in a long time. My main issues have been with RAM (thankfully the new MacBooks finally started supporting 32GB of RAM), and GPU, which ever since Apple has been in a fight with NVIDIA has been miserable. It's not just that Apple doesn't use NVIDIA, it's that they won't allow them to ship their own drivers for it. I just want to plug in an eGPU to an RTX 2080 card. Instead, you have this incredibly limited set of officially supported cards the are also hyper expensive. Black Magic stopped making their eGPU Pro, so even if money is no object you can't get a great laptop GPU extension that supports their XDR displays. Now, you might be saying, if you want a great GPU why are buying a laptop? Well, 1) even if I were to get the one model of Mac that allows me to do something interesting with GPUs (Mac Pro), I still can't install the NVIDIA cards I want. And 2) laptop + great eGPU is a great setup that is supported in the non-Mac space, so it is not a bizarre request. All of this to say: the ARM stuff is fine, but it won't really move the needle for me, and doesn't address any of my performance issues, and I would argue a lot of the performance issues a lot of people actually have (especially graphics artists).

Sleaker 6y ago

Wont this move result in more software compatibility issues from developer side though? Like why would you buy the update if the developers don't want to move to the new platform or determine it's too big of a change now?

larozin 6y ago

> One interesting question I think is outstanding - from parsing the video carefully, it seems to me that devs are going to want ARM linux virtualized, vs AMD64. Hahaha, look for a user-agent at 1:44:26 :) They use old Intel Mac for a virtualization demo.

rkhassen9 6y ago

Paid for by Apple?

pcwalton 6y ago

Rust isn't behind on ARM, except for SIMD intrinsics on stable, which are not things most languages (e.g. Java, Go) have at all for any architecture.

kovek 6y ago

I think MacBooks can run heavy ML processes, but why not run those on separate devices with specific hardware for that? I'm thinking any kind of job you'd want to run on the GPU.

celloductor 6y ago

it's easy to resign iphone models every year. it's not as easy to increase chip performance every year. there's a lot of R&D involved, i think in the long run it'll be better but Apple will have to devote more resources into it. you can't just wish for specs. the manufacturers actually get the hard job of trying to make it.

nooneknowswhy 6y ago

This is not enough for a Pro consumer. There are a wide range of development-related softwares/tools that are not compatible with ARM. And they do not usually come with huge user base. So there will not be any ARM port. They are free to try it on Macbook or Air. But MBPs? They are simply giving the market to Windows.

jrobn 6y ago

The main thing Apple has done to improve their A-series chips has been massive L2 caches. I still major advantages of putting a A-series chip into a MacBook Pro. 1) There will be a much larger thermal and power draw envelope available to new A-series chip. I suspect we will see insane “boosting” clock speeds. 2) Incredible “at idle” performance well beyond what X86 can provide with on did GPU cores, which means a bit better battery life for that screen. 3) More opportunity for tightly integrated acceleration chips On die for codec, ML, and other hardware acceleration methods for Apple only software libraries. 4) Easy porting between iOS and macOS, and tvOS. #3 will be the most significant.

imtringued 6y ago
I don't want to repeat myself so I'll just link to my previous comment. https://news.ycombinator.com/item?id=23612245 https://news.ycombinator.com/item?id=23612245

9fathom 6y ago

> One interesting question I think is outstanding - from parsing the video carefully, it seems to me that devs are going to want ARM linux virtualized, vs AMD64. I’m not highly conversant with ARM linux, but in my mind I imagine it’s still largely a second class citizen — I wonder if systems developers will get on board, deal with slower / higher battery draw intel virtualization, or move on from Apple. It's in fairly good shape, and has an active community. With the current proliferation of IoT devices, both the kernel and userland are well-maintained, and plenty of distros are available. The kernel also benefits from much of the work done for Android and Chromebooks as well. All of the usual FOSS software is ported and runs well. As of this moment, you could easily take your pick from any of Debian, Ubuntu, Fedora, Arch, Manjaro, Slack, or Alpine just for starters, plus a whole mess of specialty distros. Many of those offer both 32- and 64-bit ARM versions. Also bear in mind that recent ARM CPUs do support hardware-assisted virtualization as well. KVM and Xen are both available for ARM today, and I'd be shocked if Apple's Hypervisor.framework doesn't roll out with ARM support in the new macOS version as well. (I'm writing this from Firefox in Manjaro ARM on a PineBook Pro, that I use as my daily driver)

greggman3 6y ago

I'm excited. My #1 wish is a 16" MacBook Pro that ways 3 lbs or less. Take an iPad Pro, make it 16" instead of 12, add a keyboard, run MacOS. LG already makes 15.6" intel notebooks that weigh 3 lbs. Apple can do it too!

rock_artist 6y ago

> Apple has a functional corporate culture that ships; Well we've already seen things gets delayed and even canceled (AirPower). Cook's Apple is more about supply chain (where he excels), so if indeed the silicon design works, they would be able to 'ship'.

tdsamardzhiev 6y ago

Not a fan of Apple, but x86 is a mess and I'd love to see companies pushing for its replacement.

skohan 6y ago
What's the issue with x86? Genuinely asking
- imtringued 6y ago
  It's compatible with all the software I own. Using proton is already a hassle. Adding emulation will just make it worse.
  - tdsamardzhiev 6y ago
    Software compatibility will obviously be the main problem to resolve, but I'm an optimist.
- tdsamardzhiev 6y ago
  It has a lot of historical baggage, most notably implicit interdependencies that make it hard/impossible to optimize and reorder stuff. We're entering an era of many-core processors, and IMHO we'll absolutely have to move to a RISC architecture, and the sooner we get that box checked, the better.

geesejuggler 6y ago

> Languages like Go with supremely simple cross architecture support might get a boost here. Go's crypto libraries are heavily optimized on x86, not so on arm (see Phoronix Graviton2 benches). We will have to wait and see how much of Apple's halo effect will contribute positively to optimized arm code.

ksec 6y ago

I am predicting the opposite. Apple isn't about the extend its Mac for Performance or Battery sake. They are going about expanding its marketshare. There are close to 1 Billion iPhone users, most of them have never used a Mac. We will need a 2nd Devices for some of those task. And that will either be a iPad or Mac. Out of the 1.5B total PC Market, Apple has 100M Mac users. I will say it is not too far fetched to say Apple wants to double the number of Mac users to 200M. For every $100 dollar going to Intel, Apple could knock $200 off its Retail price while getting the same margin. A $799 MacBook ( the same starting price of iPad Pro ) will be disruptive, the premium is now small enough over the ~$500 PC Notebook price. In the longer term I think Apple is trying to reach 2 Billion Active Devices. And it certainly cant do this with iPhone alone. There are plenty of Market Space for the Mac to disrupt.

thewileyone 6y ago
> For every $100 dollar going to Intel, Apple could knock $200 off its Retail price while getting the same margin. They're not going to change their retail price. It'll be the same, but "better"/"different" ... that's how they'll market it.
- dannyw 6y ago
  I suspect it'll allow them to put OLEDs on the Macs. That would be a GIGANTIC unique differentiator for the Macs. Once you see it, you won't be able to tolerate a non-OLED display. ever again. I'm just thinking about my development environment background, Terminal, etc in pure black and off... Wow.

thewileyone 6y ago

> Apple has a functional corporate culture that ships; adding complete control of the hardware stack in is going to make for better products, full stop. One word, Catalina.

mlindner 6y ago

> Rust seems behind on ARM, for instance; I bet that will change in the next year or two. I don’t imagine that developing Intel server binaries on an ARM laptop with Rust will be pleasant. Umm what? Rust supports ARM as a first class citizen as does LLVM. They only list ARM as second class because it's not a desktop platform generally. https://forge.rust-lang.org/release/platform-support.html https://forge.rust-lang.org/release/platform-support.html

willtim 6y ago

You've missed off possibly the biggest advantage of ditching Intel. A perfectly usable machine without jet engine fans and a scolded lap. I don't use Mac's, but I see this as good for the industry.

secondcoming 6y ago

I'm not sure virtualising ARM on Intel platforms will ever be performant enough to be usable. They will probably have to ship an emulator, and even then there will be issues as it'll be very difficult to emulate the strictness of ARM CPUs on non-ARM architectures, for things like unaligned memory accesses and replicating the memory model.

deleted 6y ago

[deleted]