Wie einem 16-Bit-Programm 100% CPU zuweisen?

wolfgangbeyer

Newbie
Registriert
Juli 2008
Beiträge
5
Hallo,

Offensichtlich gestattet XP einen 16-Bit-Programm nur wenige Prozent CPU-Zeit. Erst wenn ich auf meinem PC (mit Core2Duo) mehr als 25 Tasks dieser Art starte, nimmt die Ausführungsgeschwindigkeit pro Task überhaupt ab und sinkt dann bei 50 Tasks auf ca. 50%. Wie kann ich Windows anweisen, ein 16-Bit-Programm mit 100% CPU-Power auszuführen?

Aufruf mit anderer Priorität z. B. per "start /high ..." hat keinen Einfluss. Das Programm löst numerische Probleme und ist für unser Institut sehr wichtig.

Danke für einen Hinweis!
 
Willkommen auf CB!
Hab zwar so richtig keine Ahnung davon aber hast du es schonmal mit dem Programmkompabilitätsassistenten probiert?Könnte vllt klappen.
 
Hi,
ich wüde mal eher tippen, dass das Programm nicht mit mehr CPU-Auslastung laufen kann, da es 16-Bit ist und somit auch nicht mit vollem Register genutzt werden kann. Sollten dann auch noch viele If-Anweisungen und Schleifen drinn sein gehts einfach mal nicht schneller. Wenn du den Quellcode hast würd ichs mal durch nen 32Bit Compiler schicken und evtl. besser anpassen (wenig Schleifen etc.)
 
ist ein Denkfehler von deiner Seite.

Man kann einem Programm nicht einfach so CPU Ressourcen zuweisen. Ein 16-Bit Programm kann von seiner Programmierung aus, keinen Dual Core ausnutzen. Man kann dem Programm einen Core zuweisen, aber das war es dann schon.

Vllt. hilft es, das Programm im Real-Modus(Echtzeit) laufen zu lassen.

Wenn man den Quellcode hat, kann man es umschreiben.
 
Danke für Eure Tipps, aber

ftotheC schrieb:
... hast du es schonmal mit dem Programmkompabilitätsassistenten probiert?
Da sehe ich keine Möglichkeit. Kompatibilität ist ja auch nicht das Problem.

axi schrieb:
ich wüde mal eher tippen, dass das Programm nicht mit mehr CPU-Auslastung laufen kann, da es 16-Bit ist und somit auch nicht mit vollem Register genutzt werden kann.
Das ist keine Erklärung dafür, dass 25 parallele Tasks laufen können, ohne dass einer davon langsamer ist als ein einzeln laufender, wie ich schrieb. Ich habe mal mit einem kleinen Testprogramm, das nichts als 8-Byte-Multiplikationen macht, ausprobiert, dass ich mit 25 parallelen 16-Bit-Tasks insgesamt etwa genauso schnell bin wie 2 Visual-Basic-Tasks (wegen Core2Duo), die dasselbe machen – eher sogar 30% schneller.

axi schrieb:
... evtl. besser anpassen (wenig Schleifen etc.)
Weniger Schleifen? Netter Scherz ...

frogger9 schrieb:
Man kann einem Programm nicht einfach so CPU Ressourcen zuweisen.
Du schreibst das, als wäre es selbstverständlich. Für mich ist das eine schwere Betriebssystemschwäche. Aber in dieser Hinsicht sind wir ja Kummer gewöhnt ...

frogger9 schrieb:
Man kann dem Programm einen Core zuweisen, ...
Wie macht man das eigentlich? Einen entsprechenden Parameter für das Kommando "start" oder in einem Programmlink scheint es ja nicht zu geben.

frogger9 schrieb:
Vllt. hilft es, das Programm im Real-Modus(Echtzeit) laufen zu lassen.
Leider nein. Ich erwähnte ja schon, dass die Prozesspriorität ohne Einfluss ist.

frogger9 schrieb:
Wenn man den Quellcode hat, kann man es umschreiben.
Schon, wenn man die paar Monate Zeit hat ca. 150kB Quelltext fehlerfrei zu übersetzen ...

Das Problem ist leider noch ungelöst.
 
Du kannst im TaskManager einstellen wieviele Cores ein Programm nutzen kann.
Einfach rechte Maustaste auf den Prozess und dann auf "Zugehörigkeit festlegen..."
Dort kannst dann entweder Core0 oder Core1 auswählen wennst einen C2D hast.

Was tut dein Programm eigentlich, vielleicht gibts eine Alternative dazu :confused_alt:
 
