CPU Kerne umschalten / überlasten ... [erledigt]

Alles was nicht wirklich Programmierung ist, aber auch nicht Plaudereien im Raucherraum

Moderator: Moderatoren

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11424
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

CPU Kerne umschalten / überlasten ... [erledigt]

Beitrag von AUGE_OHR » Di, 30. Okt 2012 5:30

switch_CPU.PNG
switch_CPU.PNG (41.15 KiB) 5357 mal betrachtet
brandelh hat geschrieben:
AUGE_OHR hat geschrieben:
brandelh hat geschrieben:Und selbstverständlich kann man die EXE so erstellen, dass die Anwendung alle CPUs nutzt.
:shock: und "wie" ???
http://www.xbaseforum.de/viewtopic.php? ... 799&p=7932
NEIN !!! du kannst nur die CPU "umschalten" auf eine andere CPU ... aber es arbeitet nur 1 x CPU !!!

unter Win7 probiere mal Taskmanager -> 2nd Tab "Processe" -> Xbase++ Application -> rechte Maustaste und du siehst das
only_one_CPU.png
only_one_CPU.png (15.13 KiB) 5357 mal betrachtet
wenn du das anklickst kommt das
switch_CPU.PNG
switch_CPU.PNG (41.15 KiB) 5357 mal betrachtet
nun kannst du jede "einzelne" CPU auswählen und es läuft ... aber nicht "mehr" als 1 x CPU ... oder gar "alle Prozessoren" [-X

es gibt nur dann eine Ausnahme wenn man mit einer "externen" DLL / OCX, die im eigenen Thread läuft, arbeitet wie Mappoint.
das ist aber dann die DLL / OCX welche "intern" mit mehreren CPUs arbeiten kann.
Zuletzt geändert von AUGE_OHR am Fr, 16. Nov 2012 7:17, insgesamt 1-mal geändert.
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14547
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitrag von brandelh » Di, 30. Okt 2012 7:27

AUGE_OHR hat geschrieben:NEIN !!! du kannst nur die CPU "umschalten" auf eine andere CPU ... aber es arbeitet nur 1 x CPU !!!
wie kommst du darauf ?
Die EXE wird schon seit zig Jahren auf eine CPU begrenzt, weil die Anwendung auf 2 langsamer läuft.
Das könnte man beim linken abstellen und natürlich auch zur Laufzeit - ich habe hier die 2 CPU zugeschaltet (das ginge bei deinem Bild auch !):
CPUs.png
CPUs.png (15.45 KiB) 5350 mal betrachtet
und im Taskmanager kann man auch sehen, dass die Priorität der EXE auf "normal" steht.

PS: Das regelt auf welche CPUs die Anwendung sich und ihre Threads verteilen darf (bzw. das Betriebssystem), nicht auf welchem Kern es tatsächlich auch läuft.
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11424
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitrag von AUGE_OHR » Mi, 31. Okt 2012 0:41

brandelh hat geschrieben:Die EXE wird schon seit zig Jahren auf eine CPU begrenzt,
sag ich doch
brandelh hat geschrieben:weil die Anwendung auf 2 langsamer läuft.
das ist noch eine andere Sache ...
brandelh hat geschrieben:Das könnte man beim linken abstellen und natürlich auch zur Laufzeit - ich habe hier die 2 CPU zugeschaltet (das ginge bei deinem Bild auch !):
...
und im Taskmanager kann man auch sehen, dass die Priorität der EXE auf "normal" steht.
hm ... :-k DAS verwundert mich aber :shock: ( was ist das für eine CPU ... )

ich kann zwar jede "normale" Windows Application mit "mehreren" CPUs laufen lassen aber NICHT Xbase++ Applicationen !?

wie soll man das den "beim linken" gemacht werden ? oder meinst du per Manifest ?
brandelh hat geschrieben:PS: Das regelt auf welche CPUs die Anwendung sich und ihre Threads verteilen darf (bzw. das Betriebssystem), nicht auf welchem Kern es tatsächlich auch läuft.
bei mehreren CPU möchte ich nur nicht das Xbase++ mit die CPU "zerkocht" während der Rest nichts tut.

das "Problem" ist dabei der "Turbo" Modus der Intel i5 / i7 die ja praktisch "übertakten".
das "übertakten" ist kurzfristig ja ok ( 80 - 90° ) aber wenn er "stundenlang" auf nur 1 CPU bei 100° hängt und der Rest bei 48° dann ist das bestimmt nicht gut für die CPU.
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14547
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitrag von brandelh » Mi, 31. Okt 2012 10:00

AUGE_OHR hat geschrieben:
brandelh hat geschrieben:Das könnte man beim linken abstellen und natürlich auch zur Laufzeit - ich habe hier die 2 CPU zugeschaltet (das ginge bei deinem Bild auch !):
...
und im Taskmanager kann man auch sehen, dass die Priorität der EXE auf "normal" steht.
hm ... :-k DAS verwundert mich aber :shock: ( was ist das für eine CPU ... )
Das Bild entstand auf meinen Arbeitsplatzrechner mit XP Pro SP3 auf 'AMD Athlon 64 X2 4600+' (also nicht wirklich 2 CPU, sondern 1 CPU mit 2 Kernen).
Ich kann entweder nur eine CPU auswählen (also umschalten, geht gut) oder beide, dann wird die EXE aber extrem langsam (macht keinen Sinn).

Testweise habe ich es auch noch auf meinem neuen Arbeitsplatzrechner getestet (Windows 7, Intel i5-25..) dort konnte ich "alle" oder einzelne CPUs auswählen (tatsächlich die Kerne)
solange ich einen auswählte (umschalten, geht gut) geht alles wunderbar, aber bei mehreren wird die "Hybrid" Anwendung so langsam, dass Windows "Anwendung reagiert nicht mehr" moniert.
Dann bleibt nur Task beenden. Ob es bei GUI Anwendungen auch so wäre habe ich nicht probiert.

Also grundsätzlich geht die Umschaltung und Festlegung auf eine andere CPU, die Freigabe für mehrere CPUs (Kerne) gleichzeitig müsste man mit dem Linker (resourcen) hinbekommen.
Allerdings bin ich hierbei überfragt, es ist ewig her und macht keinen Sinn, daher habe ich es nie probiert.

Ursprünglich waren alle EXE für alle CPUs (Kerne) freigegeben und ich meine Alaska erwähnte bei den Threads noch die "gute Skalierbarkeit" auf Rechnern mit mehreren CPUs, damals gab es aber kaum welche und die waren teuer.
Erst als die ersten AMD Doppelkerne bezahlbar wurden, stellten alle fest, dass die Xbase++ EXE langsamer auf den X2 liefen als auf den alten Rechnern mit einer CPU.
Damals entstand - meine ich - auch der Beitrag den ich oben zitiert habe und Alaska hat darauf reagiert und die EXE auf eine CPU begrenzt und Funktionen eingeführt um die CPU wecheln zu können (ich meine mit der 1.90.331).
AUGE_OHR hat geschrieben:bei mehreren CPU möchte ich nur nicht das Xbase++ mit die CPU "zerkocht" während der Rest nichts tut.
das "Problem" ist dabei der "Turbo" Modus der Intel i5 / i7 die ja praktisch "übertakten".
das "übertakten" ist kurzfristig ja ok ( 80 - 90° ) aber wenn er "stundenlang" auf nur 1 CPU bei 100° hängt und der Rest bei 48° dann ist das bestimmt nicht gut für die CPU.
jetzt muss man genau werden.

Hast du wirklich einen Rechner mit 2 oder mehr i5 oder i7 Prozessoren ?

Vermutlich nicht, sondern du meinst, dass die i5 bzw. i7 einen Kern aufheizen (100°) und die restlichen bei 48° dahin schlafen ?

Jimmy du machst dir unnötige Sorgen.

Erstens ist ja genau wegen Programmen die nicht sauber skalieren der "Turbomodus" eingeführt worden und zweitens wird NIE nur ein Kern 100° heiß und die anderen nicht. Intel hat die i5 und i7 so gut hinbekommen, dass die selbst am Besten auf sich aufpassen und die wenige Energie (TDP 75 Watt oder so ? ) sauber und leise auf den Kühler ableiten.
Die CPU wird wegen Xbase++ Programmen sicherlich nicht beschädigt, im Vergleich zu aktuellen Spielen langweilt sich die CPU .
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11424
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitrag von AUGE_OHR » Do, 01. Nov 2012 1:17

hi,

könnte man den CPU / Performance Teil in einen extra Thread verschieben ?
brandelh hat geschrieben:Testweise habe ich es auch noch auf meinem neuen Arbeitsplatzrechner getestet (Windows 7, Intel i5-25..) dort konnte ich "alle" oder einzelne CPUs auswählen (tatsächlich die Kerne)
solange ich einen auswählte (umschalten, geht gut) geht alles wunderbar, aber bei mehreren wird die "Hybrid" Anwendung so langsam, dass Windows "Anwendung reagiert nicht mehr" moniert.
Dann bleibt nur Task beenden. Ob es bei GUI Anwendungen auch so wäre habe ich nicht probiert.
also ich nehme MDIDEMO, starte es und wähle "eine" andere CPU ... läuft.
sobald ich "mehr" als 1x CPU ankreuze oder gar "alle" und dann ok klick -> MDIDEMO hängt ... :banghead:
brandelh hat geschrieben:Vermutlich nicht, sondern du meinst, dass die i5 bzw. i7 einen Kern aufheizen (100°) und die restlichen bei 48° dahin schlafen ?
YUP z.b. i7-2630QM
brandelh hat geschrieben:Die CPU wird wegen Xbase++ Programmen sicherlich nicht beschädigt, im Vergleich zu aktuellen Spielen langweilt sich die CPU
der Turbo-Mode ist aber NICHT für "Dauergebrauch" ausgelegt und springt auch bei aktuellen Spielen nicht "auf Anschlag".

tatsächlich wurde "vermutlich" bei einem neuen Kunden von mir ein i7, durch eine Cl*pper Applikation ohne IAMIDLE.OBJ , "zerkocht" ... alle 8 CPUs in Betrieb ... 10Std / Tag ... 3 Wochen ...

btw. eine CMD Box läuft auf allen CPUs !

man kann es es ganz leicht mit dem "original" DBU bewerkstelligen das der Lüfter anspringt und CPU 1,3,5,7 hoch-schnellt obwohl man nur DBU aufgerufen hat ... und die HD ist auch am arbeiten (nix geöffnet) und das obwohl Swapdisk abgeschaltet ... ( 8GB RAM , davon 2,74 GB unter 32bit )
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14547
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Diskussion zu "Wissensbasis - MySQL Wrapper von Hector P

Beitrag von brandelh » Do, 01. Nov 2012 18:22

AUGE_OHR hat geschrieben:tatsächlich wurde "vermutlich" bei einem neuen Kunden von mir ein i7, durch eine Cl*pper Applikation ohne IAMIDLE.OBJ , "zerkocht" ... alle 8 CPUs in Betrieb ... 10Std / Tag ... 3 Wochen ...
Na UND ?

Erstens ist eine CLIPPER APP keine Xbase++ APP und zweitens MUSS DIE CPU runterregeln, wenn sie zu heiß wird :!:
Das ist schon seit vielen Jahren so und vorher war bestenfalls der schlechte Lüfter schuld, aber NIE DIE SOFTWARE :!:

Es gibt zwar englische Sportwagen (aus den 60er Jahren) die nicht "vollgastauglich" sind, aber bei einem PC dürfen wir und nicht einreden lassen unsere Software kann den Prozessor wegen Überlastung schrotten [-X
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11424
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

CPU ...

Beitrag von AUGE_OHR » Fr, 02. Nov 2012 7:00

brandelh hat geschrieben:Erstens ist eine CLIPPER APP keine Xbase++ APP
Cl*pper verteilt es wenigstens an "alle" CPUs ;)
brandelh hat geschrieben: und zweitens MUSS DIE CPU runterregeln, wenn sie zu heiß wird :!:
noch nie eine "verbrannte" CPU gehabt ?
brandelh hat geschrieben:Das ist schon seit vielen Jahren so und vorher war bestenfalls der schlechte Lüfter schuld,
ich rede auch nicht von schlechter Luftzufuhr, es ist ja nicht nur die CPU, auch das "Umfeld" bekommt ja was ab
... aufgeplatzte Kondensatoren sind meistens in der nähe der CPU zu beobachten !
brandelh hat geschrieben:aber NIE DIE SOFTWARE :!:
oh da kenne ich so einen Fall ... allerdings nicht CPU

es gab einmal einen Nvidea GFK Treiber der die NEC 3D mit 120Hz (statt 60Hz) laufen liessen und damit die Hardware "zerstörte" ... inklusive Ersatz ( Garantie ).
ich hab dann den Fall auf der Cebit einem NEC Techniker erzählt, ... zuerst fangen die NEC 3D an zu pfeifen .. dann fällt das Bild zusammen -> ausmachen -> warten ... anschalten [-o<
der NEC Techniker gab mir dann ein kleines Plastik Teil mit einer Anzeige ... das Teil sollte ich mal vor den NEC 3D Monitor halten.
gesagt getan und was kam beim Kunden raus -> 120Hz :banghead:

aber das ist Vergangenheit, bei der heutigen Hardware habe ich das Gefühl das die nicht mehr so "belastbar" ist wie früher.
die "Turbo" Technik, was früher übertakten genannt wurde, ist IHMO nicht für Dauerbetrieb in Notebooks ausgelegt ( wo es keine H2O Kühlung gibt ) ... und unter Xbase++ auch nur auf einer CPU

und damit wäre ich wieder bei der Frage
brandelh hat geschrieben:
Und selbstverständlich kann man die EXE so erstellen, dass die Anwendung alle CPUs nutzt.
was ich immer noch nicht mit Xbase++ hin bekomme ...

p.s. mehr zum Thema Xbase++ MT hier http://cch4clipper.blogspot.de/search/l ... .%20Pirsig
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14547
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: CPU Kerne umschalten / überlasten ...

Beitrag von brandelh » Fr, 02. Nov 2012 10:04

>> Erstens ist eine CLIPPER APP keine Xbase++ APP

> Cl*pper verteilt es wenigstens an "alle" CPUs ;)

Clipper verteilt GAR NICHTS ! es läuf tin einer single CPU Dosbox !
Möglicherweise ist WINDOWS in der Lage 16 Bit CMD Boxen auf verschiedene CPUs zu verteilen, das weiß ich nicht,
aber CLIPPER steuert es garantiert nicht :!:

>> und zweitens MUSS DIE CPU runterregeln, wenn sie zu heiß wird :!:
> noch nie eine "verbrannte" CPU gehabt ?

Nein, eine Athlon A mit offendem DIE habe ich mal unsanft verkantet, die lief dann nicht mehr.
Aber im Betrieb habe ich noch keine geschrottet.
Gruß
Hubert

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 7287
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: CPU Kerne umschalten / überlasten ...

Beitrag von Tom » Fr, 02. Nov 2012 10:16

Es hat keinen Sinn, eine Xbase++-Applikation auf mehreren CPUs laufen zu lassen, denn das Design der Apps und die Struktur der Laufzeitumgebung geben das nicht her; es gibt einfach keine Aufgaben, die man so verteilen könnte. Was Sinn hätte, wäre die Möglichkeit, Module, die in separaten Threads laufen, auf andere CPUs zu verteilen, also die Umschaltung nur für einzelne Threads zuzulassen: Main() läuft auf CPU 1, im Thread gestartetes Modul XY läuft auf CPU 2 - usw.
Herzlich,
Tom

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14547
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: CPU Kerne umschalten / überlasten ...

Beitrag von brandelh » Fr, 02. Nov 2012 12:53

=D>
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11424
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: CPU Kerne umschalten / überlasten ...

Beitrag von AUGE_OHR » Fr, 02. Nov 2012 23:34

@Tom und Hubert
genau deshalb habe ich auf den Thread verwiesen http://cch4clipper.blogspot.de/search/l ... .%20Pirsig

es liegt am OS/2 Design von Xbase++ dessen Philosophie von Steffen als in die Windows Welt portiert wurde.
harbour geht bei MT den "normalen" Windows Weg ... ohne Kompromisse an "Altlasten".

richtig ist wohl das es viel Arbeit wäre für Alaska es auf "echtes" MT umzustellen ... soviel wie alles von "A" (Ansi) auf "W" (UTF-8) umzustellen.
richtig ist wohl auch das es dafür keine Fördergelder gäbe ... für Subscriptionen gibt es solche Arbeiten nicht.

p.s. harbour MT kann man so konfigurieren das es sich ähnlich wie Xbase++ verhält ... aber warum sich "einschränken" ...
gruss by OHR
Jimmy

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11424
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: CPU Kerne umschalten / überlasten ...

Beitrag von AUGE_OHR » Fr, 02. Nov 2012 23:36

brandelh hat geschrieben:> Cl*pper verteilt es wenigstens an "alle" CPUs ;)
Clipper verteilt GAR NICHTS ! es läuf tin einer single CPU Dosbox !
YUP ... und die benutzt "alle" CPUs und 100% ... deshalb auch Cl*pper ... oder DBU.EXE ( im original )

