Discussion:
VPC 7 Audio/Video
(zu alt für eine Antwort)
Thomas Priegl
2005-04-22 21:57:57 UTC
Permalink
Hallo,

ich habe einen Mac mini 1,47 GHz. mit 512 MB und darauf Virtual PC 7 mit
Win XP.

Das ganze dient vornehmlich dem Zweck Lotus 1-2-3, mein Steuerprogramm
und Homebanking zu betreiben. Und das funktioniert auch ausreichend gut.

Nun habe ich bemerkt, dass VPC die CPU anscheinend recht gut emuliert.
In verschiedenen Benchmarks erreiche ich Werte wie ein PIII 500 - 700
MHz. (je nach Benchmark).

Also habe ich auch mal Audio (MIDI, MP3, WAV) und Video (kleine AVIs und
ähnliches) ausprobiert - die Performance ist miserabel. MP3s stocken
alle 5-10 Sekunden. MIDI ist unspielbar. Selbst kleine Videos bleiben
bis zu 20 Sekunden auf dem selben Bild stehen.

Was mich dabei nur wundert: Die CPU-Auslastung sowohl unter Windows im
Taskmanager als auch unter OS X in der Aktivitätsanzeige überschreitet
kaum mal die 80%. Meist liegt sie im Bereich von 60-70%, selbst bei
Videos. Was macht VPC also falsch? Er emuliert ja die Soundkarte und die
Grafikkarte im "Software-Modus", d.h. die CPU sollte die Hauptlast
tragen, oder?

Ist der Emulator an dieser Stelle einfach nur schlecht? Gibt es ein
prinzipielles Problem welches ich übersehen habe? Wie sieht es mit VPC
auf einem PowerMac mit zwei G5 aus? Kennt jemand eine Möglichkeit
Audio/Video unter VPC zu beschleunigen?

Das alles aus reiner Neugier, ich brauche nicht wirklich Audio/Video auf
dem Emulator.

CU
Thomas
--
What's the point of living if you can't feel alive? (Vivi)
Klaus Behrends
2005-04-23 08:14:24 UTC
Permalink
Post by Thomas Priegl
Hallo,
ich habe einen Mac mini 1,47 GHz. mit 512 MB und darauf Virtual PC 7 mit
Win XP.
... die Performance ist miserabel. MP3s stocken
alle 5-10 Sekunden.
G4 Dual 1,25 MHz:

Windows Media Player ruckelt erbärmlich bei mp3,
WinAmp gibt tadellos wieder.

Das war gelegentlich nützlich bei files, deren Wiedergabe unter MacOS
aus unerfindlichen Gründen nicht funktionierte.

Gruß Klaus
Basar Alabay
2005-04-23 11:40:42 UTC
Permalink
Post by Thomas Priegl
Virtual PC 7 mit
Win XP.
Wie macht man das da eigtentlich mit diesem "Freischalten"? Ich dachte,
so ein XP ist auf eine "Hardware" eingeschworen, wie ist das bei einer
Emulation und den Besonderheiten dabei, daß ja z.B. Zustände
zwischengespeichert werden?

B. Alabay
.
--
http://www.thetrial.de/
Thomas Priegl
2005-04-23 18:27:43 UTC
Permalink
Hi,

sorry, ging versehentlich als PM raus.
Post by Basar Alabay
Wie macht man das da eigtentlich mit diesem "Freischalten"? Ich dachte,
so ein XP ist auf eine "Hardware" eingeschworen, wie ist das bei einer
Emulation und den Besonderheiten dabei, daß ja z.B. Zustände
zwischengespeichert werden?
Gute Frage. Derzeit ignoriere ich die Registrierung noch.

Auf meinem alten PC ist XP registriert. Wenn ich nun diese Kopie lösche
und die neue auf dem Emulator freischalten lasse, dann müsste das
rechtlich eigentlich einwandfrei sein. Der Emulator stellt ja auch einen
virtuellen PC zur Verfügung, dessen Hardware sich nicht ändert. Also
müsste das freischalten wohl funktionieren, denke ich mal. Wenn die
Frist abläuft werde ich es wissen.

CU
Thomas
Benjamin Gawert
2005-04-23 22:22:05 UTC
Permalink
Post by Thomas Priegl
ich habe einen Mac mini 1,47 GHz. mit 512 MB und darauf Virtual PC 7
mit Win XP.
[snip]
Post by Thomas Priegl
Also habe ich auch mal Audio (MIDI, MP3, WAV) und Video (kleine AVIs
und ähnliches) ausprobiert - die Performance ist miserabel. MP3s
stocken alle 5-10 Sekunden. MIDI ist unspielbar. Selbst kleine Videos
bleiben bis zu 20 Sekunden auf dem selben Bild stehen.
Kein Wunder...
Post by Thomas Priegl
Was mich dabei nur wundert: Die CPU-Auslastung sowohl unter Windows im
Taskmanager als auch unter OS X in der Aktivitätsanzeige überschreitet
kaum mal die 80%. Meist liegt sie im Bereich von 60-70%, selbst bei
Videos. Was macht VPC also falsch? Er emuliert ja die Soundkarte und
die Grafikkarte im "Software-Modus", d.h. die CPU sollte die Hauptlast
tragen, oder?
Jein. Das Problem ist, dass VPC nur eine steinalte S3 Trio-Grafik (Jahrgang
in etwa um 1995) und AFAIK eine primitive Uralt-Soundblaster emuliert. Für
die Trio bietet Windowsxp nur einen unbeschleunigten Treiber an, was selbst
auf einem echten PC mit echter Trio zu Rucklern führt, da die Treiber
keinerlei Beschleunigung (DDraw, DirectShow etc) beherrschen...

Das Gute am S3 Trio ist, dass er von eigentlich jedem Betriebssystem
unterstützt wird - auch von vielen Exoten...

Benjamin
Michael Koenig
2005-04-24 11:54:05 UTC
Permalink
Post by Benjamin Gawert
Das Gute am S3 Trio ist, dass er von eigentlich jedem Betriebssystem
unterstützt wird - auch von vielen Exoten...
Dann kennst Du BeOS nicht... Da muß man mangels Treiber leider mit dem
VESA-Modus arbeiten, aber wenigstens läuft es inzwischen überhaupt, was
vor VPC7 auch nicht der Fall war.
Halbwegs funktionierenden Ton habe ich allerdings auch mit
unterschiedlichen Soundblaster-Treibern für BeOS nicht hinbekommen.
--
M.I.K.e
Michael Koenig
2005-04-24 12:35:52 UTC
Permalink
Post by Thomas Priegl
ich habe einen Mac mini 1,47 GHz. mit 512 MB und darauf Virtual PC 7 mit
Win XP.
Kleine Anmerkung am Anfang: Ich habe VPC7 mit Win 2000 und Win 98SE
laufen und habe dabei die Erfahrung gemacht, daß man den Sound unter Win
2000 so ziemlich vergessen kann (selbst der Startup-Sound stottert),
während ich unter Win 98 das Spiel "Grim Fandango" ohne Tonprobleme
durchgespielt habe.
Post by Thomas Priegl
Nun habe ich bemerkt, dass VPC die CPU anscheinend recht gut emuliert.
In verschiedenen Benchmarks erreiche ich Werte wie ein PIII 500 - 700
MHz. (je nach Benchmark).
Von Benchmarks auf Emulatoren rate ich generell ab:
* Die meisten arbeiten mit sog. synthetischen Benchmarks, die sich zur
Geschwindigkeitsabschätzung nicht einmal auf echter Hardware eignen
(mehr dazu kann man beispielsweise in den Büchern von John Hennessy und
David Patterson nachlesen).

* Irgendwie bezweifle ich, daß das Timing eines Emulators exakt genug
emuliert wird, um ein mit echten Systemen vergleichbares Ergebnis zu
liefern.

* Manche Benchmark-Programme sind einfach Schrott, anders kann ich es
gar nicht ausdrücken. Auf der offiziellen iEmulator-Seite wird in einem
Film ein Benchmark mit unglaublich hohen Resultaten ausgeführt. Ich habe
mir das gleiche Programm besorgt und habe selbst auf meinem 550MHz
Pentium 3 eine FPU-Geschwingigkeit von 3293,18 MHz bekommen...

* Benchmarks prüfen normalerweise nur die CPU-Geschwindigkeit, außer man
verwendet etwas wie 3DMark, das aber auf VPC mangels 3D-Emulation nicht
funktioniert.
In der Praxis bedeutet das, daß sich der Emulator während des Benchmarks
auf die CPU-Emulation konzentrieren kann, während Grafik- und
Sound-Emulation eigentlich gar nichts zu tun haben. Sobald man aber
Grafik und Sound hinzufügt, was bei Filmen definitiv der Fall ist, muß
sich die CPU-Emulation die Mac-Rechenzeit mit den restlichen
Hardware-Emulation teilen, weswegen die relative Geschwindigkeit stark
sinkt.

