Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: mhi 21. 07. 2020, 20:33:11
-
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.
-
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.
-
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
-
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)
-
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é.
-
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
-
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.