aber es steht immer noch dein Zitat
Und selbstverständlich kann man die EXE so erstellen, dass die Anwendung alle CPUs nutzt.
ich kann diese Aussage NICHT nachvollziehen.

das Sample C:\ALASKA\XPPW32\Source\samples\solution\smp\smprun.prg läuft auf keinen von meinen PC auf Stellung "3"
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14547
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: CPU Kerne umschalten / überlasten ...

Beitrag von brandelh » Sa, 03. Nov 2012 10:55

AUGE_OHR hat geschrieben:das Sample C:\ALASKA\XPPW32\Source\samples\solution\smp\smprun.prg läuft auf keinen von meinen PC auf Stellung "3"
das bedeutet aber, dass die Freigabe auf alle Prozessoren funktioniert, aber je nach OS und Prozessor schläft die Anwendung oder hängt sich auf :D

Es ist aber auch sinnlos, weil Xbase++ Programme selten zu der Gattung gehören, die durch mangelnde Prozessorleistung eines Kernes leiden.

Beispiel aus dem Leben:
Du möchtest Brötchen vom Ort A schneller im Ort B verteilen (Landstraße 10 KM) ...
Mit dem Fahrrad dauert das etwas,
mit dem Kleinwagen geht es schneller (25 km => 100 km, aber Parkplatzsuche dauert etwas länger).
Mit dem Porsche des Nachbarn geht es nicht mehr schneller, denn die Endgeschwindigkeit des Fahrzeuges war nicht der Engpass ...
im Gegenteil, der Porsche ist schlechter beim Parken (unübersichtlicher, größer), es könnte also durchaus langsamer sein.

