Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
atari gesperrt
Anmeldungsdatum: 26.08.2007 Beiträge: 144
|
Verfasst am: 05.10.2007, 13:21 Titel: qb 4.5 nimmt soviel resourssen weg |
|
|
hallo, habe mal qb 4.5 ausprobiert mit etwas grafik und habe festgestellt das mein notebook neuester bauart probleme mit der grafikkartenerwärmung hat bei der darstellung mit grafik unter qb.
es kommt mir so vor, als wenn qb den ganzen pc in beschlag nimmt.
gibt es eine lösung um dieses für qb einzuschränken ohne leistungseinbußen? |
|
Nach oben |
|
|
csde_rats
Anmeldungsdatum: 07.01.2007 Beiträge: 2292 Wohnort: Zwischen Sessel und Tastatur
|
|
Nach oben |
|
|
atari gesperrt
Anmeldungsdatum: 26.08.2007 Beiträge: 144
|
Verfasst am: 06.10.2007, 19:28 Titel: |
|
|
jup, das war es. jetzt bleibt er kool.
mfg |
|
Nach oben |
|
|
dreael Administrator
Anmeldungsdatum: 10.09.2004 Beiträge: 2509 Wohnort: Hofen SH (Schweiz)
|
Verfasst am: 06.10.2007, 20:18 Titel: |
|
|
Die Problemursache: MS-DOS ist noch kein Multitasking-Betriebssystem, ausserdem waren in den Anfängen tragbare PCs mit netzunabhängiger Speisung aus einem Akku ebenfalls noch unüblich, womit ein Programmierer keinerlei Prozessmanagement beachten musste und einfach CPU-Leistung auch in der Tastendruck-Warteschleife konsumieren durfte.
Wer einen Blick in den Taskmanager seines Windows wirft, wird recht viele Prozesse angezeigt bekommen und sich hoffentlich auch gefragt haben, warum derjenige Prozess, mit dem man gerade arbeitet, doch insgesamt recht schnell antwortet. Dies ist nur möglich, dank dem jeder Prozess, der auf eine Eingabe (auch Ereignis übers Netzwerk) wartet, sich schlafen legt und in diesem Modus keine CPU-Leistung konsumiert. Bei Notebooks ist man sinnvollerweise noch einen Schritt weitergegangen: Wenn sämtliche Prozesse derzeit nichts zu tun haben und "schlafen", kann die CPU-Leistung massiv gedrosselt werden, womit weniger Strom verbraucht wird und somit die Akkulaufzeit verlängert wird. Diese Eigenschaft wird inzwischen auch bei den Desktops angewendet, was dort den Stromverbrauch reduziert.
Als Hinweis für Applikationsentwickler: Immerhin hat Microsoft mit INT 2Fh, AX=1680h eine CPU-Leistungszurückgabefunktion spendiert, welche man idealerweise in INKEY$-Schleifen integrieren sollte, womit auch die in QB 4.5 programmierte DOS-Applikation CPU-schonend arbeitet. _________________ Teste die PC-Sicherheit mit www.sec-check.net |
|
Nach oben |
|
|
Bimi
Anmeldungsdatum: 03.12.2007 Beiträge: 66
|
Verfasst am: 07.12.2007, 10:24 Titel: |
|
|
Ich ergänze mal ein wenig...
Wie mein Vorredner schon gesagt hattewar DOS kein Multitaskingsystem. Das ist nur ein Teil. DOS und DOS Applikationen kannten keine eventgesteuerte Programmierung.
Die Ursache der hohen CPU-Auslastung bei oftmals 100% kommt von der Architektur der damaligen Applikationen. Zu DOS-Zeiten gab es immer nur Vollgas. Die CPU arbeitet Befehle ab und das macht sie...das macht sie immer. Die CPU kennt nur die Regel "nach Befehl n führe den Befehl n+1 aus". Was aber wenn die Applikation gerade nichts zu tun hat, was soll die CPU dann ausführen. Man musste die CPU beschäftigen und diese Beschäftigung nannte sich "aktives Warten". Das Programm verhart in einer nichts-tu-endlos-schleife bis eine Benutzereingabe oder eine sonstige Aktion erfolgte - z.B. ein Tastendruck.
In einem Multitaskingsystem ist das tödlich. Die Zeit die ein Prozess in seiner Endlosschleife verbrät, fehlt anderen Prozessen. Deshalb gibt es dort einen Sheduler, der Prozesse, die nicht zu tun haben einfach schlafen legt. Nur ein Prozess schläft nie: Der Leerlaufprozess. Dieser hat eine wichtige Aufgabe, den wenn er läuft schaltet er die CPU ab. Dies wird erst beim nächsten IRQ wieder aktiv und der aktiviert den Sheduler. Hat ein andere Prozess etwas zu tun kommt er dran. Ist dieser Fertig und kein weiterer hat was zu tun, kommt der Leerlaufprozess (Null-Prozess unter UNIX) zum Zug und schaltet die CPU wieder ab. Das sprat zudem Strom und verhindert ein aufheizen der CPU.
Unter Win95 und Win98 wurde dieser Befehl nicht genutzt weil diese auch auf Rechnern laufen mussten die den Haltebefehl nicht kannten, der kam nämlich erst später. Damals konnte man diese Systeme mit einer "Softwarekühlung" nachrüsten (z.B. waterfall.exe) die genaus das machte.: Die CPU anhalten wenn sie nicht gebraucht wird.
Von alle dem weiß QB aber nichts - es ist immer noch der Ansicht man müsse die CPU beschäftigen und daher kommt es das die CPU mit Vollgas nichts macht. Das betrifft aber nicht alle DOS-Applikationen. Ob die App davon betroffen ist oder nicht hängt davon ab ob sie für Eingaben die BIOS und DOS IRQ benutzt oder nicht. MS hat in dem BIOS für die Console dafür gesorgt das dort hlt aufgerufen wird, sprich DOS Programme indirekt nachgerüstet. Wenn jedoch das Programm seinen eigenen Tastaturhandler mitbringt wei dies bei qb der Fall ist, dann nützt das ganez Bemühen nichts.
Eine weitere Methode neben der von meinem Vorredner bekannt Methode wäre es den Halte-Befehl der CPU selbst auszurufen - das geht aber nur wen qb entweder Inlineassembler kennt oder eine externe Lib einbinden kann, in der man eine entsprechende Funktion verankert.
Der Assembler Befehl ist folgender
Code: |
hlt - Hält die CPU-Ausführung an
BESCHREIBUNG
Dieser Befehl hält die Abarbeitung von Befehlen an bis ein Hardwareinterrupt auftritt. Der häufigeste hierbei ist der Timer Interrupt.
ANWENDUNG:
Der Befehl ersetzt aktive Warteschleichen (nops), spart Energie und verhindert ein zu starkes Aufheizen der CPU. Er sollte immer dann verwendet werden wenn das Programm auf ein externes Ereignis wartet
ANMERKUNG:
Dieser Befehl gehört zu den priviligierten Befehlen und steht im Protected Mode dem User-Level nicht zur Verfügung. Er ist alleine dem Kernel vorbehalten.
ACHTUNG:
hlt ist nicht auf allen Prozessoren älterer Generation verfügbar. Ab dem Pentium 1 und dessen Derivaten ist er jedoch definitiv vorhanden.
|
|
|
Nach oben |
|
|
PMedia
Anmeldungsdatum: 14.08.2006 Beiträge: 2847
|
Verfasst am: 07.12.2007, 12:00 Titel: |
|
|
Öhm....
najaaa
DOS kannte aber scho Terminate and Stay Resident (TSR), was oft für eine Art Pseudo-Multitasking ausgenutzt wurde. (Siehe DOSShell & co, wo dann auf einmal auch Alt+Tab gingen ) |
|
Nach oben |
|
|
ytwinky
Anmeldungsdatum: 28.05.2005 Beiträge: 2624 Wohnort: Machteburch
|
Verfasst am: 30.12.2007, 21:47 Titel: |
|
|
..als Terminate and Stay Resistant (nämlich bei Versuchen, diese Programme(verkehrt) zu entfernen) ausgelegt werden mußte..
(Ich hätte nicht gedacht, daß ich diesen alten Gag noch mal anbringen kann)
Gruß
ytwinky _________________
v1ctor hat Folgendes geschrieben: | Yeah, i like INPUT$(n) as much as PRINT USING.. | ..also ungefähr so, wie ich GOTO.. |
|
Nach oben |
|
|
Elvis
Anmeldungsdatum: 01.06.2006 Beiträge: 818 Wohnort: Deutschland, BW
|
Verfasst am: 31.12.2007, 00:54 Titel: |
|
|
Das Feauture, bei dem ein Prozessor während dem Betreib bis an die untere Grenze herabgetacktet wird, nennt sich bei AMD Prozessoren übrigens Cool'n'Quiet,
wie es diesbezüglich bei Intel aussieht oder dort gar die gleiche Bezeichnung verwendet wird, weiß ich nicht.
Grüße, Elvis _________________ Geforce 7300GT (256MB GDDR3, Gainward) -- 2x 512MB (DDR2 800, MDT) -- AMD Athlon64 X2 EE 3800+ -- Asrock ALiveNF5-eSATA2+ |
|
Nach oben |
|
|
Mao
Anmeldungsdatum: 25.09.2005 Beiträge: 4409 Wohnort: /dev/hda1
|
Verfasst am: 31.12.2007, 13:24 Titel: |
|
|
Hm, wenn die sich mal in einer Bezeichnung einig wären.
Nennt sich bei Intel übrigens SpeedStep.
Bringt ja aber nix bei Programmen, die den Prozessor mit Nichts-Tun-Belasten. _________________ Eine handvoll Glück reicht nie für zwei.
--
|
|
Nach oben |
|
|
dreael Administrator
Anmeldungsdatum: 10.09.2004 Beiträge: 2509 Wohnort: Hofen SH (Schweiz)
|
Verfasst am: 31.12.2007, 21:58 Titel: |
|
|
Bimi hat Folgendes geschrieben: | Deshalb gibt es dort einen Sheduler, der Prozesse, die nicht zu tun haben einfach schlafen legt. |
Eine kleine Ergänzung noch: Eine derartige Routine muss in dem Sinn der Prozess selber aufrufen! Beispiel aus UNIX/Linux-Betriebssystem: Entweder ist dies ein z.B. fread() mit blockierender I/O (Prozess fordert Daten aus z.B. /dev/ttyS0 an, aber es liegen momentan keine Zeichen an. => Betriebssystem legt diesen Prozess erst einmal "beiseite", bis Zeichen an der seriellen Schnittstelle eingetroffen sind) oder explizit mit select(): Dort übergibt ein Prozess sämtliche Datei- und Sockethandles, bei denen er auf Input wartet + optional auch ein Timeout. Das Betriebssystem "weckt" den Prozess auf, sobald an mind. 1 dieser Dateien Input anliegt und gibt auch noch bekannt, bei welchem Handle. => Verarbeitungsroutine kann gezielt dort einen fread() durchführen und Input verarbeiten.
select() braucht man üblicherweise, wenn man noch klassisch sequenziell wie QB programmiert. Moderne Sprachen und IDEs "verbergen" den select() in der Regel geschickt, in dem ein "unsichtbarer" "Super"-Prozess die jeweiligen Event-Prozeduren/Methoden aufruft, wie man sie üblicherweise in modernen GUI-IDEs verwendet. _________________ Teste die PC-Sicherheit mit www.sec-check.net |
|
Nach oben |
|
|
Bimi
Anmeldungsdatum: 03.12.2007 Beiträge: 66
|
Verfasst am: 15.01.2008, 17:20 Titel: |
|
|
Mao hat Folgendes geschrieben: |
Bringt ja aber nix bei Programmen, die den Prozessor mit Nichts-Tun-Belasten. |
...erinnert mich an die Zeit vor etwa 9 Jahren. Damals ließ sich Windows 95 nicht auf dem nigelnagelneuen AMD Athlon (K7) installieren.
Ursache:
Die Boot-Routine von Windows 95 enthielt eine Warteschleife für aktives Warten mittels nop's.
Der Athlon allerdings hatte bereits in der PF-Queue eines Logik welche nops wenn diese in höherer Anzahl auftauchten einfach übersprangen und nicht mehr ausführten.
Die Folge:
Die Schleife wartete nicht mehr.... _________________ Rechtbehelf:
Rechschreibverfehlungen, Vergehen an der Deutschen Sprache sowie Stabwechselverbuchselungen unterliegen dem Urheberrecht, sind voll beabsichtigt und fördern das aufmerksame Lesen. |
|
Nach oben |
|
|
|