I believe they’re just referring to the fact it’s native and it’s no longer being utilizing Rosetta2. Since it’s bundled with its own JRE/JDK, and other components, perhaps they just have it all compiled for M1. I was supposed to have my new MacBook Pro a couple weeks ago, but my company ordered an Intel when I specifically told them NOT to. I need to test these things out before I get them to my developers as well. Plus yes, I want a new toy. I’m waiting for a mini (for myself) to show up at my house, but I waited a long time, and that won’t be here until the end of the month. Grrrr. I really want to test Logic Pro with it!

> perhaps they just have it all compiled for M1

That won't work because of the missing W^X support in upstream releases. You need to backport patches.

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

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.

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

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.

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.

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.

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

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.

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.

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.

You're right.

As mentioned in the release notes IntelliJ ran under Rosetta 2 previously (Apples x86 to ARM emulation layer) but this new release adds native ARM (Apple Silicon) support.

I have a PyInstaller-compiled Qt .app that crashes on startup. Weird, because Intel Python in Intel PyCharm is actually working just fine.

Docker for example (might have been fixed now)

Docker works you just can’t virtualize x86 images

The tech preview[1] works and you can run x86 images (though you get a warning from the CLI).

[1] https://www.docker.com/blog/download-and-try-the-tech-previe...

Google Drive Streaming specifically will not work on Apple Silicon yet.

I would assume it's because they depend on the JVM.

X86 JVM runs fine under Rosetta2. Will will be faster now. Looking forward to it!