Daher kamen wir damals zu dem Schluss, dass es sinnvoller ist auf Serversystemenen die CPU per Zufallssteuerung auszuwählen, aber die EXE auf einem Kern zu lassen.
PS: Ich weiß natürlich nicht, wie man die EXE schon beim LINKEN auf alle Prozessoren freigibt, da ALINK offensichtlich die Begrenzung setzt.
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11424
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: CPU Kerne umschalten / überlasten ...

Beitrag von AUGE_OHR » So, 04. Nov 2012 5:57

brandelh hat geschrieben:
AUGE_OHR hat geschrieben:das Sample C:\ALASKA\XPPW32\Source\samples\solution\smp\smprun.prg läuft auf keinen von meinen PC auf Stellung "3"
das bedeutet aber, dass die Freigabe auf alle Prozessoren funktioniert,
hä ???
brandelh hat geschrieben:aber je nach OS und Prozessor schläft die Anwendung oder hängt sich auf :D
es funktioniert einfach nicht (mehr***). EGAL welche Kombination du nimmst es DARF nur eine CPU sein !
brandelh hat geschrieben:Daher kamen wir damals zu dem Schluss, dass es sinnvoller ist auf Serversystemenen die CPU per Zufallssteuerung auszuwählen, aber die EXE auf einem Kern zu lassen.
ich meine das man "in" der Application die CPU umschalten kann/soll z.b. bevor man den Thread startet.

der WMPlayer, ohne Hardware Beschleunigung, ist ein CPU Fresser beim decodieren per Software ( FFDshow Codec )
bei jeder neuen Vilm Sequenz wird nun die CPU "umgeschaltet" bevor im Thread, der unter Xbase++ immer auf der selben CPU läüft wie "Main", die nächste Vilm Sequenz decodiert wird.

da dass "umschalten" ja im laufenden Betrieb erfolgen kann, "wäre" ein "Timer" logisch ... und wenn der jeder 0.1Sec "umschalten" würde ...

es geht hier NICHT um "Power" oder "Performance" sondern um "ECO" ( bessere Energie Verteilung / Ausnutzung von vorhandenen Resourcen )
brandelh hat geschrieben:PS: Ich weiß natürlich nicht, wie man die EXE schon beim LINKEN auf alle Prozessoren freigibt, da ALINK offensichtlich die Begrenzung setzt.
***wenn man mal eine alte Xbase++ v1.5 raus holt ...
gruss by OHR
Jimmy

Benutzeravatar
Daniel
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 260
Registriert: Mi, 06. Sep 2006 14:45
Wohnort: Zürich - weitere Region

Re: CPU Kerne umschalten / überlasten ...

Beitrag von Daniel » So, 04. Nov 2012 15:35

