amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > AROS und Amiga-Emulatoren > UAE mit PPC engine?? [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- 3 4 [ - Beitrag schreiben - ]

22.08.2005, 08:05 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von Holger:

Du scheinst neuerdings öfter aus dem Zusammenhang zu reißen, ich hoffe, das ist nur eine temporäre Phase.

Sag mal, hast Du's mit der Leber oder warum reagierst Du so gereizt?

Die Emulation eines PowerPC ist prinzipbedingt komplexer als die eines 68k, und wird - bei vergleichbarem Stand der Emulatortechnik - deshalb auch prinzipbedingt langsamer sein. Zu dieser Aussage stehe ich weiterhin.

Laß mal einen Moment die Paranoia beiseite:

  • Ich sagte, ein PPC-UAE würde PPC-SW langsamer ausführen als 68k-SW.
  • Du sagtest, Apple hätte da was viel besseres versprochen, was aber für OSS kaum erreichbar sein dürfte.
  • Ich sagte, das es eine entsprechende Newsmeldung mal gegeben hätte, die Technologie aber nicht OSS wäre und im Amiga-Sektor wohl kaum etwas besseres als PearPC entstehen wird.

    Sprich, ich habe Dir gar nicht widersprochen, und schon gar nicht mit Hilfe bösartig selektiver Posts. Cool down, dude.


    [ - Antworten - Zitieren - Direktlink - ]

    		•
    22.08.2005, 11:45 Uhr

    RoKo
    Posts: 72
    Nutzer
    Zitat:
    Die Emulation eines PowerPC ist prinzipbedingt komplexer als die eines 68k,
    Warum?

    [ - Antworten - Zitieren - Direktlink - ]
    22.08.2005, 12:56 Uhr

    AC-Pseudo
    Posts: 1256
    Nutzer     		Ich verschieb den Thread mal ins passendere Board.

    [ - Antworten - Zitieren - Direktlink - ]
    22.08.2005, 16:39 Uhr

    ylf
    Posts: 4112
    Nutzer
    Zitat:
    Original von RoKo:
    Zitat:
    Die Emulation eines PowerPC ist prinzipbedingt komplexer als die eines 68k,
    Warum?
    Weil der PowerPC halt komplexer ist.
    Mehr Register, mehr Cacheebenen, eine starke Vectorrecheneinheit usw.



    bye, ylf


    [ - Antworten - Zitieren - Direktlink - ]
    22.08.2005, 18:03 Uhr

    RoKo
    Posts: 72
    Nutzer
    Zitat:
    Mehr Register, mehr Cacheebenen, eine starke Vectorrecheneinheit usw.
    Ob 16 oder 32 Register ist für einen Emulator egal, der Cache wird eh nicht emuliert und Altivec kann man auch weglassen.

    [ - Antworten - Zitieren - Direktlink - ]
    23.08.2005, 16:22 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von Solar:
    Sprich, ich habe Dir gar nicht widersprochen, und schon gar nicht mit Hilfe bösartig selektiver Posts. Cool down, dude.
    Nein, es war nicht widersprochen, sondern redundant, aber eben aufgrund des selektiven Postens wie ein Widerspruch aussehend. Warum auch immer-von bösartig war keine Rede. Du selbst wirst am besten wissen, warum Du genau diesen Teil zitiert hast und den Rest nicht.

    mfg
    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ Dieser Beitrag wurde von Holger am 23.08.2005 um 16:29 Uhr editiert. ]

    [ - Antworten - Zitieren - Direktlink - ]
    23.08.2005, 16:29 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von RoKo:
    Zitat:
    Mehr Register, mehr Cacheebenen, eine starke Vectorrecheneinheit usw.
    Ob 16 oder 32 Register ist für einen Emulator egal, der Cache wird eh nicht emuliert und Altivec kann man auch weglassen.
    Was Cache und Altivec angeht, richtig.
    Die Register-Architektur ist aber nicht egal. ppc-Compiler produzieren den Programmcode unter diversen Annahmen, wie zum Beispiel, das es effizienter ist, zehnmal Register untereinander zu kopieren/verschieben, als auch nur einmal auf den Hauptspeicher zugreifen zu müssen.
    Eine 1:1 Übersetzung in eine Architektur, bei der alle Register emuliert im Hauptspeicher liegen, ist dann logischer zehnmal langsamer. Ein Emulator muß deshalb eine Reihe von typische Mustern im Programmcode erkennen und auf sinnvollere Befehlsfolgen des Wirtsystems umsetzen, um auf eine brauchbare Geschwindigkeit zu kommen.
    (Das Beispiel jetzt bitte nicht zu ernst nehmen)

    mfg
    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]
    23.08.2005, 16:31 Uhr

    Holger
    Posts: 8116
    Nutzer     		Zur ursprünglichen Frage dieses Threads:
    Zitat:
    Original von swat:
    Tach!
    Würde es sinnvoll sein Winuae mit einem PPC Modul (Sheepshaver - Pearpcengine) auszustatten, bzw. würde es den Amigamarkt wiederbeleben?

    Nein.

    Die ppc-Hardware selber hat es ja auch nicht geschafft, den Amiga-Markt wiederzubeleben, eine Emulation derselben schafft das dann erst recht nicht.

    mfg
    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]
    23.08.2005, 21:59 Uhr

    RoKo
    Posts: 72
    Nutzer
    Zitat:
    Ein Emulator muß deshalb eine Reihe von typische Mustern im Programmcode erkennen und auf sinnvollere Befehlsfolgen des Wirtsystems umsetzen, um auf eine brauchbare Geschwindigkeit zu kommen.
    Hui, wird sowas schon in der Praxis eingesetzt? Ich kenne nur das übliche Register-Caching, das in den meisten Fällen schon recht optimal sein sollte, keine Mustererkennung benötigt und mit 32 Registern genau so einfach funktioniert wie mit 16. Gibt es einen Emulator, bei dem ich mir das mal anschauen könnte?

    [ - Antworten - Zitieren - Direktlink - ]
    23.08.2005, 22:09 Uhr

    ylf
    Posts: 4112
    Nutzer
    Zitat:
    Original von RoKo:
    Zitat:
    Ein Emulator muß deshalb eine Reihe von typische Mustern im Programmcode erkennen und auf sinnvollere Befehlsfolgen des Wirtsystems umsetzen, um auf eine brauchbare Geschwindigkeit zu kommen.
    Hui, wird sowas schon in der Praxis eingesetzt? Ich kenne nur das übliche Register-Caching, das in den meisten Fällen schon recht optimal sein sollte, keine Mustererkennung benötigt und mit 32 Registern genau so einfach funktioniert wie mit 16. Gibt es einen Emulator, bei dem ich mir das mal anschauen könnte?

    JIT(JustInTimeCompiler)? (Win)UAE?

    [ - Antworten - Zitieren - Direktlink - ]
    23.08.2005, 23:59 Uhr

    RoKo
    Posts: 72
    Nutzer
    Zitat:
    JIT(JustInTimeCompiler)? (Win)UAE?
    Ich glaube, einer von uns versteht den anderen gerade überhaupt nicht.
    Ein JIT-Compiler ist die Voraussetzung für alle weiterführenden Techniken, über die es gerade geht.

    [ - Antworten - Zitieren - Direktlink - ]
    24.08.2005, 02:24 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von RoKo:
    Zitat:
    Ein Emulator muß deshalb eine Reihe von typische Mustern im Programmcode erkennen und auf sinnvollere Befehlsfolgen des Wirtsystems umsetzen, um auf eine brauchbare Geschwindigkeit zu kommen.
    Hui, wird sowas schon in der Praxis eingesetzt? Ich kenne nur das übliche Register-Caching, das in den meisten Fällen schon recht optimal sein sollte, keine Mustererkennung benötigt und mit 32 Registern genau so einfach funktioniert wie mit 16. Gibt es einen Emulator, bei dem ich mir das mal anschauen könnte?
    :lach: Aus genau diesem Grund gibt es keinen OSS ppc-Emulatur mit brauchbarer Geschwindigkeit. Apples ppc-Emulator wird wohl so etwas haben... Und Du kannst davon ausgehen, daß aktuelle Java-VMs bei der Übersetzung so arbeiten (nur an den HotSpots), weil die bytecode-Instruktion teilweise sehr stark von der native CPU abweichen.
    Da gibt's nämlich gar keine Register. Und ein algebraisches Beispiel: es gibt keine Instruktion zum binären Invertieren einer Zahl. Also steht dann immer -x-1 für ~x im Code. So etwas muß man einfach beim Code erzeugen wieder optimieren.
    Aber da werden noch ganz andere Arten von Code-Umwandlungen betrieben. Das sprengt aber den Rahmen dieses Threads.

    mfg
    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]
    24.08.2005, 04:06 Uhr

    RoKo
    Posts: 72
    Nutzer
    Zitat:
    :lach: Aus genau diesem Grund gibt es keinen OSS ppc-Emulatur mit brauchbarer Geschwindigkeit.
    Ich kann mir nicht viele Situationen vorstellen, in denen das überhaupt besser funktioniert als simples Register-Caching. Da könnte ich natürlich daneben liegen, aber sicher bin ich mir darin, dass das nicht der Grund ist - PearPC wird momentan hauptsächlich durch seine MMU-Emulation ausgebremst. Viele just-zur-rechten-Zeit-kompilierende Emus gibt es als Freeware ohnehin nicht, aber ein paar der nach meiner Einschätzung flottesten emulieren MIPS.
    Zitat:
    Apples ppc-Emulator wird wohl so etwas haben...
    Kann schon sein, frag mal nach :)
    Zitat:
    Und Du kannst davon ausgehen, daß aktuelle Java-VMs bei der Übersetzung so arbeiten (nur an den HotSpots), weil die bytecode-Instruktion teilweise sehr stark von der native CPU abweichen.
    Da gibt's nämlich gar keine Register.
    Weshalb das übliche Register-Caching da auch prima passt und sie eben nicht mittels Mustererkennung spezieller Registernutzungen arbeiten ;)
    Zitat:
    Und ein algebraisches Beispiel: es gibt keine Instruktion zum binären Invertieren einer Zahl. Also steht dann immer -x-1 für ~x im Code. So etwas muß man einfach beim Code erzeugen wieder optimieren.
    Naa, das ist trivialer Kleinkram.
    Zitat:
    Aber da werden noch ganz andere Arten von Code-Umwandlungen betrieben. Das sprengt aber den Rahmen dieses Threads.
    Und den Rahmen dessen, was ein Emulator tun kann.

    [ - Antworten - Zitieren - Direktlink - ]
    24.08.2005, 12:20 Uhr

    Solar
    Posts: 3680
    Nutzer
    Zitat:
    Original von RoKo:

    Zitat:
    Und Du kannst davon ausgehen, daß aktuelle Java-VMs bei der Übersetzung so arbeiten (nur an den HotSpots), weil die bytecode-Instruktion teilweise sehr stark von der native CPU abweichen.
    Da gibt's nämlich gar keine Register.
    Weshalb das übliche Register-Caching da auch prima passt und sie eben nicht mittels Mustererkennung spezieller Registernutzungen arbeiten ;)

    Trotzdem geht eine HotSpot-VM her und optimiert den Bytecode (die "emulierte" Maschine) auf die native Plattform.

    http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_4.html#hotspot


    Zitat:
    Zitat:
    Und ein algebraisches Beispiel: es gibt keine Instruktion zum binären Invertieren einer Zahl. Also steht dann immer -x-1 für ~x im Code. So etwas muß man einfach beim Code erzeugen wieder optimieren.
    Naa, das ist trivialer Kleinkram.

    Du empfindest NEG x; DEC x; gegenüber NOT x; als trivialen Kleinkram?

    ;)

    Zitat:
    Zitat:
    Aber da werden noch ganz andere Arten von Code-Umwandlungen betrieben. Das sprengt aber den Rahmen dieses Threads.
    Und den Rahmen dessen, was ein Emulator tun kann.

    Deshalb erreicht PearPC auch nicht die Leistung von Rosetta. ;)

    [ - Antworten - Zitieren - Direktlink - ]
    24.08.2005, 12:35 Uhr

    RoKo
    Posts: 72
    Nutzer
    Zitat:
    Trotzdem geht eine HotSpot-VM her und optimiert den Bytecode (die "emulierte" Maschine) auf die native Plattform.
    Selbstverständlich tut sie das, das ist schließlich das Prinzip eines JIT-Compilers. Was willst Du mir damit sagen?
    Zitat:
    Du empfindest NEG x; DEC x; gegenüber NOT x; als trivialen Kleinkram?
    Ja, das ist trivial zu implementieren.
    Zitat:
    Deshalb erreicht PearPC auch nicht die Leistung von Rosetta. ;)
    Das sind beides Emulatoren. Rosetta hat aber den großen Vorteil, das es kein Betriebssystem und damit wohl auch nicht wirklich eine MMU emulieren muß.

    [ - Antworten - Zitieren - Direktlink - ]
    24.08.2005, 12:53 Uhr

    Solar
    Posts: 3680
    Nutzer     		Sag mal...?!?

    Zitat:
    Original von RoKo:
    Zitat:
    Trotzdem geht eine HotSpot-VM her und optimiert den Bytecode (die "emulierte" Maschine) auf die native Plattform.
    Selbstverständlich tut sie das, das ist schließlich das Prinzip eines JIT-Compilers.

    Kann es sein, das Du hier JIT-Compilierung (Verzögern der Übersetzung bis der übersetzte Code tatsächlich benötigt wird) und HotSpot-Optimierung (Anwenden aufwendiger Optimierungen auf ausgesuchten, oft verwendeten Code) verwechselst?

    Zitat:
    Zitat:
    Du empfindest NEG x; DEC x; gegenüber NOT x; als trivialen Kleinkram?
    Ja, das ist trivial zu implementieren.

    Gestern um 21:59 hast Du noch behauptet, von was anderem als Register-Mapping noch nicht gehört zu haben...

    Zitat:
    Rosetta hat aber den großen Vorteil, das es kein Betriebssystem und damit wohl auch nicht wirklich eine MMU emulieren muß.

    Öh... hallo? Die MMU ist Teil des Prozessors, nicht Teil des Betriebssystems...

    [ - Antworten - Zitieren - Direktlink - ]
    24.08.2005, 15:00 Uhr

    RoKo
    Posts: 72
    Nutzer
    Zitat:
    Kann es sein, das Du hier JIT-Compilierung (Verzögern der Übersetzung bis der übersetzte Code tatsächlich benötigt wird) und HotSpot-Optimierung (Anwenden aufwendiger Optimierungen auf ausgesuchten, oft verwendeten Code) verwechselst?
    Nö. Zumal "HotSpot-Optimierung" nur ein Java-Marketingbegriff ist. JIT-Compiler optimieren immer für einen bestimmten Zielprozessor. Freilich der eine mehr, der andere weniger.
    Zitat:
    Gestern um 21:59 hast Du noch behauptet, von was anderem als Register-Mapping noch nicht gehört zu haben...
    Hier ging es darum, bestimmte, kompliziertere Registernutzungen zu erkennen und nicht nur darum, zwei Operationen zu einer zu vereinen. Sowas kann ja schon manche aktuelle CPU von sich aus.
    Zitat:
    Öh... hallo? Die MMU ist Teil des Prozessors, nicht Teil des Betriebssystems...
    Ein Teil des Prozessors, den in aller erster Linie das Betriebssystem nutzt und nicht eine normale Anwendung.

    [ - Antworten - Zitieren - Direktlink - ]
    24.08.2005, 15:27 Uhr

    Solar
    Posts: 3680
    Nutzer
    Zitat:
    Original von RoKo:
    Zitat:
    Öh... hallo? Die MMU ist Teil des Prozessors, nicht Teil des Betriebssystems...
    Ein Teil des Prozessors, den in aller erster Linie das Betriebssystem nutzt und nicht eine normale Anwendung.

    Wieso meinst Du, das man sich in einem aufgebohrten UAE - oder in sonst irgendeinem PPC-Emulator - die MMU sparen könnte?

    [ - Antworten - Zitieren - Direktlink - ]
    24.08.2005, 17:32 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von RoKo:
    Nö. Zumal "HotSpot-Optimierung" nur ein Java-Marketingbegriff ist. JIT-Compiler optimieren immer für einen bestimmten Zielprozessor. Freilich der eine mehr, der andere weniger.
    Nein.
    1. Es ist kein Marketingbegriff
    2. JIT ist KEIN HotSpot-Optimizer

    Der erste grundsätzliche Unterschied ist der, daß in eine Umgebung mit HotSpot-Optimizer, der Profiler entscheidet, an welchen Stellen der JIT überhaupt aktiv wird.
    => UAE besitzt keine eingebauten Profiler
    => UAE beherrscht keinen Mixed-Mode von Interpreter und JIT
    Dann wird für ermittelte HotSpots anhand des Laufzeitverhaltens eine passende Übersetzungsstragie gewählt und der Code erneut übersetzt.
    => Im UAE wird einmal übersetzter Code nicht wieder angefaßt
    => UAE besitzt überhaupt keine unterschiedlichen Übersetzungsstrategien.
    Zitat:
    Hier ging es darum, bestimmte, kompliziertere Registernutzungen zu erkennen und nicht nur darum, zwei Operationen zu einer zu vereinen. Sowas kann ja schon manche aktuelle CPU von sich aus.
    Warum dann nicht gleich den x86 in den ppc-Emulationsmodus schalten?
    Iss wohl doch nicht so einfach.
    Wenn Dir das Umschreiben von arithmetischen Operationen zu trivial war, wie wärs denn mit
  • loop-unrolling
  • Verschieben von conditionals
  • Anpassen der out-of-order execution an die andere Anzahl von Units
  • Umformen aller branch-Instruktionen, die das Link-Register benutzen (ja, selbst einfache Unterprogramme funktionieren auf ppc völlig anders...)

    mfg
    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]

    		•
    24.08.2005, 17:46 Uhr

    Holger
    Posts: 8116
    Nutzer     		Ach so
    Zitat:
    Original von RoKo:
    Hier ging es darum, bestimmte, kompliziertere Registernutzungen zu erkennen und nicht nur darum, zwei Operationen zu einer zu vereinen. Sowas kann ja schon manche aktuelle CPU von sich aus.
    1. Was ist daran komplizierter, eine bestimmte Folge von Registermanipulationsbefehlen zu erkennen, im Vergleich zu einer bestimmten Folge von Arithmetikbefehlen?
    2. Was ist am Ergebnis komplizierter, wenn ich sowieso nur die Wahl habe, eine Serie von Instruktionen durch a) weniger, b) mehr, c) genausoviele Instruktionen zu ersetzen?
    3. Ein kleines Beispiel direkt aus dem ppc-Programmierhandbuch:
    Wie vertausche ich zwei Register?
  • Möglichkeit eins: mittels XOR
    # R3 = a
    # R4 = b
    xor R3,R3,R4 # R3 = a ^ b
    xor R4,R4,R3 # R4 = b ^ (a ^ b) = a
    xor R3,R3,R4 # R3 = (a ^ b) ^ a = b
  • Möglichkeit zwei: mittels Addition
    # R3 = a
    # R4 = b
    add R3,R3,R4 # R3 = a + b
    sub R4,R3,R4 # R4 = (a + b) - b = a
    sub R3,R3,R4 # R3 = (a + b) - a = b
    Ein ppc-Prozessor mag diese Sequenz vielleicht parallel ausführen oder gar intern durch eine einzelne Tauschanweisung ersetzen, schließlich kennen die Prozessorhersteller ja ihr eigenes Handbuch.
    Eine 1:1 Übersetzung in x86 Code ist allerdings nicht empfehlenswert, zumindest wenn es ein HotSpot ist. An anderen Stellen dagegen wäre eine Umformung aufwändiger als eine potentielle Ersparnis.
    Und wie man sieht, handelt es sich um genau so eine Folge arithmetischer Anweisungen, wie neg und decr, die man erkennen kann, nichts spezielles Register-Magisches.

    mfg
    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]

    		•
    24.08.2005, 17:50 Uhr

    Senex
    Posts: 491
    [Administrator]
    Zitat:
    Original von CarstenS:
    Kommt darauf an, was man unter "Sinn" versteht. ;) Vermutlich wäre eine solche Implementierung (die ja zum bestehenden UAE "passend" gemacht werden müsste) relativ aufwändig und auch nicht besonders schnell.

    Naja, die Performance würde ich nicht unbedingt als Hinderungsgrund ansehen, soetwas anzugehen - die Technik schreitet ja, wenn inzwischen auch langsamer, voran, und das U in UAE bezeichnete man ja auch mal als für "unusable" stehend.

    Zitat:
    Da läge es m.E. näher, AmigaOS 4 oder MorphOS gleich unter PearPC laufen zu lassen. [...] Nein, der Schlüssel zum "Erfolg" (dieses Wort nicht wörtlich nehmen) ist m.E., dass AmigaOS 4 und/oder MorphOS an eine attraktive Hardware angepasst werden.

    Naja, daß letzteres im Hinblick auf die jeweiligen OS-Entwickler Wunschdenken ist, bedarf ja eigentlich wohl keiner Erwähnung mehr.

    Und statt ersterem, wo ich dann (auf dem x86) alles nur in der Emulation vorliegen hätte, erschiene es mir sinnvoller, einen auf AROS (als Host (in der x86-Version) wie auch auszuführendes OS (hier dann in der PPC-Fassung)) maßgeschneiderten PPC-Emulator zu entwickeln und parallel dazu Team AROS Bounty #31 umzusetzen. Dann könnten MorphOS- und OS4-Binaries unter AROS laufen - und zwar nicht nur auf PPC-Rechnern, sondern auch auf x86ern. Wenn wir denn schonmal am träumen sind... :-)

    [ Dieser Beitrag wurde von Senex am 24.08.2005 um 17:51 Uhr editiert. ]

    [ - Antworten - Zitieren - Direktlink - ]
    24.08.2005, 18:07 Uhr

    CarstenS
    Posts: 5566
    Nutzer     		@Senex:
    > Wenn wir denn schonmal am träumen sind... :-)

    Das ist der springende Punkt. Ich denke, das würde deutlich mehr Entwicklungszeit beanspruchen als PearPC an AmigaOS 4/MorphOS anzupassen. Und bereits jetzt gibt es bei AROS noch so viel zu tun, dass ich nicht sehe, wie sich ein PPC-Emulator samt AmigaOS-4/MorphOS-Wrapper in absehbarer Zeit implementieren ließe.

    [ - Antworten - Zitieren - Direktlink - ]
    24.08.2005, 19:27 Uhr

    RoKo
    Posts: 72
    Nutzer
    Zitat:
    Original von Solar:
    Wieso meinst Du, das man sich in einem aufgebohrten UAE - oder in sonst irgendeinem PPC-Emulator - die MMU sparen könnte?
    Wieso meinst Du, dass ich das meine (abgesehen von Rosetta und vielleicht einer reinen WarpUp-Emu)?

    Zitat:
    Original von Holger:
    Nein.
    1. Es ist kein Marketingbegriff
    2. JIT ist KEIN HotSpot-Optimizer
    Zeig mir irgendeinen Artikel darüber, der nicht mit Java in Zusammenhang steht und Du hast mich überzeugt :)
    Aber nicht selber schreiben ;)
    Zitat:
    => UAE besitzt keine eingebauten Profiler
    Richtig. Sowas ist trotzdem nur eine Erweiterung eines JIT-Compilers und nix grundsätzlich anderes.
    Zitat:
    => UAE beherrscht keinen Mixed-Mode von Interpreter und JIT
    Falsch. Das kann so gut wie jeder JIT-Compiler, da man die üblicherweise aufbauend auf einem Interpreter entwickelt.
    Zitat:
    # loop-unrolling
    # Verschieben von conditionals
    # Anpassen der out-of-order execution an die andere Anzahl von Units
    # Umformen aller branch-Instruktionen, die das Link-Register benutzen (ja, selbst einfache Unterprogramme funktionieren auf ppc völlig anders...)
    Jup, das sind wieder die abgedrehten Sachen, die glaube kein Freeware-Emu macht :) Aber auch kein 68k-Emu. Mir scheint, wir sind vom Thema abgekommen.
    Zitat:
    Und wie man sieht, handelt es sich um genau so eine Folge arithmetischer Anweisungen, wie neg und decr, die man erkennen kann, nichts spezielles Register-Magisches.
    Jep, so habe ich das doch auch gemeint. Aber was Du anfangs geschrieben hast, hörte sich irgendwie komplizierter an, dann habe ich das wohl falsch interpretiert :)

    [ - Antworten - Zitieren - Direktlink - ]
    24.08.2005, 21:09 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von RoKo:
    Zitat:
    => UAE besitzt keine eingebauten Profiler
    Richtig. Sowas ist trotzdem nur eine Erweiterung eines JIT-Compilers und nix grundsätzlich anderes.
    Ein Profiler ist eine Erweiterung eines JIT-Compilers?
    Wie kommst Du denn darauf?
    Ein Profiler ist ein Stück Analyse-Software, das mit JIT nichts aber auch nichts zu tun hat.
    Nur weil es Leute gibt, die einen HotSpot-Optimizer entwickelt haben, der JIT und Profiler neben ein paar anderen wichtigen Komponenten verbindet, wird daraus keine "Erweiterung eines JIT-Compilers".
    Ein Netzteil ist auch keine Erweiterung eines PCs.
    Zitat:
    Zitat:
    => UAE beherrscht keinen Mixed-Mode von Interpreter und JIT
    Falsch. Das kann so gut wie jeder JIT-Compiler, da man die üblicherweise aufbauend auf einem Interpreter entwickelt.
    Aus der Anwesenheit von Interpreter und JIT-Compiler kann man noch nicht auf einen Mixed-Mode schließen. Unter Mixed-Mode verstehe ich eine Engine, die es auch ermöglicht, Code, der in einer Anwendung nur genau einmal ausgeführt wird, nicht zu übersetzen und natürlich auch nicht im Nachinein zu optimieren.
    Denn darum geht es beim HotSpot-Optimizer: Code der selten bis nie ausgeführt wird, gar nicht erst zu übersetzen, Code der manchmal aufgerufen wird, nur zu übersetzen und nur den Code, der oft aufgerufen wird mit aufwändigen Algorithmen zu optimieren.
    Zitat:
    Jup, das sind wieder die abgedrehten Sachen, die glaube kein Freeware-Emu macht :) Aber auch kein 68k-Emu. Mir scheint, wir sind vom Thema abgekommen.
    Nein, denn es ging darum, was man im Falle einer effizienten ppc-Emulation machen muß, das man (ganz richtig) bei einer 68k Emulation nicht macht.
    Der ppc ist eine Risc-Architektur, bei der das, was beim 68k eine Instruktion war, mitunter durch eine Sequenz von drei und mehr Befehlen ausgedrückt wird. Dabei geht man eben grundsätzlich von einer wesentlich schnelleren und parallelen Verarbeitung aus, die man in der Emulation ebenfalls erreichen muß. Da kann man es sich nicht erlauben, einzelne Befehle durch x86-Unterprogramme emulieren zu lassen, wie es bei der 68k-Emulation geschieht.
    Zitat:
    Jep, so habe ich das doch auch gemeint. Aber was Du anfangs geschrieben hast, hörte sich irgendwie komplizierter an, dann habe ich das wohl falsch interpretiert :)
    Es ist viel komplizierter - zumindest im Vergleich zu dem, was 68k-Emulatoren machen.

    mfg
    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]
    24.08.2005, 21:28 Uhr

    RoKo
    Posts: 72
    Nutzer
    Zitat:
    Ein Profiler ist eine Erweiterung eines JIT-Compilers?
    Ein Profiler, der als Erweiterung eines JIT-Compilers dient ist eine Erweiterung eines JIT-Compilers ;)
    Zitat:
    Aus der Anwesenheit von Interpreter und JIT-Compiler kann man noch nicht auf einen Mixed-Mode schließen. Unter Mixed-Mode verstehe ich eine Engine, die es auch ermöglicht, Code, der in einer Anwendung nur genau einmal ausgeführt wird, nicht zu übersetzen und natürlich auch nicht im Nachinein zu optimieren.
    Das machen auch viele JIT-Compiler. Üblicherweise wird dann einfach durchgezählt - wenn eine Stelle das vierte mal erreicht wird, wird kompiliert oder ähnliches.
    Zitat:
    Der ppc ist eine Risc-Architektur, bei der das, was beim 68k eine Instruktion war, mitunter durch eine Sequenz von drei und mehr Befehlen ausgedrückt wird.
    Okey, den Punkt nehme ich an :)
    Zitat:
    Es ist viel komplizierter - zumindest im Vergleich zu dem, was 68k-Emulatoren machen.
    Naaaja :)

    [ - Antworten - Zitieren - Direktlink - ]
    24.08.2005, 21:34 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von RoKo:
    Zeig mir irgendeinen Artikel darüber, der nicht mit Java in Zusammenhang steht und Du hast mich überzeugt :)
    Aber nicht selber schreiben ;)
    Ich geb Dir sogar Artikel, die nix mit Computern überhaupt zu tun haben:
    Zitat:
    http://en.wikipedia.org/wiki/Hotspot

    A hotspot is a center of high activity within a larger area of low activity. The term is applied to different things in different contexts
    Natürlich kannst Du die Entscheidung, diesen Begriff statt zum Beispiel Pareto principle oder einfach "bottleneck" zu verwenden, als Marketingentscheidung bezeichnen.
    Es ändert aber nichts daran, daß die Kombination von JIT-Compiler, Laufzeit-Profiler und selektivem Optimierer ein reales Produkt ist, das sich von einem einfachen JIT-Compiler mit Einwegoptimierung deutlich unterscheidet.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]
    24.08.2005, 21:45 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von RoKo:
    Zitat:
    Ein Profiler ist eine Erweiterung eines JIT-Compilers?
    Ein Profiler, der als Erweiterung eines JIT-Compilers dient ist eine Erweiterung eines JIT-Compilers ;)
    Er dient nicht als Erweiterung des JIT-Compilers. Die HotSpot-VM oder wie auch immer Du es nennen willst, benutzt sowohl Interpreter, JIT-Compiler, als auch den Profiler, um sein Ziel zu erreichen. Ein JIT-Compiler ist auch keine Erweiterung eines Interpreters.
    Zitat:
    Das machen auch viele JIT-Compiler. Üblicherweise wird dann einfach durchgezählt - wenn eine Stelle das vierte mal erreicht wird, wird kompiliert oder ähnliches.
    WinUAE machts trotzdem nicht.
    Und werfen die anderen JIT's, die Du im Sinn hast, den compilierten Code auch wieder weg, wenn das System feststellt, daß man unter den neuen Laufzeitbedingungen den Code besser interpretieren sollte?
    Übersetzen sie den Code unter Verwendung neuer Parameter neu?
    (Dann sind es HotSpot-Optimizer)
    Zitat:
    Zitat:
    Es ist viel komplizierter - zumindest im Vergleich zu dem, was 68k-Emulatoren machen.
    Naaaja :)
    Kompliziert genug, daß es bislang keine effizienten ppc-Emulatoren gibt.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]
    24.08.2005, 22:19 Uhr

    RoKo
    Posts: 72
    Nutzer
    Zitat:
    Ich geb Dir sogar Artikel, die nix mit Computern überhaupt zu tun haben:
    Dass es die gibt hatte ich auch schon erwähnt :) Gib mir einen Artikel mit "HotSpot-Optimizer" im hier beschriebenen Sinn und ohne Java.
    Zitat:
    Ein JIT-Compiler ist auch keine Erweiterung eines Interpreters.
    Hm, Ansichtssache. Der JIT-Compiler übernimmt immerhin meist die zentrale Rolle und degradiert eher den Interpreter zur Erweiterung. Durch die Einbeziehung eines Profilers u.s.w. sehe ich aber keine grundsätzliche Änderung der Programmstruktur des Emulators.
    Aber wir streiten nur noch um Begriffe, oder? Leider leicht sinnfrei.
    Zitat:
    Und werfen die anderen JIT's, die Du im Sinn hast, den compilierten Code auch wieder weg, wenn das System feststellt, daß man unter den neuen Laufzeitbedingungen den Code besser interpretieren sollte?
    Nö, das wäre doch komplett unsinnig. Was für Bedingungen sollten das denn sein (außer Speicher alle, dann wird er natürlich weggeworfen)?
    Zitat:
    Übersetzen sie den Code unter Verwendung neuer Parameter neu?
    Wohl keiner den ich kenne. Wie gesagt, die Freeware-JIT-Compiler sind alle nicht soooo fortgeschritten.
    Zitat:
    (Dann sind es HotSpot-Optimizer)
    Aha :)
    Zitat:
    Kompliziert genug, daß es bislang keine effizienten ppc-Emulatoren gibt.
    Nach Deinen Ansprüchen gibt es auch keinen effizienten 68k-Emulator ;)

    [ - Antworten - Zitieren - Direktlink - ]
    25.08.2005, 00:31 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von RoKo:
    Nö, das wäre doch komplett unsinnig. Was für Bedingungen sollten das denn sein (außer Speicher alle, dann wird er natürlich weggeworfen)?
    Das macht natürlich nur Sinn im Zusammenhang mit Optimierungen, wie z.B. inlining, conditional Verschieben usw.
    Stell Dir vor, einer System-Funktion wird ein CallBack-Hook übergeben, der sehr oft aufgerufen wird. Dann kann man durchaus eine Variante dieser Funktion erzeugen, in der die Hook-Funktion inlined wird. Sobald die System-Funktion mit einem anderen Hook oder gar nicht mehr aufgerufen wird, macht diese optimierte Fassung keinen Sinn mehr und kann weggeworfen werden.
    Oder nimm ein OS3.x System mit P96 oder CGX. In einem solchen System sind alle Routinen der graphics.library gepatcht und besitzen eine Verzweigung, abhängig davon, ob der RastPort/die BitMap zur Grafikkarte oder zum AGA-System gehört. Wenn jetzt ein Programm beginnt viel zu zeichnen, und schon ein typisches GUI mit den vielen dunklen und hellen Linien gehört dazu, lohnt es sich, diesen conditional code zu optimieren, in dem man die Überprüfung an den Anfang des Codes schiebt. Das heißt, vor einer größeren Anzahl von Aufrufen oder vor einer Schleife wird getestet und dann gleich in die richtigen Routinen verzweigt.
    Natürlich macht es keinen Sinn, alle Möglichkeiten zu übersetzen oder gar zu optimieren, wenn diese Abfrage immer das gleiche Resultat liefert. Es wird nur die Variante optimiert, die zutrifft - CGX/P96 oder AGA. Schlägt der vorgezogene Test fehl, weil der Benutzer z.B. den Screenmode wechselt, wird wieder in den Interpreter gesprungen. In dem Moment weiß der Emulator auch, daß diese optimierte Variante ein Löschkandidat ist, weil sie jetzt langsamer als der Interpreter ist, zumindest sobald sich herausstellt, daß nun die Bedingung in 100% der Fälle anders ist und sowieso wieder vom native-Code in den Interpreter gesprungen wird.
    Natürlich wird nicht einfach die andere Variante optimiert, sondern erstmal wieder abgewartet, wo die neuen HotSpots liegen, denn nach so einer radikalen Laufzeitänderung könnte sich auch ein ganz anderes Verhältnis von performancerelevanten Funktionen ergeben.
    Zitat:
    Zitat:
    Übersetzen sie den Code unter Verwendung neuer Parameter neu?
    Wohl keiner den ich kenne. Wie gesagt, die Freeware-JIT-Compiler sind alle nicht soooo fortgeschritten.
    Eben.
    Zitat:
    Zitat:
    Kompliziert genug, daß es bislang keine effizienten ppc-Emulatoren gibt.
    Nach Deinen Ansprüchen gibt es auch keinen effizienten 68k-Emulator ;)
    Was beim 68k-emu einen brauchbare Ergebnisse liefert, ist beim ppc-emu der Todesstoß. Wie gesagt, für 68k spielt es keine Rolle, da eine einzelne Instruktion schon wesentlich mehr bewirkt. Außerdem ist der Code im Vergleich zum Output eines ppc-Compilers anders organisiert.
    Und wenn ein x86 Rechner mit x MHz einen 68060 mit x/3 MHz emulieren kann, ist das ein gewaltiger Fortschritt im Vergleich zum Original.
    Wenn dann derselbe Rechner einen ppc604 mit x/6 MHz emulieren kann, ist das schon nicht mehr so brauchbar, insbesondere wenn die absolute Rechenleistung unter der des vergleichbaren 68k-Programms liegt.

    Das ist die Aussage, um die es in diesem Thread ging: ein ppc-Emulator für UAE macht keinen Sinn, wenn erstens die Geschwindigkeit nicht alltagstauglich (wobei das subjektiv ist), aber vor allem zweitens die Geschwindigkeit geringer als die 68k-Version des jeweiligen Programms ist.

    mfg
    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Antworten - Zitieren - Direktlink - ]
    25.08.2005, 09:34 Uhr

    Solar
    Posts: 3680
    Nutzer
    Zitat:
    Original von RoKo:
    Zitat:
    Original von Solar:
    Wieso meinst Du, das man sich in einem aufgebohrten UAE - oder in sonst irgendeinem PPC-Emulator - die MMU sparen könnte?
    Wieso meinst Du, dass ich das meine (abgesehen von Rosetta und vielleicht einer reinen WarpUp-Emu)?

    Nochmal: Wie kommst Du auf die Idee, Rosetta könne ohne MMU-Emulation funktionieren?

    Zitat:
    Original von Holger:
    Nein.
    1. [HotSpot] ist kein Marketingbegriff
    2. JIT ist KEIN HotSpot-Optimizer
    Zeig mir irgendeinen Artikel darüber, der nicht mit Java in Zusammenhang steht und Du hast mich überzeugt :)
    [/quote]

    Das ist alleine deshalb schon schwierig, weil Java die einzige Mainstream-Programmiersprache ist, die gleichzeitig Performancekritisch und Bytecode-basiert ist. Somit war und ist Java die Triebfeder für entsprechende Forschung (wie auch schon bei JIT, meines Wissens ebenfalls ein Kind der Java-Entwicklung).

    Aber hier hat's zum Beispiel eine Präsentation, die sich intensiv mit HotSpot-Technologie beschäftigt, aber kein Java erwähnt.



    [ Dieser Beitrag wurde von Solar am 25.08.2005 um 09:34 Uhr editiert. ]

    [ - Antworten - Zitieren - Direktlink - ]

    1 -2- 3 4 [ - Beitrag schreiben - ]


    amiga-news.de Forum > AROS und Amiga-Emulatoren > UAE mit PPC engine?? [ - Suche - Neue Beiträge - Registrieren - Login - ]


    .
    Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
    Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
    .