Hacker News Reader

Comment by rk06 | Hacker News Reader

well here you go:

apps are natively compiled for instruction sets eg: x86, x64, ARM64 etc.

M1 has an new instruction set. so Apps targeting (x64, x86) need to compile specially to run natively on M1 chip.

currently there are few apps which are native as the chip is new. Apple has provided rosetta emulator, which will emulate x86 apps to run on M1

strange, everyone talked rosetta emulator in every single benchmark.

NOTE: the above is my current understanding. it may be slightly or grossly incorrect in some areas

View on HN

Anyone know what rewriting for M1 actually entails? Guessing maybe you just recompile all your libraries for M1 and fix any errors and warnings that crop up.

Any "hot spots" that have been optimised by writing assembler has to be re-written. Same applies to any dependencies with similar optimisations.

Well except that they can benefit from many years of Linux (and Windows) on AArch64, as a result of which OpenJDK is already ready and optimized AArch64.

Basically, just recompile for the M1. For the rare apps that have some assembly or cpu-specific intrinsics (e.g. for vectorization in math-heavy code), you'll need to port those to ARM64 as well, but that should be very rare.

IDEA contains a JRE which has a JIT compiler. This is of course entirely cpu-specific, so had to be completely redone. OFC, ARM JITs for java already existed so they just had to ship to one of those.

Atomics can be a pain point as well. The strong memory model of x86 tolerates sloppy use of atomics so bugs can easily fly under the radar, until the code is re-compiled for a weaker memory model like ARMs and suddenly you have a nightmare web of race conditions to deal with.

Porting PyPy is harder than just re-running the compiler, because PyPy contains a few big architecture-dependent "details", like the JIT compiler and the foreign function interfaces (CFFI and ctypes). More details found at: https://news.ycombinator.com/item?id=25591695

Having said that some consideration to keep in mind:

- audio code needs to be optimized for real time thread constrains. Many optimizations usually made by vectorizing rather than threading that would've lead to locks and synchronization not always possible for real-time processing. So not all SIMD code can be compiled just by changing a flag.

- machine specific code. While rare. Some companies still got such code for various reasons. And needs more complex transition.

- Not all companies were able to obtain DTK. We for example, got our first M1 machine 3 weeks ago.

- Backward support. While we'd like to have universal builds, musicians use their systems for years. We still support 10.7. With Big Sur Apple seems to break SHA1 signs making builds from Big Sur work reliably only on 10.11 or newer. (The first release to support SHA256 codesigns) https://news.ycombinator.com/user?id=rock_artist

As far I understand the Rosetta2 is not an emulator, but a layer that translate x86/x64 binary code to M1 binary code, it does not emulate a x86 machine in the system.

Something in the lines of Wine, I guess.

You're right.

There is also an emulator layer. It's used as a fallback when the much faster ahead-of-time binary translator can't work. The emulator is generally not a good experience -- if you have to use it, you really want to go native asap.

Examples where it is required is any kind of self-modifying code, such as JITs and the like. Since IDEA is a java application that ships with it's own JRE, the aot translator can only translate the JRE parts and when the execution first jumps to freshly written memory the system bails to the emulator. Since the emulator is an order of magnitude (probably more...) slower than native, and the entire IDE runs on JIT, this is very bad.

It includes a full emulator, there's no other way to run code generated at runtime which it can do.

Reply on news.ycombinator.com