brandelh hat geschrieben:Es ist aber auch sinnlos, weil Xbase++ Programme selten zu der Gattung gehören, die durch mangelnde Prozessorleistung eines Kernes leiden.
Na ja, es gibt schon Zeiten, wo die Prozessorleistung auf 100% schnellt.
Oder meinst Du, dass eher das Netzwerk der limitierende Faktor ist?
Daher kamen wir damals zu dem Schluss, dass es sinnvoller ist auf Serversystemenen die CPU per Zufallssteuerung auszuwählen, aber die EXE auf einem Kern zu lassen.
"Zufall?" Auch hier wäre doch das OS zuständig, die Prozessorlast zu verteilen - und nicht die Anwendung.
Wobei natürlich eine Kommunikation zwischen XBase und OS stattfinden muss.
Gruss von Daniel

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14547
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: CPU Kerne umschalten / überlasten ...

Beitrag von brandelh » So, 04. Nov 2012 21:26

Hallo Daniel,

der oben genannte Link zeigt ein Alaska Beispiel mit Diskussion von 2006 darüber, wie man die aktuelle Last
der CPU ermittelt und danach die neue EXE startet. Das Problem ist nur, dass dieser Wert nur im Augenblick der ABFRAGE
gültig ist. Schon beim Programmstart kann die tatsächliche Auslastung ganz anders sein.

Wenn man nun z.b. über die in 1.90.355 eingebaute Funktion RandomInt() oder eine eigene Zufallszahl nutzt,
werden die Xbase++ Programm zufällig verteilt, das ist weniger aufwändig und statistisch sicher nicht schlechter als der aktuelle Zustand.

PS: Beispiel zum Umschalten der CPU (Anzeige im Programm ist Missverständlich !):
...\XPPW32\source\samples\solution\smp

CPU1 = 1
CPU2 = 2
CPU3 = 4
CPU4 = 8
etc.

Der Maskenwert 3 wäre CPU 1 + 2, der wird aber nicht eingestellt.
Im Taskmanager kann man dank Arbeitsroutine sehen, wie die Belastung auf 100% schnellt.

PS: Auch wenn eine Anwendung auf 100% steht, ist es ja meinst nicht die CPU die bremst, sondern die Festplatte (Daten),
Netzwerk (Festplatte, Drucker) oder Drucker etc. besonders aber COM Schnittstellen. Alles ist viel langsamer als die CPU.
Auch eine doppelt so schnelle CPU kann bei der gleichen Platte nicht mehr Daten lesen, natürlich haben moderne Festplatten
mehr Übertragungsleistung, aber das meine ich nicht.
Gruß
Hubert

psp
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 237
Registriert: Do, 22. Okt 2009 13:42

Re: CPU Kerne umschalten / überlasten ...

Beitrag von psp » Di, 06. Nov 2012 14:24

Ein Überlasten der CPU dürfte im heutigen Zeitalter nicht mehr möglich sein und wenn dann muss die CPU einen weg haben.

Intel hat zu Zeiten des Heißbrüters P4 das Throttling extrem zur Anwendung kam, um die überhitzten CPUs etwas herunter zu kühlen. Die Technik sitzt bis heute noch in den CPUs.

Ich habe hier zum Arbeiten einen i7-3770 bekommen und wenn eine XBase++-Anwendung einen Kern auslastet, merkt und sieht man das. Im Task-Manager ist dann einer der Kerne zu 100% ausgelastet, der Prozess zeigt eine Gesamtauslastung von 12-13% an (100/8 wegen HT). Die Temperaturen halten sich in Grenzen und der Turbo schaltet sich immer Lastabhängig ein, man kann auch mit 4 ( bzw. 8 ) gut ausgelasteten Kernen noch einen minimalen Turbo heraus holen.

Privat habe ich aktuell noch einen i7-860 auch mit aktivierten HT+Turbo. Man merkt zwar eine Auslastung z.B. bei Anno 2070, aber ein runterschrauben jedweder Leistungsparameter sind mir fremd. Der Stromverbrauch geht normal nach oben, da die ganze CPU + GPU ausgelastet wird. Heiß gelaufen ist noch nie etwas in den letzten 3 Jahren. Selbst mit einer dauerhaften Übertaktung (2,8 GHz auf 3,6 GHz) hält sich das Thema stark in Grenzen, der aktivierte Turbo konnte noch eine Schippe drauf legen.

Ich würde es persönlich begrüßen, wenn Alaska das bereits nutzbare Multithreading auch auf mehrere CPUs verteilen würde. Sicher sind die berühmten Flaschenhälse immer ein Problem, aber bestimmte Vorgänge könnte man trotz dessen parallel verarbeiten.

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11424
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: CPU Kerne umschalten / überlasten ...

Beitrag von AUGE_OHR » Mi, 07. Nov 2012 8:30

psp hat geschrieben:... i7-3770 .... Die Temperaturen halten sich in Grenzen
von welchen Temperaturen sprechen wir ? womit "misst" du es ?
psp hat geschrieben:Ich würde es persönlich begrüßen, wenn Alaska das bereits nutzbare Multithreading auch auf mehrere CPUs verteilen würde. Sicher sind die berühmten Flaschenhälse immer ein Problem, aber bestimmte Vorgänge könnte man trotz dessen parallel verarbeiten.
siehe Thread http://cch4clipper.blogspot.de/search/l ... .%20Pirsig
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14547
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: CPU Kerne umschalten / überlasten ...

