Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

qb 4.5 nimmt soviel resourssen weg

 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Spezielle Fragen
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
atari
gesperrt


Anmeldungsdatum: 26.08.2007
Beiträge: 144

BeitragVerfasst am: 05.10.2007, 12:21    Titel: qb 4.5 nimmt soviel resourssen weg Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
csde_rats



Anmeldungsdatum: 07.01.2007
Beiträge: 2292
Wohnort: Zwischen Sessel und Tastatur

BeitragVerfasst am: 05.10.2007, 13:19    Titel: Antworten mit Zitat

Das liegt nur an der CPU: http://forum.qbasic.at/viewtopic.php?t=2172
_________________
If hilfreicher_Beitrag then klick(location.here)

Klick
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
atari
gesperrt


Anmeldungsdatum: 26.08.2007
Beiträge: 144

BeitragVerfasst am: 06.10.2007, 18:28    Titel: Antworten mit Zitat

jup, das war es. jetzt bleibt er kool.

mfg
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
dreael
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 2507
Wohnort: Hofen SH (Schweiz)

BeitragVerfasst am: 06.10.2007, 19:18    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Bimi



Anmeldungsdatum: 03.12.2007
Beiträge: 66

BeitragVerfasst am: 07.12.2007, 09:24    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
PMedia



Anmeldungsdatum: 14.08.2006
Beiträge: 2847

BeitragVerfasst am: 07.12.2007, 11:00    Titel: Antworten mit Zitat

Ö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 lächeln )
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ytwinky



Anmeldungsdatum: 28.05.2005
Beiträge: 2624
Wohnort: Machteburch

BeitragVerfasst am: 30.12.2007, 20:47    Titel: Antworten mit Zitat

PMedia hat Folgendes geschrieben:
DOS kannte aber scho Terminate and Stay Resident (TSR), was oft
..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) vor lachen auf dem Boden rollen
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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Elvis



Anmeldungsdatum: 01.06.2006
Beiträge: 818
Wohnort: Deutschland, BW

BeitragVerfasst am: 30.12.2007, 23:54    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Mao



Anmeldungsdatum: 25.09.2005
Beiträge: 4409
Wohnort: /dev/hda1

BeitragVerfasst am: 31.12.2007, 12:24    Titel: Antworten mit Zitat

Hm, wenn die sich mal in einer Bezeichnung einig wären. grinsen
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
Benutzer-Profile anzeigen Private Nachricht senden
dreael
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 2507
Wohnort: Hofen SH (Schweiz)

BeitragVerfasst am: 31.12.2007, 20:58    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Bimi



Anmeldungsdatum: 03.12.2007
Beiträge: 66

BeitragVerfasst am: 15.01.2008, 16:20    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Spezielle Fragen Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.

 Impressum :: Datenschutz