Catalina & High Sierra in Qemu X86 Emulation auf einem M1-Mac:

Geekbench 5 Score: 68 / 205

Vielleicht läuft das irgendwann mal besser wenn die besonderen Fähigkeiten von Apples Prozessoren unterstützt werden (Umschalten auf X86 Memory Mode).

Ausserdem fehlt vermutlich jegliche Grafikbeschleunigung und das macht moderne Betriebsysteme schon allein quälend langsam.

Kann das bitte mal jemand der sich damit etwas besser auskennt als ich und der Bereitseins M1 hat, für MacOS 10.6.8 testen und messen?
Das ist ja noch „ein etwas schlankeres System“ es braucht dabei gar nicht das Maximum an Speed. Es reicht vollkommen, wenn Werte von vor 5-10 Jahren da erreicht werden. Denn da kommt es nämlich auf die Geschwindigkeit des Users an... die läßt sich nicht durch einen schnelleren Rechner beschleunigen

MikeMuc
Und was soll das bringen? Kannst ja kaum noch was mit 10.6 machen.

Vielleicht hat er eine App, die dringend benötigt wird und seit 10.7 aber nicht lauffähig ist.

QEMU emuliert hier wirklich ein ganzes System. QEMU kann zwar auch als Virtulizer arbeiten, also das machen, was sonst VirtualBox, VMWare und Parallels machen, aber eben nur dann, wenn das emulierte System die gleiche Hardware bieten soll wie das reale System. Das ist hier aber nicht der Fall.

Im Emulator Modus hingegen muss QEMU alles emulieren, da bringt es nichts den Memory Mode im System umzuschalten, denn die Apps greifen gar nicht direkt auf den Speicher zu. Hier wird einer virtuellen, emulierten CPU gesagt, sie soll eine Speicheroperation ausführen und diese wird dann von QEMU Code durchgeführt und der hat nichts davon, wenn der Speicher einen anderen Mode nutzt, denn das ist ARM Code und der läuft am schnellsten im ARM Mode.

Auch Grafikbeschleunigung wird es hier nie geben, denn auch die GPU ist virtuell und durch QEMU emuliert. QEMU führt dann die Zeichenoperationen wo möglich mit Systemfunktionen aus und die sind aber bereits nativ beschleunigt.

Für mehr Geschwindigkeit müsste sich QEMU in das Gastsystem einklinken, so wie das auch Virtulizer tun, also z.B. eigene Treiber dort installieren, dann könnten sie z.B. recht problemlos OpenGL bereitstellen, indem sie die OpenGL Anweisungen direkt an die OpenGL Implementierung in macOS durchreichen und mit dem DirectX Wrapper aus dem Wine Projekt könnten sie auch das beschleunigen.

Wieso sollte das für Rosetta einen Unterschied machen dass der M1 in einen X86 kompatiblen Speichermodus schalten kann und für andere Emulationen nicht? Übersetzt wird der Code in beiden Fällen (bei Rosetta bis auf Systemaufrufe etc.). Die Frage ist natürlich ob es realistisch ist Qemu entsprechend umzubauen.

Na da merkt man aber nichts von. Für mich sieht das eher nach Softrendering aus.

Da spricht doch grundsätzlich nichts dagegen, oder?

Weil Rosetta keine CPU emuliert. Rosetta ist ein Transpiler. Der baut den x86 Code beim Start der App oder dynamisch beim Ausführen oder sogar beides wie ein JIT Compiler in Code um, der dann direkt auf der CPU laufen kann. Und damit man hier nicht auch noch die Speicherzugriffe komplex umbauen muss, ist es natürlich von Vorteil, wenn diese genauso durchgeführt werden, sie sie ein x86 System durchführen würde.

Das kann aber Rosetta nur deswegen tun, weil es mit dem System zusammen arbeitet und nicht hinter dessen Rücken werkelt. Denn transpiled Code hat ein Problem, wenn Code auf sich selber oder auf die Stackframes zugreift. Guckst du hier: Alleine signierter Code wird da zum riesigen Problem. Natürlich nicht für Apple, weil sie ja beides, den Transpiler und das System darunter kontrollieren und diese daher Hand in Hand arbeiten. Aber Windows weiß nichts vom Transpiler, der muss für Windows komplett transparent sein, was fast unmöglich ist, wenn auch noch JIT ins Spiel kommt. Emuliert man hingegen alles, hat man kein Problem, weil dann ja wirklich der echte x86 Code in der Emulation läuft (der also auch jede Signaturprüfung bestehen wird) und alles im Speicher wirklich so aussieht wie auf einem echten x86 System (Zugriffe aus Stackframes sind kein Problem).

Das liegt daran, dass QEMU Zeichenoperationen nur dann als solche erkennen kann, wenn eine entsprechende Funktion der von QEMU emulierten Grafikkarte genutzt wird. QEMU selber kann aber keine komplexe 3D Grafikkarte emulieren (das wäre auch extrem langsam), außer wie gesagt über eigene Windows Treiber, die es aber nicht gibt und daher zeichnet Windows hier bereits selber alles in Software, weil Windows nur noch solche 3D Grafikkarten unterstützt. Wenn Windows in Software zeichnet, kann QEMU das aber auch nicht beschleunigen, weil es kann nicht erkennen was Windows da gerade zeichnet oder das Windows überhaupt dabei ist etwas zu zeichnen (bis die auf den Schirm kommen sind die Bilddaten nur Bytewerte in einem Speicherblock und nicht als Bilddaten zu erkennen).

