ARM Mac: Why I'm Worried About Virtualization

Post by lfy_google » Thu, Jun 25, 2020, 8:38 PM UTC

my123 wrote: post #218

lfy_google wrote: post #205

Earlier quoted context omitted.

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

Hello, OpenGL is deprecated but still supported on Apple Silicon, even for arm64 apps.

Post by sirn » Thu, Jun 25, 2020, 8:58 PM UTC

bmalehorn wrote: post #174

sirn wrote: post #114

Earlier quoted context omitted.

Was your emulation done with qemu user space emulator[1] (the syscall translation layer) or qemu system emulator[2] (the VM)? If it was qemu-system you might have better numbers with qemu-user-static, which does binary translation similar to Rosetta 2 rather than a being a full system emulator with all its overhead. You can probably use qemu-user-static to translate x86-64-only binaries in a Linux container on an ARM…

I ran this on a Linux laptop - it looks like it's running qemu-user-static: root 9934 103 0.0 125444 6664 pts/0 Rl+ 12:25 0:12 /usr/bin/qemu-aarch64-static /usr/bin/gzip So it might be that Docker already runs a native x86_64 Linux, then uses qemu-static binary translation.

    $ dd if=/dev/urandom bs=4k count=10k | gzip >/dev/null
    10240+0 records in
    10240+0 records out
    41943040 bytes (42 MB, 40 MiB) copied, 1.02284 s, 41.0 MB/s

    $ dd if=/dev/urandom bs=4k count=10k | proot -R /tmp/aarch64-alpine -q qemu-aarch64-static sh -c 'gzip >/dev/null'
    10240+0 records in
    10240+0 records out
    41943040 bytes (42 MB, 40 MiB) copied, 3.33964 s, 12.6 MB/s

Post by jeremyjh » Thu, Jun 25, 2020, 9:08 PM UTC

eberkund wrote: post #176

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…

Post by DaiPlusPlus » Thu, Jun 25, 2020, 9:12 PM UTC

Symmetry wrote: post #173

saagarjha wrote: post #168

Earlier quoted context omitted.

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

I actually wouldn't be surprised if Apple were to put SVE in their first desktop class ARM chip. They were the first to move to 64 bits after all and SVE has been optional in the standard for quite a while and they wouldn't be the first implementer this time.

Post by tams » Thu, Jun 25, 2020, 9:15 PM UTC

yjftsjthsd-h wrote: post #156

60secz wrote: post #133

Earlier quoted context omitted.

Not op, but alpine package manager leaves a lot to be desired especially compared to ubuntu. Also much easier to set locale. Since minimal ubuntu & debian exist, I think the question should be: "Why would you use alpine?" especially considering potentially slower performance: https://pythonspeed.com/articles/alpine-docker-python/

> Not op, but alpine package manager leaves a lot to be desired especially compared to ubuntu. How so? If anything, apk is way nicer than apt in a container build script (or anything automated); with apt you have to use -y and maybe force the noninteractive frontend, where `apk add foo` just works, correctly, automatically, with no effort required. > Also much easier to set locale. > considering potentially slower pe…