Hohe CPU Auslastung bei 64Bit Anwendungen

[EWeiss]

Ich versuche es noch einmal ohne über den Compiler zu schimpfen. :)
Die Ausgangssituation ist diese das die gleiche Anwendung gleicher Quelltext unter 32Bit 0% und mit 64Bit 25% Cpu Auslastung produziert.
Bei 32Bit könnt ihr die Geschwindigkeit auf Maximum stellen und es bleibt bei fast 0% Auslastung wenn die Durchsichtigkeit ausgeschaltet ist.

Was ich versucht habe.

Zitat:

Dort habe ich jetzt schon versucht MMTimer (Hochauflösender Timer vom MMSystem inkl. QueryPerformanceFrequency Callback usw.
Ein Sleep(0) oder Sleep(1) bringt auch nichts.
Den Timer auf 25ms zu setzen bremst das gesamte zeichnen aus.

Mein Problem ist zu ergründen warum das so ist.
Die Anwendung zum testen das es so ist kann man sich hier anschauen.

Es tritt nur dann auf wenn diese Funktion aufgerufen wird.

Delphi-Quellcode:

      if (ObjItem.angle <> 0) then
       begin
         GdipSetInterpolationMode(graphics, ObjItem.quality);

         GdipRotateWorldTransform(graphics, ObjItem.angle + 180, MatrixOrderAppend); //<<<< hier 
         GdipTranslateWorldTransform(graphics, xD + (wD div 2), yD + (hD div 2), MatrixOrderAppend); //<<<<< und hier

         GdipDrawImageRectRectI(graphics, img, wD div 2, hD div 2, -wD, -hD, xS, yS, wS, hS, 2, imgAttr,
           ImgAbort, nil);
       end else
       begin
         GdipSetInterpolationMode(graphics, ObjItem.quality);
         GdipDrawImageRectRectI(graphics, img, PosX, PosY, wD, hD, xS, yS, wS, hS, 2, imgAttr, ImgAbort, nil);
       end;

Das kann man leicht testen indem man einfach die "eigene Rotation und die 3D tiefe ausschaltet" beide Eigenschaften verwenden im etwas abgeänderte form die gleiche Funktion.

Meine Vermutung ist das dieses Problem von der GDIPlus 64Bit selbst verursacht wird oder aber wie zuvor schon öfters eine der Typen nicht korrekt für 64Bit definiert ist.

Vielleicht hat ja doch noch jemand eine Idee falls es an der Anwendung selbst liegt.
Bei der DLL werde ich es dann wohl selbst finden müssen obwohl ich nicht erkennen kann das es hier ein Type Problem geben könnte. (Etwas fehlt mir auch die Erfahrung ;) )

Hier noch dir Funktionen

Delphi-Quellcode:

GdipTranslateWorldTransform: function(Graphics: LONG_PTR; dx: Single; dy: Single; order: GpMatrixOrder): GPSTATUS; stdcall;
GdipRotateWorldTransform: function(Graphics: LONG_PTR; angle: Single; order: GpMatrixOrder): GPSTATUS; stdcall;

Die übergebenen Typen sind alle identisch..
Habe es auch schon mit Pointer versucht bringt keine Verbesserung.

gruss

[EWeiss]

Hat sich erledigt.
Jemand hat sich bereit erklärt das Problem zu analysieren. (Wenn es jemand kann dann er ;) )

Bei ihm ist die Auslastung 32Bit vs. 64Bit die gleiche so um 0 > 3 Prozent. (Win10)
Es scheint so das es nicht an Delphi (Compiler) sondern an meiner älteren Hardware liegt.
Das Problem ist bei mir unter 32Bit nie aufgetreten, warum es mit der 64Bit Version nicht geht, nun da bin ich nicht der Spezialist um das zu analysieren.
Es scheint tiefer zu gehen als der Code selbst.

Von daher denke ich das ich es so hinnehmen muss wie es ist.
Programmtechnisch gesehen kann ich auf die angesprochenen Funktionen die in GDIPlus verwendet werden keinen Einfluss nehmen.
GDIPlus64 <> GDIPlus32

