5 ms·

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

by rk06 6y ago

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

jensv 6y ago
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.
- jensv 6y ago
  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 https://news.ycombinator.com/user?id=rock_artist
- JosephRedfern 6y ago
  Any "hot spots" that have been optimised by writing assembler has to be re-written. Same applies to any dependencies with similar optimisations.
  - danieldk 6y ago
    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.
- roblabla 6y ago
  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.
  - Tuna-Fish 6y ago
    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.
  - jsheard 6y ago
    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.
- jensv 6y ago
  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 https://news.ycombinator.com/item?id=25591695
sususu 6y ago
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.
- import 6y ago
  You're right.
- Tuna-Fish 6y ago
  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.
- dtech 6y ago
  It includes a full emulator, there's no other way to run code generated at runtime which it can do.

by rk06 6y ago

jensv 6y ago

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.

jensv 6y ago
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 https://news.ycombinator.com/user?id=rock_artist
JosephRedfern 6y ago
Any "hot spots" that have been optimised by writing assembler has to be re-written. Same applies to any dependencies with similar optimisations.
- danieldk 6y ago
  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.
roblabla 6y ago
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.
- Tuna-Fish 6y ago
  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.
- jsheard 6y ago
  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.
jensv 6y ago
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 https://news.ycombinator.com/item?id=25591695

sususu 6y ago

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.

import 6y ago
You're right.
Tuna-Fish 6y ago
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.
dtech 6y ago
It includes a full emulator, there's no other way to run code generated at runtime which it can do.