Hohe CPU auslastung bei 64Bit Anwendung

[EWeiss]

Zitat:

Zitat von old7 (Beitrag 1411498)

OK, ich dachte, du beziehst dich auf OTTB. Mehr Infos zu deinem Problem würden daher nicht schaden.

Ich habe alle gegeben die relevant sind.

Aber noch mal siehe den Shot und den Unterschied zwischen 32 und 64Bit.
Ich kann den Quelltext nicht verändern denn er läuft 100% mit allen meinen anderen Beispielen.
Kann mir nicht vorstellen das 4Byte (LONG_PTR) mehr für Graphics dieses Problem verursachen könnte.

Das wäre die einzige Erklärung.

gruss

[hoika]

Hallo,
Einspruch, es sind viel zu wenig Infos.

25% komplett -> sind wohl 100% CPU-Last auf einem Prozessor.

Aber Du hast es ja gefixt, leider, ohne uns zu sagen, was das Problem war.

PS:
Das der 64Bit-Compiler noch eine Baustelle ist, sollte allen klar sein.

[jaenicke]

Zitat:

Zitat von hoika (Beitrag 1411507)

PS:
Das der 64Bit-Compiler noch eine Baustelle ist, sollte allen klar sein.

Inwiefern?

Und bezüglich 100%:
Eine mögliche Ursache ist, wenn etwas zu oft hintereinander immer wieder gezeichnet wird. In dem Fall könnte man ein kurzes Sleep versuchen um herauszufinden ob es dann behoben ist. Zur Lösung gäbe es dann vermutlich noch eine bessere Lösung.

[KodeZwerg]

Ich würde auch vorschlagen in der Timer/Loop die Dir diese Kristalle animiert, einfach mal den Gfx Output auszukommentieren um schon mal zu erfahren ob es daran liegt.

[jaenicke]

Er hat ja schon geschrieben, dass es daran liegt. Insofern dürfte das Sleep als Ersatz für eine richtige Frameratenkontrolle zunächst helfen. Sinnvoller ist aber die Framerate direkt zu limitieren.

Nebenbei:
Lustigerweise dürfte hier die bessere Performance unter 64-Bit zu dem Problem führen, weil die Befehle so schnell abgearbeitet werden, dass diese viel öfter hintereinander ausgeführt werden als unter 32-Bit. Und wenn man diese Framerate dann nicht begrenzt, wird halt alles genutzt was da ist.

[Zacherl]

Oder eventuell in der 64-Bit Release Konfiguration ausversehen irgendwelche Debug-Features aktiviert oder die Codeoptimierung deaktiviert? Mich macht die derart unterschiedliche Größe des Kompilats stutzig. Etwas größer sind 64-Bit Binaries zwar schon, aber bei weitem nicht in diesem Ausmaß.

[EWeiss]

Ihr habe alle schon das Pic gesehen oder?
Und ja mein Timer läuft mit 0 ms ob es letztendlich auch 0 sind mag dahin gestellt sein.

Zitat:

Er hat ja schon geschrieben, dass es daran liegt. Insofern dürfte das Sleep als Ersatz für eine richtige Frameratenkontrolle zunächst helfen. Sinnvoller ist aber die Framerate direkt zu limitieren.

Ich verstehe euch nicht was soll das helfen wenn ich unter 32Bit 0% Auslastung habe.

Ich soll also den Code optimieren mit Framerate runterfahren usw.. mache meine 32Bit Version dadurch langsamer nur um die 64Bit Version was die CPU Auslastung angeht runterzufahren, ist nicht euer ernst oder?
Zudem hat das Auswirkungen auf alle nachfolgenden Anwendungen die dann diese DLL verwenden.

Zitat:

Ich würde auch vorschlagen in der Timer/Loop die Dir diese Kristalle animiert, einfach mal den Gfx Output auszukommentieren um schon mal zu erfahren ob es daran liegt.

Ich würde vorschlagen ihr überlegt mal was ihr da schreibt.
Ich soll den Code Schrotten damit der 64Bit Compiler (Kompilat am ende die CPU weniger auslastet?)
Nochmal! Wie kann eine Anwendung 64Bit mit gleichen Quell Code kompiliert um ein vielfaches schlechter sein als eine 32Bit Anwendung (Aber hallo in allen belangen)

Zitat:

Das der 64Bit-Compiler noch eine Baustelle ist, sollte allen klar sein.

Ich denke auch das dies das Hauptproblem ist.

Zitat:

Oder eventuell in der 64-Bit Release Konfiguration ausversehen irgendwelche Debug-Features aktiviert oder die Codeoptimierung deaktiviert?

Daran habe ich mich zuerst versucht..
Incl. Debug-Informationen sind natürlich deaktiviert. Davon ab auch mit aktiven Debug Infos ist die EXE bis auf 2>3K genauso groß wobei die Größe im Moment mal nicht mein Problem ist sondern die CPU Auslastung.
Code Optimierung ist an.

Ich glaube es ist zwecklos mit Delphi 64Bit Anwendungen zu entwickeln!
Nur weil ich den Schalter der Plattform umlege von 32 auf 64 und dann Kompiliere.. Schrotte ich mir fast meine CPU? Lustig das ganze.

gruss

[Daniel]

Zitat:

Zitat von EWeiss (Beitrag 1411570)

Ich glaube es ist zwecklos mit Delphi 64Bit Anwendungen zu entwickeln!
Nur weil ich den Schalter der Plattform umlege von 32 auf 64 und dann Kompiliere.. Schrotte ich mir fast meine CPU?

Dein Projekt ist offenbar nicht 64bit-kompatibel. Deine Erfahrungen lassen sich - zum Glück - nicht verallgemeinern.
An welcher Stelle exakt sollte der Compiler daran Schuld sein?

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1411570)

Ich glaube es ist zwecklos mit Delphi 64Bit Anwendungen zu entwickeln!

Richtig! Alle problemlos laufenden Delphi 64-Bit Anwendungen sind vermutlich eh nur Fake. :roll:

[EWeiss]

Zitat:

Zitat von Daniel (Beitrag 1411571)

Zitat:

Zitat von EWeiss (Beitrag 1411570)

Ich glaube es ist zwecklos mit Delphi 64Bit Anwendungen zu entwickeln!
Nur weil ich den Schalter der Plattform umlege von 32 auf 64 und dann Kompiliere.. Schrotte ich mir fast meine CPU?

Dein Projekt ist offenbar nicht 64bit-kompatibel. Deine Erfahrungen lassen sich - zum Glück - nicht verallgemeinern.
An welcher Stelle exakt sollte der Compiler daran Schuld sein?

Ist doch offensichtlich, habe den Part des Quelltextes gepostet.
Genau den gleichen verwende ich unter VS mit GDI+ (gleiche Version) und hier wird meine CPU NICHT ausgelastet.

Ich schicke dir gern den Quelltext kompiliere ihn dann sage du mir das es nicht so ist.
Ich sage es nochmal.. wie kann bei gleicher quellte das Ergebnis schlechter sein als mit 32Bit.
Fühlt euch doch nicht immer direkt auf dem Schlips getreten NUR wenn es um euer geliebtes Delphi geht es ist ein Werkzeug nicht mehr.
Einfach sachlich bleiben hilft unterm strich um einiges mehr.

Zitat:

Richtig! Alle problemlos laufenden Delphi 64-Bit Anwendungen sind vermutlich eh nur Fake.

Ja zu dem Schluss komme ich leider. Sachlich bleiben hilft mir unter umständen mehr.

gruss