PS:
Zumindest kann ich davon ausgehen das es nicht an meiner Programmierung oder den 64Bit Compiler von Delphi liegt. ;)

gruss

[Fritzew]

Schön das es geklärt ist,
hatte es gerade compilert und wollte da mal reinschauen.
Kann ich es mir sparen... ;-)

[EWeiss]

Zitat:

Zitat von Fritzew (Beitrag 1411833)

Schön das es geklärt ist,
hatte es gerade compilert und wollte da mal reinschauen.
Kann ich es mir sparen... ;-)

Da kannst du nicht reinschauen weil das Problem innerhalb der DLL zu finden ist.
Trotzdem Danke.

gruss

[Fritzew]

Jetzt ist es wohl klar........
Aber nur zur Info: Auf meinem Rechner pendeln beide Versionen zwischen 0 und 1 %

[EWeiss]

Zitat:

Zitat von Fritzew (Beitrag 1411836)

Jetzt ist es wohl klar........
Aber nur zur Info: Auf meinem Rechner pendeln beide Versionen zwischen 0 und 1 %

Hervorragend ;) Danke für die Info
Denke Win10 oder?

Bei mir auf dem Rechner Win7 wie schon gesagt 64Bit 25% andere 0.
Meine CPU Core2 Quad Q9650 3GHZ.

gruss

[Fritzew]

Grafikkarte:
NVidia QUADRO P600
Intel Core i7-8700K 3.7 Ghz
64 GB Ram
Windows 10 ja

[EWeiss]

Zitat:

Zitat von Fritzew (Beitrag 1411841)

Grafikkarte:
NVidia QUADRO P600
Intel Core i7-8700K 3.7 Ghz
64 GB Ram
Windows 10 ja

Ok PowerPC ;)
Meine Graka NVidia GTX 780 TI

Danke nochmals.

gruss

[EWeiss]

Sorry eins wollte ich noch nachfragen.
Wenn du das teil mit voller Leistung laufen lässt wie ist die CPU Auslastung dann?
Also alles an inklusive Speed auf Maximum.

Nebenbei bei mir auf Win10 externe Festplatte über USB 2 85% CPU Auslastung. :)
Bis mein System vollständig gestartet ist benötige ich etwa 10 Min.

gruss

[Fritzew]

Tja, pendelt bei beiden Version zwischen 3 und 4%
Das hast Du echt gut gemacht.
Wobei mein Rechner ja eher am oberen Rand anzusiedeln ist. Arbeite halt im CAD Bereich und da ist Speed alles.....

[EWeiss]

Zitat:

Zitat von Fritzew (Beitrag 1411850)

Tja, pendelt bei beiden Version zwischen 3 und 4%
Wobei mein Rechner ja eher am oberen Rand anzusiedeln ist. Arbeite halt im CAD Bereich und da ist Speed alles.....

Danke.. Damit ist es für mich erledigt das Thema.

Zitat:

Das hast Du echt gut gemacht.

Hatte auch diverse Hilfe von dir und anderen hier :)

gruss

[himitsu]

Zitat:

Zitat von EWeiss (Beitrag 1411831)

Hat sich erledigt.
Jemand hat sich bereit erklärt das Problem zu analysieren. (Wenn es jemand kann dann er ;) )

Oder wenn jemand will, dann kann er auch selber.

z.B. AQTime :zwinker:

Erstmal schauen wo überhaupt die meiste Zeit anfällt.


Aber wie bereits schon jamand sagte, kann man auch schauen ob z.B. irgendwo "zu oft" gezeichnet wird, also ob man schon an der Anzahl der Ausführungen etwas sparen kann, bevor man schaut die einzelnen Zeichendurchläufe zu optimieren.
(z.B. 300000 FPS sind mehr als genug, als überhaupt jemand das alles sehen könnte)

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1411858)

Zitat:

Zitat von EWeiss (Beitrag 1411831)

Hat sich erledigt.
Jemand hat sich bereit erklärt das Problem zu analysieren. (Wenn es jemand kann dann er ;) )

Oder wenn jemand will, dann kann er auch selber.

z.B. AQTime :zwinker:

Erstmal schauen wo überhaupt die meiste Zeit anfällt.


Aber wie bereits schon jamand sagte, kann man auch schauen ob z.B. irgendwo "zu oft" gezeichnet wird, also ob man schon an der Anzahl der Ausführungen etwas sparen kann, bevor man schaut die einzelnen Zeichendurchläufe zu optimieren.
(z.B. 300000 FPS sind mehr als genug, als überhaupt jemand das alles sehen könnte)

Werde den Profiler mal testen.. Danke.
Er wird mir aber dabei auch nicht helfen denn wie schon analysiert liegt es an meiner Hardware und wo bzw. wodurch das Problem auftritt weis ich ja.
Der Profiler kann mir also nur sagen was ich am ende schon weis.

gruss

[Zacherl]

Zitat:

Zitat von himitsu (Beitrag 1411858)

Aber wie bereits schon jamand sagte, kann man auch schauen ob z.B. irgendwo "zu oft" gezeichnet wird, also ob man schon an der Anzahl der Ausführungen etwas sparen kann, bevor man schaut die einzelnen Zeichendurchläufe zu optimieren.

Das habe ich tatsächlich überprüft und sowohl unter 32- als auch 64-Bit schafft der von Emil verwendete Timer (SetTimer) bei mir nicht mehr als 64 FPS.

[EWeiss]

Zitat:

Zitat von Zacherl (Beitrag 1411860)

Zitat:

Zitat von himitsu (Beitrag 1411858)

Aber wie bereits schon jamand sagte, kann man auch schauen ob z.B. irgendwo "zu oft" gezeichnet wird, also ob man schon an der Anzahl der Ausführungen etwas sparen kann, bevor man schaut die einzelnen Zeichendurchläufe zu optimieren.

Das habe ich tatsächlich überprüft und sowohl unter 32- als auch 64-Bit schafft der von Emil verwendete Timer (SetTimer) bei mir nicht mehr als 64 FPS.

Deshalb habe ich auch auf den MMTimer zunächst mal verzichtet denn der schafft mehr ;)

Zitat:

Werde den Profiler mal testen.. Danke.

Besser nicht ;) Der will als Trail zu viele Persönliche Informationen von mir.
Das kann ich nicht machen! :)

gruss

[himitsu]

Es gibt auch andere Profiler, nicht nur AQTime.

Und von XE bis XE7 war eine kostenlose Edition des AQTime im Delphi enthalten, welche keine Daten haben wollte.

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1411867)

Es gibt auch andere Profiler, nicht nur AQTime.

Und von XE bis XE7 war eine kostenlose Edition des AQTime im Delphi enthalten, welche keine Daten haben wollte.

Danke für die Infos aber ich kann an der Funktion Inside GDIPlus eh nichts ändern und Zacherl sagte ja schon mehr als 64 Frames sind nicht drin.
Es liegt definitiv nicht am "Timer, Compiler, Delphi, Code" sondern an meiner Hardware.

gruss

[himitsu]

Ein Profiler kann dir zeigen wo im Programm die meiste Zeit für alle Berechnungen anfallen, also wer an den 100% CPU-Last die meiste Schuld hat.

Das geht bei AQTime auf ganze Prozeduren, bis hin zu einzelnen Delphi-Befehlen und vielleicht sogar auf Assembler-Ebene. (je tiefer die Ebene, um so größer die Beeinflussung der Messung > kannst selber ausprobieren, wenn du manuell eine Zeitmessung einbaust und z.B. in einem

Delphi-Quellcode:

for i := 0 to 10000000 do Inc(x);

die Dauer der einzelnen INC misst und zusammenrechnest und das dann mit "nur" einer einzelnen Messung um die ganze Schleife vergleichst)


Natürlich erzeugen Compiler für verschiedene Systeme unterschiedlichen Code. (egal ob Win32, Win64, iOS, MacOX, Linux usw.)
Da gibt es sogar nochmal einen Unterschied, ob du ein 32 Bit-Programm in einer 32-Bit-CPU laufen lässt oder in einer 64-Bit-CPU/64-Bit-Windows,
bzw. 32-Bit-Anwendung in einem 32-Bit-Windows auf einer 64-Bit-CPU
und das dann noch gegen den 64-Bit-Code in der 64-Bit-CPU/Windows.