Dazu noch ein Vergleichswert:
Auf meinem 2GHz G5 läuft Grim Fandango unter Win 98SE tadellos, wie
schon oben angedeutet. Weswentlich aufwendiger dürfte das Spiel
allerdings nicht sein, da es anscheinend schon etwas an der Grenze ist.
Laut offizieller Angabe benötigt das Spiel einen 133MHz Pentium, d.h.
inklusive Grafik und Sound sinkt die relative CPU-Leistung wohl auf 150
bis 200 MHz ab.
Post by Thomas Priegl
Also habe ich auch mal Audio (MIDI, MP3, WAV) und Video (kleine AVIs und
ähnliches) ausprobiert - die Performance ist miserabel. MP3s stocken
alle 5-10 Sekunden. MIDI ist unspielbar. Selbst kleine Videos bleiben
bis zu 20 Sekunden auf dem selben Bild stehen.
Falls möglich, solltest Du mal Win 98 probieren (am besten mit 98Lite
abspecken, um noch mehr Geschwindigkeit zu bekommen), da Win XP aus
meiner Sicht für den Emulator einfach zu aufgeblasen ist. Selbst Win
2000 fühlt sich auf dem Emulator deutlich langsamer an und das ist noch
nicht so schlimm wie Win XP.
Laut einigen anderen Benutzern soll Win NT4 auf VPC am schnellsten sein,
was ich aber mangels NT4 nicht selber nachprüfen kann. Für Grafik und
Sound ist Win 98 aber eventuell besser geeignet.
Man könnte meinen, daß Win 95 noch schneller sein sollte, was zumindest
beim Booten definitiv stimmt, aber es gibt da irgendwelche
Treiberprobleme, weswegen der Sound stottert und die Grafik bei
aufwendigeren Programmen nur sporadisch funktioniert. Da scheinen sich
die 98-Treiber mit VPC deutlich besser zu verstehen.
Post by Thomas Priegl
Was mich dabei nur wundert: Die CPU-Auslastung sowohl unter Windows im
Taskmanager als auch unter OS X in der Aktivitätsanzeige überschreitet
kaum mal die 80%. Meist liegt sie im Bereich von 60-70%, selbst bei
Videos. Was macht VPC also falsch? Er emuliert ja die Soundkarte und die
Grafikkarte im "Software-Modus", d.h. die CPU sollte die Hauptlast
tragen, oder?
Vielleicht hat man eine Bremse eingebaut, daß VPC sich nicht zu viel
Rechenzeit auf dem Mac schnappt?
Bezüglich der Aktivitiät im Windows-Taskmanager kann ich nur
spekulieren, daß die Anzeige entweder nicht ganz korrekt ist oder der
Flaschenhals bei dieser Anwendung eben nicht bei der CPU-Emulation
sondern bei Grafik und/oder Sound liegt.
Post by Thomas Priegl
Ist der Emulator an dieser Stelle einfach nur schlecht?
Der Emulator wird einfach langsamer, je mehr Hardware er emulieren muß.
Post by Thomas Priegl
Gibt es ein prinzipielles Problem welches ich übersehen habe?
Den Mehraufwand, den Win XP für VPC darstellt. Ich würde es definitiv
nicht einsetzen. Aber es ist mal wieder typisch Microsoft, XP
durchzudrücken, auch wenn es in diesem Fall nicht besonders geeignet ist.
Ich habe mir VPC auch nur mit Win 2000 gekauft, für den Fall, daß ich
ein NT-basiertes Programm ausführen oder USB verwenden muß. Ansonsten
verwende ich eigentlich ausschließlich Win 98SE, bei dem ich mittels
98Lite den Internet Explorer entfernt und den Windows Explorer durch den
aus Win 95 ersetzt habe.
Post by Thomas Priegl
Wie sieht es mit VPC auf einem PowerMac mit zwei G5 aus?
Nachdem VPC7 entgegen der Ankündigungen die Dual-Prozessoren immer noch
nicht richtig ausreizt, ist es dort auch nicht wirklich besser. Der G5
hat sogar den Nachteil, daß die Endian-Konvertierungen nicht mehr über
den Bus laufen, sondern über explizite Instruktionen ablaufen müssen.
Der Hauptvorteil des G5 dürften vor allem der schnellere Bus und die
schnellere Festplatte sein.
Post by Thomas Priegl
Kennt jemand eine Möglichkeit Audio/Video unter VPC zu beschleunigen?
Außer Win 98 statt XP einzusetzen, fällt mir jetzt pauschal nichts ein.
Ich denke mal, die VM-Extensions sollten ja installiert sein.
--
M.I.K.e
Thomas Priegl
2005-04-24 13:58:43 UTC
Permalink
Hallo,
Post by Michael Koenig
* Die meisten arbeiten mit sog. synthetischen Benchmarks, die sich zur
Geschwindigkeitsabschätzung nicht einmal auf echter Hardware eignen
(mehr dazu kann man beispielsweise in den Büchern von John Hennessy und
David Patterson nachlesen).
Ich habe mit "Super Pi" den Wert der Zahl Pi auf 1 Mio. Stellen genau
berechnen lassen.
Post by Michael Koenig
* Irgendwie bezweifle ich, daß das Timing eines Emulators exakt genug
emuliert wird, um ein mit echten Systemen vergleichbares Ergebnis zu
liefern.
Möglich. Es ging mir mehr darum einen Eindruck zu bekommen, keine
exakten Zahlen. Das problem bei VPC ist IMHO, dass durch die schlechte
Grafikleistung das System langsamer wirkt als es eigentlich ist.
Post by Michael Koenig
* Manche Benchmark-Programme sind einfach Schrott, anders kann ich es
gar nicht ausdrücken. Auf der offiziellen iEmulator-Seite wird in einem
Film ein Benchmark mit unglaublich hohen Resultaten ausgeführt. Ich habe
mir das gleiche Programm besorgt und habe selbst auf meinem 550MHz
Pentium 3 eine FPU-Geschwingigkeit von 3293,18 MHz bekommen...
Als synthetischen Benchmark habe ich SiSoft Sandra verwendet. Das
Ergebnis dort erscheint mir aber in der Tat zu hoch zu sein.
Post by Michael Koenig
* Benchmarks prüfen normalerweise nur die CPU-Geschwindigkeit, außer man
verwendet etwas wie 3DMark, das aber auf VPC mangels 3D-Emulation nicht
funktioniert.
Exakt.
Post by Michael Koenig
In der Praxis bedeutet das, daß sich der Emulator während des Benchmarks
auf die CPU-Emulation konzentrieren kann, während Grafik- und
Sound-Emulation eigentlich gar nichts zu tun haben. Sobald man aber
Grafik und Sound hinzufügt, was bei Filmen definitiv der Fall ist, muß
sich die CPU-Emulation die Mac-Rechenzeit mit den restlichen
Hardware-Emulation teilen, weswegen die relative Geschwindigkeit stark
sinkt.
Natürlich.
Post by Michael Koenig
Auf meinem 2GHz G5 läuft Grim Fandango unter Win 98SE tadellos, wie
schon oben angedeutet. Weswentlich aufwendiger dürfte das Spiel
allerdings nicht sein, da es anscheinend schon etwas an der Grenze ist.
Laut offizieller Angabe benötigt das Spiel einen 133MHz Pentium, d.h.
inklusive Grafik und Sound sinkt die relative CPU-Leistung wohl auf 150
bis 200 MHz ab.
Verständlich, da ja die Fähigkeiten z.B. der Radeon in meinem Mac mini
gar nicht genutzt werden. Bis vor ca. 1,5 Jahren hatte ich in meinem PC
eine Viper 550 mit Riva TNT1. So etwas würde ich mir vom Emulator
wünschen (und ich weiß, wird ein Traum bleiben).
Post by Michael Koenig
Falls möglich, solltest Du mal Win 98 probieren (am besten mit 98Lite
abspecken, um noch mehr Geschwindigkeit zu bekommen), da Win XP aus
meiner Sicht für den Emulator einfach zu aufgeblasen ist. Selbst Win
2000 fühlt sich auf dem Emulator deutlich langsamer an und das ist noch
nicht so schlimm wie Win XP.
OK. Ich habe noch in irgend einer Kiste Win 98 (erste Version). Hatte
nur gelesen, dass die Extensions von VPC Win 98 nicht mehr unterstützen
und deswegen Win XP verwendet. Win 2000 habe ich nicht. NT 4.0 könnte
ich noch versuchen.
Post by Michael Koenig
Laut einigen anderen Benutzern soll Win NT4 auf VPC am schnellsten sein,
was ich aber mangels NT4 nicht selber nachprüfen kann. Für Grafik und
Sound ist Win 98 aber eventuell besser geeignet.
Denke ich auch. Ich werde bei Gelegenheit mal ein wenig herumspielen. Es
geht mir ja auch nur darum, denn alles was ich wirklich mit dem Emulator
machen muss, das funktioniert auch mit XP schon recht gut.
Post by Michael Koenig
Man könnte meinen, daß Win 95 noch schneller sein sollte, was zumindest
beim Booten definitiv stimmt, aber es gibt da irgendwelche
Treiberprobleme, weswegen der Sound stottert und die Grafik bei
aufwendigeren Programmen nur sporadisch funktioniert. Da scheinen sich
die 98-Treiber mit VPC deutlich besser zu verstehen.
Win 95 hat mir nie gefallen. Das versuche ich erst gar nicht. Booten
will ich den VPC eh nicht.
Post by Michael Koenig
Vielleicht hat man eine Bremse eingebaut, daß VPC sich nicht zu viel
Rechenzeit auf dem Mac schnappt?
Nein, definitiv nicht. Mit Super Pi oder ähnlichen CPU-intensiven
Aufgaben bekomme ich den Taskmanager auf 100% und die Aktivitätsanzeige
bis zum Anschlag und mein Mac mini dreht den Lüfter auf als wäre er kurz
vor dem durchbrennen. ;-)
Post by Michael Koenig
Bezüglich der Aktivitiät im Windows-Taskmanager kann ich nur
spekulieren, daß die Anzeige entweder nicht ganz korrekt ist oder der
Flaschenhals bei dieser Anwendung eben nicht bei der CPU-Emulation
sondern bei Grafik und/oder Sound liegt.
Ja. Aber das wundert mich eben ein wenig. Wenn die Grafik und Sound
nicht Hardwarebeschleunigt werden, dann müsste es eigentlich alles die
CPU berechnen. Und die sollte IMHO dann auch auf Anschlag stehen.
Post by Michael Koenig
Der Emulator wird einfach langsamer, je mehr Hardware er emulieren muß.
Ja, das ist ein Punkt.
Post by Michael Koenig
Den Mehraufwand, den Win XP für VPC darstellt. Ich würde es definitiv
nicht einsetzen. Aber es ist mal wieder typisch Microsoft, XP
durchzudrücken, auch wenn es in diesem Fall nicht besonders geeignet ist.
:-)
Post by Michael Koenig
Ich habe mir VPC auch nur mit Win 2000 gekauft, für den Fall, daß ich
ein NT-basiertes Programm ausführen oder USB verwenden muß. Ansonsten
verwende ich eigentlich ausschließlich Win 98SE, bei dem ich mittels
98Lite den Internet Explorer entfernt und den Windows Explorer durch den
aus Win 95 ersetzt habe.
Ich werde das auch mal testen.
Post by Michael Koenig
Nachdem VPC7 entgegen der Ankündigungen die Dual-Prozessoren immer noch
nicht richtig ausreizt, ist es dort auch nicht wirklich besser. Der G5
hat sogar den Nachteil, daß die Endian-Konvertierungen nicht mehr über
den Bus laufen, sondern über explizite Instruktionen ablaufen müssen.
Der Hauptvorteil des G5 dürften vor allem der schnellere Bus und die
schnellere Festplatte sein.
Mal aus reiner Neugier: Auf einem Dual G5: Emuliert VPC da zwei x86-CPUs
oder nur eine? Win 2000 sollte ja eigentlich zwei unterstützen, oder XP
natürlich auch.
Post by Michael Koenig
Außer Win 98 statt XP einzusetzen, fällt mir jetzt pauschal nichts ein.
Ich denke mal, die VM-Extensions sollten ja installiert sein.
Sind sie (unter XP). Für Win 98 werden sie angeblich bei VPC 7 nicht
mehr angeboten. Habe ich aber noch nicht versucht.

CU
Thomas
Michael Koenig
2005-04-24 18:15:12 UTC
Permalink
Post by Thomas Priegl
Ich habe mit "Super Pi" den Wert der Zahl Pi auf 1 Mio. Stellen genau
berechnen lassen.
Die Zahl der Instruktionen, die dafür tatsächlich verwendet werden,
dürfte ziemlich gering sein. Das ist eben ein Problem der synthetischen
Benchmarks, es wird eigentlich nur ein Teil des Instruktionssatzes
genutzt und dann noch bei einem Sandkasten-Problem. Daraus kann man
schon auf einer echten Hardware kaum eine Aussage über die generelle
Geschwindigkeit machen, bei einem Emulator wir das dann noch
problematischer.
Post by Thomas Priegl
Möglich. Es ging mir mehr darum einen Eindruck zu bekommen, keine
exakten Zahlen. Das problem bei VPC ist IMHO, dass durch die schlechte
Grafikleistung das System langsamer wirkt als es eigentlich ist.
Dadurch daß die Grafik komplett emuliert werden muß, schluckt sie
einiges an Rechenzeit und mit größeren Auflösungen nimmt das natürlich
noch zu, weil die zu verarbeitende Datenmenge einfach drastisch steigt.
Post by Thomas Priegl
Als synthetischen Benchmark habe ich SiSoft Sandra verwendet. Das
Ergebnis dort erscheint mir aber in der Tat zu hoch zu sein.
Ich bin mir nicht mehr sicher, was ich mal verwendet habe, aber
angeblich wäre VPC danach schneller als mein echter PC, was definitiv
nicht der Fall ist, selbst wenn es nur um reine Prozessorleistung geht.
Interessanter ist aber die Festplatte trotz Emulation deutlich schneller
als bei meinem PC, liegt aber daran, daß der veraltet ist und der G5 mit
SATA arbeitet.
Post by Thomas Priegl
Verständlich, da ja die Fähigkeiten z.B. der Radeon in meinem Mac mini
gar nicht genutzt werden. Bis vor ca. 1,5 Jahren hatte ich in meinem PC
eine Viper 550 mit Riva TNT1. So etwas würde ich mir vom Emulator
wünschen (und ich weiß, wird ein Traum bleiben).
Wenn Du ältere Ankündigungen zu VPC7 nachverfolgst, wirst Du
feststellen, daß Microsoft offensichtlich eine Hardwarebeschleunigung in
Arbeit hatte, sie aber wegen mangelnder Stabilität wohl wieder ausgebaut
hat.
Es wäre natürlich auch möglich, daß die Reporter etwas falsch verstanden
haben und die Beschleunigung der Bildschirmdarstellung durch
QuartzExtreme als Hardwarebeschleunigung auf der PC-Seite aufgefaßt haben...
Prinzipiell halte ich eine 3D-Beschleunigung nicht für unmöglich, sei es
nun auf API-Ebene oder als Abarbeitung von Display-Lists (wie es bei der
Emulation von Spielekonsolen schon fast normal ist), also würde ich
nicht komplett ausschließen, daß es dieses Feature irgendwann geben könnte.
Post by Thomas Priegl
Ja. Aber das wundert mich eben ein wenig. Wenn die Grafik und Sound
nicht Hardwarebeschleunigt werden, dann müsste es eigentlich alles die
CPU berechnen. Und die sollte IMHO dann auch auf Anschlag stehen.
Ich bin mir jetzt nicht ganz sicher, ob sich die CPU-Anzeige von VPC auf
die PC- oder Mac-CPU bezieht...
Post by Thomas Priegl
Mal aus reiner Neugier: Auf einem Dual G5: Emuliert VPC da zwei x86-CPUs
oder nur eine?
Nein, es wird immer nur eine CPU emuliert. Wie viele CPUs man emuliert
hängt sowieso nicht davon ab, wie viele CPUs im Rechner stecken. Wenn
die emulierten CPUs synchron laufen sollen, müssen sie meiner Ansicht
nach ohnehin im gleichen Thread laufen, d.h. es wäre allenfalls als
Testfall interessant, würde aber keinerlei Beschleunigung bieten,
sondern der zusätzliche Verwaltungsaufwand würde den Emulator langsamer
machen.
Die verbesserte Unterstützung von Dual-Prozessoren bezog sich bei VPC
darauf, daß Grafik und Sound verstärkt in eigene Threads ausgelagert
werden, damit sie auf einem anderen Prozessor als die CPU-Emulation
laufen könnten. Das war für VPC7 eigentlich auch angekündigt, wurde aber
wohl nur teilweise, wenn überhaupt, in Angriff genommen.

