Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ARM Mac: Why I'm Worried About Virtualization

bmalehorn.com

Post reply on HN
Print view View original

91–100 of 313 posts

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

#91

Post by Teknoman117 »

quux wrote: post #47

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.

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.

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

#92

Post by seanparsons »

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.

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

#93

Post by smspf »

thayne wrote: post #85
smspf wrote: 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…

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

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.

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

#94

Post by bmalehorn »

bazizbaziz wrote: post #84

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…

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.

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

#95

Post by tonyedgecombe »

donarb wrote: post #73
fluxem wrote: 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

It’s interesting that Electron is on that list.

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

#96

Post by smspf »

user5994461 wrote: post #65
acdha wrote: 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…

I've been using postgres, cassandra, redis and mysql/mariadb on aarch64. Only ran into issues with MySQL, which we rootcaused to some weird atomic locks not working as expected on the first generation of ARMv8(.0) a couple years back.

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

#97

Post by wtetzner »

octorian wrote: post #40
m000 wrote: post #3

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

Every time Microsoft or Apple majorly screws something up, people say this. It still hasn't happened yet. However, I think Apple has been a far greater threat to Linux adoption than Microsoft. Why? Because it gives techies the *nix environment they want, with the software and hardware support no one will give them on Linux. There is real value in proprietary commercial end-user application software. Most companies wh…

> However, I think Apple has been a far greater threat to Linux adoption than Microsoft. Why? Because it gives techies the *nix environment they want, with the software and hardware support no one will give them on Linux.

With WSL, you basically get an actual Linux userland (with WSL2, I think you get an actual Linux kernel too), not just a Unix that's like Linux but different enough to be annoying. But I'm not sure that will be enough to convince people to move to Windows.

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

#98

Post by asadlionpk »

tonyedgecombe wrote: post #95
donarb wrote: post #73

Earlier quoted context omitted.

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

It’s interesting that Electron is on that list.

Crucial piece of tech for many products like VSCode, Slack, Discord, etc.

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

#99

Post by bmalehorn »

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

Author here.

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

Yup, performance benchmarks are inherently flawed and nobody knows anything right now without the hardware. However if ARM -> x86 emulation is anything like x86 -> ARM emulation, I would expect a really big performance loss.

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

Ah actually I address this in the article, and even run an arm64 image. The short version is, it would be a lot of work to convert your whole backend infrastructure to ARM just because you got a new laptop.

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

Yes, if only everything were built from source! I'm not saying there's no solution, just that the solution would be a lot of work. If the library is obscure enough and the errors are strange enough, it might be so much work as to be impossible to the busy web developer.

My goal was to write a kind of hand-wavy article to get people talking about this problem.

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

#100

Post by acdha »

user5994461 wrote: post #65
acdha wrote: 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…

Fair enough — I've used Oracle's products enough to know that software distribution and packaging is not a priority there.
Post reply on HN