21 ms·

ARM Mac: Why I'm Worried About Virtualization

156 points by bmalehorn 6y ago

deleted 6y ago
[deleted]
lachlan-sneff 6y ago
This is ridiculous. Your code will just have to support multiple architectures, which is very easy with modern languages and tooling.
- maxmcd 6y ago
  Yeah, ARM is coming and docker will move to support it. We already have this: https://docs.docker.com/buildx/working-with-buildx/ https://docs.docker.com/buildx/working-with-buildx/ Things like the pinebook pro (and hopefully more linux ARM devices) will keep pushing this further.
  - henryfjordan 6y ago
    Docker came to the ARM-based raspberry pi in 2016: https://www.raspberrypi.org/blog/docker-comes-to-raspberry-pi/ https://www.raspberrypi.org/blog/docker-comes-to-raspberry-p...
  - buildbot 6y ago
    I know of several in production embedded devices running docker, and have worked on a few...It's already here and works great.
- Spivak 6y ago
  I mean the post is technically right. You're probably better of skipping the first generation of ARM Macs until software support happens unless you're someone who wants to work on that software support.
- jnwatson 6y ago
  Hardly. You’re investing a great deal of effort in building a parallel set of images that probably will never see production. The one use case when this might be viable is targeting AWS Graviton2. Does anybody know if you can run an emulated Graviton2 on ARM Mac?
  - my123 6y ago
    Parallels on Arm macOS simulates the Snapdragon 835 SoC to emulated operating systems.
- bobalob_wtf 6y ago
  I think you missed the point. What about all the dependencies of your code that are only compiled for x86_64? The article isn't talking about native apps on the laptop, it's about apps that run on a server but that you are developing locally. You can't run your x86 docker image on your ARM mac without emulation. You can't run your x86 Windows VM without emulation etc. Of course there are solutions like using a remote server or a VM in the cloud, but if you're buying a decent machine then you would normally expect to be able to run these things locally.
  - acdha 6y ago
    Do you have any examples of this? The last time I tried an AWS ARM server, it was literally no modification other than changing the server type — Linux has run on ARM for many years and Apple is far from the first company to use the platform. For example, back in 2017 Cloudflare was basically looking at this as a question of which hardware ran most cost-effectively rather than having engineering heroics first: https://blog.cloudflare.com/arm-takes-wing/ https://blog.cloudflare.com/arm-takes-wing/
    - user5994461 6y ago
      I want to say Oracle database clients as an example. My company definitely had problems to get database drivers to work generally speaking and on both 32 bits and 64 bits. Have a look at postgres, oracle, cassandra, redis, sybase to name a few, I am not sure which one was worse, it wasn't me doing the work. But I've seen some of the C and C++ dependencies that needed to compile with the errors that happened and that was horrendous.
      - jbverschoor 6y ago
        That’s a good moment to make your c/c++ code more robust, and cross-platform, like the languages they are
        user5994461 6y ago
        The problem wasn't in our code, it was in the database code that was either from open source or from a vendor. If you want a sample. Try to install the cassandra client library in python. It will pull in and compile all sort of shit. That's supposed to be python and easily cross platform.
- heavyset_go 6y ago
  There are very few packages compiled for ARM on PyPI, and there are more than a few packages on PyPI that are a pain to build from source.
m000 6y ago
Apple will singlehandedly make 2021 "the year of Linux on the desktop".
- the-golden-one 6y ago
  I thought that was WSL2 on Windows 10?
- pantalaimon 6y ago
  When was the year of the macOS desktop?
  - julienfr112 6y ago
    2012 ?
  - inetknght 6y ago
    1996
  - m000 6y ago
    It's not about stealing users from macOS. It's about stealing developers. Hell, Apple is at the mercy of Microsoft and Adobe right now. I'd bet they had to line their pockets very well, so that they don't get any funny ideas. But Apple can't just pay-up every cross-platform software developer. Smaller developers will have to re-evaluate whether macOS remains a viable target platform for them. Which can translate to a dev-gain for Linux. The catch is that Linux is in much better position to translate an influx of developers to an influx of new users: Linux runs on what you have, while macOS requires you buy Apple hardware. And let's not forget about macOS as a gaming platform. Linux has made a huge leap forward with Steam Proton. On macOS there's still a ton of games not supporting x86_64 (Catalina), and situation won't get better by transition to ARM.
    - dnh44 6y ago
      That may be true but it’s not accounting for the iPhone and iPad developers out there that will be able to easily target macOS after the switch.
grahamlee 6y ago
It didn’t take months, the time I did it (running Docker on a Pinebook, which was not a great experience). It took a couple of hours to flip some base images away from Alpine, as Debian already has a load of ARM packages built.
- thomaslord 6y ago
  This assumes that your Docker workload can run on an ARM system without lots of hacking, and also that you trust the ARM-compiled version you're running locally to function identically to the x86-compiled version running on your server.
  - marmaduke 6y ago
    It's not the worst assumption on HN by far
  - grahamlee 6y ago
    No, it doesn't. If I'd made the statement "all you need to do is…" then it would have involved some assumptions. What I said was "I did this and all it took was…" no assumptions, just experience.
  - thrill 6y ago
    If only people writing applications could find some way of testing that their apps function properly.
- 8K832d7tNmiQ 6y ago
  That’s under a case where all libraries you need supports aarch64 architecture, which is sort of true for popular libraries, but not all libraries.
- yjftsjthsd-h 6y ago
  > It took a couple of hours to flip some base images away from Alpine, as Debian already has a load of ARM packages built. Why did you have to switch from Alpine to Debian? Alpine supports ARM quite happily, and it looks like they're shipping Docker images for ARM (and other architectures, too).
user5994461 6y ago
Didn't think of that. If running Docker is 10 times slower on ARM and virtual box doesn't support the architecture at all, this might indeed end developers using Mac.
- rbanffy 6y ago
  Running Docker on an emulated x86 will be slow, but I doubt it'd be 10x slower. There are snapdragon laptops running Windows. How much slower is running Docker on them?
- armagon 6y ago
  I've been developing on a Mac for years, and I've never needed to use Docker or virtualisation to do it. (I've been doing game development, and now web front end development. I'm sure the major game engines and browsers will be ported to run on ARM chips (although it may take a while)). Honest question: What sort of development regularly requires using docker or virtualized OSes?
  - neurostimulant 6y ago
    Almost every server applications (databases, webservers, webapps) are available as docker images. It's very easy to deploy those apps using docker, which is why it's taking over sysadmin world by storm. Previously, handling a big web application deployment is a complex task that requires a dedicated team. Now, you can just package your app as a docker image, and other people that know docker will know how to deploy your app without having to know its internal dependency graph first.
    - anthk 6y ago
      If you use Docker as a production tool instead of prototyping several shit will happen soon.
      - yjftsjthsd-h 6y ago
        It's not quite as simple as GP implies, but why not? I work at a place running Docker in prod, and our only issues are with the swarm networking, not Docker itself.
jjoonathan 6y ago
If you stay back on x86 virtualization will be slow, but if you jump to ARM this is great! > However, this would take months (infomercial arms) I'm sure it won't make sense for everyone, but I'm just as sure it will make sense for many.
marricks 6y ago
It will be extremely interesting to see what the dev's say with the test boxes. Curious if there's any magical fixes like switching over to ARM Linux, since the software of an image would likely be compiled for x86 I really doubt it... Perhaps this will spur some people over to running ARM servers in the cloud...
- rbanffy 6y ago
  It's unlikely the test boxes are going to people who deploy to x86 backends. They are targeted towards iOS and macOS developers. We can have the experience of developing on ARM to deploy on x86 right now with ARM workstations. A 16 core barebones costs around $700
- lukevp 6y ago
  Has anyone received an invite into the program yet? I applied on day one, but don’t have a Mac Store app currently published, so I’m not sure if I will get accepted.
  - Vomzor 6y ago
    I don’t have a published Mac app either and I got accepted.
core-questions 6y ago
> Why can't you update the Docker image to also support ARM? You theoretically could switch your backend to run ARM Linux. However, this would take months - renting out ARM instances, re-building all repositories, and a tense switch over. I don't see why this would be so hard. If anything, I expect to see a massive upswing in things like AWS Graviton2 uptake, and a lot of common Docker images being built with ARM versions out of the box. It might be about a year or so, but eventually we'll be able to just go ARM-native the whole way. What Apple needs to do is make a first-class, WSL-tier implementation of Docker for Mac for ARM.
- rbanffy 6y ago
  The Honeycomb.io folks reported 40% more capacity per dollar on Graviton 2 over x86. That alone should motivate people to start looking into ARM backends.
- Spivak 6y ago
  I'm kinda thankful to Apple for biting the bullet on this one. For whatever reason people will move mountains for Apple where other companies' products would just languish and die. The second order effects of ARM being something that's "safe" for people to use should be great!
  - deleted 6y ago
    [deleted]
- jjoonathan 6y ago
  Didn't they show off a native arm docker image running in the keynote?
  - rbanffy 6y ago
    I think it was running in Parallels
- user5994461 6y ago
  >>> expect ... a lot of common Docker images being built with ARM versions out of the box. This has no chance of happening. The common cloud CI systems do not support ARM at all (travis, circle CI and co). There is only a minority of developers with macbook and the rest is not going to spend $2000 to buy one just to build some docker images.
dlivingston 6y ago
Do we know that Boot Camp isn’t supported by Big Sur? Or is it just that one can’t run an x86 OS on an ARM architecture? In other words - will I still be able to dual-boot into something like ARM-flavored Linux?
- leecb 6y ago
  one can’t run an x86 OS on an ARM architecture This is the limitation. There is an ARM version of Windows, but the comments from Microsoft don't sound terribly promising: “Microsoft only licenses Windows 10 on ARM to OEMs. We have nothing further to share at this time.” [1] And Apple has more firmly stated that this won't be an option: “We’re not direct booting an alternate operating system,” says Craig Federighi, Apple’s senior vice president of software engineering. “Purely virtualization is the route. These hypervisors can be very efficient, so the need to direct boot shouldn’t really be the concern.” [1] 1: https://www.theverge.com/2020/6/24/21302213/apple-silicon-mac-arm-windows-support-boot-camp?utm_campaign=theverge&utm_content=chorus&utm_medium=social&utm_source=twitter https://www.theverge.com/2020/6/24/21302213/apple-silicon-ma...
  - gumby 6y ago
    And the iPhone didn’t permit native third part apps when launched. Not because they weren’t ready to announce it yet but because at launch time they figured web apps would be enough. I have no idea what plans they might have but I would be surprised if you couldn’t install some ARM Linux distros on their laptops sometime next year.
- yborg 6y ago
  Boot Camp support will remain for Intel machines. Current understanding is that ARM machines will have no Boot Camp capability at all.
- deleted 6y ago
  [deleted]
jeremyjh 6y ago
My 2017 Macbook pro still has quite a lot of life in it, but it seems unlikely I will replace it with another Mac in a few years. Before the Mac I had a Lenovo X1 Carbon running Linux and it was great; and even then was a better development environment in some ways (docker has better filesystem performance, pacman is much better than homebrew). I do use some audio processing applications and my kids play a few games that do not run at all on Linux. I may try WSL again instead of going straight back to Linux, but its hard to imagine Mac will be the best OS for me.
- drewrv 6y ago
  I recently had to get a new laptop and went with windows for the first time in a decade. Macs are still great to develop on for now, but looking at the trajectory apple has taken, the growing pains ARM will likely bring, and also the trajectory of Windows, it seemed like Windows would be the safer choice over the next few years.