[VM-Extionsions]
Post by Thomas Priegl
Sind sie (unter XP). Für Win 98 werden sie angeblich bei VPC 7 nicht
mehr angeboten. Habe ich aber noch nicht versucht.
Sie werden nicht "unterstützt" (im Info-Fenster steht dann auch
knallrot: "Unsupported Configuration"), aber die VM-Extensions für Win
98 sind definitiv noch vorhanden und funktionieren auch.
Im ReadMe ist übrigens auch explizit erwähnt, daß BeOS nicht unterstütz
wird, dabei ist VPC7 die erste Version, in der BeOS benutzbar läuft.
--
M.I.K.e
Thomas Priegl
2005-04-24 18:28:04 UTC
Permalink
Hallo,
Post by Michael Koenig
Die Zahl der Instruktionen, die dafür tatsächlich verwendet werden,
dürfte ziemlich gering sein. Das ist eben ein Problem der synthetischen
Benchmarks, es wird eigentlich nur ein Teil des Instruktionssatzes
genutzt und dann noch bei einem Sandkasten-Problem. Daraus kann man
schon auf einer echten Hardware kaum eine Aussage über die generelle
Geschwindigkeit machen, bei einem Emulator wir das dann noch
problematischer.
Zumindest wird ein reales Ergebnis berechnet. :-)
Post by Michael Koenig
Dadurch daß die Grafik komplett emuliert werden muß, schluckt sie
einiges an Rechenzeit und mit größeren Auflösungen nimmt das natürlich
noch zu, weil die zu verarbeitende Datenmenge einfach drastisch steigt.
Ja. Ich fahre Win XP in 1024x768.
Post by Michael Koenig
Ich bin mir nicht mehr sicher, was ich mal verwendet habe, aber
angeblich wäre VPC danach schneller als mein echter PC, was definitiv
nicht der Fall ist, selbst wenn es nur um reine Prozessorleistung geht.
Interessanter ist aber die Festplatte trotz Emulation deutlich schneller
als bei meinem PC, liegt aber daran, daß der veraltet ist und der G5 mit
SATA arbeitet.
Da verliert der Mac mini dank Notebookplatte natürlich.
Post by Michael Koenig
Wenn Du ältere Ankündigungen zu VPC7 nachverfolgst, wirst Du
feststellen, daß Microsoft offensichtlich eine Hardwarebeschleunigung in
Arbeit hatte, sie aber wegen mangelnder Stabilität wohl wieder ausgebaut
hat.
Schade. Wäre ein interessantes Feature.
Post by Michael Koenig
Es wäre natürlich auch möglich, daß die Reporter etwas falsch verstanden
haben und die Beschleunigung der Bildschirmdarstellung durch
QuartzExtreme als Hardwarebeschleunigung auf der PC-Seite aufgefaßt haben...
Prinzipiell halte ich eine 3D-Beschleunigung nicht für unmöglich, sei es
nun auf API-Ebene oder als Abarbeitung von Display-Lists (wie es bei der
Emulation von Spielekonsolen schon fast normal ist), also würde ich
nicht komplett ausschließen, daß es dieses Feature irgendwann geben könnte.
Wemm, dann wahrscheinlich nicht als kostenloses Update, befürchte ich.
Post by Michael Koenig
Ich bin mir jetzt nicht ganz sicher, ob sich die CPU-Anzeige von VPC auf
die PC- oder Mac-CPU bezieht...
Gute Frage. Das wäre dann die dritte Anzeige. Aber auch die ist bei Pi
am Anschlag und bei Videos nicht.
Post by Michael Koenig
Nein, es wird immer nur eine CPU emuliert. Wie viele CPUs man emuliert
hängt sowieso nicht davon ab, wie viele CPUs im Rechner stecken. Wenn
die emulierten CPUs synchron laufen sollen, müssen sie meiner Ansicht
nach ohnehin im gleichen Thread laufen, d.h. es wäre allenfalls als
Testfall interessant, würde aber keinerlei Beschleunigung bieten,
sondern der zusätzliche Verwaltungsaufwand würde den Emulator langsamer
machen.
Die Frage ist: Läuft der emulierte PC nur auf einer CPU oder können die
Threads, welche in XP auf dem VPC laufen auf beide CPUs verteilt werden?

Ich kann mir im Moment gar nicht vorstellen wie eine Verteilung von
Win-Threads auf die CPUs erfolgen könnte, ohne dass Win von zwei CPUs
ausgeht.

Man könnte alternativ vielleicht zwei Win-Instanzen parallel betreiben,
aber das ist ja nicht der Sinn der Sache. :-)
Post by Michael Koenig
Die verbesserte Unterstützung von Dual-Prozessoren bezog sich bei VPC
darauf, daß Grafik und Sound verstärkt in eigene Threads ausgelagert
werden, damit sie auf einem anderen Prozessor als die CPU-Emulation
laufen könnten. Das war für VPC7 eigentlich auch angekündigt, wurde aber
wohl nur teilweise, wenn überhaupt, in Angriff genommen.
OK. Das bezieht sich auf VPC-Threads, welche in MacOS laufen. Aber Win
wäre immer noch auf eine CPU beschränkt.
Post by Michael Koenig
Sie werden nicht "unterstützt" (im Info-Fenster steht dann auch
knallrot: "Unsupported Configuration"), aber die VM-Extensions für Win
98 sind definitiv noch vorhanden und funktionieren auch.
Wo sind sie voerhanden?
Post by Michael Koenig
Im ReadMe ist übrigens auch explizit erwähnt, daß BeOS nicht unterstütz
wird, dabei ist VPC7 die erste Version, in der BeOS benutzbar läuft.
Das habe ich gelesen. Muß das mal wieder rauskramen und versuchen zum
laufen zu bringen.

CU
Thomas
Michael Koenig
2005-04-24 19:08:55 UTC
Permalink
Post by Thomas Priegl
Die Frage ist: Läuft der emulierte PC nur auf einer CPU oder können die
Threads, welche in XP auf dem VPC laufen auf beide CPUs verteilt werden?
Windows-Threads lassen sich nicht einfach in OSX-Threads umwandeln. Die
einzige Aufteilung, die beim Emulator aus meiner Sicht möglich ist, wäre
die Hardware-Emulation in Threads auszulagern, damit der Scheduler diese
auf verschiedene Prozessoren verteilen kann.
Post by Thomas Priegl
Ich kann mir im Moment gar nicht vorstellen wie eine Verteilung von
Win-Threads auf die CPUs erfolgen könnte, ohne dass Win von zwei CPUs
ausgeht.
Selbst dann wäre es wahrscheinlich ohne extremen Mehraufwand, wie
separate Code-Caches wahrscheinlich nicht möglich. Das wiederum würde
aber bedeuten, daß nicht nur der Speicherverbrauch steigt, sondern daß
Code eventuell doppelt übersetzt werden muß, was sich auch wieder
negativ auf die Geschwindigkeit auswirkt.

Da Emulatoren mit dynamischer Recompilierung blockorientiert und nicht
mit einzelnen Instruktionen arbeiten, halte ich es ohnehin für fraglich,
ob man mit dieser Methode eine SMP-Maschine zuverlässig emulieren könnte.
Post by Thomas Priegl
OK. Das bezieht sich auf VPC-Threads, welche in MacOS laufen. Aber Win
wäre immer noch auf eine CPU beschränkt.
Ich wüßte auch nicht, was emuliertem Windows mehr als eine CPU bringen
sollte. Das Hauptanliegen eines Emulators aus meiner Sicht ist, eine
Applikation so schnell und zuverlässig wie möglich ablaufen zu lassen.
Wenn man die Emulation von Grafik und Sound auf einen Prozessor
auslagern könnte, daß die CPU-Emulation quasi einen Prozessor für sich
alleine hätte, wäre das eine deutlich bessere Beschleunigung.

Das was Dir vorschwebt, klingt für mich mehr nach einem Simulator als
einem Emulator und in dem Fall hat man ein eher langsames Resultat.

[VM-Extionsions für Win 98]
Post by Thomas Priegl
Wo sind sie voerhanden?
Zuerst mußt Du das Betriebssystem installieren und dann in VPC folgendes
Menü (könnte bei der eventuell Deutsch sein) auswählen:
PC > Install or Update Additions

Dadurch sollte VPC ein Image mounten und automatisch den Installer für
die VM-Extensions ausführen.

[BeOS auf VPC7]
Post by Thomas Priegl
Das habe ich gelesen. Muß das mal wieder rauskramen und versuchen zum
laufen zu bringen.
Die Installation solltest Du am besten mit Tastatursteuerung
durchführen, da die Maus im Graustufenmodus extrem hüpft. Nach der
Installation dann VESA aktivieren, am einfachsten mit VESA Accepted.
Sound bekommt man leider nicht wirklich zum laufen, aber die emulierte
Netzwerkkarte wird automatisch erkannt.
Es läuft nicht gerade umwerfend schnell, aber zumindest kann man es
jetzt benutzen, was vor VPC7 gar nicht funktionierte.
--
M.I.K.e
Thomas Priegl
2005-04-24 19:52:15 UTC
Permalink
Hallo,
Post by Michael Koenig
Windows-Threads lassen sich nicht einfach in OSX-Threads umwandeln. Die
einzige Aufteilung, die beim Emulator aus meiner Sicht möglich ist, wäre
die Hardware-Emulation in Threads auszulagern, damit der Scheduler diese
auf verschiedene Prozessoren verteilen kann.
Hm ...
Post by Michael Koenig
Selbst dann wäre es wahrscheinlich ohne extremen Mehraufwand, wie
separate Code-Caches wahrscheinlich nicht möglich. Das wiederum würde
aber bedeuten, daß nicht nur der Speicherverbrauch steigt, sondern daß
Code eventuell doppelt übersetzt werden muß, was sich auch wieder
negativ auf die Geschwindigkeit auswirkt.
Warum sollte der Code doppelt übersetzt werden müssen? Eine JVM kann
auch beliebig viele Threads parallel ausführen, aber deswegen muß
Hotspot meines Wissens den selben Code nicht mehrfach übersetzen (z.B.
wenn eine Klasse in zwei Threads verwendet wird). Oder ist das hier
grundlegend anders?

