Hardware > Emulatoren

Magic_PC mit zu hoher Prozessorlast

<< < (7/8) > >>

Dabbeljubie:
Das habe ich oben schon verstanden. Aber wenn der Aufrufteil (MagiC_PC.exe) bereits die Prozessoren zu sehr beschäftigt, kann doch etwas Zusätzliches (deine MagiC_PC.os) die Gesamt-Belastung doch nicht auch noch senken? Wie gesagt: Wenn es gar keine MagiC_PC.os gibt, gibt es auch keine zusätzliche Last und trotzdem schafft sich ja die MagiC_PC.exe schon ganz allein müd' und kaputt.?!?

goetz @ 3rz:

--- Zitat von: Dabbeljubie am Di 22.03.2022, 20:53:08 ---Das habe ich oben schon verstanden. Aber wenn der Aufrufteil (MagiC_PC.exe) bereits die Prozessoren zu sehr beschäftigt, kann doch etwas Zusätzliches (deine MagiC_PC.os) die Gesamt-Belastung doch nicht auch noch senken? Wie gesagt: Wenn es gar keine MagiC_PC.os gibt, gibt es auch keine zusätzliche Last und trotzdem schafft sich ja die MagiC_PC.exe schon ganz allein müd' und kaputt.?!?

--- Ende Zitat ---

Ich denke dein Nachfragen invalidiert den ersten Satz, wenn ich den VP richtig verstanden habe :) Code (MagiCPC) + Code (MagiC-OS) = mehr Code, meinst du? Nicht wenn man im zweiten Teil Code einbaut der der CPU Zeit zum verschnaufen gibt.

Dabbeljubie:

--- Zitat ---Nicht wenn man im zweiten Teil Code einbaut der der CPU Zeit zum verschnaufen gibt.
--- Ende Zitat ---
Wenn, und nur wenn tatsächlich anstelle des "Stresscodes" im Windows-Teil ein "Verschnauf-Code" im Atari-Teil ausgeführt wird. Da wir aber bei Windows ebenfalls präemptiv mit und in interrupts unterwegs sind, habe ich Zweifel, dass da Emulationscode die Situation verbessern kann. Wie gesagt: Was während der Emulation hilft, ist der Pausen-Mode oder wenn ein Windowsfenster-Menü runtergeklappt wird. Bei den Menüs ist es dann wohl so, dass MPC alles stehen und liegen lässt und Windows selbst recourcenschonend (nur) die Bedienbarkeit der Menüs gewährleisten muss. Daher die 2 % Last oder so.

In welcher Sprache sind denn die freigegebenen Sourcen für den Kernel?

Thorsten Otto:
Ich bin es echt ein bisschen leid das immer wieder zu erklären. Glaub mir einfach mal daß ich (normalerweise) weiss was ich da tue.

Ich vermute in dem Fall sehr stark, daß dort ein anderer Thread neben der Emulation aktiv ist der die CPU Zeit verbrät (vermutlich einer der den Bildschirm aktualisiert). Das wäre blöd, weil ich da von der Emulation aus nicht dran komme ohne genau zu wissen was intern passiert, was dann wiederum auf eine Analyse der EXE hinaus läuft.

DIe Sourcen für den Kernel sind grösstenteils in Assembler.

Dabbeljubie:

--- Zitat ---Ich bin es echt ein bisschen leid das immer wieder zu erklären.
--- Ende Zitat ---
Das musst du nicht, denn wir haben uns eigentlich gut genug verstanden.

--- Zitat ---Glaub mir einfach mal daß ich (normalerweise) weiss was ich da tue.
--- Ende Zitat ---
Es geht nicht darum, was du tust. Ich sage dir, dass es zwar ehrbar von dir ist, dass du am Kernel etwas verändern willst, was Fehler-Code wo ganz anders egalisieren soll, aber ich bezweifle, dass das klappt. Das hatte ich geschrieben und jetzt hoffe ich, dass ich Unrecht behalte und du vielleicht doch was findest, bin aber eben nicht optimistisch.


--- Zitat ---daß dort ein anderer Thread neben der Emulation aktiv ist der die CPU Zeit verbrät (vermutlich einer der den Bildschirm aktualisiert)
--- Ende Zitat ---
Das Problem bei dieser Idee ist doch, dass diese Bildschirmaktualisierung ohne die Emulation gar nichts hätte, was sie aktualisieren könnte. Fehlt die ganze Emulationsdatei, müsste die EXE eigentlich Däumchen drehen und schimpfen. Letzteres tut sie dann auch, wenn man MagiC_PC.os wegläßt, denn es kommt dann ein Dialog mit "C:\MPC_620\MagiC_PC.os nicht gefunden!", aber sie tobt dabei trotzdem weiter.

Dein Ansatz "daß dort ein anderer Thread neben der Emulation aktiv ist der die CPU Zeit verbrät", ist garantiert richtig. Vermutlich irgendwas, was dauernd laufen muss, um die Emulation an einigen Ecken zu checken. Und das passiert sogar dann, wenn gar keine Emulation da ist.  >:(

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete