Hohe CPU Auslastung bei 64Bit Anwendungen

[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.