BTW: Übersetzt VPC alles im voraus in nativen G4/G5 Code (analog eines
Java Just in Time Compilers) oder macht VPC auch eine Analyse wie
Hotspot, übersetzt erst nach n durchläufen und interpretiert vorher?
Post by Michael Koenig
Da Emulatoren mit dynamischer Recompilierung blockorientiert und nicht
mit einzelnen Instruktionen arbeiten, halte ich es ohnehin für fraglich,
ob man mit dieser Methode eine SMP-Maschine zuverlässig emulieren könnte.
Hm ... ein Emulator übersetzt x86 Maschinencode in G4/G5 Maschinencode.
Eine JVM übersetzt Java Bytecode in x86 bzw. G4/G5 Maschinencode. Ich
kenne mich da wirklich nicht gut aus, aber wo ist der große Unterschied?
Post by Michael Koenig
Ich wüßte auch nicht, was emuliertem Windows mehr als eine CPU bringen
sollte.
Na hoffentlich das selbe wie einem Windows auf realer Hardware. :-)
Post by Michael Koenig
Das Hauptanliegen eines Emulators aus meiner Sicht ist, eine
Applikation so schnell und zuverlässig wie möglich ablaufen zu lassen.
Jein. Ich würde sagen, er sollte n Applikationen parallel so schnell wie
möglich ablaufen lassen. Ich arbeite extrem selten nur mit einer
Applikation.
Post by Michael Koenig
Wenn man die Emulation von Grafik und Sound auf einen Prozessor
auslagern könnte, daß die CPU-Emulation quasi einen Prozessor für sich
alleine hätte, wäre das eine deutlich bessere Beschleunigung.
Absolut ja!
Post by Michael Koenig
Das was Dir vorschwebt, klingt für mich mehr nach einem Simulator als
einem Emulator und in dem Fall hat man ein eher langsames Resultat.
Nein, das will ich nicht. :-)
Post by Michael Koenig
Zuerst mußt Du das Betriebssystem installieren und dann in VPC folgendes
PC > Install or Update Additions
Dadurch sollte VPC ein Image mounten und automatisch den Installer für
die VM-Extensions ausführen.
Ja. So ist es auch unter XP. Aber ich habe gelesen, dass in VPC 7 eben
dies für Win 98 nicht mehr unterstützt werden soll.
Post by Michael Koenig
Die Installation solltest Du am besten mit Tastatursteuerung
durchführen, da die Maus im Graustufenmodus extrem hüpft. Nach der
Installation dann VESA aktivieren, am einfachsten mit VESA Accepted.
Sound bekommt man leider nicht wirklich zum laufen, aber die emulierte
Netzwerkkarte wird automatisch erkannt.
Es läuft nicht gerade umwerfend schnell, aber zumindest kann man es
jetzt benutzen, was vor VPC7 gar nicht funktionierte.
Schade. Gerade die unglaubliche Performance von BeOS hat mich damals
begeistert. Sonst konnte man damit ja nicht soviel machen. ;-)

CU
Thomas
Michael Koenig
2005-04-25 18:49:49 UTC
Permalink
Post by Thomas Priegl
Warum sollte der Code doppelt übersetzt werden müssen?
Stimmt, ist irgendwie Blödsinn, aber ich versuche gedanklich dem Problem
der Synchronisation der beiden emulierten CPUs aus dem Weg zu gehen.
Aber meiner Ansicht nach lassen sich mehrere emulierte CPUs eben nur
ansprechend synchronisieren, wenn sie im gleichen Thread emuliert
werden. Ich kann mich natürlich auch täuschen...

Wenn die Emulation von einem Dual-Prozessor, insbesondere mit
dynamischer Recompilierung, halbwegs einfach wäre, dann gäbe es meiner
Ansicht nach deutlich mehr Sega-Saturn-Emulatoren. Der SH-2 ist
eigentlich vergleichsweise trivial, aber die Tatsache, daß der Saturn
gleich zwei davon hat, macht die Emulation der Hardware deutlich
aufwendiger.
Post by Thomas Priegl
Eine JVM kann auch beliebig viele Threads parallel ausführen
Der Unterschied bei Java ist aber, daß Du nicht mehrere VMs hast,
sondern Threading durch die Thread-Klasse und nötige Synchronisation im
Bytecode durch monitorenter und monitorexit gesteuert werden.
Das ist etwas komplett anderes, als zwei reele Prozessoren in
unterschiedlichen Threads mit dynamischer Recompilierung zu emulieren
und dann noch zu versuchen, beide so zu synchronisieren, daß sich das
ganze dann wie ein SMP-System verhält.

Eine andere Idee von Dir war ja, die Windows-Threads quasi in
Emulations-Threads zu übertragen, aber dadurch würde der Emulator so
stark auf Windows (und wahrscheinlich nur XP, da es bei jeder Version
etwas anders sein dürfte) angepaßt, daß es kein PC-Emulator wäre.
In dem Fall wäre es dann besser, nur die CPU-Emulation zu nehmen, mit
einem PE-Loader zu kombinieren und die Win-API auf OSX zu portieren. Da
hätte außerdem den Nebeneffekt, daß man sich bis auf die CPU die
Hardwareemulation spart und die API nativ läuft. Und so ein Projekt ist
schließlich in Arbeit:
<http://darwine.opendarwin.org/>
Post by Thomas Priegl
BTW: Übersetzt VPC alles im voraus in nativen G4/G5 Code (analog eines
Java Just in Time Compilers)
Nein, das wäre definitiv zu langsam und würde zu noch längeren
Wartezeiten beim Start eines Programms führen, als das bei einem Java
JIT-Compiler der Fall war. Mal abgesehen davon, daß man bei einem echten
Maschinenprogramm nicht immer eindeutig entscheiden kann, was jetzt
wirklich alles Code ist.

Wie die meisten Emulatoren mit dynamischer Recompilierung arbeitet VPC
mit sog. Basisblöcken ("basic blocks"). Dieser aus der
Compileroptimierung bekannte Terminus bezeichnet eine Folge von
Instruktionen, die immer sequenziell ausgeführt wird, oder anders
ausgedrückt, ein Basisblock reicht von einem Einsprungpunkt bis zur
nächsten Verzweigung.
Sobald eine Adresse angesprungen werden soll, für die noch keine
Entsprechung im Translation-Cache vorliegt, wird der Basisblock ab
dieser Adresse übersetzt, die Übersetzung in den Cache gehängt und
danach angesprungen.
Dazu noch ein kleiner Artikel des Entwicklers:
<http://www.byte.com/art/9711/sec4/art4.htm>
Post by Thomas Priegl
oder macht VPC auch eine Analyse wie
Hotspot, übersetzt erst nach n durchläufen und interpretiert vorher?
Pauschal fällt mir nur ein in der Praxis eingesetzter
Binärcode-Übersetzer ein, der vorher einen Durchlauf mit Interpreter und
Profiler machte. Die Rede ist von FX!32, dem x86-Emulator für
WinNT/Alpha, der allerdings keine dynamische sondern eine statische
Übersetzung macht, die erst nach der Laufzeit erzeugt wird und dann für
den nächsten Durchlauf in einer Datenbank gespeichert wird.
Nach meinen Informationen sind die Profile-Informationen, die während
der Interpretation gesammelt werden, auch nicht gerade berauschend.
Primär geht es dabei um drei Dinge:
* Registrierung von Spungzielen, um eben Basisblöcke ausmachen zu können
* Markierung von nicht ausgerichteten Speicherzugriffen, da
"misalignment" auf dem Alpha einer Sonderbehandlung bedarf
* Markierung von indirekten Sprüngen, da diese eines der Hauptprobleme
der statischen Übersetzung darstellen; falls die gefundenen möglichen
Sprungziele zur Laufzeit nicht zutreffen sollten, muß sowieso wieder der
Fallback-Interpreter ran

HotSpot hat bei Java aus meiner Sicht primär einen Vorteil:
Initialisierungscode, der ohnehin nur einmal ausgeführt wird, muß nicht
übersetzt werden, was sich insbesondere auf die Startgeschwindigkeit
einer Applikation günstig auswirken dürfte.
Ansonsten sehe ich HotSpot vielmehr als Reperatur einer schlechten
JVM-Definition! Warum?
Nun, der Java-Bytecode wird vom Java-Compiler generiert, der natürlich
genau weiß, wo sich die Basisblöcke befinden, nur dummerweise wird der
Anfang eines Basisblocks im Bytecode nicht markiert. Eine der
Hauptaufgaben des Profilings in HotSpot dürfte es also sein, ähnlich wie
in FX!32, zur Laufzeit die Basisblöcke wiederzufinden, die zur
Compilezeit bereits bekannt waren.
Aber auch ansonsten hat ja Sun einiges für die Laufzeit aufgehoben, was
man besser zur Compilezeit erledigen sollte, wie die Registerallokation,
nachdem die JVM eine Stackmaschine ist...
Ich denke mal mit etwas besserem Design der JVM wäre so etwas wie
HotSpot einfach nicht nötig.
Post by Thomas Priegl
Hm ... ein Emulator übersetzt x86 Maschinencode in G4/G5 Maschinencode.
Eine JVM übersetzt Java Bytecode in x86 bzw. G4/G5 Maschinencode. Ich
kenne mich da wirklich nicht gut aus, aber wo ist der große Unterschied?
Genauso gut könntest Du fragen, was der Unterschied zwischen einem
Spaziergang und einem Marathonlauf ist...

Mal ein paar Unterschiede wahllos herausgegriffen:

* Bei Java hat man modularen Ausgangscode in Form von Klassen-Dateinen
und Methoden. Bei dynamischer Recompilierung bekommt man einfach einen
Batzen Maschinencode, bei dem je nach Objektformat noch nicht einmal
klar gegliedert sein muß, was davon Code oder Daten sind. Mal abgesehen
davon, daß ja zur Laufzeit auch problemlos weiterer Maschinencode
erzeugt werden kann.

* Selbstmodifizierender Code ist bei der JVM kein Thema, bei dynamischer
Recompilierung *das* Problem schlechthin, insbesondere wenn man es mit
der IA-32 zu tun hat, bei der aus Kompatibilitätsgründen ein Cache-Flush
vollkommen transparent sein muß und deswegen dem Emulator in keinster
Weise (z.B. durch eine spezielle Instruktion) mitgeteilt wird.

* Die JVM ist eine abstrakte Laufzeitumgebung ohne Seiteneffekte, bei
einem Emulator muß man die Emulation der CPU und der restlichen Hardware
richtig synchronisieren und darf sich noch mit einigen Seiteneffekten
herumschlagen (allseits beliebt sind schlecht dokumentierte
Condition-Flags).

Ich schätze mal, ich könnte noch mehr in die Tiefe gehen, aber das
sollte erstmal reichen...
Post by Thomas Priegl
Jein. Ich würde sagen, er sollte n Applikationen parallel so schnell wie
möglich ablaufen lassen. Ich arbeite extrem selten nur mit einer
Applikation.
Hmm, wenn Du Dich genötigt fühlst, auf einem PC-Emulator unter Windows
mehrere Applikationen gleichzeitig zu benutzen, dann würde ich mich an
Deiner Stelle fragen, ob ich nicht auf dem falschen System arbeite.

Für mich ist Emulation zum einen eine Form der Nostalgie und zum anderen
die Möglichkeit, einige wenige Applikationen, für die es auf meinem
aktuellen Primärsystem keine Entsprechung gibt, weiterzunutzen.

[VM-Extensions]
Post by Thomas Priegl
Ja. So ist es auch unter XP. Aber ich habe gelesen, dass in VPC 7 eben
dies für Win 98 nicht mehr unterstützt werden soll.
Und nochmal, "unsupported" heißt nicht unbedingt "geht nicht mehr".
Probier es einfach aus, bei mir klappt es.
Post by Thomas Priegl
Schade. Gerade die unglaubliche Performance von BeOS hat mich damals
begeistert.
Stimmt schon. Ich hatte mal ein längeres Streitgespräch mit einem in der
BeOS-Newsgroups, weil er BeOS unbedingt in Bochs testen wollte (weil er
sich außer stande sah, sein Linux mal für ein paar Minuten
herunterzufahren) und mir nicht glauben wollte, daß er die Vorteile des
Systems so definitiv nicht einschätzen kann.
Post by Thomas Priegl
Sonst konnte man damit ja nicht soviel machen. ;-)
Ich habe es eigentlich noch einige Jahre nach der Einstellung der
Weiterentwicklung weiterverwenden können. Erst als immer mehr Webseiten,
die ich leider brauchte, mit den vorhandenen Browsern nicht mehr
funktionierten, faßte ich den Entschluß auf ein anderes System
umzusteigen. Nachdem mein PC dann auch schon veraltet war und einige
kleine Macken bekommen hatte, habe ich es dann gleich mit einem Wechsel
der Hardware verbunden.
--
M.I.K.e
Thomas Priegl
2005-04-25 20:16:54 UTC
Permalink
Hallo,
Post by Michael Koenig
Post by Thomas Priegl
Warum sollte der Code doppelt übersetzt werden müssen?
Stimmt, ist irgendwie Blödsinn, aber ich versuche gedanklich dem Problem
der Synchronisation der beiden emulierten CPUs aus dem Weg zu gehen.
Aber meiner Ansicht nach lassen sich mehrere emulierte CPUs eben nur
ansprechend synchronisieren, wenn sie im gleichen Thread emuliert
werden. Ich kann mich natürlich auch täuschen...
Wie gesagt, ich bin kein Experte. Und ich stimme Dir zu: Irgend etwas
wird da schon problematisch sein, sonst würde VPC es wohl machen.
Post by Michael Koenig
Wenn die Emulation von einem Dual-Prozessor, insbesondere mit
dynamischer Recompilierung, halbwegs einfach wäre, dann gäbe es meiner
Ansicht nach deutlich mehr Sega-Saturn-Emulatoren. Der SH-2 ist
eigentlich vergleichsweise trivial, aber die Tatsache, daß der Saturn
gleich zwei davon hat, macht die Emulation der Hardware deutlich
aufwendiger.
Ja. Auch die Programmierung soll ja schon sehr schwer gewesen sein, was
den Untergang des Saturns ja zumindest begünstigt hat. Aber ich oute
mich jetzt mal als alten Nintendo-Fan und sage "SNES forever!" ... :-)
Post by Michael Koenig
Der Unterschied bei Java ist aber, daß Du nicht mehrere VMs hast,
sondern Threading durch die Thread-Klasse und nötige Synchronisation im
Bytecode durch monitorenter und monitorexit gesteuert werden.
Das ist etwas komplett anderes, als zwei reele Prozessoren in
unterschiedlichen Threads mit dynamischer Recompilierung zu emulieren
und dann noch zu versuchen, beide so zu synchronisieren, daß sich das
ganze dann wie ein SMP-System verhält.
Eine andere Idee von Dir war ja, die Windows-Threads quasi in
Emulations-Threads zu übertragen, aber dadurch würde der Emulator so
stark auf Windows (und wahrscheinlich nur XP, da es bei jeder Version
etwas anders sein dürfte) angepaßt, daß es kein PC-Emulator wäre.
In dem Fall wäre es dann besser, nur die CPU-Emulation zu nehmen, mit
einem PE-Loader zu kombinieren und die Win-API auf OSX zu portieren. Da
hätte außerdem den Nebeneffekt, daß man sich bis auf die CPU die
Hardwareemulation spart und die API nativ läuft. Und so ein Projekt ist
<http://darwine.opendarwin.org/>
Ja. Aber ich finde einen "echten" PC-Emulator schon besser. War schon
recht witzig darauf einfach mal "Damn Small Linux" laufen zu lassen. :-)

