4 ms·

> Rosetta 2 translates the entire text segment of the binary from x86 to ARM up-front. Do I understand correctly that the Rosetta is basically a transpiler fro

> Rosetta 2 translates the entire text segment of the binary from x86 to ARM up-front. Do I understand correctly that the Rosetta is basically a transpiler from x86-64 machine code to ARM machine code which is run prior to the binary execution? If so, does it affect the application startup times?

nilsb 4y ago
Yes, it does. The delay of the first start of an app is quite noticeable. But the transpiled binary is apparently cached somewhere.
- saagarjha 4y ago
  /var/db/oah.
nicoburns 4y ago
> If so, does it affect the application startup times? It does, but only the very first time you run the application. The result of the transpilation is cached so it doesn't have to be computed again until the app is updated.
- dylan604 4y ago
  Does that essentially mean each non-native app is doubled in disk use? Maybe not doubled but requires more space to be sure.
  - saagarjha 4y ago
    Yes.
  - varenc 4y ago
    Yes... you can see the cache in /var/db/oah/ Though only the actual binary size that gets doubled. For large apps it’s usually not the binary that’s taking up most of the space.
- kijiki 4y ago
  Similar to DEC's FX!32 in that regard. FX!32 allowed running x86 Windows NT apps on Alpha Windows NT.
  - saltcured 4y ago
    There was also an FX!32 for Linux. But I think it may have only included the interpreter part and left out the transpiler part. My memory is vague on the details. I do remember that I tried to use it to run the x86 Netscape binary for Linux on a surplus Alpha with RedHat Linux. It worked, but so slowly that a contemporary Python-based web browser had similar performance. In practice, I settled on running Netscape from a headless 486 based PC and displaying remotely on the Alpha's desktop over ethernet. That was much more usable.
- arianvanp 4y ago
  And deleting the cache is undocumented (it is not in the file system) so if you run Mac machines as CI runners they will trash and brick themselves running out of disk space over time.
  - koala_man 4y ago
    Really? This SO question says it's stored in /var/db/oah/ https://apple.stackexchange.com/questions/427695/how-can-i-limit-the-disk-usage-of-the-rosetta-2-oah-cache https://apple.stackexchange.com/questions/427695/how-can-i-l...
  - jonny_eh 4y ago
    You mean the cache is ever expanding?
  - rowanG077 4y ago
    What in the actual fuck. That is such an insane decision. Where is it stored then? Some dark corner of the file system inaccessible via normal means?
    - happyopossum 4y ago
      GP is incorrect - they’re stored in individual files inside /var/db/oah, and can be deleted without causing harm.
esskay 4y ago
The first load is fairly slow, but once it's done it every load after that is pretty much identical to what it'd be running on an x86 mac due to the caching it does.
- EricE 4y ago
  For me my M1 was fast enough that the first load didn't seem that different - and more importantly subsequent loads were lighting fast! It's astonishing how good Rosetta 2 is - utterly transparent and faster than my Intel Mac thanks to the M1.
  - savoytruffle 4y ago
    If installed using a packaged installer, or the App Store, the translation is done during installation instead of at first run. So, slow 1st launch may be uncommon for a lot of apps or users.

nilsb 4y ago

Yes, it does. The delay of the first start of an app is quite noticeable. But the transpiled binary is apparently cached somewhere.

saagarjha 4y ago
/var/db/oah.

nicoburns 4y ago

> If so, does it affect the application startup times? It does, but only the very first time you run the application. The result of the transpilation is cached so it doesn't have to be computed again until the app is updated.

dylan604 4y ago
Does that essentially mean each non-native app is doubled in disk use? Maybe not doubled but requires more space to be sure.
- saagarjha 4y ago
  Yes.
- varenc 4y ago
  Yes... you can see the cache in /var/db/oah/ Though only the actual binary size that gets doubled. For large apps it’s usually not the binary that’s taking up most of the space.
kijiki 4y ago
Similar to DEC's FX!32 in that regard. FX!32 allowed running x86 Windows NT apps on Alpha Windows NT.
- saltcured 4y ago
  There was also an FX!32 for Linux. But I think it may have only included the interpreter part and left out the transpiler part. My memory is vague on the details. I do remember that I tried to use it to run the x86 Netscape binary for Linux on a surplus Alpha with RedHat Linux. It worked, but so slowly that a contemporary Python-based web browser had similar performance. In practice, I settled on running Netscape from a headless 486 based PC and displaying remotely on the Alpha's desktop over ethernet. That was much more usable.
arianvanp 4y ago
And deleting the cache is undocumented (it is not in the file system) so if you run Mac machines as CI runners they will trash and brick themselves running out of disk space over time.
- koala_man 4y ago
  Really? This SO question says it's stored in /var/db/oah/ https://apple.stackexchange.com/questions/427695/how-can-i-limit-the-disk-usage-of-the-rosetta-2-oah-cache https://apple.stackexchange.com/questions/427695/how-can-i-l...
- jonny_eh 4y ago
  You mean the cache is ever expanding?
- rowanG077 4y ago
  What in the actual fuck. That is such an insane decision. Where is it stored then? Some dark corner of the file system inaccessible via normal means?
  - happyopossum 4y ago
    GP is incorrect - they’re stored in individual files inside /var/db/oah, and can be deleted without causing harm.

esskay 4y ago

The first load is fairly slow, but once it's done it every load after that is pretty much identical to what it'd be running on an x86 mac due to the caching it does.

EricE 4y ago
For me my M1 was fast enough that the first load didn't seem that different - and more importantly subsequent loads were lighting fast! It's astonishing how good Rosetta 2 is - utterly transparent and faster than my Intel Mac thanks to the M1.
- savoytruffle 4y ago
  If installed using a packaged installer, or the App Store, the translation is done during installation instead of at first run. So, slow 1st launch may be uncommon for a lot of apps or users.