Sháním: Apple Rosetta (PPC → x86) a Rosetta 2 (x86 → ARM) binárky na analýzu

mhi

  • ***
  • 240
    • Zobrazit profil
Najde se zde nejaky dobrosrdecny majitel nainstalovaneho historickeho Apple Mac OS X 10.4.4–10.6.8  na x86, ktery by mel funkcni Rosettu https://en.wikipedia.org/wiki/Rosetta_(software) a poskytl mi jeji binarky na analyzu?

(/usr/libexec/oah/translate),
(/usr/libexec/oah/translated)
(/usr/libexec/oah/Shims/*)

Dale shanim nekoho kdo ma preview verzi BigSur a tusi, zda se z ni da vytahnout nova Rosetta (x86->ARM), pripadne jak je implementovana (ARM Apple dev desku tu predpokladam jeste nikdo nema a nevim zda v x86 instalaci BigSuru bude ?).

Nejde mi ani tak zkoumani binarniho translatoru jako takoveho, spis o vrstvu prevadejici ABI cally mezi architekturami (na rozdil od qemu-sys... je totiz prekladana jen ta nezbytne nutna cast a jinak se pouzivaji nativni knihovny, tedy alespon tak jsem to pochopil).

No a do tretice mimo tema shanim stroj kde se da spustit Sun Wabi, je to hodne velka historie, umoznovalo to na Sparcu poustet Win aplikace (balicek SUNWwabiX z roku cca 1996). Klidne i na remote, binarky jako takove mam, ale nemam zelezo.
« Poslední změna: 22. 07. 2020, 08:44:01 od Petr Krčmář »


RDa

  • *****
  • 1 152
    • Zobrazit profil
    • E-mail
Podle me ta Rosetta2 bude hodne M1 specificka - vypada to tak, ze na spusteni X86 se nepouziva preklad do cisteho ARM, ale ze ten procesor umi nejak hw akcelerovat dekodovani x86.. takze je to takove pul na pul, sw/hw reseni.

by_cx

Podle me ta Rosetta2 bude hodne M1 specificka - vypada to tak, ze na spusteni X86 se nepouziva preklad do cisteho ARM, ale ze ten procesor umi nejak hw akcelerovat dekodovani x86.. takze je to takove pul na pul, sw/hw reseni.

Před spuštěním x86 dochází ke statickému překladu instrukcí Intelu na instrukce M1. Navíc pokud to používá nějakou dynamickou knihovnu ze systému, tak ta jede nativně. HW akcelerace x86 by znamenala, že to je x86 procesor a to by Intel asi nerozdýchal.

https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment

RDa

  • *****
  • 1 152
    • Zobrazit profil
    • E-mail
HW akcelerace x86 by znamenala, že to je x86 procesor a to by Intel asi nerozdýchal.

To neni nutne pravda. Apple ma v app-store k dispozici dost relevantni vzorek X86 kodu, staci z toho udelat statistiku a najit bottleneck ciste sw prekladu - a pro tu konkretni vec resit v kremiku specialni instrukci.

Nebo jinak: vysvetlete mi, proc bezi uzivatelsky kod na 50% vykonu v OSX, ale na <10% vykonu pod Win (bavime se o aplikacich pro benchmarky, ktere nepouzivaji syscally, ktere by mohli prispet tim ze jsou nativni)

AoK

  • ***
  • 204
    • Zobrazit profil
Podle me ta Rosetta2 bude hodne M1 specificka - vypada to tak, ze na spusteni X86 se nepouziva preklad do cisteho ARM, ale ze ten procesor umi nejak hw akcelerovat dekodovani x86.. takze je to takove pul na pul, sw/hw reseni.

Před spuštěním x86 dochází ke statickému překladu instrukcí Intelu na instrukce M1. Navíc pokud to používá nějakou dynamickou knihovnu ze systému, tak ta jede nativně. HW akcelerace x86 by znamenala, že to je x86 procesor a to by Intel asi nerozdýchal.

https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment

Robert Graham na Twitteru psal, že m1 "podvádí" a samotný procesor umí použít memory ordering intelu pro instrukce, nějaké info k tomu je tady https://github.com/saagarjha/TSOEnabler, takže ve výsledku SW přeloží instrukce na ekvivalentní pro m1 ve stejné pořadí a není potřeba je přeskládávat, to je pravděpodobně pak hlavní bottleneck u Windowsu na arm při spouštění x86 kódu.

Licence Intelu se tím očividně neporušuje a přitom se tím řeší hlavní výkonnostní problém, zajímavé.


mhi

  • ***
  • 240
    • Zobrazit profil
https://twitter.com/ErrataRob/status/1331736203402547201

Na rovinu, uplne to s tim nechapu. TSO se tyka SMP, nikoliv endianity jak jsem nekde cetl; to je dobre na locking u smp aplikaci (ktere chteji bezet na vice jadrech; je opravdu hodne takovych aplikaci ktera obsadi treba 4 jadra?). Prijde mi, ze to neni uplne zasadni problem, ale mozna se pletu. Co jsem cetl tak se vzdy resily Objective-C veci kde se to da emulovat i ve "weak" memory modelu ARMu.

·
Nov 11
fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1

David Smith
@Catfish_Man
·
Nov 11
…and ~14 nanoseconds on an M1 emulating an Intel



Zajimave je taky (k Navíc pokud to používá nějakou dynamickou knihovnu ze systému, tak ta jede nativně ): "The system prevents you from mixing arm64 code and x86_64 code in the same process. Rosetta translation applies to an entire process, including all code modules that the process loads dynamically." https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment


mhi

  • ***
  • 240
    • Zobrazit profil
Nebo jinak: vysvetlete mi, proc bezi uzivatelsky kod na 50% vykonu v OSX, ale na <10% vykonu pod Win (bavime se o aplikacich pro benchmarky, ktere nepouzivaji syscally, ktere by mohli prispet tim ze jsou nativni)

To jestli bude translator efektivni zavisi na mnoha vecech, treba jestli se preklada nejaky minimalisticky basic block a po kazdem exitu se slozite dohledava cilova adresa pres  lookup table, nebo jsou ty bloky delsi a rovnou cele optimalizovane.

Optimalizace je vcelku snadna na 2 urovnich: pri samotnem prekladu (muzu prekladat vic instrukci najednou a navic to delat chytre), nebo optimalizovat po translaci; ARM ma vyhodu ze se da snadno poznat z opkodu kde se cte/zapisuje jaky registr a tak staci "obarvenim registru" a kodem ktery pripomina bubblesort velmi efektivne optimalizovat kratke bloky kodu.

Vlastni preklad mezi ISA muze byt velmi rychla zalezitost, kdyz se na to udela predchroupany automat, ktery pak jen sype "z rukavu" nove instrukce. K tomuto jsem se ale nikdy nedostal, ze bych se tim zabyval.

Ten WindowsOnARM translator jsem nezkoumal, protoze mi nikdy poradne Wokna na RPi nechodily.