Trotzdem ist Darwine ein interessantes Projekt.
Post by Michael Koenig
Nein, das wäre definitiv zu langsam und würde zu noch längeren
Wartezeiten beim Start eines Programms führen, als das bei einem Java
JIT-Compiler der Fall war. Mal abgesehen davon, daß man bei einem echten
Maschinenprogramm nicht immer eindeutig entscheiden kann, was jetzt
wirklich alles Code ist.
Nun, Java hatte vor HotSpot einen JIT und HotSpot ist dem IMHO in allen
Bereichen überlegen. Insbesondere die Server-VM läuft IMHO pfeilschnell.

Bei der Client-VM stört mich noch immer die zu lange Startzeit bei Swing
und auch der Speicherbedarf. Die Performance einer laufenden Anwendung
ist aber sehr gut.

Und - um wieder on topic zu sein - Java 1.5 geht sogar ganz vernünftig
unter VPC. :-)
Post by Michael Koenig
Wie die meisten Emulatoren mit dynamischer Recompilierung arbeitet VPC
mit sog. Basisblöcken ("basic blocks"). Dieser aus der
Compileroptimierung
Argh ... ich erinnere mich mit schrecken an eine Vorlesung namens
Compilerbau. Ich habe das alles aus gutem Grund verdrängt. ;-)
Post by Michael Koenig
bekannte Terminus bezeichnet eine Folge von
Instruktionen, die immer sequenziell ausgeführt wird, oder anders
ausgedrückt, ein Basisblock reicht von einem Einsprungpunkt bis zur
nächsten Verzweigung.
Sobald eine Adresse angesprungen werden soll, für die noch keine
Entsprechung im Translation-Cache vorliegt, wird der Basisblock ab
dieser Adresse übersetzt, die Übersetzung in den Cache gehängt und
danach angesprungen.
<http://www.byte.com/art/9711/sec4/art4.htm>
Sehr interessant. Werde ich mir am Wochenende mal in Ruhe durchlesen.
Post by Michael Koenig
Pauschal fällt mir nur ein in der Praxis eingesetzter
Binärcode-Übersetzer ein, der vorher einen Durchlauf mit Interpreter und
Profiler machte. Die Rede ist von FX!32, dem x86-Emulator für
WinNT/Alpha, der allerdings keine dynamische sondern eine statische
Übersetzung macht, die erst nach der Laufzeit erzeugt wird und dann für
den nächsten Durchlauf in einer Datenbank gespeichert wird.
Nach meinen Informationen sind die Profile-Informationen, die während
der Interpretation gesammelt werden, auch nicht gerade berauschend.
* Registrierung von Spungzielen, um eben Basisblöcke ausmachen zu können
* Markierung von nicht ausgerichteten Speicherzugriffen, da
"misalignment" auf dem Alpha einer Sonderbehandlung bedarf
* Markierung von indirekten Sprüngen, da diese eines der Hauptprobleme
der statischen Übersetzung darstellen; falls die gefundenen möglichen
Sprungziele zur Laufzeit nicht zutreffen sollten, muß sowieso wieder der
Fallback-Interpreter ran
Initialisierungscode, der ohnehin nur einmal ausgeführt wird, muß nicht
übersetzt werden, was sich insbesondere auf die Startgeschwindigkeit
einer Applikation günstig auswirken dürfte.
Ja, das ist _ein_ Vorteil.
Post by Michael Koenig
Ansonsten sehe ich HotSpot vielmehr als Reperatur einer schlechten
JVM-Definition! Warum?
Nun, der Java-Bytecode wird vom Java-Compiler generiert, der natürlich
genau weiß, wo sich die Basisblöcke befinden, nur dummerweise wird der
Anfang eines Basisblocks im Bytecode nicht markiert. Eine der
Hauptaufgaben des Profilings in HotSpot dürfte es also sein, ähnlich wie
in FX!32, zur Laufzeit die Basisblöcke wiederzufinden, die zur
Compilezeit bereits bekannt waren.
Aber auch ansonsten hat ja Sun einiges für die Laufzeit aufgehoben, was
man besser zur Compilezeit erledigen sollte, wie die Registerallokation,
nachdem die JVM eine Stackmaschine ist...
Ach. Und für welche Anzahl von Registern willst Du das machen wenn die
Hardware - und damit deren Register - Dir zur Compilezeit nicht bekannt
ist? Oder meinst Du etwas anderes?
Post by Michael Koenig
Ich denke mal mit etwas besserem Design der JVM wäre so etwas wie
HotSpot einfach nicht nötig.
Dem möchte ich widersprechen. Optimierung zur Compilezeit hat immense
Nachteile. Du kannst z.B. kaum vernünftig optimieren, wenn Dir die
exakte CPU nicht bekannt ist. Siehe Erweiterungen von x86 wie MMX, SSEx,
3DNow ... Wie viele Programme nutzen davon nichts oder nur einen Teil?

Ein weiterer Vorteil ist, das HotSpot zur Laufzeit deutlich mehr
Informationen zur Verfügung hat als ein Compiler.

Ich bin jedenfalls sehr froh, dass ich mir bei Java keinerlei gedanken
darüber machen muß, für welche CPU-Variante oder gar Architektur ich
übersetze.
Post by Michael Koenig
Genauso gut könntest Du fragen, was der Unterschied zwischen einem
Spaziergang und einem Marathonlauf ist...
Gibt es da einen Unterschied? SCNR.
Post by Michael Koenig
* Bei Java hat man modularen Ausgangscode in Form von Klassen-Dateinen
und Methoden. Bei dynamischer Recompilierung bekommt man einfach einen
Batzen Maschinencode, bei dem je nach Objektformat noch nicht einmal
klar gegliedert sein muß, was davon Code oder Daten sind. Mal abgesehen
davon, daß ja zur Laufzeit auch problemlos weiterer Maschinencode
erzeugt werden kann.
* Selbstmodifizierender Code ist bei der JVM kein Thema, bei dynamischer
Recompilierung *das* Problem schlechthin, insbesondere wenn man es mit
der IA-32 zu tun hat, bei der aus Kompatibilitätsgründen ein Cache-Flush
vollkommen transparent sein muß und deswegen dem Emulator in keinster
Weise (z.B. durch eine spezielle Instruktion) mitgeteilt wird.
Wie macht Transmeta das beim Crusoe?
Post by Michael Koenig
* Die JVM ist eine abstrakte Laufzeitumgebung ohne Seiteneffekte, bei
einem Emulator muß man die Emulation der CPU und der restlichen Hardware
richtig synchronisieren und darf sich noch mit einigen Seiteneffekten
herumschlagen (allseits beliebt sind schlecht dokumentierte
Condition-Flags).
Ich schätze mal, ich könnte noch mehr in die Tiefe gehen, aber das
sollte erstmal reichen...
Ja, absolut. Danke für den Überblick. :-)
Post by Michael Koenig
Hmm, wenn Du Dich genötigt fühlst, auf einem PC-Emulator unter Windows
mehrere Applikationen gleichzeitig zu benutzen, dann würde ich mich an
Deiner Stelle fragen, ob ich nicht auf dem falschen System arbeite.
Wie schon gesagt, dass ist keine Anforderung von mir. Ich verwende VPC
für sehr wenige Altlasten aus der Windows Welt.

Aber wenn ich schon einen Emulator habe, dann möchte ich gerne das
Maximum des möglichen dabei haben. Ich habe ja nur einen Mac mini und
keinen Dual G5. Deswegen war diese Frage reine Neugier.
Post by Michael Koenig
Für mich ist Emulation zum einen eine Form der Nostalgie und zum anderen
die Möglichkeit, einige wenige Applikationen, für die es auf meinem
aktuellen Primärsystem keine Entsprechung gibt, weiterzunutzen.
Exakt. Und zu diesen zwei Gründen kommt für mich noch ein dritter hinzu:
Es ist ein nettes technologisches Spielzeug.
Post by Michael Koenig
Und nochmal, "unsupported" heißt nicht unbedingt "geht nicht mehr".
Probier es einfach aus, bei mir klappt es.
Ich habe jetzt mal NT 4.0 verwendet. Dafür gibt es die Extensions, sie
lassen sich aber erst ab SP6 installieren. Dumm nur, dass der IE 2.0 der
bei NT dabei ist keine einzige Webseite mehr richtig anzeigen kann - der
Download von SP6 ist damit nicht möglich. Werde das wohl über den Umweg
CD bzw. CD-Image lösen müssen.
Post by Michael Koenig
Stimmt schon. Ich hatte mal ein längeres Streitgespräch mit einem in der
BeOS-Newsgroups, weil er BeOS unbedingt in Bochs testen wollte (weil er
sich außer stande sah, sein Linux mal für ein paar Minuten
herunterzufahren) und mir nicht glauben wollte, daß er die Vorteile des
Systems so definitiv nicht einschätzen kann.
Wunderbar damals die OpenGL-Performance - obwohl (in meiner Version)
reiner Software-Modus.
Post by Michael Koenig
Ich habe es eigentlich noch einige Jahre nach der Einstellung der
Weiterentwicklung weiterverwenden können. Erst als immer mehr Webseiten,
die ich leider brauchte, mit den vorhandenen Browsern nicht mehr
funktionierten, faßte ich den Entschluß auf ein anderes System
umzusteigen. Nachdem mein PC dann auch schon veraltet war und einige
kleine Macken bekommen hatte, habe ich es dann gleich mit einem Wechsel
der Hardware verbunden.
Ich hatte damals ISDN ... no way.

CU
Thomas
Michael Koenig
2005-05-07 12:56:35 UTC
Permalink
Entwas verspätet...