Es gibt auch im Pascal/RTL/VCL/... nochmal unterschiedliche Versionen je Plattform vom mehreren Funktionen, vor allem bei Codes wo direkt mit Assembler gearbeitet wird.


Daran kannst du nichts ändern (unabhängig davon, dass andere/neuere Win32-Compiler anderen Code und bessere Optimierungen bieten und dass man für einzelne Delphi-Funktionen eigene/fremde Versionen nutzen kann)
aber du kannst schauen wo die Zeit/CPULast anfällt und da dann eventuell deinen Quellcode anpassen.


Bedenke dass Win64 so ähnlich wie iOS, Linux und Co. angesehen werden muß
und nicht jeder Code einfach so überall gleich verwendet werden kann.

Bei einfachen Funktionen geht das schon,
sobald System-APIs ins Spiel kommen, kann es die düben nicht/anders geben,
und insgesamt muß man eben für unterschiedliche Systeme auch eigenen/angepassten Code erstellen.

[EWeiss]

Zitat:

also wer an den 100% CPU-Last die meiste Schuld hat.

Das verstehe ich. :)
Aber noch einmal das weis ich auch ohne Profiler.

Es sind diese beiden Funktionen und da habe ich keinen Einfluss drauf unabhängig davon wie viele Frames ich Rendern kann\könnte.
Wenn meine Hardware mit diesen Funktionen Probleme hat kann ich nichts dran ändern.
Da es unter 32BIT läuft kann es nur daran liegen das sich die GDIPlus64 mit meiner Hardware nicht verträgt.

Delphi-Quellcode:

GdipTranslateWorldTransform: function(Graphics: LONG_PTR; dx: Single; dy: Single; order: GpMatrixOrder): GPSTATUS; stdcall;
GdipRotateWorldTransform: function(Graphics: LONG_PTR; angle: Single; order: GpMatrixOrder): GPSTATUS; stdcall;

Zitat:

und da dann eventuell deinen Quellcode anpassen.

Da ist nichts anzupassen was soll ich an den Funktionen ändern?

gruss

[himitsu]

Hmmm, OK, da kann natürlich erstmal der Code der GDI+ DLLs sich unterscheiden (die für 64 Bit könnten einfach nur grottenschlecht sein)
dann natürlich noch dein Grafiktreiber usw.

Aber es kann auch sein, dass du im GDI+ irgendwo ein paar Einstellungen anders machen mußt, damit es schneller/sparsamer läuft.
Oder dass du unter 64 Bit mit einer anderen API oder anderen/neueren Funktionen jener API bessere Ergebnisse erzielst.

Für so manche Funktionen haben oftmals auch andere Entwickler "bessere" Funktionen gebaut, als die im Betriebssystem vorhandenen.

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1411874)

Aber es kann auch sein, dass du im GDI+ irgendwo ein paar Einstellungen anders machen mußt, damit es schneller/sparsamer läuft.

GDI+ ist der Hauptsächliche Part meines Frameworks und meine Funktionen bzw.. wie ich sie anspreche sind optimiert bis zum geht nicht mehr.

Zitat:

Für so manche Funktionen haben oftmals auch andere Entwickler "bessere" Funktionen gebaut, als die im Betriebssystem vorhandenen.

Würde gegen mein Framework sprechen. .Ich mixe keine GDI Zeichnungs Funktionen in Kombination mit GDI+ wenn es nicht nötig ist.

Zitat:

die für 64 Bit könnten einfach nur grottenschlecht sein

Möglich habe ich aber keinen Einfluss drauf.

Zitat:

dann natürlich noch dein Grafiktreiber usw.

Wäre eine Möglichkeit das noch zu checken.
Aber ich verwende beabsichtigt einen alten Treiber( 352.86 ) weil die Nachfolgenden von NVIDIA wirklich Grotten schlecht sind.
Das ist der einzige der bei mir bisher noch keinen Absturz oder gar Blue-Screen verursacht hat.

gruss

[EWeiss]

Nebenbei eine Sinnvolle Verwendung wäre zum Beispiel so etwas.