Und nein, es spricht natürlich nichts dagegen sich tiefer in das System einzuklinken, außer dass die QEMU Entwickler eben keine großen Windows Entwickler sind und selbst die meisten Windows Entwickler überfordert wären einen Grafikkartentreiber zu schreiben. Das ist mit enorm viel Aufwand verbunden und davon profitiert am Ende nur genau ein System (nur Windows und dort auch nur eine Version, da Grafikkartentreiber praktisch für jede Windows Version angepasst werden müssen). QEMU versucht aber eine riesige Bandbreite an Hardwareemulationen, Virtualisierungen, Gast- und Hostsystemen abzudecken, das ist denen viel wichtiger als ob dein Windows schnelle Grafik hat. In der Zeit, die sie in einen solche Treiber investieren müssten, könnten sie genauso gut eine neue CPU Emulation einbauen und das wäre denen wahrscheinlich viel wichtiger.

Danke, das erklärt mir einiges, aber eins kapier ich immer noch nicht. Wieso gilt das:

nicht auch bei einer Emulation?

Deckt vermutlich das meiste ab was ich unter Snow Leopard laufen lassen würde:

Running Mac OS 9 and Mac OS X 10.0 - 10.4 on Apple Silicon (M1) & Intel via QEMU

Ich kann zum Beispiel einen Teil meines Lebensunterhaltes damit verdienen weil ich mir dann keine Gedanken über andere Alternativen suchen müßte.
Im konkreten Fall nutze ich derzeit Freehand in einer VM auf einem Intel Mac. Und komme mir keiner mit Affinity oder Illustrator. Beide können nicht das, was ich brauche! Nebenbei: fehlerfrei konnten beide nie Freehanddateien konvertieren.

Das ist doch eh ein PPC-Programm, da sollte 10.4 auf PPC Qemu die bessere Alternative sein.

PS: Oder sogar Sheepshaver mit Macos 9.1 !

pünktchen
Weil hier kein Code direkt auf den Speicher zugreift, sondern der Zugriff über den Emulator erfolgt und dort steht dann Code, der irgendwo irgendwie auf Speicher zugreift, da auch der Speicher letztlich emuliert wird (der muss z.B. nicht wirklich zusammenhängend existieren auch wenn er dem emulierten System so präsentiert wird; er muss auch physikalisch gar nicht vorhanden sein, denn er kann in einer Swap Datei liegen; ein emuliertes System kann mehr physischen Speicher "sehe" als der Rechner in Wahrheit besitzt). Und die Speicherzugriffe in der x86 Emulation von QEMU erfolgen bereits strenger geordnet als das bei x86 der Fall ist. QEMU selber führt nie Speicherzugriffe in einer anderen Reihenfolge aus, als sie dort im Code stehen. Warum sollte er das auch tun?

Bei transpiled Code hingegen werden x86 Speicherzugriffe in ARM Speicherzugriffe übersetzt und die greifen dann wirklich direkt auf den physischen Speicher zu, ohne irgend einen Code dazwischen, weil das einfach schnell ist. Nur hier hält ARM keine strikte Reihenfolge ein, denn ARM darf solche Zugriffe in anderer Reihenfolge ausführen als sie im Code stehen; das darf x86 nur bedingt und das würde daher zu Problemen in manchen Apps führen. Daher unterstützt der M1 einen Modus in dem sich die CPU nicht wie ARM sondern wie x86 bei Speicherzugriffen verhält und nur die Reihenfolge ändern darf, wenn x86 das an dieser Stelle auch hätte tun dürfen.

Dieser Modus hat nichts direkt mit der Art von Code zu tun. Man kann den auch für rein nativen ARM Code einschalten. Allerdings ist das dann nur ein Nachteil, denn die Reihenfolge freier wählen zu dürfen bringt Geschwindigkeitsvorteile für die CPU bei der Ausführung. Dass x86 so eine strikte Reihenfolge garantiert ist heute nachteilig und mit ein Grund, warum x86 im Vergleich zu anderen Architekturen nicht so gut skaliert. Auch gerade mit mehreren Kernen, denn auch hier müssen bestimmte Garantien über alle Kerne hinweg eingehalten werden und das wird mit zunehmender Anzahl der Kerne immer mehr zum Flaschenhals (denn der Bus zwischen den Kernenn kann nicht unendlich schnell werden). Daher sind andere CPU Architekturen hier freier, was die meiste Zeit keine Rolle spielt, außer da, wo Code eben solche Garantien wirklich braucht, was aber nur selten der Fall ist und dort lässt sich diese dann explizit im Code herstellen über Anweisungen der CPU die genau für diesen Zweck vorgesehen sind. Nur kann der Transpiler kaum erkenne, wo der übersetzte Code wirklich eine x86 Garantie braucht und wo nicht und überall die Garantie herzustellenn wäre nicht schneller als die QEMU Emulation, daher ist es einfacher wenn die CPU diese auf Wunsch von sich aus bereitstellen kann.