Thomas Priegl wrote:
[Emulation eines SMP-Systems]
Post by Thomas Priegl
Wie gesagt, ich bin kein Experte. Und ich stimme Dir zu: Irgend etwas
wird da schon problematisch sein, sonst würde VPC es wohl machen.
Ich bin auch kein Experte, aber die Synchronisation der üblichen
Hardware ist normalerweise schon schlimm genug, weswegen ich mir nicht
vorstelllen kann, daß jemand freiwillig SMP emulieren wird.
Post by Thomas Priegl
Ja. Auch die Programmierung soll ja schon sehr schwer gewesen sein, was
den Untergang des Saturns ja zumindest begünstigt hat. Aber ich oute
mich jetzt mal als alten Nintendo-Fan und sage "SNES forever!" ... :-)
Pah! Wenn schon, dann Dreamcast! ;-)
(Ich habe hier aber auch einen GameCube und einen GBA SP...)
Post by Thomas Priegl
Post by Michael Koenig
<http://darwine.opendarwin.org/>
Ja. Aber ich finde einen "echten" PC-Emulator schon besser. War schon
recht witzig darauf einfach mal "Damn Small Linux" laufen zu lassen. :-)
Ich muß gestehen, daß eines der Hauptanliegen der PC-Emulation für mich
immer noch die Möglichkeit ist, DOS- und Windows-Applikationen
laufenzulassen.
Für DOS ist DOSBox ganz brauchbar und für Windows könnte Darwine eine
einfache Lösung sein, mit der eventuell auch ein Nicht-Freak noch ein
paar Sachen zum laufen bringt.
Post by Thomas Priegl
Nun, Java hatte vor HotSpot einen JIT und HotSpot ist dem IMHO in allen
Bereichen überlegen.
Wie gesagt, liegt daran, daß Initialisierungscode nicht übersetzt wird
und daß der JIT einfach nicht besonders gut optimieren kann.
Post by Thomas Priegl
Argh ... ich erinnere mich mit schrecken an eine Vorlesung namens
Compilerbau. Ich habe das alles aus gutem Grund verdrängt. ;-)
Ich empfand die Vorlesung zur Codegenerierung deutlich interessanter als
sämtliches Gelaber über Scanner und Parser, weil man auf diese Weise
endlich mal einige der Designentscheidungen bei C versteht
(beispielsweise warum Arrays mit 0 beginnend numeriert werden und warum
es keine Schachtelung von Funktionen gibt).
Post by Thomas Priegl
Post by Michael Koenig
<http://www.byte.com/art/9711/sec4/art4.htm>
Sehr interessant. Werde ich mir am Wochenende mal in Ruhe durchlesen.
Das hier könnte auch noch interessant sein:
<http://developer.apple.com/technotes/pt/pt_39.html>

[VM: Register- statt Stackmaschine]
Post by Thomas Priegl
Ach. Und für welche Anzahl von Registern willst Du das machen wenn die
Hardware - und damit deren Register - Dir zur Compilezeit nicht bekannt
ist? Oder meinst Du etwas anderes?
Man nimmt eine relativ hohe Registerzahl, damit die lokalen Variablen
gut auf Register verteilt sind.
Zur Laufzeit werden diese Register dann auf die echten Register
verteilt. Falls nicht genügend Hardwareregister vorhanden sind, wird ein
Austausch wie bei virtueller Seitenverwaltung vorgenommen
(beispielsweise über eine Variante von LRU), was immer noch deutlich
schneller als Graph-Colouring ist. Wenn die Zielmaschine mehr Register
hat (wie etwa im Itanium), dann hat man wahrscheinlich immer noch eine
deutlich bessere Registerallokation, als wenn man sie komplett zur
Laufzeit machen müßte.
Post by Thomas Priegl
Dem möchte ich widersprechen. Optimierung zur Compilezeit hat immense
Nachteile. Du kannst z.B. kaum vernünftig optimieren, wenn Dir die
exakte CPU nicht bekannt ist.
Ich sage ja auch nicht, daß zur Compilezeit der Zielcode erzeugt werden
soll, sondern daß eine der aufwendigsten Aufgaben der Codegenerierung,
und das ist die Registerallokation, nicht komplett zur Laufzeit gemacht
werden sollte.
Post by Thomas Priegl
Siehe Erweiterungen von x86 wie MMX, SSEx,
3DNow ... Wie viele Programme nutzen davon nichts oder nur einen Teil?
Fragt sich wie viele Java-Programme diese Features wirklich nutzen
könnten. Gerade bei SIMD hängt sehr viel von den jeweiligen Algorithmen
ab, mal abgesehen davon, daß sich mit den meisten Hochsprachen
Vektorrechnungen schlecht beschreiben lassen.
Post by Thomas Priegl
Ein weiterer Vorteil ist, das HotSpot zur Laufzeit deutlich mehr
Informationen zur Verfügung hat als ein Compiler.
Sicher, nur leider muß sich HotSpot eben auch einige Informationen
erneut zusammensuchen, die dem Compiler bekannt waren. Und *das* ist
definitiv ein schwerwiegender Designfehler.
Post by Thomas Priegl
Ich bin jedenfalls sehr froh, dass ich mir bei Java keinerlei gedanken
darüber machen muß, für welche CPU-Variante oder gar Architektur ich
übersetze.
Vielleicht sollte ich dann nicht erwähnen, daß ich mich gerade in
PIC-Microcontroller einarbeiten darf, die man auf niedrigster Ebene
programmieren muß ;-)

[Probleme mit selbstmodifizierendem Code]
Post by Thomas Priegl
Wie macht Transmeta das beim Crusoe?
Ganz offen: Keine Ahnung.
Die Informationen von Transmeta sind äußerst spärlich. Ich konnte bisher
auch kaum etwas über ihre interne VLIW-Architektur herausfinden.
Eventuell gibt es ja im Patent einige Details (ich denke, daß Transmeta
sich das "Code Morphing" patentiert haben müßte), aber diese
Patentschriften sind normalerweise eine sehr gute Einschlafhilfe...

Die übliche Methode ist wohl mit Prüfsummen zu arbeiten, was aber den
Nachteil hat, daß man vor Ausführung eines Blocks immer die Prüfsumme
des Originals neu berechnen und mit der Prüfsumme zur Zeit der
Übersetzung vergleichen muß, was logischerweise etwas zeitaufwendig ist.

Ich hatte vor einiger Zeit eine Idee, die auf der Theorie basiert, daß
man normalerweise Code und Daten nicht in der gleichen Speicherseite
hält. Dabei wird dann die Routine für den schreibenden Speicherzugriff
so modifiziert, daß sie nach einen Schreibzugriff auf einem Seite mit
bekanntem Code dafür sorgt, daß alle Übersetzungen für diese Seite aus
dem Translation-Cache entfernt werden.
Hat den Nachteil, daß Schreibzugriffe verlangsamt werden, könnte in der
Praxis aber weniger problematisch sein, als die Prüfsummen-Methode.

[Emulation aus Nostalgie und zur Migration]
Post by Thomas Priegl
Es ist ein nettes technologisches Spielzeug.
Stimmt ;-)

[BeOS]
Post by Thomas Priegl
Wunderbar damals die OpenGL-Performance - obwohl (in meiner Version)
reiner Software-Modus.
Die OpenGL-Implementierung über Glide war eigentlich recht fix.
Funktionierte allerdings nur mit R4.5.
Post by Thomas Priegl
Ich hatte damals ISDN ... no way.
Ist jetzt zu spät, aber trotzdem...
<http://www.be-faq.de/index.html#3.1.2>
--
M.I.K.e
Thomas Priegl
2005-05-07 16:53:31 UTC
Permalink
Hallo Michael,
Post by Michael Koenig
[Emulation eines SMP-Systems]
Post by Thomas Priegl
Wie gesagt, ich bin kein Experte. Und ich stimme Dir zu: Irgend etwas
wird da schon problematisch sein, sonst würde VPC es wohl machen.
Ich bin auch kein Experte, aber die Synchronisation der üblichen
Hardware ist normalerweise schon schlimm genug, weswegen ich mir nicht
vorstelllen kann, daß jemand freiwillig SMP emulieren wird.
Ach mal sehen. Vielleicht ja mal einen Pentium D auf einem Cell Mac ...

;-)

BTW und halb off topic: Wie ist Deine Meinung zum Cell? Und würde der
ggf. in einem PowerMac brauchbare Ergebnisse liefern können oder ist die
Architektur da einfach zu spezifisch?
Post by Michael Koenig
Pah! Wenn schon, dann Dreamcast! ;-)
Habe ich. Aber Jenseits von Soul Calibur, Shenmue und Code: Veronica ist
mir da nicht so viel in Erinnerung geblieben. Aber gut, diese drei
allein sind es schon Wert einen Dreamcast zu besitzen.

Allerdings: Der Dreamcast hat heute schon ziemliche Probleme manche CDs
noch sauber abzuspielen, das ca. 10 Jahre ältere SNES und das noch viel
ältere NES laufen dagegen auch heute noch wie am ersten Tag ...
Post by Michael Koenig
(Ich habe hier aber auch einen GameCube und einen GBA SP...)
Ersteres System habe ich auch.

Und um wieder on toppic zu sein: Mac zum arbeiten (für Internet,
Programmierung, Office, MP3 usw.) und dazu dann jeweils ein oder zwei
aktuelle Konsolen zum Spielen - das wird wohl für die nächsten Jahre
meine Kombination werden.

Einen Wintel-PC brauche ich in dem Szenario glücklicherweise nicht mehr.
Post by Michael Koenig
Ich muß gestehen, daß eines der Hauptanliegen der PC-Emulation für mich
immer noch die Möglichkeit ist, DOS- und Windows-Applikationen
laufenzulassen.
Für DOS ist DOSBox ganz brauchbar und für Windows könnte Darwine eine
einfache Lösung sein, mit der eventuell auch ein Nicht-Freak noch ein
paar Sachen zum laufen bringt.
DOS brauche ich zum Glück nicht mehr. :-)
Post by Michael Koenig
Wie gesagt, liegt daran, daß Initialisierungscode nicht übersetzt wird
und daß der JIT einfach nicht besonders gut optimieren kann.
ACK.
Post by Michael Koenig
Man nimmt eine relativ hohe Registerzahl, damit die lokalen Variablen
gut auf Register verteilt sind.
Zur Laufzeit werden diese Register dann auf die echten Register
verteilt. Falls nicht genügend Hardwareregister vorhanden sind, wird ein
Austausch wie bei virtueller Seitenverwaltung vorgenommen
(beispielsweise über eine Variante von LRU), was immer noch deutlich
schneller als Graph-Colouring ist. Wenn die Zielmaschine mehr Register
hat (wie etwa im Itanium), dann hat man wahrscheinlich immer noch eine
deutlich bessere Registerallokation, als wenn man sie komplett zur
Laufzeit machen müßte.
Gut, das müsste man jetzt messen. Rein subjektiv betrachtet finde ich
Hotspot Server mittlerweile für sehr viele Aufgaben extrem schnell.

Wenn ich da aktuell meine ersten Erfahrungen mit einem Framework ansehe,
der COM/DCOM mit C++ verwendet (also compiliert und ohne VM) und ASP.NET
als Front-End (also die .NET VM, denke ich) ... Aber wie in den meisten
Fällen vermute ich mal, dass auch hier die Performance in der
Architektur verloren geht und nicht im Compiler bzw. der VM.

Ich mache halt Enterprise Applikationen in der Logistik, keine
Grafiktrieber oder Wettersimulationen oder ähnliches, wo es vielleicht
auch heute noch anders aussieht.
Post by Michael Koenig
Ich sage ja auch nicht, daß zur Compilezeit der Zielcode erzeugt werden
soll, sondern daß eine der aufwendigsten Aufgaben der Codegenerierung,
und das ist die Registerallokation, nicht komplett zur Laufzeit gemacht
werden sollte.
Gut, kann ich mangels Wissen nicht widersprechen.
Post by Michael Koenig
Fragt sich wie viele Java-Programme diese Features wirklich nutzen
könnten. Gerade bei SIMD hängt sehr viel von den jeweiligen Algorithmen
ab, mal abgesehen davon, daß sich mit den meisten Hochsprachen
Vektorrechnungen schlecht beschreiben lassen.
Ich möchte halt dahin kommen, dass ich mein Programm für eine recht weit
von der jeweiligen Hardware entfernte Architektur schreibe, welche dann
ihrerseits jeweils auf die gerade aktuelle Hardware voll optimiert ist.
Wenn ich also im Programm irgend eine komplexe Berechnung habe, dann
möchte ich , dass auf dem Mac automatisch Altivec verwendet wird und auf
einem Pentium SSE3 und auf einem Athlon/Itanium/HP/Sun/IBM was auch
immer (Vergleich mag hinken, ich kenne die jeweiligen Recheneinheiten
der CPUs nicht gut genug).

In meinem Umfeld wird niemand bereit sein mir Geld für eine Optimierung
auf die aktuelle Projekthardware zu zahlen. Andererseits wird
Serverseitig durchaus ein hoher Datendurchsatz und eine schnelle
Antwortzeit verlangt (zumindest in einigen Teilbereichen).