Diamanten mit Thumbnails der eigenen Anwendung ersetzen Array anpassen sowie eine neue Brennweite(FocalLength) festlegen das war es dann schon.
Beim Klick auf eines der Thumbnails den jeweiligen Skin auswählen.
Hier als Beispiel mein Mediaplayer.

gruss

[KodeZwerg]

Zitat:

Zitat von EWeiss (Beitrag 1411875)

Aber ich verwende beabsichtigt einen alten Treiber( 352.86 ) weil die Nachfolgenden von NVIDIA wirklich Grotten schlecht sind.
Das ist der einzige der bei mir bisher noch keinen Absturz oder gar Blue-Screen verursacht hat.

gruss

Also in Bezug zu Windows 10, nimm Bitte einen der 39Xer Reihe, das gibt Dir einen guten Geschwindigkeitsboost, der ist auch mit 780 GTX Kompatibel. Auf mein Läppi ist ne alte dedicated 5XX MX samt Win10 mit aktuellen Treibern am laufen.

[EWeiss]

Zitat:

Zitat von KodeZwerg (Beitrag 1411880)

Zitat:

Zitat von EWeiss (Beitrag 1411875)

Aber ich verwende beabsichtigt einen alten Treiber( 352.86 ) weil die Nachfolgenden von NVIDIA wirklich Grotten schlecht sind.
Das ist der einzige der bei mir bisher noch keinen Absturz oder gar Blue-Screen verursacht hat.

gruss

Also in Bezug zu Windows 10, nimm Bitte einen der 39Xer Reihe, das gibt Dir einen guten Geschwindigkeitsboost, der ist auch mit 780 GTX Kompatibel. Auf mein Läppi ist ne alte dedicated 5XX MX samt Win10 mit aktuellen Treibern am laufen.

Da verwende ich den neuesten bringt aber nichts denn wenn du vielleicht gelesen hast verwendet ich ein System das über einen USB Adapter 2, externe Platte läuft.
Das benötigt bis zum Start, vollständiger Desktop geladen zirka 10 Min..
Da ist nix mit Boost selbst wenn ich es wollte. 85% Auslastung sagt wohl alles.

Windows 10 ist nur ein Developer Test System.. Als Standard System werde ich es nie verwenden.
Von daher egal!

gruss

[KodeZwerg]

Ich hatte das mit Usb 2 gelesen, aber erst jetzt bei Wiederholung richtig verstanden.
Beim erstem mal Lesen hab ich mich erschrocken und dachte "er meint das bestimmt anders"
40MB/s Limit, das ist natürlich ärgerlich,
aber wie Du erwähntest, auch egal da Win7 im Vordergrund steht.

[EWeiss]

Zitat:

Zitat von KodeZwerg (Beitrag 1411884)

Ich hatte das mit Usb 2 gelesen, aber erst jetzt bei Wiederholung richtig verstanden.
Beim erstem mal Lesen hab ich mich erschrocken und dachte "er meint das bestimmt anders"
40MB/s Limit, das ist natürlich ärgerlich,
aber wie Du erwähntest, auch egal da Win7 im Vordergrund steht.

Na ja trotzdem Danke für den TIP.

gruss

[KodeZwerg]

399.07 - WHQL, ich habe gerade mal geschaut was in Deiner Kombination aktuell wäre. [Win7/700er Reihe]

[EWeiss]

Zitat:

Zitat von KodeZwerg (Beitrag 1411886)

399.07 - WHQL, ich habe gerade mal geschaut was in Deiner Kombination aktuell wäre. [Win7/700er Reihe]

Ja.. Danke! Wie ich schon sagte alle Treiber nach meinen sind Grotten schlecht!
Das WHQL besagt gar nichts ist halt nur verifiziert und hat nichts mit Qualität zu tun.
Das Problem ist halt bei NVIDIA, diese optimieren ihre Treiber für Spiele und vernachlässigen das System damit kann ich nichts anfangen.

Meine Treiber lade ich hier und glaube mir habe sie fast schon alle durch.
Und der neueste ist nicht gleich der beste!
Und angeblich stabile Versionen haben mein System schon öfters abstürzen lassen als mir lieb ist.
Wie gesagt.. was ich mir wünsche wäre ein System Ready nicht einen "Game Ready" Treiber den gibt es aber leider nicht.