Hm aber in einem modernen OS wie macOS läuft der Speicherzugriff doch eh über den virtuellen Speicher des OS und nicht direkt. Ob ein Emulator da noch eine weitere Abstraktionsschicht drauf packt sollte doch keinen Unterschied machen?

Es läuft über die CPU, denn das System verwaltet zwar den virtuellen Speicher, kann also z.B. entscheiden welche virtuelle auf welche physische Speicherseite abgebildet werden soll und wann welche Seiten wie ausgelagert werden sollen, aber beim eigentlichen Zugriff ist es nicht involviert, das macht die CPU ganz alleine in Hardware direkt über eine Mapping Tabelle, denn sonst wäre das unendlich langsam. Die CPU sieht auch wenn eine Seite ausgelagert wurde und wirft eine Exception, wodurch der Prozess angehalten wird und die das System abfangen kann, um dann die Seite wieder einzulagern und den Prozesse weiterlaufen zu lassen.

Und genau dieses CPU Funktionalität muss ein CPU Emulator natürlich auch emulieren, denn auch das Gastsystem erwartet ja auch, dass es der CPU das Mapping vorgeben kann bzw. Exceptions von der CPU bekommt. Wie CPUs aber z.B. virtuellen Speicher verwalten, wie Exceptions aussehen und geworfen werden oder das Format der Mapping Tabelle unterscheidet sich von Architektur zu Architektur. Mal ganz davon abgesehen, dass ein normaler Prozess wie QEMU nicht in das Speichermanagement des Kernels eingreifen kann. Und selbst wenn er das könnte, wie soll das funktionieren, wenn Windows sagt "Mappe VM Seite X auf physische Seit Y" und Y ist aber bereits in macOS belegt? Selbst dann müsste QEMU eine Zwischenschicht einziehen und die Seiten intern noch einmal ummappen, wovon Windows jedoch nichts merken darf.

Ich will damit nicht sagen, dass QEMU hier groß etwas tun muss. Natürlich macht sich QEMU die Funktionen des Hostsystems zu nutze wo auch immer möglich, aber zumindest die Adressen von Speicherzugriffen muss QEMU selber mappen, denn diese liegen physisch ganz woanders als wo das Gastsystem denkt, da es deren Lage nicht wie bei einem echten physischen System frei bestimmen kann, weil darunter eben ein unsichtbares Hostsystem liegt, das die Lage bereits vorgibt. Und QEMU muss auch prüfen, ob das Gastsystem eine Seite ausgelagert hat und bei einem Zugriff dann selber Exceptions werfen, die das Gastsystem abfangen kann, denn auch hierfür kann er nicht auf die echten Exeptions des Hostsystems zugreifen, die bekommt nur der Kernel.

Das ist nicht so tragisch, wie es sich anhört, da Speicher sowieso um mehrere Faktoren langsamer ist als die CPU , d.h. der Speicherzugriff selber wird dadurch kaum langsamer, trotzdem bremst es die Emulation aus, sprich, dadurch wird die emulierte CPU langsamer, weil die in dieser Zeit nichts anderes tun kann, und das ist mit ein Grund warum die Emulation als Ganzes langsam ist. In einem virtualisierten System hat man das Problem hingegen nicht, denn hier kümmert sich die CPU auch in Hardware um das Gastsystem und dort wo normalerweise der Kernel eingreifen würde, greift für das Gastsystem der Hypervisor ein, also die VM App, die nichts aktiv überwachen muss, sondern direkt von der CPU angesprochen wird, wenn sie sich um was kümmern soll. Daher ist der Performanceverlust hier minimal, da das virtualisierte System die meiste Zeit genauso laufen kann, als würde es alleine auf der CPU laufen und nicht in einer VM. Nur wenn das Gastsystem ganz bestimmte CPU Anweisungen ausführen oder auf virtuelle Hardware zugreifen will, muss die VM aktiv in das Geschehen eingreifen.

Ah Freehand, wie schön war es damals damit zu arbeiten.

Diesem Programm weint ein befreundeter Landschaftsplaner schon seit Jahrzehnten hinterher....
Gab es da nicht mal ein Projekt um aus dieser Adope-Software Shareware zu machen? Oder sogar Open Source? Könnte sowas nicht auch über Rosetta2 laufen ohne direkt ein komplettes OSX86 emulieren/virtualisieren zu müssen?

Kann das denn etwas, das andere Vektorgrafikprogramme nicht können? Und gibt es da nicht auch was vergleichbares für iPads und sogar für den Stift optimiert?

Nein, es ist ein PPC-Programm. Dazu bräuchte es Rosetta 1. Und das war zuletzt in 10.6 drin, deshalb läuft es seitdem nicht mehr. Vielleicht könnte man die Windowsversion in eine Winebottle packen und dann von Rosetta 2 übersetzen lassen.

Also laut lief Freehand mal unter Wine. Einen Versuch wäre es wert.