Wenn Hotspot heute da noch nicht gut genug ist, dann vielleicht morgen.
Es ist aber über die Jahre diesem Ziel doch sehr viel näher gekommen -
rein subjektiv ohne Benchmarks betrieben zu haben.
Post by Michael Koenig
Sicher, nur leider muß sich HotSpot eben auch einige Informationen
erneut zusammensuchen, die dem Compiler bekannt waren. Und *das* ist
definitiv ein schwerwiegender Designfehler.
Möglich.
Post by Michael Koenig
Vielleicht sollte ich dann nicht erwähnen, daß ich mich gerade in
PIC-Microcontroller einarbeiten darf, die man auf niedrigster Ebene
programmieren muß ;-)
Siehe oben. Ich habe ein anderes Feld zu bestellen. :-)
Post by Michael Koenig
Ganz offen: Keine Ahnung.
OK. :-)
Post by Michael Koenig
Die Informationen von Transmeta sind äußerst spärlich. Ich konnte bisher
auch kaum etwas über ihre interne VLIW-Architektur herausfinden.
Eventuell gibt es ja im Patent einige Details (ich denke, daß Transmeta
sich das "Code Morphing" patentiert haben müßte), aber diese
Patentschriften sind normalerweise eine sehr gute Einschlafhilfe...
Die übliche Methode ist wohl mit Prüfsummen zu arbeiten, was aber den
Nachteil hat, daß man vor Ausführung eines Blocks immer die Prüfsumme
des Originals neu berechnen und mit der Prüfsumme zur Zeit der
Übersetzung vergleichen muß, was logischerweise etwas zeitaufwendig ist.
Ich hatte vor einiger Zeit eine Idee, die auf der Theorie basiert, daß
man normalerweise Code und Daten nicht in der gleichen Speicherseite
hält. Dabei wird dann die Routine für den schreibenden Speicherzugriff
so modifiziert, daß sie nach einen Schreibzugriff auf einem Seite mit
bekanntem Code dafür sorgt, daß alle Übersetzungen für diese Seite aus
dem Translation-Cache entfernt werden.
Hat den Nachteil, daß Schreibzugriffe verlangsamt werden, könnte in der
Praxis aber weniger problematisch sein, als die Prüfsummen-Methode.
OK. Ich kann hier nicht wirklich mitreden. Hätte mich nur interessiert,
ob die vielleicht den Stein der Weisen gefunden haben.
Post by Michael Koenig
Ist jetzt zu spät, aber trotzdem...
<http://www.be-faq.de/index.html#3.1.2>
Mittlerweile DSL ... :-)

CU
Thomas
Michael Koenig
2005-05-11 21:53:19 UTC
Permalink
Post by Thomas Priegl
Post by Michael Koenig
[Emulation eines SMP-Systems]
Ach mal sehen. Vielleicht ja mal einen Pentium D auf einem Cell Mac ...
Ich hoffe ernsthaft, daß Intel die veraltete Architektur irgendwann
einstampft, und ob Cell wirklich etwas für Apple wäre?
Post by Thomas Priegl
BTW und halb off topic: Wie ist Deine Meinung zum Cell? Und würde der
ggf. in einem PowerMac brauchbare Ergebnisse liefern können oder ist die
Architektur da einfach zu spezifisch?
Bei Cell bin ich sogar für die PS3 skeptisch, aber das liegt wohl auch
daran, daß die Performanz-Aussagen immer noch ziemlich theoretisch sind
und Sony allgemein zu Übertreibungen neigt - ich warte immer noch auf
deren Beweis, daß die PS2 10-mal leistungsfähiger als die Dreamcast ist,
was aber rein Hardware-technisch gar nicht funktionieren kann...

Ich sehe Ken Kutaragi als jemanden, der gerne mit Hardware spielt, sich
aber anscheinend nicht sehr viel Gedanken darüber macht, wie seine
Vorstellungen eigentlich in die Praxis umzusetzen sind. Die PS2 war
nicht nur sehr schwer zu programmieren, sondern auch noch voller
Hardware-Bugs. Und einem PSP-Entwickler zufolge, scheint dieses Gerät
auch die meisten der typischen PS2-Bugs, wie fehlerhaftes Clipping und
starke Rechenungenauigkeiten, geerbt zu haben. Da kann man für die
Entwickler nur hoffen, daß die PS3 vielleicht etwas weniger Bugs hat.

Prinzipiell sehe ich aber das Problem, daß Cell sehr extrem auf
Parallelität setzt. Nur dummerweise lassen sich nicht alle Algorithmen
so einfach parallelisieren. Mal abgesehen davon, daß die wenigsten
Entwickler auf einem PowerMac wirklich die Dual-Prozessoren ausreizen.
Da müßten sie auf Cell (egal ob in der PS3 oder in einem eventuellen
Mac) doch deutlich umdenken, bei mehreren CPU-Kernen, die wiederum
mehrere Multimedia-Kerne kontrollieren (wie genau deren Funktionsumfang
aussieht, habe ich bisher auch noch nicht herausgefunden).

Nachdem ich mich schon frage, wie man Cell überhaupt in der PS3 sinnvoll
ausreizen soll, ist es bei einem all-round Computer wie einem Mac noch
fraglicher, ob man die ganzen sekundären Kerne überhaupt verwenden kann.
Einige würden ja sogar gerne zugunsten von ein oder zwei zusätzlichen
FPUs auf die AltiVec-Einheit verzichten. Ganz so sehe ich es nicht, da
inzwischen doch einiges an Multimedia-Daten verarbeitet wird, aber die
APUs in Cell würden wahrscheinlich doch die meiste Zeit brach liegen.

Ich lasse mich gerne vom Gegenteil überzeugen, aber rein
programmiertechnisch sehe ich Cell eher als problematisch denn als
Überhammer an.
Post by Thomas Priegl
Habe ich. Aber Jenseits von Soul Calibur, Shenmue und Code: Veronica ist
mir da nicht so viel in Erinnerung geblieben. Aber gut, diese drei
allein sind es schon Wert einen Dreamcast zu besitzen.
Shenmue müßte ich langsam mal spielen. Code Veronica habe ich erst auf
dem Gamecube beendet, weil ich mir auf der Dreamcast die Complete
Edition geholt habe und es mir dann doch zu blöd wurde, bei vielen
Rätseln in eine Musterlösung zu schauen, weil ich den japanischen Text
nicht verstehe.
Aber Soul Calibur ist immer noch genial, insbesondere mit dem
Sega-Arcade-Stick.
Post by Thomas Priegl
Allerdings: Der Dreamcast hat heute schon ziemliche Probleme manche CDs
noch sauber abzuspielen, das ca. 10 Jahre ältere SNES und das noch viel
ältere NES laufen dagegen auch heute noch wie am ersten Tag ...
Anscheinend sind die Laser doch empfindlicher als die für die Module
nötigen Kontakte. Ich habe glücklicherweise immer noch eine
"Backup-Dreamcast" im Schrank ;-)
Post by Thomas Priegl
Und um wieder on toppic zu sein: Mac zum arbeiten (für Internet,
Programmierung, Office, MP3 usw.) und dazu dann jeweils ein oder zwei
aktuelle Konsolen zum Spielen - das wird wohl für die nächsten Jahre
meine Kombination werden.
Momentan spiele ich dank World of Warcraft mehr am Mac, wenn ich denn
Zeit und Lust dazu habe. Aber ansonsten habe ich mehr als genug nicht
fertig gespielte Konsolenspiele.
Post by Thomas Priegl
Einen Wintel-PC brauche ich in dem Szenario glücklicherweise nicht mehr.
Half-Life 2 hätte mich interesssiert, aber ansonsten hat es schon lange
kein wirklich interessantes PC-Spiel gegeben, das ich nicht irgendwann
auch auf dem Mac oder einer Konsole bekommen hätte.
Post by Thomas Priegl
DOS brauche ich zum Glück nicht mehr. :-)
Es gibt immer noch ein paar gute DOS-Spiele, aber dank Engines wie
ScummVM werden es auch immer weniger, für die man einen DOS-Emulator
bräuchte.
Post by Thomas Priegl
Ich mache halt Enterprise Applikationen in der Logistik, keine
Grafiktrieber oder Wettersimulationen oder ähnliches, wo es vielleicht
auch heute noch anders aussieht.
Ich finde Java hat seine Berechtigung, wenn man im Netzwerk arbeitet und
es auf unterschiedlichsten Plattformen laufen soll. Ansonsten wird aber
Java auch für einige Dinge eingesetzt, für die es wirklich nicht
sinnvoll ist.
Ist eine Weile her, daß ich mal damit gearbeitet habe, aber ich hoffe,
daß die Grafikroutinen inzwischen schneller sind. Ich durfte mal mit
einer Art TOAD-für-Arme arbeiten, das in Java geschrieben war und Swing
einsetzte. Auf einem Pentium 3 mit 600MHz war das eine echte Qual...
Post by Thomas Priegl
Ich möchte halt dahin kommen, dass ich mein Programm für eine recht weit
von der jeweiligen Hardware entfernte Architektur schreibe, welche dann
ihrerseits jeweils auf die gerade aktuelle Hardware voll optimiert ist.
Darin sehe ich aber auch irgendwie ein Problem, mag aber auch an meiner
Vorliebe für elegante Architekturen liegen:
Ich denke mal, die Tatsache, daß immer mehr Leute keine Ahnung von der
Architektur haben und es ihnen eigentlich auch vollkommen egal ist,
hauptsache es läuft, hat wohl u.a. dazu geführt, daß die aktuell am
häufigsten eingesetzte Desktop-Architektur (eventuell auch Server) so
ein Monster ist, daß Hennessy und Patterson sie folgendermaßen beschreiben:
"Nevertheless, this checkered ancestry has led to an architecture that
is difficult to explain and impossible to love."
(Computer Organization & Design, 2nd edition, p. 178)

Sicherlich ist eine gewisse Konstanz, insbesondere aus ökonomischer
Sicht, wünschenswert, aber ein zwanghaftes festhalten an schlechtem
Design ist schlicht und einfach ein Innovationshemmer. Wenn ich sehe,
mit wie viel Alpha-Know-How Intel und AMD diese veraltete Architektur
beschleunigen und was inzwischen aus dem Alpha geworden ist, könnte ich
weinen.
Post by Thomas Priegl
Wenn ich also im Programm irgend eine komplexe Berechnung habe, dann
möchte ich , dass auf dem Mac automatisch Altivec verwendet wird und auf
einem Pentium SSE3 und auf einem Athlon/Itanium/HP/Sun/IBM was auch
immer (Vergleich mag hinken, ich kenne die jeweiligen Recheneinheiten
der CPUs nicht gut genug).
Wie gesagt, Autovektorisierung ist meiner Ansicht nach immer noch nicht
ganz ausgereift, u.a. weil Sprachen wie C und deren Derivate (und damit
haben wir es heutzutage überwiegend zu tun) gar nicht die Möglichkeit
bieten, dem Compiler auf Syntaxebene irgendwelche Hinweise zu geben.
Daß ein JIT-Compiler, der nicht nur halbwegs guten Code erzeugen soll,
sondern das auch noch möglichst schnell, weil es ja zur Laufzeit
passiert, beim ausreizen der SIMD-Einheiten mehr Chancen hätte,
bezweifle ich irgendwie.
Mal abgesehen davon, daß es wirklich überraschend ist, wie groß die
Unterschiede zwischen den einzelnen Instruktionssätzen sein können.
Post by Thomas Priegl
In meinem Umfeld wird niemand bereit sein mir Geld für eine Optimierung
auf die aktuelle Projekthardware zu zahlen.
Im Embedded-Bereich ist es anscheinend genau umgekehrt, da wird auf die
Hardware optimiert, damit man diese möglichst billig halten kann. Ich
kenne aber auch die andere Seite, da ich vorher überwiegend
Datenbankprogrammierung gemacht habe.
Post by Thomas Priegl
Andererseits wird
Serverseitig durchaus ein hoher Datendurchsatz und eine schnelle
Antwortzeit verlangt (zumindest in einigen Teilbereichen).
Ich darf mich gerade mit Timing im Mikrosekundenbreich beschäftigen ;-)
Post by Thomas Priegl
Wenn Hotspot heute da noch nicht gut genug ist, dann vielleicht morgen.
Es ist aber über die Jahre diesem Ziel doch sehr viel näher gekommen -
rein subjektiv ohne Benchmarks betrieben zu haben.
HotSpot ist sicherlich nicht schlecht, mir ist nur sauer aufgestoßen,
daß es eine wahrscheinlich nicht ganz so kleine Aufgabe von HotSpot ist,
die Fehler im JVM-Design auszubügeln.