PS:
Macht auch keinen sinn jetzt weiter über Treiber zu philosophieren das Thema ist eigentlich schon durch. ;)

Destotrotz habe den Treiber von dir getestet wie erwartet nach ca. 5 Stunden der erste schwarze Bildschirm danach war mein Video das ich gerade angeschaut habe nur noch ein grüner Bildschirm.
Und wieder den alten zuverlässigen drauf.

gruss

[himitsu]

Zitat:

Zitat von EWeiss (Beitrag 1411875)

wie ich sie anspreche sind optimiert bis zum geht nicht mehr.

Für Win32, also in jenem System wo sie optimiert wurden.


Tja, und nun nochmal das Gleiche für 64 Bit. :stupid:

[EWeiss]

Zitat:

Zitat von EWeiss (Beitrag 1411851)

Zitat:

Zitat von Fritzew (Beitrag 1411850)

Tja, pendelt bei beiden Version zwischen 3 und 4%
Wobei mein Rechner ja eher am oberen Rand anzusiedeln ist. Arbeite halt im CAD Bereich und da ist Speed alles.....

Danke.. Damit ist es für mich erledigt das Thema.
gruss

Scheint ja zu laufen :)
Du verstehst es nur nicht das ich nichts weiter tun kann, es ist Hardware bedingt.

Frage @Zacherl und ja er weis bestimmt was er tut.
Er hat zwar meinen Quelltext nicht studiert aber er wird dir zumindest sagen können das da, im Moment zumindest, nichts weiter optimiert werden kann.
Und bei ihm schwanken beide Plattformen etwa bei 0 - 1%.

gruss

[Zacherl]

Zumindest davon ausgehend, dass wirklich die zwei GDIP Aufrufe für die hohe Auslastung sorgen (was ich bei mir nicht 100%ig verifizieren konnte, da das Problem bei mir nicht auftritt), kann es nur noch ein implementationstechnisches Problem der GDI+ Schnittstelle sein. Hier springt der Code ja in die entsprechende Dll, auf die man nun wirklich keinen Einfluss mehr hat.

Meine Vermutung war, dass für die 64-Bit Version eventuell neuere CPU Instructions (AVX, etc.) zur Optimierung verwendet werden und für Systeme ohne diese Instructions lediglich ein primitiver und imperformanter Fallback implementiert wurde. Ist natürlich reine Spekulation, aber scheinbar tritt das Problem ja wirklich nur hardwarespezifisch bei Emil auf dessen CPU beispielsweise tatsächlich kein AVX und co. unterstüzt.

[Memnarch]

GDI+ stammt noch aus XP-Zeiten, die 64Bit Portierung muss also erst viel später gekommen sein. Durchaus möglich, dass da etwas geschlampt wurde. Besonders ärgerlich: Im Gegensatz zu GDI, ist GDI+ auf Win7 nur Softwareseitig implementiert. Das machts natürlich um so ärgerlicher.

[EWeiss]

Zitat:

kann es nur noch ein implementationstechnisches Problem der GDI+ Schnittstelle sein.

Ok.. Ich lade GDI+ dynamisch.
Aber selbst wenn das ein Problem sein sollte was ich bezweifeln möchte müssten die gleichen Probleme dann auch unter 32Bit auftreten.
Denn auch hier wird sie Dynamisch geladen.

Ich habe die Typen Graphics und Image als LONG_PTR definiert weil meine Properties in einem vordefiniert Speicherbereich der Winproc geschrieben und gelesen werden.. siehe

Zitat:

cbWndExtra!
Extra Class Memory Specifies the amount of extra memory, in bytes, that the system should reserve for the class. All windows in the class share the extra memory and can use it for any application-defined purpose. The system initializes this memory to zero.

um sie nachher nicht extra noch einmal konvertieren zu müssen.
Die Größe des Speicherbereich ist dann abhängig von 64 btw. 32Bit. Deshalb *SizeOf(LONG_PTR)
Die Propertys werden dann mit SetWindowLongPtr geschrieben und GetWindowLongPtr gelesen.

Also es ist schon optimiert.
Man kann es drehen wie man will da ist leider nichts zu machen.

gruss