Beitrag von brandelh » Mi, 07. Nov 2012 9:27

Hallo Jimmy,

du hast ja den LINK auf die Diskussion schon zum zweiten Mal gebracht um auf Multi CORE/CPU Unterstützung hinzuweisen.

Ich kann aber dort nur die Diskussion (2009) finden in der die grundsätzlichen Schwierigkeiten von Multithreading diskutiert werden.
Steffen sagte zwar etwas wie "in Zukunft wird es viele Kerne geben" aber ging nicht darauf ein, dass tatsächlich Xbase++ auf mehreren Kernen nicht oder nur schleichend läuft.
"xHarbour" scheint MT ohne interne Sicherheit der Daten (der Programmierer muss dies sicherstellen) zur Verfügung zu stellen und beide waren sich einig dass dies nicht sinnvoll ist.
"Harbour" ist intern da sicherer, aber eventuelle Fehler landen nicht als Runtime Error sondern als Internal Error (oder werden gar nicht erkannt ?) ...

Harbour soll schneller sein, weil es die "Fehlererkennung nicht wie Xbase++" umgesetzt hat; es kann aber auch sein, dass er mit "Costs" etwas anderes meint (Harbour kostet ja nix).

Tatsächlich findet man dort keinen Speedtest-Vergleich und keine Hinweise wie man mehrere Kerne sinnvoll nutzen kann !

AUßER man läßt es im Programm selbst komplett sein und nutzt für verschiedene Programminstanzen verschiedene Kerne.
Das geht bei Xbase aktuell schon.
Ob ein Terminalserver Xbase++ Anwendungen selbst auf verschiedene CPUs verteilen kann, oder ob das die Anwendung selbst machen muss, das kann ich nicht beurteilen.
Ansonsten dient die zweite CPU dafür immer eine reagierende Oberfläche zu haben und wenn ich mit der QuickPDF-DLL eine PDF erstelle, sind auch zwei CPUs/Kerne aktiv.

Man sollte sich mal den Taskmanager auf einem X4 oder X8 ansehen wenn man verschiedene Anwendungen öffnet.
Meist schlafen die CPUs ... denn Textverarbeitung, Datenbankanwendungen etc. warten meist auf Eingaben von Anwendern.
Ein zweiter Thread z.B. um eine Liste zu drucken ohne die Oberfläche einzufrieren (also dass sie nicht auf die Maus reagiert, weil ja das Programm gerade druckt) ist sehr sinnvoll und spart die dauernden Aufrufe der Ereignisschleife. Aber dafür braucht man keinen zweiten CPU Kern.
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11424
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: CPU Kerne umschalten / überlasten ...

Beitrag von AUGE_OHR » Fr, 09. Nov 2012 2:58

brandelh hat geschrieben:du hast ja den LINK auf die Diskussion schon zum zweiten Mal gebracht um auf Multi CORE/CPU Unterstützung hinzuweisen.
dann versuch es doch damit mal http://cch4clipper.blogspot.de/search/label/Przemek wo du auch einen "Speedtest" findest.

harbour, was nicht die Xbase++ OS/2 "Altlast" zu tragen hatte, ist den "normalen" Windows Weg mit Threads gegangen.
die "Vorteil" die Steffen 2009 nannte sind in harbour v3.0 inzwischen längst optional (!).

es sind ja nicht die "mehr" CPUs sondern die 100% die nur im "Turbo"-Modus erreicht werden was ein "übertakten" ist !
dafür ist die Kühlung IMHO in Notebooks nicht für "Dauerbetrieb" ausgelegt !
man kann dann doch "hören" wie der Lüfter hoch schaltet wenn man "original" DBU.EXE starte oder eine Xbase++ Application "stark beschäftigt" ist. der Lüfter springt aber erst im "Turbo" Modus an und "nutzt" die thermischen "Reserven" von anderen CPUs ... solange "die" nichts zu tun haben.

btw. mich nervt "das" der Lüfter dann hoch schaltet und LÄRM macht :angry4:

nun sagen die Hersteller : das geht schon "so" ... bis die Garantie abgelaufen ist :(

wenn man ein "grosses" Gehäuse und eine CPU / H2O Kühlung hätte ... aber dann "passt" es ja nicht auf so kleinem Raum. gerade wenn der Raum so begrenzt ist werden die restlichen Bauteile thermisch stark beeinflusst.

hab hier gerade DELL 745 "Mini" PCs (25x25x5cm).
Die CPU ( Coreduo 6600 ) wird passiv durch 2 Lüfter (60mm / 1600rpm) , die durch eine Abdeckung verbunden sind, bei < 36° im Leerlauf gekühlt.
man könnte wohl eine deutlich stärkere CPU einbauen denn bei der Konstruktion komme ich auch bei "Volllast" kaum über 48° ... ABER

der Rest im Gehäuse, vermutlich Notebook Technik, liegt dann schon bei > 50° ... inklusive 3.5" Festplatte unter der ein GFK Slot ähnlicher radial (?) Lüfter auf die GFK "on-Board" und RAM blässt. schon nach kurzer Zeit geht die 3.5° HD auf > 56° ... dafür sind die nicht ausgelegt (siehe S.M.A.R.T. )!

die hohe Temperatur der Festplatten und "ausgelaufene" Kondensatoren sind wohl "Schuld" das die PC nach Ablauf der Garantie immer mehr Ärger machten ...

Nachtrag : Wenn man die "Abdeckung" entfernt beträgt die HDD Temp 50° und die der CPU 48° im Leerlauf und 58° unter Volllast ...
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14547
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: CPU Kerne umschalten / überlasten ...

Beitrag von brandelh » Fr, 09. Nov 2012 9:26

Ich habe vor kurzem mal das Harbour 3.x Projekt geladen und installiert ...
Hello World konnte ich gleich kompilieren, also eingentlich kein Hexenwerk.
Dann habe ich FWH Demo geladen, die muss man nur auf einem Win 32 Bit Rechner installieren kann (entpackt kann man es dann auf Win 64 Bit Rechner kopieren).

Syntax und Code haben mir gut gefallen, viel gemacht habe ich aber nicht.

Was ich wirklich toll finde ist die dynamische Typkontrolle (man kann aber auch richtig typisieren).

Code: Alles auswählen

LOCAL I, sTxt
I := 1 // ab jetzt prüft der COMPILER (optional mit Warnschalter) ob I auch wirklich numerisch [b]verwendet[/b] wird.
sTxt := "Hallo " // ab jetzt ... ob sTxt auch wirklich als  Text [b]verwendet[/b] wird.
? "Testwert: " + I   // COMPILER FEHLER WARNUNG, nicht erst beim Kunden die Runtime  :!: 
I := "25" // kein Fehler, nun ist I halt eine Stringvariable
? "Testwert: " + I   // alles klar.
Ich persönlich würde wahrscheinlich tatsächlich streng typisieren, aber diese Technik funktioniert ohne code Änderung - EIN RIESEN SCHRITT in Richtung Fehlersuche.
Das hätte auch Xbase++ gut zu Gesicht gestanden !

Nun zum "Speedtest" ... dieses Programm ist schon schwer zu lesen insbesondere ohne Einrückung im BLOG Format.
Ich habe im Blog KEINE Ergebnisse gesehen, nur die Aufforderung jemand mit beiden compilern soll es doch mal laufen lassen.
Sorry, dazu habe ich einfach keine Lust.

Wenn ich die Kommentare recht verstehe ist MT bei Harbour standardmäßig abgeschaltet.
Xbase++ nutzt ja standardmäßig 3 Threads (soweit ich mich erinnere, MAIN, GUI und ? ) ... vermutlich ist das der Grund weshalb die CPU Verschiebung abgeschaltet werden muss.
Zwei Threads auf verschiedenen CPUs und dann auf gleiche Daten - geschützt - zugreifen, das zwingt alle beteiligten Kerne zu teuerem (lahmen) Syncronisationswarteschleifen.

Falls du das mit "OS/2 Altlast" meinst, kannst du Recht haben - KEINE Ahnung - aber Xbase++ nutzt ganz normale Windows Threads, das hat Pablo bestätigt :!:
Gruß
Hubert

Benutzeravatar
Daniel
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 260
Registriert: Mi, 06. Sep 2006 14:45
Wohnort: Zürich - weitere Region

Re: CPU Kerne umschalten / überlasten ...

Beitrag von Daniel » Fr, 09. Nov 2012 9:34

AUGE_OHR hat geschrieben:es sind ja nicht die "mehr" CPUs sondern die 100% die nur im "Turbo"-Modus erreicht werden was ein "übertakten" ist ! dafür ist die Kühlung IMHO in Notebooks nicht für "Dauerbetrieb" ausgelegt !

btw. mich nervt "das" der Lüfter dann hoch schaltet und LÄRM macht :angry4:
Ja, das finde ich auch nervig, wenn der Laptop solchen Lärm macht. Und die Lebensdauer ist auch ein Thema.
Ich hatte einen alten Toshiba Laptop, der 7 Jahre lief, aber natürlich wollen die Hersteller, dass wir nach längstens 2 Jahren einen neuen kaufen ... [-X

Ein Kunde fragt mich auch immer wieder, denn er hofft, dass es noch ein wenig schneller laufen würde (wegen einer oder 2 min! #-o )
Aber wahrscheinlich haben die XBase-Leute genug anderes zu tun.
Gruss von Daniel

Benutzeravatar
Daniel
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 260
Registriert: Mi, 06. Sep 2006 14:45
Wohnort: Zürich - weitere Region

Re: CPU Kerne umschalten / überlasten ...

Beitrag von Daniel » Fr, 09. Nov 2012 9:46

brandelh hat geschrieben:Zwei Threads auf verschiedenen CPUs und dann auf gleiche Daten - geschützt - zugreifen, das zwingt alle beteiligten Kerne zu teuerem (lahmen) Syncronisationswarteschleifen.
Ja, leuchtet ein.
Wo ich es mir vorstellen könnte, wäre z.B. ein Fakturierungslauf, wo alle Kunden verarbeitet werden. Aber das müsste man dann entsprechend programmieren, z.B. nach Postleitzahlen aufteilen, und dann mit tempFiles arbeiten, damit nicht gleichzeitig in dieselben Dateien geschrieben wird.
Allerdings geht die ganze Verarbeitung relativ rasch, geschätzt um 5-7min, was nachher Zeit braucht, ist die ganze Druckverarbeitung, diese verteile ich auf 2 - 3 Drucker, allerdings noch ohne verschiedene Threads. Da könnte ich ev. eher noch Zeit sparen. Das würde eben die Aufteilung in mehrere tempFiles bedingen, damit die Threads unabhängig arbeiten können.
Gruss von Daniel

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14547
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: CPU Kerne umschalten / überlasten ...

Beitrag von brandelh » Fr, 09. Nov 2012 9:57

Daniel hat geschrieben:Ein Kunde fragt mich auch immer wieder, denn er hofft, dass es noch ein wenig schneller laufen würde (wegen einer oder 2 min! #-o )
Aber wahrscheinlich haben die XBase-Leute genug anderes zu tun.
Wenn du jetzt die Mehrkern Unterstützung meinst, das Problem haben andere auch.
Selbst viele neue Spiele nutzen die 2. oder 3. CPU kaum aus und gerade die KI Berechnungen könnte man schön auslagern.
Normale Videoschnittsoftware (um die 100 Euro) kann das falls überhaupt erst sein wenigen Versionen.
Datenverwaltungssoftware hat normalerweise KEIN CPU Problem, die fehlende Performance kommt von winzigen Blockgrößen beim Lesen von einzelnen Datensätzen
(eine 20 MB Datei liest memoread() schneller ein, als ein paar Datensätze daraus im SHARED Modus).

Die Domäne der Multiprozessorunterstützung (oder gar GPU) liegt bei professionellen Programmen für Videoschnitt, CAD, wissenschaftliche Berechnungen etc.
Das Hauptproblem der Entwickler solcher Anwendungen liegt dann darin, die Aufgaben sinnvoll aufzuteilen, sodass diese unabhängig voneinander auf CPUs verteilt und danach mit Geschwindigkeitsgewinn :!: für die Gesamtaufgabe abgearbeitet und die Ergebnisse vereint werden.

@ TOM sicherlich wieder nicht 100% ausformuliert und vollständig :-)

Ich bleibe dabei, unser aller Problem ist NICHT die fehlende MultiCore Unterstützung, sondern die fehleranfällige Art der Datenspeicherung :!:

In dem Moment wo Daten von der Festplatte verarbeitet werden ist DIESE das langsamste Teil.
Druckausgaben können noch lahmer sein, da diese ja die Daten lesen müssen (Festplatte), in den Spooler kopieren (Festplatte, Netz ?) und von dort dann an den Drucker.
Mit Grafik kommen da jede Menge Daten zusammen und kein Mensch erinnert sich noch an die Zeiten als Nadeldrucker bzw. Schreibmaschine 20 Zeichen pro Sekunde drucken konnten.

PS: ich generiere gerne PDF Dateien, drucke und speichere sie.
Diese könntest du auf einen extra Druckserver kopieren, der sie annimmt ausdruckt und löscht (im Druckverzeichnis).
Somit könnte dein Programm eventuell schneller wieder für die Verarbeitung anderer zur Verfügung stehen.
Gruß
Hubert

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 7287
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: CPU Kerne umschalten / überlasten ...

Beitrag von Tom » Fr, 09. Nov 2012 10:08

Hallo, Hubert.

Genau. Du skizzierst Anwendungen, die von der gleichzeitigen Nutzung mehrerer CPUs profitieren können. Wenn man in iTunes ein ganzes Album lädt, verteilt iTunes sowohl den Download, als auch die Überarbeitung der empfangenen Daten auf die Rechnerkerne; das kann man schön beobachten. Die Prozesse sind weitgehend unabhängig voneinander, aber die Applikation überwacht sie. Wenn ich eine komplexe Aufgabe aufteilen kann, ohne dass sich der Status einer Teilaufgabe grundsätzlich beeinflussend auswirkt, schreit das quasi nach Mehrkernnutzung. Das Rendering von Videos muss pro Sekunde > 25 Bilder überarbeiten, aber die Aufgabe ist erst beendet, wenn alle Bilder gerendert wurden. Deshalb kann man hierfür parallel mehrere Prozessoren nutzen. Am Ende dieser Aufgabe wird sich die Hauptapplikation wieder auf einen Prozessor beschränken; die Videoschnittprogramme laufen nicht grundsätzlich auf mehreren Prozessoren. Die ganze GUI und Intelligenz der Software wird auf einem laufen.

Wenn ich eine Xbase-Applikation habe, die Multithreading auf eine Weise nutzt, die ganze Applikationsbestandteile - u.U. wiederholt - in eigenen Threads ablaufen lässt, habe ich ein Design, das sich prinzipiell auch für eine Verteilung eignen würde. Die Frage wäre aber tatsächlich, ob man dadurch etwas gewinnen würde, denn selbst wenn ich beispielsweise eine mehrfach gestartete Kundenverwaltung jeweils einer CPU zuordnen könnte, schafft es der Benutzer wohl kaum, sie tatsächlich parallel zu nutzen, also von der Verteilung zu profitieren. Das Bottleneck liegt für uns anderswo, nämlich tatsächlich in der Datenhaltung. Lediglich der Aufbau komplexer Dialoge könnte möglicherweise etwas schneller werden, würde man sie vom Hauptprozessor, den die App nutzt, wegschieben. Aber ich habe auch Fälle, in denen sich umfangreiche Auswertungen selbsttätig minimieren und erst wieder melden, wenn sie beendet sind - Kunden nutzen diese Zeit, um anderswo weiterzuarbeiten, in der selben Applikation. Könnte ich die Auswertung nun umschichten, liefe das, was im Vordergrund benutzt wird, vielleicht etwas schneller, was reine Programmlogik und GUI anbetrifft. Die Datenzugriffe würden sich so oder so gegenseitig beeinflussen, denn eine Festplatte kann nur einmal zur gleichen Zeit Daten lesen.
Herzlich,
Tom

Antworten