[Handhabung von selbstmodifizierendem Code]
Post by Thomas Priegl
OK. Ich kann hier nicht wirklich mitreden. Hätte mich nur interessiert,
ob die vielleicht den Stein der Weisen gefunden haben.
Der einzige Stein der Weisen ist es, auf einen Cache-Flush zu reagieren.
Wenn man es aber mit einer Prozessor ohne separate D- und I-Caches zu
tun hat oder dieser Cache-Flush aus irgendwelchen Gründen automatisch
von der Hardware erledigt wird, wie bei x86-Prozessoren, dann gibt es
nur unterschiedliche Workarounds, die alle ihre Vor- und Nachteile haben.
Wie Transmeta das Problem gelöst hat, kann ich so leider nicht sagen.
--
M.I.K.e
Thomas Priegl
2005-05-11 22:24:30 UTC
Permalink
Hallo Michael,
Post by Michael Koenig
Ich hoffe ernsthaft, daß Intel die veraltete Architektur irgendwann
einstampft, und ob Cell wirklich etwas für Apple wäre?
Warum? Das einzig gute an x86 ist IMHO die Abwärtskompatibilität.
Post by Michael Koenig
Bei Cell bin ich sogar für die PS3 skeptisch, aber das liegt wohl auch
daran, daß die Performanz-Aussagen immer noch ziemlich theoretisch sind
und Sony allgemein zu Übertreibungen neigt - ich warte immer noch auf
deren Beweis, daß die PS2 10-mal leistungsfähiger als die Dreamcast ist,
was aber rein Hardware-technisch gar nicht funktionieren kann...
Ich würde mal schätzen, was den reinen Polygoncount angeht, schafft die
PS2 das sogar annähernd. Aber Polygone sind nicht alles.
Post by Michael Koenig
Ich sehe Ken Kutaragi als jemanden, der gerne mit Hardware spielt, sich
aber anscheinend nicht sehr viel Gedanken darüber macht, wie seine
Vorstellungen eigentlich in die Praxis umzusetzen sind. Die PS2 war
nicht nur sehr schwer zu programmieren, sondern auch noch voller
Hardware-Bugs. Und einem PSP-Entwickler zufolge, scheint dieses Gerät
auch die meisten der typischen PS2-Bugs, wie fehlerhaftes Clipping und
starke Rechenungenauigkeiten, geerbt zu haben. Da kann man für die
Entwickler nur hoffen, daß die PS3 vielleicht etwas weniger Bugs hat.
Und von Anfang an etwas kompletter (was API angeht) daherkommt als die
PS2: Man denke nur an die extremen Probleme mit AA zu Anfang ...
Post by Michael Koenig
Prinzipiell sehe ich aber das Problem, daß Cell sehr extrem auf
Parallelität setzt. Nur dummerweise lassen sich nicht alle Algorithmen
so einfach parallelisieren. Mal abgesehen davon, daß die wenigsten
Entwickler auf einem PowerMac wirklich die Dual-Prozessoren ausreizen.
Da müßten sie auf Cell (egal ob in der PS3 oder in einem eventuellen
Mac) doch deutlich umdenken, bei mehreren CPU-Kernen, die wiederum
mehrere Multimedia-Kerne kontrollieren (wie genau deren Funktionsumfang
aussieht, habe ich bisher auch noch nicht herausgefunden).
Nachdem ich mich schon frage, wie man Cell überhaupt in der PS3 sinnvoll
ausreizen soll, ist es bei einem all-round Computer wie einem Mac noch
fraglicher, ob man die ganzen sekundären Kerne überhaupt verwenden kann.
Einige würden ja sogar gerne zugunsten von ein oder zwei zusätzlichen
FPUs auf die AltiVec-Einheit verzichten. Ganz so sehe ich es nicht, da
inzwischen doch einiges an Multimedia-Daten verarbeitet wird, aber die
APUs in Cell würden wahrscheinlich doch die meiste Zeit brach liegen.
Ja. Und der Kern allein ist zu kastriert um für general purpose wirklich
schneller zu sein als eine "normale" CPU.
Post by Michael Koenig
Ich lasse mich gerne vom Gegenteil überzeugen, aber rein
programmiertechnisch sehe ich Cell eher als problematisch denn als
Überhammer an.
Ich bin da auch sehr skeptisch. Aber irgendwo habe ich noch die Hoffnung
(was die PS3 angeht), dass Sony vielleicht aus den Fehlern der PS2
gelernt hat. Ein Indiz dafür ist IMHO der nVidia Grafikchip.
Post by Michael Koenig
Shenmue müßte ich langsam mal spielen. Code Veronica habe ich erst auf
dem Gamecube beendet, weil ich mir auf der Dreamcast die Complete
Edition geholt habe und es mir dann doch zu blöd wurde, bei vielen
Rätseln in eine Musterlösung zu schauen, weil ich den japanischen Text
nicht verstehe.
Aber Soul Calibur ist immer noch genial, insbesondere mit dem
Sega-Arcade-Stick.
Soul Calibur ist ungeschlagen. Selbst SC2 auf dem Gamecube kommt da
nicht ran. Aber aktuell wartet Resident Evil 4 auf mich ...
Post by Michael Koenig
Anscheinend sind die Laser doch empfindlicher als die für die Module
nötigen Kontakte. Ich habe glücklicherweise immer noch eine
"Backup-Dreamcast" im Schrank ;-)
Der fehlt mir. :-)
Post by Michael Koenig
Momentan spiele ich dank World of Warcraft mehr am Mac, wenn ich denn
Zeit und Lust dazu habe. Aber ansonsten habe ich mehr als genug nicht
fertig gespielte Konsolenspiele.
Ich ebenso (was nicht durchgespiele Titel angeht).
Post by Michael Koenig
Half-Life 2 hätte mich interesssiert, aber ansonsten hat es schon lange
kein wirklich interessantes PC-Spiel gegeben, das ich nicht irgendwann
auch auf dem Mac oder einer Konsole bekommen hätte.
Ich kenne wenige "Shooter", die mich jemals interessiert hätten.
Goldeneye (N64) und Metroid Prime (GCN) gehören zu den ganz wenigen
Ausnahmen.
Post by Michael Koenig
Ich finde Java hat seine Berechtigung, wenn man im Netzwerk arbeitet und
es auf unterschiedlichsten Plattformen laufen soll. Ansonsten wird aber
Java auch für einige Dinge eingesetzt, für die es wirklich nicht
sinnvoll ist.
Bei uns ist es sogar 95% Windows. Aber allein der Vorteil, dass wir mit
Java auf dem Client und auf dem Server die selbe Sparche haben, ist immens.
Post by Michael Koenig
Ist eine Weile her, daß ich mal damit gearbeitet habe, aber ich hoffe,
daß die Grafikroutinen inzwischen schneller sind. Ich durfte mal mit
einer Art TOAD-für-Arme arbeiten, das in Java geschrieben war und Swing
einsetzte. Auf einem Pentium 3 mit 600MHz war das eine echte Qual...
Die Startzeit ist immer noch miserabel. Ansonsten reicht IMHO für Swing
ein PII mit so ungefähr 300-400 MHz. absolut aus. Viel RAM ist da
wesentlich wichtiger. Jede Swing-Applikation sollte mind. 128 MB frei haben.

Ansonsten tut das Swapping von Windows immer noch sehr weh. Weiß der
Geier warum, aber anscheinend wird da bei Java/Swing mehr ausgelagert
als bei nativen Applikationen, wenn das Programm inaktiv wird. Wenn Du
dann wieder zum Java-Programm wechselst, dann muss erst mal wieder alles
eingelagert werden. MacOS X ist da übrigens besser. Obwohl mein Mac mini
mit 512 MB da weniger RAM hat als mein Notebook mit 768 MB, führt die
Speicherverwaltung von MacOS im Endeffekt zu einem besseren Ergebnis.
Post by Michael Koenig
Darin sehe ich aber auch irgendwie ein Problem, mag aber auch an meiner
Ich denke mal, die Tatsache, daß immer mehr Leute keine Ahnung von der
Architektur haben und es ihnen eigentlich auch vollkommen egal ist,
hauptsache es läuft, hat wohl u.a. dazu geführt, daß die aktuell am
häufigsten eingesetzte Desktop-Architektur (eventuell auch Server) so
"Nevertheless, this checkered ancestry has led to an architecture that
is difficult to explain and impossible to love."
(Computer Organization & Design, 2nd edition, p. 178)
Da stimme ich Dir sogar zu. Aber was hilft mir das, wenn die Hardware
einfach billiger zu bekommen ist als die Optimierung der Software?
Post by Michael Koenig
Sicherlich ist eine gewisse Konstanz, insbesondere aus ökonomischer
Sicht, wünschenswert, aber ein zwanghaftes festhalten an schlechtem
Design ist schlicht und einfach ein Innovationshemmer. Wenn ich sehe,
mit wie viel Alpha-Know-How Intel und AMD diese veraltete Architektur
beschleunigen und was inzwischen aus dem Alpha geworden ist, könnte ich
weinen.
ACK.
Post by Michael Koenig
Wie gesagt, Autovektorisierung ist meiner Ansicht nach immer noch nicht
ganz ausgereift, u.a. weil Sprachen wie C und deren Derivate (und damit
haben wir es heutzutage überwiegend zu tun) gar nicht die Möglichkeit
bieten, dem Compiler auf Syntaxebene irgendwelche Hinweise zu geben.
Daß ein JIT-Compiler, der nicht nur halbwegs guten Code erzeugen soll,
sondern das auch noch möglichst schnell, weil es ja zur Laufzeit
passiert, beim ausreizen der SIMD-Einheiten mehr Chancen hätte,
bezweifle ich irgendwie.
Mal abgesehen davon, daß es wirklich überraschend ist, wie groß die
Unterschiede zwischen den einzelnen Instruktionssätzen sein können.
Glaube ich gerne. Und dass es einfach ist habe ich nicht behauptet. Aber
wenn ich mir Hotspot heute ansehe und das mit der JVM von vor 5 Jahren
vergleiche ... was wird man mit weiteren 5 Jahren Entwicklung in dieser
Richtung noch alles erreichen können?
Post by Michael Koenig
Im Embedded-Bereich ist es anscheinend genau umgekehrt, da wird auf die
Hardware optimiert, damit man diese möglichst billig halten kann. Ich
kenne aber auch die andere Seite, da ich vorher überwiegend
Datenbankprogrammierung gemacht habe.
Eine Stunde Arbeit von mir kostet den Kunden mind. 130 EUR. Was kostet 1
GB mehr Hauptspeicher? Was kann ich in der kurzen Zeit wirklich an
Optimierung erreichen im Vergleich zu dem, was die 1 GB mehr an RAM bringen?
Post by Michael Koenig
Ich darf mich gerade mit Timing im Mikrosekundenbreich beschäftigen ;-)
OK. Ich (bzw. Kollegen in meinem Umfeld) muß maximal Antwortzeiten im
Bereich von einigen hundert Millisekunden erreichen - und in jedem
Einzelfall garantieren können und müssen wir die auch nicht.
Post by Michael Koenig
HotSpot ist sicherlich nicht schlecht, mir ist nur sauer aufgestoßen,
daß es eine wahrscheinlich nicht ganz so kleine Aufgabe von HotSpot ist,
die Fehler im JVM-Design auszubügeln.
Möglich.
Post by Michael Koenig
Der einzige Stein der Weisen ist es, auf einen Cache-Flush zu reagieren.
Wenn man es aber mit einer Prozessor ohne separate D- und I-Caches zu
tun hat oder dieser Cache-Flush aus irgendwelchen Gründen automatisch
von der Hardware erledigt wird, wie bei x86-Prozessoren, dann gibt es
nur unterschiedliche Workarounds, die alle ihre Vor- und Nachteile haben.
Wie Transmeta das Problem gelöst hat, kann ich so leider nicht sagen.
OK. Many thanks trotzdem für die Erläuterungen.

CU
Thomas

Lesen Sie weiter auf narkive:
Loading...