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

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

Moderator: Moderatoren

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: CPU Kerne umschalten / überlasten ...

Beitrag von brandelh »

=D>
wobei ...
Tom hat geschrieben:... 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.
Wenn ich "Netzwerkanwendungen" teste, nutze ich meist 2 Rechner mit mehrern Instanzen des Programms und versuche Konflikte zu provozieren.
Hier bin dann ich das "Bottleneck", ich bin beim Tippen alleine einfach nicht schnell genug und 10 Anwender im eigenen Testnetzwerk bekomme ich nicht :D
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: CPU Kerne umschalten / überlasten ...

Beitrag von AUGE_OHR »

brandelh hat geschrieben:Ich bleibe dabei, unser aller Problem ist NICHT die fehlende MultiCore Unterstützung, sondern die fehleranfällige Art der Datenspeicherung :!:
naja mit eine SSD kann man MagicHelp auch aus einer DBF "füttern" ( sonst empfehle ich lieber ein Array )

aber trotzdem kann es bei Disk I/O und vielen Thread , alles auf einer CPU, schon mal zu Problemen kommen ... weil sie mit 1 x CPU" auskommen müssen.
meisten ist das "default" die 1st CPU wo ja auch das OS() drauf zugreifen will ... und wenn man dann noch eine andere Applicktion ( Outlook ) startet die auch viel Disk I/O produziert ...

wenn ich mir z.b. den
EH: 4233 Sub: 0(0) OS: 0 XPP: 0
von Rudolf ansehe habe ich stark im Verdacht das da auch noch OCX / DLL / MAPI oder sonstige 3-PP im Spiel ist.
ein "Alias lost" bedeutet oft das die Connection zum OCX / DLL / MAPI "verloren" gegangen ist und man nicht mehr im GUI Thread ist wo die 3-PP abläuft.

gerade diese OCX / MAPI Calls sind unter XbpActiveXControl() "wesentlich" langsamer als Disp_HPR.DLL (400%) ... und wenn man dann Disp_HPR.DLL zusammen mit harbour nimmt (600-800%)
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: CPU Kerne umschalten / überlasten ...

Beitrag von brandelh »

AUGE_OHR hat geschrieben:gerade diese OCX / MAPI Calls sind unter XbpActiveXControl() "wesentlich" langsamer als Disp_HPR.DLL (400%) ... und wenn man dann Disp_HPR.DLL zusammen mit harbour nimmt (600-800%)
ich kann dir zwar nicht mehr ganz folgen, aber wie sollte DIES durch eine zweite CPU im Programm selbst verbessert werden ?
Ich vermute eher, dass XbpActiveXControl() sagen wir mal "umständlicher" implementiert wurde und daher langsamer arbeitet als bei Harbour.
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: CPU Kerne umschalten / überlasten ...

Beitrag von AUGE_OHR »

brandelh hat geschrieben:ich kann dir zwar nicht mehr ganz folgen, aber wie sollte DIES durch eine zweite CPU im Programm selbst verbessert werden ?
naja ... nicht jedes OCX / DLL ist "MT unfähig" ... diese Beschränkung kommt IMHO von Xbase++

die PostgreSQL "libpq.dll" ist ja Thread fähig und ich könnte eine "eigene" Connection pro Thread haben ...
wenn ich nun pro Thread eine CPU hätte könnte man auch grosse Resultset bearbeiten, wie ich es mit SQL vorhabe, ohne Performance Einbussen auf anderen Threads / CPUs.
brandelh hat geschrieben:Ich vermute eher, dass XbpActiveXControl() sagen wir mal "umständlicher" implementiert wurde und daher langsamer arbeitet als bei Harbour.
ich kann ja statt dessen Disp_HPR.DLL nehmen und es mit Xbase++ ODER harbour verwenden.
wenn also Disp_HPR.DLL als "Konstante" gilt liegt der Geschwindigkeits-Unterschiede bei der Appplikation welche die DLL anspricht.


***

... nur wie schon gesagt, geht es mir in diesem Thread nicht um "Power" sondern um "ECO"
ich habe mal 3 Demos gemacht die das verdeutlichen sollen.

1.) morecpu1.exe : kein Thread, alles wie gewohnt auf CPU 1
2.) morecpu2.exe : kein Thread, schaltet aber jedes mal auf eine CPU (random)
3.) morecpu3.exe : mit Thread, schaltet mit o:setInterval(10) ständig um

wenn ihr die Demos starte im Taskmanager ansehen was die CPUs machen.
wer "mehr Belastung" benötigt starte mit (irgendeinem) Parameter AUSSER "1"

Resultat "Lüfter" :
bei 1.) springt der Lüfter nach kurzer Zeit an
bei 2.) springt der Lüfter "ab-und-zu" an wenn es "länger dauert" und er (noch) mehr Power benötigt
bei 3.) springt der Lüfter so gut wie nie an ;)

p.s. ich habe die GRA Ausgabe nicht gemessen d.h. ich weiss nicht ob 3.) "langsamer" ist als 1.) oder 2.) ist ... ist eh "sehr langsam" mit Xbase++ GRA ...
Dateianhänge
MoreCPU.zip
v1.9.335
(22.63 KiB) 332-mal heruntergeladen
gruss by OHR
Jimmy
Antworten