fluxem 6y ago
But linux can be run on arm natively. Moreover, most packages are also compiled for arm. So apt-get install will work just the same. I'm sure they will be able to target Apple's specific arm chips when they come out.
- donarb 6y ago
  Apple released a list of open source projects that they have ported to ARM, they intend to upload patches to each of these projects: - Bgfx - Blender - Boost - Skia - Zlib-Ng - Chromium - cmake - Electron - FFmpeg - Halide - Swift Shader - Homebrew - MacPorts - Mono - nginx - map - Node - OpenCV - OpenEXR - OpenJDK - SSE2Neon - Pixar USD - Qt - Python 3 - Redis - Cineform CFHD - NumPy - Go - V8
  - tonyedgecombe 6y ago
    It’s interesting that Electron is on that list.
    - asadlionpk 6y ago
      Crucial piece of tech for many products like VSCode, Slack, Discord, etc.
      - pjmlp 6y ago
        Given how much Microsoft's React Native team bashes Electron with their performance bar charts (300x more bloat than RN), I look forward that, as soon as it is mature across Linux, macOS and Windows, they replace Electron with RN on VSCode.
    - yjftsjthsd-h 6y ago
      Makes sense; port Electron and you get a bunch of apps for free.
    - imtringued 6y ago
      It's also interesting that this won't fix old Electron applications. The idea of easy cross platform development via Electron is a myth because most developers won't support your platform even if all support requires is checking a box. When you consider that this is the primary justification for using Electron over other stacks it just makes your blood boil. All the downsides with none of the benefits.
ris 6y ago
If you hadn't sold yourself out of the free market, you would be able to choose what architecture machine you bought.
- Spivak 6y ago
  A free market wouldn't have saved you because the market has every incentive to gravitate to a single architecture because vendors and customers want the best software compatibility. The more popular an architecture (or really any platform) gets the more software that's written for it until it starves out competitors because they can't run the software their customers want.
julienfr112 6y ago
Mac book was never really a dev platform. Maybe for front or nodejs, or definitly for native apple apps, but seriously, brew and so are so subpar.
- rbanffy 6y ago
  I use Macports and I'm quite happy.
- setpatchaddress 6y ago
  Genuinely curious what you feel is subpar about brew. It seems to work pretty well.
- chrisseaton 6y ago
  I develop low-level code like compilers just fine on a MacBook.
  - fortran77 6y ago
    What's "low level" about a compiler?
    - chrisseaton 6y ago
      > Mac book was never really a dev platform. Maybe for front or nodejs, or definitly for native apple apps, but seriously, brew and so are so subpar. I'm not sure what you're asking? It's lower level than the examples which were given. There's nothing stopping you using a MacBook for almost any development task. It's not just for front-end tasks. You can do work that runs directly on the architecture.
- dhosek 6y ago
  I've been doing dev work on Macs since 2002. Perl, PHP, Java, C++. It's been a great environment. I don't expect most of my workflow to be impacted by the ARM transition, but given I've refreshed my Mac Mini and laptop both in the last 18 months, I don't expect to be changing architectures any time soon either.
pwinnski 6y ago
If the worst of every possible thing happens and you avoid the most obvious solutions and one is very, very slow, then yes, you're right to worry. Or, you could use already-extant Debian ARM releases and spend minutes rather than months switching over.
justaguy88 6y ago
I wonder if Apple will still allow a dual boot with a native (arm64 in this case) Linux
- gardaani 6y ago
  There's no official support for ARM-based Macs: https://news.ycombinator.com/item?id=23640746 https://news.ycombinator.com/item?id=23640746
- vetinari 6y ago
  Short answer: no. Slightly longer (but not much) answer: https://www.youtube.com/watch?v=Hg9F1Qjv3iU&feature=youtu.be&t=3772 https://www.youtube.com/watch?v=Hg9F1Qjv3iU&feature=youtu.be...
- yadco 6y ago
  Well given the roadblocks they put for their recent x86-64 MacBooks running Linux, it's very unlikely.
timsally 6y ago
It is very likely that ARM-based Macs will lack a performant hypervisor upon release. We will have to see how VMWare responds. I'd bet it will inspire new products and innovation and the desktop space will move towards a less x86-x64 centric world. In the end it is a short term problem. Someone will respond and provide a performant hypervisor that can run on an ARM host and virtualize x86-x64 and ARM guests. It's true it will cause some pain in the first year or two, but even as a heavy VMWare Fusion user I am really looking forward to the benefits of a vertically integrated laptop.
- WrtCdEvrydy 6y ago
  VMWare did have a hypervisor for Raspberry Pi.
  - my123 6y ago
    Yes, VMWare ESXi runs on Arm just fine. :-)
    - jki275 6y ago
      Can you run an x86 guest under it?
      - lode 6y ago
        No. Virtualization (dividing a host into different logical hosts but executing unmodified CPU instructions, like VMware, VirtualBox, ...) and emulation (translating instructions, like Rosetta) are two different beasts.
        jki275 6y ago
        That's pretty much what I assumed from what I know of VMWare. It's going to be a big issue for future Macs, there are entire segments of developers who may have to abandon Macs if we can't run VMs of x86 operating systems.
- 6y ago
saxonww 6y ago
Develop on the platform you want to deploy to.
- deleted 6y ago
  [deleted]
- yjftsjthsd-h 6y ago
  I am not running Darwin in prod. EDIT: I suppose I should clarify; I don't totally disagree. I personally run Ubuntu on my laptop and servers. But plenty of people are quite happy developing on Darwin and deploying to some sort of GNU/Linux.
- jki275 6y ago
  Develop on an ESP32? You're a masochist, but I like it.
gtrubetskoy 6y ago
I remember the days when having to switch between x86, ppc, sparc, etc was a thing (not to mention the many flavors of UN*X) and we survived. In fact I think it was more fun back before the x86/Linux server domination. Architecture diversity is good.
quux 6y ago
I'm not a heavy docker user but why can't I develop docker containers on Arm (as native containers, no emulation) and deploy to x86_64? Or vice versa? I understand that some packages are binary only and wouldn't be necessarily available for Arm, especially initially, but the majority should be.
- icedchai 6y ago
  You can. Because of the Raspberry Pi and other ARM SBCs, the most popular base images already run on ARM. The ones that are missing will catch up pretty fast.
- Teknoman117 6y ago
  It's not that you can't, you just have to be mindful. Because docker containers contain compiled applications, you have to be aware of what CPU architecture they're compiled for. ARM can't natively run x86 binaries, x86 can't natively run ARM binaries. If you want to develop containers for x86 systems on an ARM system, you'll have to cross compile your containers, which I'm not sure if docker actually supports outside of emulation. If you are only a consumer of containers, most of the popular ones have been compiled for multiple architectures.