Danke für den Hinweis. Wenn das die einzige Möglichkeit ist, wäre das ein weiteres Armutszeugnis: Zum einen erfordert es einen manuellem Eingriff, zum anderen steht man dumm da, wenn mehrere Instanzen eines Programms laufen, man aber nur eine bestimmte konfigurieren will.

Eigentlich ist es eine Palette von ca. 20 gleichartigen Ray-Tracing-Programmen für die Lichtverteilung jeweils für eine bestimmte geometrische und materielle Situation unter Berücksichtigung von Volumenstreunung und Fluoreszenz und mit verschiedensten Fragestellungen. Heute kann man solche Programme auch kaufen, z. B. die Expertenversion von TracePro für ca. 20.000€ und mit entsprechendem Einarbeitungs- und Programmieraufwand ...
 
Genausogut ist denkbar, dass die 16-Bit Anwendung multithreaded ist und schlecht optimiert mit hohem Idle-Anteil läuft. Wäre das modernere Povray keine Alternative?
 
Es sind selbstgeschriebene Programme für Borland Turbobasic 1.0. Das gab’s mal so um 1990, wurde aber dann nicht weiterentwickelt. Multithreading war da noch kein Thema. Der Output von Povray dürfte sich auf Bilder beschränken. Fragestellungen, wie z.B. wieviel Fluoreszenzlicht kann ich mit einer Glasfaser, eingestochen in biologisches Gewebe, sammeln, wenn ich von außen eine bestimmte Lichtverteilung einstrahle und welche Raumbestrahlungsstärke herrscht in einer bestimmten Gewebetiefe u. a., kann man damit vermutlich nicht beantworten.
 
wolfgangbeyer schrieb:
Du schreibst das, als wäre es selbstverständlich. Für mich ist das eine schwere Betriebssystemschwäche. Aber in dieser Hinsicht sind wir ja Kummer gewöhnt ...

Für mich ist das eine ziemlich blödsinnige Bemerkung.

Das Problem ist leider noch ungelöst.
..
Es sind selbstgeschriebene Programme für Borland Turbobasic 1.0.

Versuch's mal mit einer Dos 3.3-Bootdiskette. Das war vor ~ 20 Jahren mal das aktuelle Betriebssystem.
 
Liegt es vielleicht daran, dass die 16-Bit-Programme
a) gar nicht nativ auf einem 32-Bit-System laufen (sondern unter WOWEXEC laufen)
b) kooperatives Multitasking durchführen...
das dürfte erklären, warum man den Prozessen keine höhere Priorität und dergleichen zuweisen kann... die geringe Ausführungsgeschwindigkeit erklärt es aber meiner Meinung nach noch nicht
 
Turbo Basic 1.0 ist wohl nicht gerade Heutiger Standard. Stammt wirklich noch aus der Zeit von XTler.

TB nutzt nur 64KB Speicher, egal ob du 1GiB hast.
 
1668mib schrieb:
... sondern unter WOWEXEC laufen

Ein Task WOWEXEC.EXE ist im Taskmanager nicht zu sehen.

frogger9 schrieb:
TB nutzt nur 64KB Speicher, egal ob du 1GiB hast.

Das ist das Limit für ein Zahlen- oder Stringfeld. Insgesamt werden schon 640KB genutzt.

Ein Stück weit hat sich die Angelegenheit geklärt: Ursache scheinen (zu) häufige Aufrufe der Uhrzeit (Statement „timer“) zu sein. Wenn ich das auf wenige pro Sekunde reduziere, kann ich mit 2 Tasks meinen Core2Duo voll auslasten, wie erwartet. Die Performance eines Tasks ist dann auch genau so hoch, wie wenn ich das Programm unter nacktem Dos (Dos-Boot-Diskette) ausführe.

Seltsamerweise bricht aber die Performance nach 5s dann aber wieder völlig ein. Sie lässt sich jedoch merkwürdigerweise aufrechterhalten, wenn man mindestens alle 5s irgendwas auf den Bildschirm schreibt. Komischerweise kann ich dieses Gesamtverhalten aber nicht mit einem Testprogramm reproduzieren, so dass evtl. noch andere Faktoren eine Rolle spielen. Aber mit dieser Lösung kann ich erst mal leben.
 
Naja es handelt sich um DOS-Programme? Kein Wunder, dass da kein WoWExec zum Einsatz kommt...
WoWExec ist das 16-Bit-Windows-Untersystem.
 
Zurück
Oben