Live data from Hacker News

ARM Mac: Why I'm Worried About Virtualization

bmalehorn.com

71–80 of 313 posts

Re: ARM Mac: Why I'm Worried About Virtualization

#71
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.

Re: ARM Mac: Why I'm Worried About Virtualization

#72

> 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 ver…

>>> 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.

> There is only a minority of developers with macbook

I travel the world meeting developers from multiple communities. I very rarely see one without a MacBook.

Re: ARM Mac: Why I'm Worried About Virtualization

#73
post #15

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.

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

Re: ARM Mac: Why I'm Worried About Virtualization

#74

> 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 ver…

>>> 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.

I don't think this is actually the big problem some people make it out to be. You can cross compile ARM binaries on x86. You can even run ARM binaries on x86 (with qemu.) Any CI system can easily call scripts to do this.

Re: ARM Mac: Why I'm Worried About Virtualization

#77
post #8

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...

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.

Re: ARM Mac: Why I'm Worried About Virtualization

#78
post #53

Earlier quoted context omitted.

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:…

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…

That’s a good moment to make your c/c++ code more robust, and cross-platform, like the languages they are

Re: ARM Mac: Why I'm Worried About Virtualization

#80
post #71

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-c…

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..
Post reply on HN