lowbloodsugar 6y ago
If I were to describe my job, or programming in general, it might be "problems that have no obvious solution". This is a sad article that just seems to be the opposite in spirit to "Hacker" ethos.
snapetom 6y ago
A lot of developer-centric focus discussion on how Docker would work (hint: it does), but VirtualBox is still pretty common in the sysadmin world and other industry circles. Moreover, there seems to be no way it will ever work. It will be interesting to see how that turns out.
- bmalehorn 6y ago
  Author here. That's a major point of the article - "are we screwed?" I'm not an expert on virtualization but I wanted to see some discussion on this topic, because it feels like we might be screwed and nobody is talking about. Anyway I was happy to see Docker worked, at least on a basic level.
  - snapetom 6y ago
    Cool. Thanks for writing it. It summarizes and collects a lot of issues we were all grumbling about here and there. The main hurdles for Docker are organization, not technical. However, the other issues you bring up are going to be more technical (same as you, though, not a hypervisor expert and/or we're going to be at the mercy of big vendors like Apple, Oracle, and Microsoft. Those are much harder problems to overcome.
nojito 6y ago
Apple has their own virtualization offering to share and they are being quite coy about
rgovostes 6y ago
I'm more convinced dropping dual boot and supporting virtualization is the right move. Only the host OS is going to have the right drivers for the trackpad, wi-fi, GPU, power management, etc. etc. Through virtualization, the guest OS doesn't have to worry about constantly evolving hardware models. Virtualized OS performance is already very good, and USB passthrough has existed for a while. Snapshots are a godsend. What won't work are things like CUDA for eGPUs over Thunderbolt 3, and you'll have to share disk and RAM with the host OS. But for most use cases it's probably the right choice. (This doesn't address the author's concern about moving away from x86.)
jbverschoor 6y ago
We have qemu on arm. It’s fast enough to software render half-life. Servers will follow desktop, so in a few years a lot of things are arm
smspf 6y ago
So many wrong assumptions ... 1. If emulating aarch64 (arm64) on x86_64 is 6x slower (on your system, btw, it's not an universal constant), it doesn't mean emulating x86_64 on aarch64 will be 6x slower. It'd probably be worse, or at least that's my gut feeling. 2. Generic container images like the Ubuntu mentioned usually have aarch64 (arm64) support, so running the x86_64 image makes no sense for the presented use-case. 3. You won't be able to use most software because they don't release ARM binaries ... and the example uses `wget` && `tar xf`, with no binary signature check. As someone who has been porting stuff from x86_64 to aarch64 for a couple of years, I admit I've seen this pattern frequently. The most obvious solution is to build from sources, which would have been better off on x86_64 too, instead of fetching a prebuilt (and unverified) binary from the internet. Maybe there are some CPU flags the compiler could notice and apply optimizations which are not included in the prebuilt binary. I'm not an Apple fan and I'm certainly not a fan of cross-architecture development either. I do agree with the general idea behind the article, however I find it a bit hand wavy.
- zekrioca 6y ago
  Yes, agreed. And the examples exposed are not fair. There are a lot of optimizations one can do in Docker, specially when dealing with I/O workloads (dd example in the article). Cloud providers have been doing this for long, long time already.. Why the author did not mention those, it is to be seen..
- thayne 6y ago
  > Generic container images like the Ubuntu mentioned usually have aarch64 (arm64) support, so running the x86_64 image makes no sense for the presented use-case. I think the argument here is you can't build your own docker images that you use in production and run them on your mac without emulation (unless your production workload also runs on ARM).
  - smspf 6y ago
    That's a fair point. Emulation implies other limitations too - code compiled on your machine might leverage only the CPU features emulated, which would lead to sub-optimal binaries, not to mention much slower builds.
zekrioca 6y ago
I guess someone will port Docker to JVM, and use the JVM optimized to whatever ARM processor there will be.
- neilalexander 6y ago
  Docker is written in Go which already has first-class cross-compilation support, so getting the Docker tools running on ARM is practically a non-issue.
  - zekrioca 6y ago
    Yeah, I thought about the conceptual idea, similar to what MS did: https://threatvector.cylance.com/en_us/home/teardown-windows-10-on-arm-x86-emulation.html https://threatvector.cylance.com/en_us/home/teardown-windows...
bazizbaziz 6y ago
This seems like a weird benchmark, reading from /dev/urandom and gzipping random data does not seem like something most folks will want to do. It even appears like /dev/urandom speeds differ greatly on various architectures [0] and there are issues with /dev/random being fundamentally slow due to the entropy pool [1] (but I guess this is why the author uses /dev/urandom). It would be better to measure something more related to what docker users will actually do, like container build time of a common container, and/or latency of HTTP requests to native/emulated containers running on the some container. One reason to feel positive about the virtualization issues is that Rosetta 2 provides x86->ARM translation for JITs which an ARM-based QEMU could perhaps integrate into it's own binary translation [2]. [0] https://ianix.com/pub/comparing-dev-random-speed-linux-bsd.html https://ianix.com/pub/comparing-dev-random-speed-linux-bsd.h... [1] https://superuser.com/questions/359599/why-is-my-dev-random-so-slow-when-using-dd https://superuser.com/questions/359599/why-is-my-dev-random-... [2] https://developer.apple.com/videos/play/wwdc2020/10686/ https://developer.apple.com/videos/play/wwdc2020/10686/
- bmalehorn 6y ago
  Author here. I'm glad somebody said something! Yes the gzip perf test is pretty silly, but illustrates a significant difference. /dev/urandom throughput on this setup was about 100 MB / s so it wasn't a bottleneck for this test - the bottlneck was gzip. Feel free to come up with a performance test yourself! I personally want to know what an HTTP test would look like. You can run an ARM image by running: docker run -it arm64v8/ubuntu Unfortunately, Rosetta 2 is not going to help here. Rosetta 2 translates x86 -> ARM, but only on Mac binaries. It does not translate Linux binaries, and cannot reach inside a Docker image.
  - yjftsjthsd-h 6y ago
    So I'm not familiar with how Darwin does things, but on most FOSS unixes it's easy to use qemu to run one arch on another, either full system or just user mode emulation (which when wired up correctly lets you seamlessly execute ex. ARM binaries on an x86 system). I would expect it to be easy enough to either set up user mode translation, or just swap Docker's backing hypervisor with an x86 VM. Or, worst case, just run qemu-system-x86_64 on your ARM Mac, run Linux inside that VM, and run Docker on that Linux; SSH in and it should be mostly transparent.
seanparsons 6y ago
Any company with a load of binaries built without any effort towards supporting cross platform builds that uses Docker is gonna have a bad day with this. They buy a bunch of new MacBooks and then find they can't use them until they spend a few weeks porting everything.
- neilalexander 6y ago
  I suppose that depends what they’re written in. Some languages (e.g. Go) far simpler than others.
Skunkleton 6y ago
> Docker on a Mac utilizes a hypervisor. Hypervisors rely on running the same architecture on the host as the guest, and are about about 1x - 2x as slow as running natively. That doesnt sound right to me. Perhaps on IO bound tasks, if you are using emulated devices. On CPU bound tasks you should see near native performance.
old-gregg 6y ago
When I ask Mac-loving developers, why they chose to run MacOS when developing non-MacOS software, they used to give me good reasons. I think their reasoning is no longer valid. The hardware has gotten worse (keyboard, touchbar), the OS has gotten more hostile, meanwhile the state of Linux on Laptop has gotten a lot better. So... I used to understand them, but I no longer do. https://i.kym-cdn.com/photos/images/newsfeed/001/016/674/802.jpg https://i.kym-cdn.com/photos/images/newsfeed/001/016/674/802...
ed25519FUUU 6y ago
I use docker every day and I guess I’m just not worried about this. The container pushes come from a CI host, so I’m not worried about compatibility. And it’s 20% slower? Well, most of the build time is slow for all sorts of reasons. I honestly don’t think I’ll even notice.
phamilton 6y ago
> ec2 only offers 6 general-purpose ARM instance sizes m6g, c6g, r6g each support 6 sizes for a total of 24
- _msw_ 6y ago
  Disclosure: I work at AWS building cloud infrastructure C6g, M6g, and R6g (powered by AWS Graviton2) each support 8 sizes, along with bare metal. A1 instances (powered by AWS Graviton) have 5 sizes, along with bare metal. That's a total of 33 distinct instance sizes.
  - bmalehorn 6y ago
    Thanks, I didn't know about c6g, m6g, r6g. I've updated the post to remove this mention - I only counted a1 instances. That still leaves storage optimized and GPU optimized instances missing. I'm guessing storage should be easy enough to add, but what about GPU? From my novice experience with GPUs, they need finicky drivers that must be ported by the GPU manufacturers, so I figure it might take a while to get competitive ARM GPU instances.
    - _msw_ 6y ago
      Configurations of these instances with NVMe local storage are coming. NVIDIA is supporting Arm for CUDA development, see https://nvidianews.nvidia.com/news/nvidia-brings-cuda-to-arm-enabling-new-path-to-exascale-supercomputing https://nvidianews.nvidia.com/news/nvidia-brings-cuda-to-arm... and https://blogs.nvidia.com/blog/2019/11/18/ngc-containers-arm/ https://blogs.nvidia.com/blog/2019/11/18/ngc-containers-arm/
- xsmasher 6y ago
  This seemed like the weakest argument in the article; as arm becomes more popular it will get more support.
bitwize 6y ago
Once again -- Apple will do what the entire industry without Apple couldn't do. In this case, force a migration to ARM-based servers, so that prod is running on the same architecture as the developer's machine. Apple is finally killing x86.
- tjoff 6y ago
  Hooray, we have successfully fixed the mistake with an open platform and will now be relegated to incompatible hardware without any competition. At last, the future will surely be bright!
  - duskwuff 6y ago
    How was x86 any more "open" of a platform? If anything, x86 is a far more "closed" platform, as there are only two remaining manufacturers of x86 parts, and there is no licensing process to join them. Meanwhile, there are hundreds of ARM licensees, and the process for becoming a licensee is all documented online [1]. [1]: https://www.arm.com/why-arm/how-licensing-works https://www.arm.com/why-arm/how-licensing-works
    - tjoff 6y ago
      How? It is absolutely inconceivable how much more open it is. Also, the CPU is but a minor part of the puzzle. But still that is still twice as many as apple (good luck exchanging that apple-arm with any other brand). Please let me know how open you think the next apple ARM platform is when you try to boot any OS not written by apple. Please compare that with a computer built from AMD/Intel with a motherboard out of dozens of manufacturers etc. Any ATX power supply etc. Pretty much any PCI-E graphics card etc.
      - duskwuff 6y ago
        You are confusing the x86 CPU architecture (which is closed) with the PC platform (which is relatively open). > Also, the CPU is but a minor part of the puzzle. But still that is still twice as many as apple (good luck exchanging that apple-arm with any other brand). Even on x86, interchangeable CPUs are the exception, not the rule. Intel and AMD CPUs haven't even used the same socket since the 1990s, and even within those manufacturers, socket incompatibilities are common. Software interchangeability is more of an operating systems issue than an architectural one. With appropriate software shims, though, there is no reason to suspect that (for example) Linux ARM software could be run on an Apple ARM CPU. In fact, it's quite likely that tools like the Android emulator will do exactly that. > Please compare that with a computer built from AMD/Intel with a motherboard out of dozens of manufacturers etc. Any ATX power supply etc. Pretty much any PCI-E graphics card etc. Server-class ARM hardware generally does use similar parts as x86 servers, including power supplies and PCIe peripherals.
adrianpike 6y ago
I'm actually not worried, for a few reasons; - I already do cross-arch development day-in and day out between x86 and ARM, and have only run into hard blockers on a library or tool a handful of times. The solve was generally pretty straightforward to either use an ARM-compatible alternative, or to cross-compile it myself. - We've done this many many times before and it's not that bad. I know I'm not the only one old enough here to remember the days of having heterogeneous fleets across PPC, SPARC, and x86. Or even more recent - different extensions for x86 with different chipset manufacturers.
- kevin_thibedeau 6y ago
  Tons of x86 code accesses misaligned addresses.
  - saagarjha 6y ago
    Well, that's only because it's efficient to do so on x86. Code recompiled for ARM isn't going to do that.
    - DaiPlusPlus 6y ago
      It’s not that simple if that code is using explicit struct layouts or x86/x64 intrinsics. Forgive my ignorance though - but what ISA extensions are in Apple’s ARM chips for SIMD? Intel poured a lot of effort into SSE+AXE - Does Apple have a compete there?
      - saagarjha 6y ago
        > It’s not that simple if that code is using explicit struct layouts or x86/x64 intrinsics. Performance sensitive code that relies on alignment guarantees and other platform details will not work and need to be updated, yes. IIRC Apple's chips do NEON for SIMD, not sure if they support SVE yet. (But I figure they will have to once it becomes a required part of the ARM standard…)
        6y ago
Uehreka 6y ago
For my most recent project[1], I wanted to see if Amazon’s Graviton instances would be a good choice for my docker deployments (I was deploying MongoDB, an Express server, and several instances of the Janus WebRTC server). I was developing in Pop OS on an x86_64 desktop (since we’re gonna have to start specifying now) and found the toolchain around building ARM64 images to be pretty simple once I got it set up. I benchmarked some `t2a.nano`s against some `a1.medium`s and found that the `nano`s were sufficient for my needs, so I went with them (they are cheaper than `a1.medium`s, even if the `a1`s have a better price-to-performance ratio). I didn’t find it too difficult to rebuild any of these projects for cross-architecture usage. Even Janus, which has a TON of C/C++ dependencies (some of which have to be compiled from a particular version of the source) easily built for ARM with no change in the Dockerfile. So I kind of feel like OP is exaggerating the effort required to migrate servers to ARM. Sure it might be a hassle when you have tons of microservices, but you can move them incrementally, and most things recompile with no changes. And regardless of what architecture your dev machine is, you’ll want to be able to compile for and work with both architectures if you want to get the most out of the infrastructure on offer in 2020. [1] Shameless plug: https://chrisuehlinger.com/blog/2020/06/16/unshattering-the-audience-building-theatre-on-the-web-in-2020/ https://chrisuehlinger.com/blog/2020/06/16/unshattering-the-...
- bmalehorn 6y ago
  Cool, thanks for sharing. It's these kind of experiences that I was hoping to gather from making this post. Did you notice at the end that you did NOT end up choosing ARM? You ended up going with x86_64 because that's what made more sense for your backend. That's part of my point - developers should choose their backend architecture based on the performance and pricing of their backend, not their development laptop. And if that decision is "we should keep using x86", then there will be a big performance hit in development.
  - pjmlp 6y ago
    Back in the UNIX glory days, I was responsible for keeping a software stack running across Windows NT (later 2000), Aix, HP-UX, Solaris, each with its own CPU architecture. This is just another CPU story, no big deal.
monadic2 6y ago
Tl;dr they want to run x86 linux for their own reasons rather than arm.
gigatexal 6y ago
It’s still early days. bhyve which is likely what they’re using or whatever the hypervisor is will just run arm docker images — unless you have a hard x86 dependency many of our http micro services should run just fine on arm images at least my workflow will be just fine.
- gigatexal 6y ago
  Furthermore this is speculation. We don’t have ARM Macs yet to test. This is like all the nerds in the forums speculating on hardware leaks how the next gen GPUs will perform: wait for hardware and reviews. Making any sort of claim as to what to buy or not at this point seems disingenuous.
eberkund 6y ago
Are there any excited embedded developers in the crowd? I have done a little embedded work and cross compiling has always been a huge pain in the ass to setup. I know some people have even gone as far as purchasing expensive niche workstations with ARM CPUs specifically to avoid this problem. I feel like having a mainstream ARM platform like the MBP will make compiling software for ARM-based single board computers a breeze.
- detaro 6y ago
  I'd much rather have a more powerful x86 workstation for the same money than an ARM laptop. Never really had problems with cross-compile. And without support for running Linux natively, it doesn't get me much for even for the parts of testing that don't need the specific target (well, VMs maybe).
  - TheNorthman 6y ago
    To be clear, we don't know if the ARM MacBook will be able to run Linux natively. We only know that Apple won't continue support for Boot Camp and therefor Windows anymore. Linux was never supported.
    - sigjuice 6y ago
      There won't be native Linux. https://news.ycombinator.com/item?id=23640746 https://news.ycombinator.com/item?id=23640746 (Craig Federighi confirms Apple Silicon Macs will not support booting other OS) EDIT: fixed link
      - TheNorthman 6y ago
        I don't understand your point. Native Linux isn't restricted to x86_64. EDIT: Your new link doesn't tell a different story. From the comments: > It is still possible to disable secure boot using csrutil. Apple has never officially supported booting Linux on a Mac. > https://twitter.com/never_released/status/1275850872153690114 https://twitter.com/never_released/status/127585087215369011...
outworlder 6y ago
On the flip side, I guess ARM Macs will now allow the use of hypervisors for Android simulators, instead of a full hardware virtualization. ... thus making Android development better on Macs?
- jeroenhd 6y ago
  Android emulators on desktop generally run amd64 images of Android using existing virtualisation hardware and software. At best, you can say that you can run ARM-only games at native speed now, but as a developer you won't really notice much different (assuming the processors aren't slower than Intel's)
- jayd16 6y ago
  Android already had x86 builds and that was the preferred way to run the emulator so its mostly likely a neutral change (once they get hardware virtualization for arm working). The GPU aspect of things might improve maybe?
- deleted 6y ago
  [deleted]
- lfy_google 6y ago
  Android Emulator developer here. In addition to what the other comments said about android emulation with hypervisors existing already for x86, we're also looking into the Hypervisor.framework API for Apple silicon. It won't be a trivial task (hoping for pre-existing code to port over maybe?) but we have the other pieces like using Hypervisor.framework for x86 already, and being able to cross compile the other code for arm64, so that would be the only major task left. On the subj. of better GPU support, it depends on what it's actually like using the drivers, but from previous experience with the GPUs and drivers shipped with macOS, there shouldn't be any special kind of trouble at least. We may have to use Metal if Apple also gets rid of opengl support on those new machines, but there are also existing translators for gles and vk to metal. The graphics hw itself, is actually the least of our worries due to how consistent the hardware is likely to be---we'd have to deal with a much fewer set of hw/driver quirks versus other host OS platforms.
edw 6y ago
I'd like to advocate for remote development environments. Most of my day is spent typing into a tmux session on a cloud-hosted box. (I picked up a Magic Keyboard for my 11" iPad Pro, and thanks to Blink it's a great glass terminal. It's not going to work if you're debugging let's say a React app, but I've been very happy on it the last several days churning out Golang.) Running stuff on your laptop makes it run slow, get hot, and burn battery. I've considered getting a small x86 or ARM media appliance as a (physically local) remote server for when I can't count on an Internet connection. A media PC costs how much? The big holdup has been the tyranny of choice I'm confronted with. (Suggestions are welcome!) I think very few people would be surprised if the coming of ARM Macs will, along with AWS's ARM moves (and Microsoft's), drive acceptance and adoption of ARM-based server computing. The mechanism won't be anything formal, just the vague pressure that comes from people wanting their programs and libraries to compile locally.
- chooseaname 6y ago
  I have a small server at home running proxmox. I have a couple containers (lxd) running for personal dev projects. I agree that if you can do it like this, it's nice. I can be pretty much anywhere and open up a terminal, vpn in, and pick up where I left off thanks to tmux.
sjs382 6y ago
I would expect about a 5x slowdown running Docker images. Docker on a Mac utilizes a hypervisor. Hypervisors rely on running the same architecture on the host as the guest, and are about about 1x - 2x as slow as running natively. Since you're running ARM Mac, these hypervisors can only run ARM Linux. They can't run x86_64 Linux. What will happen instead? These tools will fall back on emulators. Most of the software I run in Docker already supports ARM. I'd imagine that a lot of (most of?) us that use Docker do, too.
- jayd16 6y ago
  It'll be annoying maintaining multiple docker images. Kind of defeats the purpose.
binarynate 6y ago
The loss of Boot Camp is huge. One of the reasons I develop on a Mac is so that I can use a single machine for all development (including macOS, iOS, and Windows development). Most of the time, developing for Windows on Parallels works fine, but there are some cases where it's necessary to boot directly into Windows to test or debug adequately. I hope Apple is able to reach an agreement with Microsoft or at least continues shipping Intel-based Macs until then.
- beagle3 6y ago
  It will ship Intel based laptops for at least a couple more years (at the very least, the models that will already be out at the switch), and will support them for a lot more; so just buy the best intel based once following the switch, and it will last you 4-5 more years. But also: Getting a cloud windows station or an el-cheapo-$500-under-the-desk-when-you-really-need-it Windows machine is probably worth it if you're doing professional work. It would quickly cost much less than the time you lose when rebooting to the the other OS, from my experience.
jmull 6y ago
> Should I get an ARM Mac? ...if you use virtualization often, I wouldn't recommend it. I use virtualization continuously, but not for anything that needs to be as fast as possible. I won’t hesitate to get an ARM Mac once I can run x64 Windows VMs on it. (Presumably VMWare Fusion or Parallels, and for once I won’t feel ripped off by the upgrade pricing.) Docker on Mac doesn’t work that well today, so I don’t have any workflows that depend on it.
- jki275 6y ago
  There is no reason to expect that virtualbox, parallels or Vmware will emulate x86-64 to run a guest OS. None of them does any emulation today, they are virtualization platforms.
pazimzadeh 6y ago
On the bright side, it looks like low-latency streaming is good enough that as long as you have internet connection, Boot Camp is not really necessary. This works well for me: https://shadow.tech/usen/ https://shadow.tech/usen/
cbsmith 6y ago
Hey guys... we have done emulation before, and it's not nearly so bad. Also, there ARM images for Docker. You don't HAVE to run x86-64 binaries.
lowbloodsugar 6y ago
I had an ARM based desktop in 1988. Be thrilled to have one again.
013a 6y ago
I'd say that I'm excited for ARM. That doesn't mean the transition will be seamless or easy. I know that a big complaint about the move is "great, now I'm doing ARM locally and deploying to x86". I think this is a legitimate concern, for now, but I also strongly believe it is inevitable that, within the next decade, deploying to x86 in the Cloud will be as "weird" as ARM would be today. The benefits are way too numerous. Well, more accurately, I think it'll be a "I'm on Fargate, oh wow, Fargate runs on ARM, I had no idea" kind of thing. Ok, the article outlines why you may need some idea, but come on; we're talking about one line where I'm downloading the x86 version of a dependency instead of an ARM version. That's an easy fix. I don't know what this means for open accessibility of hardware. Right now, I could go buy and run locally the Intel Xeon chip powering my app in the cloud; when things move to ARM, it absolutely will be "AWS Graviton" (not sold outside AWS) or "Azure ARM Whatever" (not sold outside Azure). This sucks for accessibility, but, actually, does it? ARM enables the cloud providers to do this; they could never design their own x86 chips. As long as we're all standardized on the same ISA, and the chips generally have the same characteristics, I'm looking forward to a very bright future where vendors are now also competing against one-another in the silicon. And I may not be able to buy an AWS Graviton, but I'm sure (well, hopeful) that one day I'll be able to build an ARM desktop that isn't a Raspberry Pi. AWS will have their chips, Quallcomm has theirs, Apple has theirs, Microsoft and Google have some, and they're all competing against one another. Ok, maybe this is a pipe dream. But, I'm definitely in the short Intel camp, at least on the long-term.
- klelatti 6y ago
  This touches on an interesting question which I think underlying some of the concerns here today: Who will build ARM chips comparable to an i7 say that I can go out and buy and plug into my machine at home? No-one does now and it's not obvious who would as we speak today. But if the demand is there then even with lots of obstacles to overcome, of course, then they can and will.
  - smspf 6y ago
    Not sure about the socket used (it might be soldered down), but aarch64-based workstations are already available for the general public, e.g. [1]. [1] https://www.anandtech.com/show/15737/arm-development-for-the-office-unboxing-an-ampere-emag-workstation https://www.anandtech.com/show/15737/arm-development-for-the...
huslage 6y ago
Hypervisors are by no means 1-2x slower. Testing I/O is not testing the performance of a hypervisor. It's testing the I/O stack.
__warlord__ 6y ago
Has Apple mentioned something about Thunderbolt 3 or USB 4 on this new Macs?
AkihiroSuda 6y ago
> Why can't you update the Docker image to also support ARM? You theoretically could switch your backend to run ARM Linux. However, this would take months No need to take months. `docker buildx` can build multi-arch images without using real ARM instances.
- Matthias247 6y ago
  Does that help if the software you build inside the container doesn't build on ARM? Imagine a 3 digit count of legacy C libraries which do so far not compile on ARM for a variety of reasons. You would need to spend a significant amount of time to make them compile and run.
lsllc 6y ago
My guess is that Apple will end up copying Microsoft and providing a WSL style Linux kernel "shim" into Darwin (pretty easy as it's already UNIX) and use Rosetta2 to translate any x86_64 containers to aarch64). No need for a hypervisor.
harpratap 6y ago
There's another unintended consequence of this virtualization - docker is already has very high CPU usage on my macbook, anywhere from 50-100%. Because of which it is always hot and toasty. This is caused already caused my screen to start deteriorating (https://www.ifixit.com/Answers/View/567125/Horizontal+line+on+bottom+of+MacBook+Pro+2017+(Due+to+overheating) https://www.ifixit.com/Answers/View/567125/Horizontal+line+o...) and the battery has degraded considerably too, even when I'm not coding on it and docker is shut down. This means a significant hit to the longevity of such devices as they not meant to be pushed so hard 40 hours a week. With ARM macs I see it getting even worse.
leoh 6y ago
This is silly. Most stacks will have counterparts on both architectures. Just run CI with the same configurations as prod. Problems due to differences will be rare for most stacks -- modern languages are well defined and run against extensive spec tests on all major platforms -- and will smooth out over time.
rcarmo 6y ago
All my Docker stuff is multi-arch these days. Here’s one of my sample pipelines, written precisely to show how easy it is: https://github.com/rcarmo/azure-pipelines-multiarch-docker https://github.com/rcarmo/azure-pipelines-multiarch-docker
Aqueous 6y ago
this is why intel should be scared - very scared - that the PC world seems to be converting to ARM en masse. PCs might be a relatively small fraction of intel’s total sales, but it’s the second order effects they should be worried about. if it becomes less convenient for developers on ARM machines to develop and deploy software to x86 cloud architecture, they will begin to demand that the cloud architecture be shifted to ARM as well.
paride5745 6y ago
As a Linux tech, I welcome this Apple move honestly. Having a proper competitor for x86/x64 is a good thing. The fact docker is slower on ARM (at the moment!) is mostly due to the lack of interests for optimizations. With Apple starting to produce MacARM machines, and maybe more ARM servers in the wild, docker (and other platforms/frameworks) will start to get more performant on ARM as well.

156 points by bmalehorn 6y ago

deleted 6y ago

[deleted]

This is ridiculous. Your code will just have to support multiple architectures, which is very easy with modern languages and tooling.

maxmcd 6y ago
Yeah, ARM is coming and docker will move to support it. We already have this: https://docs.docker.com/buildx/working-with-buildx/ https://docs.docker.com/buildx/working-with-buildx/ Things like the pinebook pro (and hopefully more linux ARM devices) will keep pushing this further.
- henryfjordan 6y ago
  Docker came to the ARM-based raspberry pi in 2016: https://www.raspberrypi.org/blog/docker-comes-to-raspberry-pi/ https://www.raspberrypi.org/blog/docker-comes-to-raspberry-p...
- buildbot 6y ago
  I know of several in production embedded devices running docker, and have worked on a few...It's already here and works great.
Spivak 6y ago
I mean the post is technically right. You're probably better of skipping the first generation of ARM Macs until software support happens unless you're someone who wants to work on that software support.
jnwatson 6y ago
Hardly. You’re investing a great deal of effort in building a parallel set of images that probably will never see production. The one use case when this might be viable is targeting AWS Graviton2. Does anybody know if you can run an emulated Graviton2 on ARM Mac?
- my123 6y ago
  Parallels on Arm macOS simulates the Snapdragon 835 SoC to emulated operating systems.
bobalob_wtf 6y ago
I think you missed the point. What about all the dependencies of your code that are only compiled for x86_64? The article isn't talking about native apps on the laptop, it's about apps that run on a server but that you are developing locally. You can't run your x86 docker image on your ARM mac without emulation. You can't run your x86 Windows VM without emulation etc. Of course there are solutions like using a remote server or a VM in the cloud, but if you're buying a decent machine then you would normally expect to be able to run these things locally.
- acdha 6y ago
  Do you have any examples of this? The last time I tried an AWS ARM server, it was literally no modification other than changing the server type — Linux has run on ARM for many years and Apple is far from the first company to use the platform. For example, back in 2017 Cloudflare was basically looking at this as a question of which hardware ran most cost-effectively rather than having engineering heroics first: https://blog.cloudflare.com/arm-takes-wing/ https://blog.cloudflare.com/arm-takes-wing/
  - user5994461 6y ago
    I want to say Oracle database clients as an example. My company definitely had problems to get database drivers to work generally speaking and on both 32 bits and 64 bits. Have a look at postgres, oracle, cassandra, redis, sybase to name a few, I am not sure which one was worse, it wasn't me doing the work. But I've seen some of the C and C++ dependencies that needed to compile with the errors that happened and that was horrendous.
    - jbverschoor 6y ago
      That’s a good moment to make your c/c++ code more robust, and cross-platform, like the languages they are
      - user5994461 6y ago
        The problem wasn't in our code, it was in the database code that was either from open source or from a vendor. If you want a sample. Try to install the cassandra client library in python. It will pull in and compile all sort of shit. That's supposed to be python and easily cross platform.
heavyset_go 6y ago
There are very few packages compiled for ARM on PyPI, and there are more than a few packages on PyPI that are a pain to build from source.

m000 6y ago

Apple will singlehandedly make 2021 "the year of Linux on the desktop".

the-golden-one 6y ago
I thought that was WSL2 on Windows 10?
pantalaimon 6y ago
When was the year of the macOS desktop?
- julienfr112 6y ago
  2012 ?
- inetknght 6y ago
  1996
- m000 6y ago
  It's not about stealing users from macOS. It's about stealing developers. Hell, Apple is at the mercy of Microsoft and Adobe right now. I'd bet they had to line their pockets very well, so that they don't get any funny ideas. But Apple can't just pay-up every cross-platform software developer. Smaller developers will have to re-evaluate whether macOS remains a viable target platform for them. Which can translate to a dev-gain for Linux. The catch is that Linux is in much better position to translate an influx of developers to an influx of new users: Linux runs on what you have, while macOS requires you buy Apple hardware. And let's not forget about macOS as a gaming platform. Linux has made a huge leap forward with Steam Proton. On macOS there's still a ton of games not supporting x86_64 (Catalina), and situation won't get better by transition to ARM.
  - dnh44 6y ago
    That may be true but it’s not accounting for the iPhone and iPad developers out there that will be able to easily target macOS after the switch.

grahamlee 6y ago

It didn’t take months, the time I did it (running Docker on a Pinebook, which was not a great experience). It took a couple of hours to flip some base images away from Alpine, as Debian already has a load of ARM packages built.

thomaslord 6y ago
This assumes that your Docker workload can run on an ARM system without lots of hacking, and also that you trust the ARM-compiled version you're running locally to function identically to the x86-compiled version running on your server.
- marmaduke 6y ago
  It's not the worst assumption on HN by far
- grahamlee 6y ago
  No, it doesn't. If I'd made the statement "all you need to do is…" then it would have involved some assumptions. What I said was "I did this and all it took was…" no assumptions, just experience.
- thrill 6y ago
  If only people writing applications could find some way of testing that their apps function properly.
8K832d7tNmiQ 6y ago
That’s under a case where all libraries you need supports aarch64 architecture, which is sort of true for popular libraries, but not all libraries.
yjftsjthsd-h 6y ago
> It took a couple of hours to flip some base images away from Alpine, as Debian already has a load of ARM packages built. Why did you have to switch from Alpine to Debian? Alpine supports ARM quite happily, and it looks like they're shipping Docker images for ARM (and other architectures, too).

user5994461 6y ago

Didn't think of that. If running Docker is 10 times slower on ARM and virtual box doesn't support the architecture at all, this might indeed end developers using Mac.

rbanffy 6y ago
Running Docker on an emulated x86 will be slow, but I doubt it'd be 10x slower. There are snapdragon laptops running Windows. How much slower is running Docker on them?
armagon 6y ago
I've been developing on a Mac for years, and I've never needed to use Docker or virtualisation to do it. (I've been doing game development, and now web front end development. I'm sure the major game engines and browsers will be ported to run on ARM chips (although it may take a while)). Honest question: What sort of development regularly requires using docker or virtualized OSes?
- neurostimulant 6y ago
  Almost every server applications (databases, webservers, webapps) are available as docker images. It's very easy to deploy those apps using docker, which is why it's taking over sysadmin world by storm. Previously, handling a big web application deployment is a complex task that requires a dedicated team. Now, you can just package your app as a docker image, and other people that know docker will know how to deploy your app without having to know its internal dependency graph first.
  - anthk 6y ago
    If you use Docker as a production tool instead of prototyping several shit will happen soon.
    - yjftsjthsd-h 6y ago
      It's not quite as simple as GP implies, but why not? I work at a place running Docker in prod, and our only issues are with the swarm networking, not Docker itself.

jjoonathan 6y ago

If you stay back on x86 virtualization will be slow, but if you jump to ARM this is great! > However, this would take months (infomercial arms) I'm sure it won't make sense for everyone, but I'm just as sure it will make sense for many.

marricks 6y ago

It will be extremely interesting to see what the dev's say with the test boxes. Curious if there's any magical fixes like switching over to ARM Linux, since the software of an image would likely be compiled for x86 I really doubt it... Perhaps this will spur some people over to running ARM servers in the cloud...

rbanffy 6y ago
It's unlikely the test boxes are going to people who deploy to x86 backends. They are targeted towards iOS and macOS developers. We can have the experience of developing on ARM to deploy on x86 right now with ARM workstations. A 16 core barebones costs around $700
lukevp 6y ago
Has anyone received an invite into the program yet? I applied on day one, but don’t have a Mac Store app currently published, so I’m not sure if I will get accepted.
- Vomzor 6y ago
  I don’t have a published Mac app either and I got accepted.

core-questions 6y ago

> Why can't you update the Docker image to also support ARM? You theoretically could switch your backend to run ARM Linux. However, this would take months - renting out ARM instances, re-building all repositories, and a tense switch over. I don't see why this would be so hard. If anything, I expect to see a massive upswing in things like AWS Graviton2 uptake, and a lot of common Docker images being built with ARM versions out of the box. It might be about a year or so, but eventually we'll be able to just go ARM-native the whole way. What Apple needs to do is make a first-class, WSL-tier implementation of Docker for Mac for ARM.

rbanffy 6y ago
The Honeycomb.io folks reported 40% more capacity per dollar on Graviton 2 over x86. That alone should motivate people to start looking into ARM backends.
Spivak 6y ago
I'm kinda thankful to Apple for biting the bullet on this one. For whatever reason people will move mountains for Apple where other companies' products would just languish and die. The second order effects of ARM being something that's "safe" for people to use should be great!
- deleted 6y ago
  [deleted]
jjoonathan 6y ago
Didn't they show off a native arm docker image running in the keynote?
- rbanffy 6y ago
  I think it was running in Parallels
user5994461 6y ago
>>> expect ... a lot of common Docker images being built with ARM versions out of the box. This has no chance of happening. The common cloud CI systems do not support ARM at all (travis, circle CI and co). There is only a minority of developers with macbook and the rest is not going to spend $2000 to buy one just to build some docker images.

dlivingston 6y ago

Do we know that Boot Camp isn’t supported by Big Sur? Or is it just that one can’t run an x86 OS on an ARM architecture? In other words - will I still be able to dual-boot into something like ARM-flavored Linux?

leecb 6y ago
one can’t run an x86 OS on an ARM architecture This is the limitation. There is an ARM version of Windows, but the comments from Microsoft don't sound terribly promising: “Microsoft only licenses Windows 10 on ARM to OEMs. We have nothing further to share at this time.” [1] And Apple has more firmly stated that this won't be an option: “We’re not direct booting an alternate operating system,” says Craig Federighi, Apple’s senior vice president of software engineering. “Purely virtualization is the route. These hypervisors can be very efficient, so the need to direct boot shouldn’t really be the concern.” [1] 1: https://www.theverge.com/2020/6/24/21302213/apple-silicon-mac-arm-windows-support-boot-camp?utm_campaign=theverge&utm_content=chorus&utm_medium=social&utm_source=twitter https://www.theverge.com/2020/6/24/21302213/apple-silicon-ma...
- gumby 6y ago
  And the iPhone didn’t permit native third part apps when launched. Not because they weren’t ready to announce it yet but because at launch time they figured web apps would be enough. I have no idea what plans they might have but I would be surprised if you couldn’t install some ARM Linux distros on their laptops sometime next year.
yborg 6y ago
Boot Camp support will remain for Intel machines. Current understanding is that ARM machines will have no Boot Camp capability at all.
deleted 6y ago
[deleted]

jeremyjh 6y ago

My 2017 Macbook pro still has quite a lot of life in it, but it seems unlikely I will replace it with another Mac in a few years. Before the Mac I had a Lenovo X1 Carbon running Linux and it was great; and even then was a better development environment in some ways (docker has better filesystem performance, pacman is much better than homebrew). I do use some audio processing applications and my kids play a few games that do not run at all on Linux. I may try WSL again instead of going straight back to Linux, but its hard to imagine Mac will be the best OS for me.

drewrv 6y ago
I recently had to get a new laptop and went with windows for the first time in a decade. Macs are still great to develop on for now, but looking at the trajectory apple has taken, the growing pains ARM will likely bring, and also the trajectory of Windows, it seemed like Windows would be the safer choice over the next few years.

fluxem 6y ago

But linux can be run on arm natively. Moreover, most packages are also compiled for arm. So apt-get install will work just the same. I'm sure they will be able to target Apple's specific arm chips when they come out.

donarb 6y ago
Apple released a list of open source projects that they have ported to ARM, they intend to upload patches to each of these projects: - Bgfx - Blender - Boost - Skia - Zlib-Ng - Chromium - cmake - Electron - FFmpeg - Halide - Swift Shader - Homebrew - MacPorts - Mono - nginx - map - Node - OpenCV - OpenEXR - OpenJDK - SSE2Neon - Pixar USD - Qt - Python 3 - Redis - Cineform CFHD - NumPy - Go - V8
- tonyedgecombe 6y ago
  It’s interesting that Electron is on that list.
  - asadlionpk 6y ago
    Crucial piece of tech for many products like VSCode, Slack, Discord, etc.
    - pjmlp 6y ago
      Given how much Microsoft's React Native team bashes Electron with their performance bar charts (300x more bloat than RN), I look forward that, as soon as it is mature across Linux, macOS and Windows, they replace Electron with RN on VSCode.
  - yjftsjthsd-h 6y ago
    Makes sense; port Electron and you get a bunch of apps for free.
  - imtringued 6y ago
    It's also interesting that this won't fix old Electron applications. The idea of easy cross platform development via Electron is a myth because most developers won't support your platform even if all support requires is checking a box. When you consider that this is the primary justification for using Electron over other stacks it just makes your blood boil. All the downsides with none of the benefits.

ris 6y ago

If you hadn't sold yourself out of the free market, you would be able to choose what architecture machine you bought.

Spivak 6y ago
A free market wouldn't have saved you because the market has every incentive to gravitate to a single architecture because vendors and customers want the best software compatibility. The more popular an architecture (or really any platform) gets the more software that's written for it until it starves out competitors because they can't run the software their customers want.

julienfr112 6y ago

Mac book was never really a dev platform. Maybe for front or nodejs, or definitly for native apple apps, but seriously, brew and so are so subpar.

rbanffy 6y ago
I use Macports and I'm quite happy.
setpatchaddress 6y ago
Genuinely curious what you feel is subpar about brew. It seems to work pretty well.
chrisseaton 6y ago
I develop low-level code like compilers just fine on a MacBook.
- fortran77 6y ago
  What's "low level" about a compiler?
  - chrisseaton 6y ago
    > Mac book was never really a dev platform. Maybe for front or nodejs, or definitly for native apple apps, but seriously, brew and so are so subpar. I'm not sure what you're asking? It's lower level than the examples which were given. There's nothing stopping you using a MacBook for almost any development task. It's not just for front-end tasks. You can do work that runs directly on the architecture.
dhosek 6y ago
I've been doing dev work on Macs since 2002. Perl, PHP, Java, C++. It's been a great environment. I don't expect most of my workflow to be impacted by the ARM transition, but given I've refreshed my Mac Mini and laptop both in the last 18 months, I don't expect to be changing architectures any time soon either.

pwinnski 6y ago

If the worst of every possible thing happens and you avoid the most obvious solutions and one is very, very slow, then yes, you're right to worry. Or, you could use already-extant Debian ARM releases and spend minutes rather than months switching over.

justaguy88 6y ago

I wonder if Apple will still allow a dual boot with a native (arm64 in this case) Linux

gardaani 6y ago
There's no official support for ARM-based Macs: https://news.ycombinator.com/item?id=23640746 https://news.ycombinator.com/item?id=23640746
vetinari 6y ago
Short answer: no. Slightly longer (but not much) answer: https://www.youtube.com/watch?v=Hg9F1Qjv3iU&feature=youtu.be&t=3772 https://www.youtube.com/watch?v=Hg9F1Qjv3iU&feature=youtu.be...
yadco 6y ago
Well given the roadblocks they put for their recent x86-64 MacBooks running Linux, it's very unlikely.

timsally 6y ago

It is very likely that ARM-based Macs will lack a performant hypervisor upon release. We will have to see how VMWare responds. I'd bet it will inspire new products and innovation and the desktop space will move towards a less x86-x64 centric world. In the end it is a short term problem. Someone will respond and provide a performant hypervisor that can run on an ARM host and virtualize x86-x64 and ARM guests. It's true it will cause some pain in the first year or two, but even as a heavy VMWare Fusion user I am really looking forward to the benefits of a vertically integrated laptop.

WrtCdEvrydy 6y ago
VMWare did have a hypervisor for Raspberry Pi.
- my123 6y ago
  Yes, VMWare ESXi runs on Arm just fine. :-)
  - jki275 6y ago
    Can you run an x86 guest under it?
    - lode 6y ago
      No. Virtualization (dividing a host into different logical hosts but executing unmodified CPU instructions, like VMware, VirtualBox, ...) and emulation (translating instructions, like Rosetta) are two different beasts.
      - jki275 6y ago
        That's pretty much what I assumed from what I know of VMWare. It's going to be a big issue for future Macs, there are entire segments of developers who may have to abandon Macs if we can't run VMs of x86 operating systems.
6y ago

saxonww 6y ago

Develop on the platform you want to deploy to.

deleted 6y ago
[deleted]
yjftsjthsd-h 6y ago
I am not running Darwin in prod. EDIT: I suppose I should clarify; I don't totally disagree. I personally run Ubuntu on my laptop and servers. But plenty of people are quite happy developing on Darwin and deploying to some sort of GNU/Linux.
jki275 6y ago
Develop on an ESP32? You're a masochist, but I like it.

gtrubetskoy 6y ago

I remember the days when having to switch between x86, ppc, sparc, etc was a thing (not to mention the many flavors of UN*X) and we survived. In fact I think it was more fun back before the x86/Linux server domination. Architecture diversity is good.

quux 6y ago

I'm not a heavy docker user but why can't I develop docker containers on Arm (as native containers, no emulation) and deploy to x86_64? Or vice versa? I understand that some packages are binary only and wouldn't be necessarily available for Arm, especially initially, but the majority should be.

icedchai 6y ago
You can. Because of the Raspberry Pi and other ARM SBCs, the most popular base images already run on ARM. The ones that are missing will catch up pretty fast.
Teknoman117 6y ago
It's not that you can't, you just have to be mindful. Because docker containers contain compiled applications, you have to be aware of what CPU architecture they're compiled for. ARM can't natively run x86 binaries, x86 can't natively run ARM binaries. If you want to develop containers for x86 systems on an ARM system, you'll have to cross compile your containers, which I'm not sure if docker actually supports outside of emulation. If you are only a consumer of containers, most of the popular ones have been compiled for multiple architectures.

lowbloodsugar 6y ago

If I were to describe my job, or programming in general, it might be "problems that have no obvious solution". This is a sad article that just seems to be the opposite in spirit to "Hacker" ethos.

snapetom 6y ago

A lot of developer-centric focus discussion on how Docker would work (hint: it does), but VirtualBox is still pretty common in the sysadmin world and other industry circles. Moreover, there seems to be no way it will ever work. It will be interesting to see how that turns out.

bmalehorn 6y ago
Author here. That's a major point of the article - "are we screwed?" I'm not an expert on virtualization but I wanted to see some discussion on this topic, because it feels like we might be screwed and nobody is talking about. Anyway I was happy to see Docker worked, at least on a basic level.
- snapetom 6y ago
  Cool. Thanks for writing it. It summarizes and collects a lot of issues we were all grumbling about here and there. The main hurdles for Docker are organization, not technical. However, the other issues you bring up are going to be more technical (same as you, though, not a hypervisor expert and/or we're going to be at the mercy of big vendors like Apple, Oracle, and Microsoft. Those are much harder problems to overcome.

nojito 6y ago

Apple has their own virtualization offering to share and they are being quite coy about

rgovostes 6y ago

I'm more convinced dropping dual boot and supporting virtualization is the right move. Only the host OS is going to have the right drivers for the trackpad, wi-fi, GPU, power management, etc. etc. Through virtualization, the guest OS doesn't have to worry about constantly evolving hardware models. Virtualized OS performance is already very good, and USB passthrough has existed for a while. Snapshots are a godsend. What won't work are things like CUDA for eGPUs over Thunderbolt 3, and you'll have to share disk and RAM with the host OS. But for most use cases it's probably the right choice. (This doesn't address the author's concern about moving away from x86.)

jbverschoor 6y ago

We have qemu on arm. It’s fast enough to software render half-life. Servers will follow desktop, so in a few years a lot of things are arm

smspf 6y ago

So many wrong assumptions ... 1. If emulating aarch64 (arm64) on x86_64 is 6x slower (on your system, btw, it's not an universal constant), it doesn't mean emulating x86_64 on aarch64 will be 6x slower. It'd probably be worse, or at least that's my gut feeling. 2. Generic container images like the Ubuntu mentioned usually have aarch64 (arm64) support, so running the x86_64 image makes no sense for the presented use-case. 3. You won't be able to use most software because they don't release ARM binaries ... and the example uses `wget` && `tar xf`, with no binary signature check. As someone who has been porting stuff from x86_64 to aarch64 for a couple of years, I admit I've seen this pattern frequently. The most obvious solution is to build from sources, which would have been better off on x86_64 too, instead of fetching a prebuilt (and unverified) binary from the internet. Maybe there are some CPU flags the compiler could notice and apply optimizations which are not included in the prebuilt binary. I'm not an Apple fan and I'm certainly not a fan of cross-architecture development either. I do agree with the general idea behind the article, however I find it a bit hand wavy.

zekrioca 6y ago
Yes, agreed. And the examples exposed are not fair. There are a lot of optimizations one can do in Docker, specially when dealing with I/O workloads (dd example in the article). Cloud providers have been doing this for long, long time already.. Why the author did not mention those, it is to be seen..
thayne 6y ago
> Generic container images like the Ubuntu mentioned usually have aarch64 (arm64) support, so running the x86_64 image makes no sense for the presented use-case. I think the argument here is you can't build your own docker images that you use in production and run them on your mac without emulation (unless your production workload also runs on ARM).
- smspf 6y ago
  That's a fair point. Emulation implies other limitations too - code compiled on your machine might leverage only the CPU features emulated, which would lead to sub-optimal binaries, not to mention much slower builds.

zekrioca 6y ago

I guess someone will port Docker to JVM, and use the JVM optimized to whatever ARM processor there will be.

neilalexander 6y ago
Docker is written in Go which already has first-class cross-compilation support, so getting the Docker tools running on ARM is practically a non-issue.
- zekrioca 6y ago
  Yeah, I thought about the conceptual idea, similar to what MS did: https://threatvector.cylance.com/en_us/home/teardown-windows-10-on-arm-x86-emulation.html https://threatvector.cylance.com/en_us/home/teardown-windows...

bazizbaziz 6y ago

This seems like a weird benchmark, reading from /dev/urandom and gzipping random data does not seem like something most folks will want to do. It even appears like /dev/urandom speeds differ greatly on various architectures [0] and there are issues with /dev/random being fundamentally slow due to the entropy pool [1] (but I guess this is why the author uses /dev/urandom). It would be better to measure something more related to what docker users will actually do, like container build time of a common container, and/or latency of HTTP requests to native/emulated containers running on the some container. One reason to feel positive about the virtualization issues is that Rosetta 2 provides x86->ARM translation for JITs which an ARM-based QEMU could perhaps integrate into it's own binary translation [2]. [0] https://ianix.com/pub/comparing-dev-random-speed-linux-bsd.html https://ianix.com/pub/comparing-dev-random-speed-linux-bsd.h... [1] https://superuser.com/questions/359599/why-is-my-dev-random-so-slow-when-using-dd https://superuser.com/questions/359599/why-is-my-dev-random-... [2] https://developer.apple.com/videos/play/wwdc2020/10686/ https://developer.apple.com/videos/play/wwdc2020/10686/

bmalehorn 6y ago
Author here. I'm glad somebody said something! Yes the gzip perf test is pretty silly, but illustrates a significant difference. /dev/urandom throughput on this setup was about 100 MB / s so it wasn't a bottleneck for this test - the bottlneck was gzip. Feel free to come up with a performance test yourself! I personally want to know what an HTTP test would look like. You can run an ARM image by running: docker run -it arm64v8/ubuntu Unfortunately, Rosetta 2 is not going to help here. Rosetta 2 translates x86 -> ARM, but only on Mac binaries. It does not translate Linux binaries, and cannot reach inside a Docker image.
- yjftsjthsd-h 6y ago
  So I'm not familiar with how Darwin does things, but on most FOSS unixes it's easy to use qemu to run one arch on another, either full system or just user mode emulation (which when wired up correctly lets you seamlessly execute ex. ARM binaries on an x86 system). I would expect it to be easy enough to either set up user mode translation, or just swap Docker's backing hypervisor with an x86 VM. Or, worst case, just run qemu-system-x86_64 on your ARM Mac, run Linux inside that VM, and run Docker on that Linux; SSH in and it should be mostly transparent.

seanparsons 6y ago

Any company with a load of binaries built without any effort towards supporting cross platform builds that uses Docker is gonna have a bad day with this. They buy a bunch of new MacBooks and then find they can't use them until they spend a few weeks porting everything.

neilalexander 6y ago
I suppose that depends what they’re written in. Some languages (e.g. Go) far simpler than others.

Skunkleton 6y ago

> Docker on a Mac utilizes a hypervisor. Hypervisors rely on running the same architecture on the host as the guest, and are about about 1x - 2x as slow as running natively. That doesnt sound right to me. Perhaps on IO bound tasks, if you are using emulated devices. On CPU bound tasks you should see near native performance.

old-gregg 6y ago

When I ask Mac-loving developers, why they chose to run MacOS when developing non-MacOS software, they used to give me good reasons. I think their reasoning is no longer valid. The hardware has gotten worse (keyboard, touchbar), the OS has gotten more hostile, meanwhile the state of Linux on Laptop has gotten a lot better. So... I used to understand them, but I no longer do. https://i.kym-cdn.com/photos/images/newsfeed/001/016/674/802.jpg https://i.kym-cdn.com/photos/images/newsfeed/001/016/674/802...

ed25519FUUU 6y ago

I use docker every day and I guess I’m just not worried about this. The container pushes come from a CI host, so I’m not worried about compatibility. And it’s 20% slower? Well, most of the build time is slow for all sorts of reasons. I honestly don’t think I’ll even notice.

phamilton 6y ago

> ec2 only offers 6 general-purpose ARM instance sizes m6g, c6g, r6g each support 6 sizes for a total of 24

_msw_ 6y ago
Disclosure: I work at AWS building cloud infrastructure C6g, M6g, and R6g (powered by AWS Graviton2) each support 8 sizes, along with bare metal. A1 instances (powered by AWS Graviton) have 5 sizes, along with bare metal. That's a total of 33 distinct instance sizes.
- bmalehorn 6y ago
  Thanks, I didn't know about c6g, m6g, r6g. I've updated the post to remove this mention - I only counted a1 instances. That still leaves storage optimized and GPU optimized instances missing. I'm guessing storage should be easy enough to add, but what about GPU? From my novice experience with GPUs, they need finicky drivers that must be ported by the GPU manufacturers, so I figure it might take a while to get competitive ARM GPU instances.
  - _msw_ 6y ago
    Configurations of these instances with NVMe local storage are coming. NVIDIA is supporting Arm for CUDA development, see https://nvidianews.nvidia.com/news/nvidia-brings-cuda-to-arm-enabling-new-path-to-exascale-supercomputing https://nvidianews.nvidia.com/news/nvidia-brings-cuda-to-arm... and https://blogs.nvidia.com/blog/2019/11/18/ngc-containers-arm/ https://blogs.nvidia.com/blog/2019/11/18/ngc-containers-arm/
xsmasher 6y ago
This seemed like the weakest argument in the article; as arm becomes more popular it will get more support.

bitwize 6y ago

Once again -- Apple will do what the entire industry without Apple couldn't do. In this case, force a migration to ARM-based servers, so that prod is running on the same architecture as the developer's machine. Apple is finally killing x86.

tjoff 6y ago
Hooray, we have successfully fixed the mistake with an open platform and will now be relegated to incompatible hardware without any competition. At last, the future will surely be bright!
- duskwuff 6y ago
  How was x86 any more "open" of a platform? If anything, x86 is a far more "closed" platform, as there are only two remaining manufacturers of x86 parts, and there is no licensing process to join them. Meanwhile, there are hundreds of ARM licensees, and the process for becoming a licensee is all documented online [1]. [1]: https://www.arm.com/why-arm/how-licensing-works https://www.arm.com/why-arm/how-licensing-works
  - tjoff 6y ago
    How? It is absolutely inconceivable how much more open it is. Also, the CPU is but a minor part of the puzzle. But still that is still twice as many as apple (good luck exchanging that apple-arm with any other brand). Please let me know how open you think the next apple ARM platform is when you try to boot any OS not written by apple. Please compare that with a computer built from AMD/Intel with a motherboard out of dozens of manufacturers etc. Any ATX power supply etc. Pretty much any PCI-E graphics card etc.
    - duskwuff 6y ago
      You are confusing the x86 CPU architecture (which is closed) with the PC platform (which is relatively open). > Also, the CPU is but a minor part of the puzzle. But still that is still twice as many as apple (good luck exchanging that apple-arm with any other brand). Even on x86, interchangeable CPUs are the exception, not the rule. Intel and AMD CPUs haven't even used the same socket since the 1990s, and even within those manufacturers, socket incompatibilities are common. Software interchangeability is more of an operating systems issue than an architectural one. With appropriate software shims, though, there is no reason to suspect that (for example) Linux ARM software could be run on an Apple ARM CPU. In fact, it's quite likely that tools like the Android emulator will do exactly that. > Please compare that with a computer built from AMD/Intel with a motherboard out of dozens of manufacturers etc. Any ATX power supply etc. Pretty much any PCI-E graphics card etc. Server-class ARM hardware generally does use similar parts as x86 servers, including power supplies and PCIe peripherals.

adrianpike 6y ago

I'm actually not worried, for a few reasons; - I already do cross-arch development day-in and day out between x86 and ARM, and have only run into hard blockers on a library or tool a handful of times. The solve was generally pretty straightforward to either use an ARM-compatible alternative, or to cross-compile it myself. - We've done this many many times before and it's not that bad. I know I'm not the only one old enough here to remember the days of having heterogeneous fleets across PPC, SPARC, and x86. Or even more recent - different extensions for x86 with different chipset manufacturers.

kevin_thibedeau 6y ago
Tons of x86 code accesses misaligned addresses.
- saagarjha 6y ago
  Well, that's only because it's efficient to do so on x86. Code recompiled for ARM isn't going to do that.
  - DaiPlusPlus 6y ago
    It’s not that simple if that code is using explicit struct layouts or x86/x64 intrinsics. Forgive my ignorance though - but what ISA extensions are in Apple’s ARM chips for SIMD? Intel poured a lot of effort into SSE+AXE - Does Apple have a compete there?
    - saagarjha 6y ago
      > It’s not that simple if that code is using explicit struct layouts or x86/x64 intrinsics. Performance sensitive code that relies on alignment guarantees and other platform details will not work and need to be updated, yes. IIRC Apple's chips do NEON for SIMD, not sure if they support SVE yet. (But I figure they will have to once it becomes a required part of the ARM standard…)
      - 6y ago

Uehreka 6y ago

For my most recent project[1], I wanted to see if Amazon’s Graviton instances would be a good choice for my docker deployments (I was deploying MongoDB, an Express server, and several instances of the Janus WebRTC server). I was developing in Pop OS on an x86_64 desktop (since we’re gonna have to start specifying now) and found the toolchain around building ARM64 images to be pretty simple once I got it set up. I benchmarked some `t2a.nano`s against some `a1.medium`s and found that the `nano`s were sufficient for my needs, so I went with them (they are cheaper than `a1.medium`s, even if the `a1`s have a better price-to-performance ratio). I didn’t find it too difficult to rebuild any of these projects for cross-architecture usage. Even Janus, which has a TON of C/C++ dependencies (some of which have to be compiled from a particular version of the source) easily built for ARM with no change in the Dockerfile. So I kind of feel like OP is exaggerating the effort required to migrate servers to ARM. Sure it might be a hassle when you have tons of microservices, but you can move them incrementally, and most things recompile with no changes. And regardless of what architecture your dev machine is, you’ll want to be able to compile for and work with both architectures if you want to get the most out of the infrastructure on offer in 2020. [1] Shameless plug: https://chrisuehlinger.com/blog/2020/06/16/unshattering-the-audience-building-theatre-on-the-web-in-2020/ https://chrisuehlinger.com/blog/2020/06/16/unshattering-the-...

bmalehorn 6y ago
Cool, thanks for sharing. It's these kind of experiences that I was hoping to gather from making this post. Did you notice at the end that you did NOT end up choosing ARM? You ended up going with x86_64 because that's what made more sense for your backend. That's part of my point - developers should choose their backend architecture based on the performance and pricing of their backend, not their development laptop. And if that decision is "we should keep using x86", then there will be a big performance hit in development.
- pjmlp 6y ago
  Back in the UNIX glory days, I was responsible for keeping a software stack running across Windows NT (later 2000), Aix, HP-UX, Solaris, each with its own CPU architecture. This is just another CPU story, no big deal.

monadic2 6y ago

Tl;dr they want to run x86 linux for their own reasons rather than arm.

gigatexal 6y ago

It’s still early days. bhyve which is likely what they’re using or whatever the hypervisor is will just run arm docker images — unless you have a hard x86 dependency many of our http micro services should run just fine on arm images at least my workflow will be just fine.

gigatexal 6y ago
Furthermore this is speculation. We don’t have ARM Macs yet to test. This is like all the nerds in the forums speculating on hardware leaks how the next gen GPUs will perform: wait for hardware and reviews. Making any sort of claim as to what to buy or not at this point seems disingenuous.

eberkund 6y ago

Are there any excited embedded developers in the crowd? I have done a little embedded work and cross compiling has always been a huge pain in the ass to setup. I know some people have even gone as far as purchasing expensive niche workstations with ARM CPUs specifically to avoid this problem. I feel like having a mainstream ARM platform like the MBP will make compiling software for ARM-based single board computers a breeze.

detaro 6y ago
I'd much rather have a more powerful x86 workstation for the same money than an ARM laptop. Never really had problems with cross-compile. And without support for running Linux natively, it doesn't get me much for even for the parts of testing that don't need the specific target (well, VMs maybe).
- TheNorthman 6y ago
  To be clear, we don't know if the ARM MacBook will be able to run Linux natively. We only know that Apple won't continue support for Boot Camp and therefor Windows anymore. Linux was never supported.
  - sigjuice 6y ago
    There won't be native Linux. https://news.ycombinator.com/item?id=23640746 https://news.ycombinator.com/item?id=23640746 (Craig Federighi confirms Apple Silicon Macs will not support booting other OS) EDIT: fixed link
    - TheNorthman 6y ago
      I don't understand your point. Native Linux isn't restricted to x86_64. EDIT: Your new link doesn't tell a different story. From the comments: > It is still possible to disable secure boot using csrutil. Apple has never officially supported booting Linux on a Mac. > https://twitter.com/never_released/status/1275850872153690114 https://twitter.com/never_released/status/127585087215369011...

outworlder 6y ago

On the flip side, I guess ARM Macs will now allow the use of hypervisors for Android simulators, instead of a full hardware virtualization. ... thus making Android development better on Macs?

jeroenhd 6y ago
Android emulators on desktop generally run amd64 images of Android using existing virtualisation hardware and software. At best, you can say that you can run ARM-only games at native speed now, but as a developer you won't really notice much different (assuming the processors aren't slower than Intel's)
jayd16 6y ago
Android already had x86 builds and that was the preferred way to run the emulator so its mostly likely a neutral change (once they get hardware virtualization for arm working). The GPU aspect of things might improve maybe?
deleted 6y ago
[deleted]
lfy_google 6y ago
Android Emulator developer here. In addition to what the other comments said about android emulation with hypervisors existing already for x86, we're also looking into the Hypervisor.framework API for Apple silicon. It won't be a trivial task (hoping for pre-existing code to port over maybe?) but we have the other pieces like using Hypervisor.framework for x86 already, and being able to cross compile the other code for arm64, so that would be the only major task left. On the subj. of better GPU support, it depends on what it's actually like using the drivers, but from previous experience with the GPUs and drivers shipped with macOS, there shouldn't be any special kind of trouble at least. We may have to use Metal if Apple also gets rid of opengl support on those new machines, but there are also existing translators for gles and vk to metal. The graphics hw itself, is actually the least of our worries due to how consistent the hardware is likely to be---we'd have to deal with a much fewer set of hw/driver quirks versus other host OS platforms.

edw 6y ago

I'd like to advocate for remote development environments. Most of my day is spent typing into a tmux session on a cloud-hosted box. (I picked up a Magic Keyboard for my 11" iPad Pro, and thanks to Blink it's a great glass terminal. It's not going to work if you're debugging let's say a React app, but I've been very happy on it the last several days churning out Golang.) Running stuff on your laptop makes it run slow, get hot, and burn battery. I've considered getting a small x86 or ARM media appliance as a (physically local) remote server for when I can't count on an Internet connection. A media PC costs how much? The big holdup has been the tyranny of choice I'm confronted with. (Suggestions are welcome!) I think very few people would be surprised if the coming of ARM Macs will, along with AWS's ARM moves (and Microsoft's), drive acceptance and adoption of ARM-based server computing. The mechanism won't be anything formal, just the vague pressure that comes from people wanting their programs and libraries to compile locally.

chooseaname 6y ago
I have a small server at home running proxmox. I have a couple containers (lxd) running for personal dev projects. I agree that if you can do it like this, it's nice. I can be pretty much anywhere and open up a terminal, vpn in, and pick up where I left off thanks to tmux.

sjs382 6y ago

I would expect about a 5x slowdown running Docker images. Docker on a Mac utilizes a hypervisor. Hypervisors rely on running the same architecture on the host as the guest, and are about about 1x - 2x as slow as running natively. Since you're running ARM Mac, these hypervisors can only run ARM Linux. They can't run x86_64 Linux. What will happen instead? These tools will fall back on emulators. Most of the software I run in Docker already supports ARM. I'd imagine that a lot of (most of?) us that use Docker do, too.

jayd16 6y ago
It'll be annoying maintaining multiple docker images. Kind of defeats the purpose.

binarynate 6y ago

The loss of Boot Camp is huge. One of the reasons I develop on a Mac is so that I can use a single machine for all development (including macOS, iOS, and Windows development). Most of the time, developing for Windows on Parallels works fine, but there are some cases where it's necessary to boot directly into Windows to test or debug adequately. I hope Apple is able to reach an agreement with Microsoft or at least continues shipping Intel-based Macs until then.

beagle3 6y ago
It will ship Intel based laptops for at least a couple more years (at the very least, the models that will already be out at the switch), and will support them for a lot more; so just buy the best intel based once following the switch, and it will last you 4-5 more years. But also: Getting a cloud windows station or an el-cheapo-$500-under-the-desk-when-you-really-need-it Windows machine is probably worth it if you're doing professional work. It would quickly cost much less than the time you lose when rebooting to the the other OS, from my experience.

jmull 6y ago

> Should I get an ARM Mac? ...if you use virtualization often, I wouldn't recommend it. I use virtualization continuously, but not for anything that needs to be as fast as possible. I won’t hesitate to get an ARM Mac once I can run x64 Windows VMs on it. (Presumably VMWare Fusion or Parallels, and for once I won’t feel ripped off by the upgrade pricing.) Docker on Mac doesn’t work that well today, so I don’t have any workflows that depend on it.

jki275 6y ago
There is no reason to expect that virtualbox, parallels or Vmware will emulate x86-64 to run a guest OS. None of them does any emulation today, they are virtualization platforms.

pazimzadeh 6y ago

On the bright side, it looks like low-latency streaming is good enough that as long as you have internet connection, Boot Camp is not really necessary. This works well for me: https://shadow.tech/usen/ https://shadow.tech/usen/

cbsmith 6y ago

Hey guys... we have done emulation before, and it's not nearly so bad. Also, there ARM images for Docker. You don't HAVE to run x86-64 binaries.

lowbloodsugar 6y ago

I had an ARM based desktop in 1988. Be thrilled to have one again.

013a 6y ago

I'd say that I'm excited for ARM. That doesn't mean the transition will be seamless or easy. I know that a big complaint about the move is "great, now I'm doing ARM locally and deploying to x86". I think this is a legitimate concern, for now, but I also strongly believe it is inevitable that, within the next decade, deploying to x86 in the Cloud will be as "weird" as ARM would be today. The benefits are way too numerous. Well, more accurately, I think it'll be a "I'm on Fargate, oh wow, Fargate runs on ARM, I had no idea" kind of thing. Ok, the article outlines why you may need some idea, but come on; we're talking about one line where I'm downloading the x86 version of a dependency instead of an ARM version. That's an easy fix. I don't know what this means for open accessibility of hardware. Right now, I could go buy and run locally the Intel Xeon chip powering my app in the cloud; when things move to ARM, it absolutely will be "AWS Graviton" (not sold outside AWS) or "Azure ARM Whatever" (not sold outside Azure). This sucks for accessibility, but, actually, does it? ARM enables the cloud providers to do this; they could never design their own x86 chips. As long as we're all standardized on the same ISA, and the chips generally have the same characteristics, I'm looking forward to a very bright future where vendors are now also competing against one-another in the silicon. And I may not be able to buy an AWS Graviton, but I'm sure (well, hopeful) that one day I'll be able to build an ARM desktop that isn't a Raspberry Pi. AWS will have their chips, Quallcomm has theirs, Apple has theirs, Microsoft and Google have some, and they're all competing against one another. Ok, maybe this is a pipe dream. But, I'm definitely in the short Intel camp, at least on the long-term.

klelatti 6y ago
This touches on an interesting question which I think underlying some of the concerns here today: Who will build ARM chips comparable to an i7 say that I can go out and buy and plug into my machine at home? No-one does now and it's not obvious who would as we speak today. But if the demand is there then even with lots of obstacles to overcome, of course, then they can and will.
- smspf 6y ago
  Not sure about the socket used (it might be soldered down), but aarch64-based workstations are already available for the general public, e.g. [1]. [1] https://www.anandtech.com/show/15737/arm-development-for-the-office-unboxing-an-ampere-emag-workstation https://www.anandtech.com/show/15737/arm-development-for-the...

huslage 6y ago

Hypervisors are by no means 1-2x slower. Testing I/O is not testing the performance of a hypervisor. It's testing the I/O stack.

__warlord__ 6y ago

Has Apple mentioned something about Thunderbolt 3 or USB 4 on this new Macs?

AkihiroSuda 6y ago

> Why can't you update the Docker image to also support ARM? You theoretically could switch your backend to run ARM Linux. However, this would take months No need to take months. `docker buildx` can build multi-arch images without using real ARM instances.

Matthias247 6y ago
Does that help if the software you build inside the container doesn't build on ARM? Imagine a 3 digit count of legacy C libraries which do so far not compile on ARM for a variety of reasons. You would need to spend a significant amount of time to make them compile and run.

lsllc 6y ago

My guess is that Apple will end up copying Microsoft and providing a WSL style Linux kernel "shim" into Darwin (pretty easy as it's already UNIX) and use Rosetta2 to translate any x86_64 containers to aarch64). No need for a hypervisor.

harpratap 6y ago

There's another unintended consequence of this virtualization - docker is already has very high CPU usage on my macbook, anywhere from 50-100%. Because of which it is always hot and toasty. This is caused already caused my screen to start deteriorating (https://www.ifixit.com/Answers/View/567125/Horizontal+line+on+bottom+of+MacBook+Pro+2017+(Due+to+overheating) https://www.ifixit.com/Answers/View/567125/Horizontal+line+o...) and the battery has degraded considerably too, even when I'm not coding on it and docker is shut down. This means a significant hit to the longevity of such devices as they not meant to be pushed so hard 40 hours a week. With ARM macs I see it getting even worse.

leoh 6y ago

This is silly. Most stacks will have counterparts on both architectures. Just run CI with the same configurations as prod. Problems due to differences will be rare for most stacks -- modern languages are well defined and run against extensive spec tests on all major platforms -- and will smooth out over time.

rcarmo 6y ago

All my Docker stuff is multi-arch these days. Here’s one of my sample pipelines, written precisely to show how easy it is: https://github.com/rcarmo/azure-pipelines-multiarch-docker https://github.com/rcarmo/azure-pipelines-multiarch-docker

Aqueous 6y ago

this is why intel should be scared - very scared - that the PC world seems to be converting to ARM en masse. PCs might be a relatively small fraction of intel’s total sales, but it’s the second order effects they should be worried about. if it becomes less convenient for developers on ARM machines to develop and deploy software to x86 cloud architecture, they will begin to demand that the cloud architecture be shifted to ARM as well.

paride5745 6y ago

As a Linux tech, I welcome this Apple move honestly. Having a proper competitor for x86/x64 is a good thing. The fact docker is slower on ARM (at the moment!) is mostly due to the lack of interests for optimizations. With Apple starting to produce MacARM machines, and maybe more ARM servers in the wild, docker (and other platforms/frameworks) will start to get more performant on ARM as well.