Seltsame Berechnung mit <sizeOf>

[negaH]

Nimm packed record und speichere diesen direkt.
Das hat die Vorteile
1.) weniger RAM Verbrauch deiner riesigen Levels
2.) vieleinfachere Speicher/Laderoutinen.


Performancetechnisch unterscheidet sich das garnicht, denn selbst wenn du ausgerichtete Records benutzen würdest so würde DEIN obiger Record KEINERLEI Performanceeinbussen haben. Das liegt daran das beide Felder an 8 Bytes Grenze ausgerichtet sind, und nur das zweite Feld eben nur 2 Bytes groß ist. Somit ist der Zugriff auf beide Felder immer an 8 Bytes ausgerichtet. Ein ausgerichteter Record würde nur noch zusätzlich 6 Bytes am Ende des Records verwalten der in jedem falle Performance irrelevant ist.
Heutige CPU's haben KEIN problem nur 1,2,4,8 Bytes zu laden, das geht alles gleich schnell/langsam. Sie haben nur das Problem wenn diese Daten NICHT an eienr Speicheradresse stehen die nicht an 4 bzw. 8 Bytes Grenze ausgerichtet wurde. Dann entstehen zusätzliche Taktzyklen innerhalb der CPU, aber im Grunde irrelevant für uns, da das unverhältnismäßig kleiner ist als die vielen anderen Flaschenhälse der Hardware (Festplatten, Threads, Tasksswitsches, Interrupts etc pp.)

Gruß Hagen

[Dannyboy]

Zitat von NicoDE:

Dann verstehe ich das Performance-'Problem' nicht, da es nur beim Zugriff auf nicht ausgerichtete Member und/oder nicht ausgerichtete (packed) Arrays auftritt...

Das Level selbst steht auch in der Datei drin. Eine Levelzelle besteht auch aus einem
Record (Byte, Integer, real und Word).

[NicoDE]

Hi Hagen,

Ich meinte oben den speziellen Fall 'Foo[i>0].Bar'. Der Zugriff wäre in seinem Falle nicht an 8-Byte-Grenzen ausgerichtet (sondern 'nur' 4-Byte) ... was aber auf den aktuellen CPUs (was Windows betrifft) kein Problem ist

[Gruber_Hans_12345]

Zitat von negaH:

Nimm packed record und speichere diesen direkt.
Das hat die Vorteile
1.) weniger RAM Verbrauch deiner riesigen Levels
2.) vieleinfachere Speicher/Laderoutinen.


Performancetechnisch unterscheidet sich das garnicht, denn selbst wenn du ausgerichtete Records benutzen würdest so würde DEIN obiger Record KEINERLEI Performanceeinbussen haben. Das liegt daran das beide Felder an 8 Bytes Grenze ausgerichtet sind, und nur das zweite Feld eben nur 2 Bytes groß ist. Somit ist der Zugriff auf beide Felder immer an 8 Bytes ausgerichtet. Ein ausgerichteter Record würde nur noch zusätzlich 6 Bytes am Ende des Records verwalten der in jedem falle Performance irrelevant ist.
Heutige CPU's haben KEIN problem nur 1,2,4,8 Bytes zu laden, das geht alles gleich schnell/langsam. Sie haben nur das Problem wenn diese Daten NICHT an eienr Speicheradresse stehen die nicht an 4 bzw. 8 Bytes Grenze ausgerichtet wurde. Dann entstehen zusätzliche Taktzyklen innerhalb der CPU, aber im Grunde irrelevant für uns, da das unverhältnismäßig kleiner ist als die vielen anderen Flaschenhälse der Hardware (Festplatten, Threads, Tasksswitsches, Interrupts etc pp.)

Gruß Hagen

Was passiert dann wenn aber 10 solcher Records in einem Array hintereinander stehen ? dann fängt das 2. record nicht an einer "geraden" Adresse an oder ?
Ist es beim kopieren von solchen Array's trotzdem nicht schneller, wenn 2mal 8 Bytes kopiert werden wie wenn einmal 8 und einmal 2 Bytes (oder 5m al 2 Bytes) kopiert werden müssen ?


Abgesehen davon würde ich auch packed records verwenden, da ich auch glaube, das der Performacne Gewinn im Vergleich zum schöneren und übersichtlichern / wartbaren Code einfach zu maginal ist.

Gruss
Hans

[w3seek]

Wie bereits mehrfach gesagt wurde ist der performanceverlust wirklich derart gering dass es normalerweise (vor allem nicht bei den derzeitigen CPUs) bemerkbar ist. Sowas macht sich hoechstens bei extremst rechenintensiven Code bemerkbar wie, hauptsaechlich im kernel bereich wie z.b. der scheduler. Da macht sich so ein performanceverlust schon deutlich bemerkbar. Wenn du allerdings "nur" einen Level-Editor hast macht das nicht sehr viel sinn. Zumal die Beeintraechtigung der Performance doch idr viel staerker durch andere prozesse oder Threads beeintraechtigt wird. Abgesehen davon wenn du so extrem optimieren willst dann wuerde ich auch eine andere Sprache vorziehen, der delphi codeoptimierer koennte auch um einiges besseren code erzeugen...

[negaH]

In einem Array[] of RecordXY würde nun der zweite Eintrag nur noch an 2 Bytes Grenze ausgerichtet sein. Dies ist aber nur halb so wild da das auf heutigen CPUs nur 1 Taktzyklus mehr beim Zugriff bedeutet. Die Piplines und der Cache der CPUs sind auf solche Daten optimiert. Der 1 Taktzyklus entsteht nur noch innerhalb der CPU die die 32Bit Daten in 16Bit runterbrechen muß.

Beim Kopieren ist es wiederum irrelevant das man clevererweise mit Move(Source[0], Dest[0], Count * SizeOf(Source[0])); kopieren wird. In diesem Moment behandelt die CPU die kompletten Daten als ein an 4/8 Bytes Grenzen ausgerichteten Datenblock. Das kopieren wäre sogar effizienter mit packed records da viel weniger unnötige Daten kopiert werden müssen.

Nimm immer packed Records kann ich nur sagen, und konzentiere dich darauf deine Algorithmen zu verbessern falls du mehr Speed brauchst. Der Unterschied zwischen packed und unpacked Records würde erst relevant wenn man den Rest des gesammten Codes schonn in handmade Assembler codiert hat, nur dann würde eine Ausrichtung der Daten zum Verhältnis des zeitlichen Programmieraufwandes stehen.

Wenn du wirklich was optimieren willst dann vermeide den Int64 und erhöhe das Word auf Cardinal.
Beim Int64 produziert der Compiler wesentlich inperformanteren Code der sehr oft in die RTL spingen muß, als für Cardinals, und nur beim Zugriff auf 16 Bit oder 8 Bit Daten wird eine 32Bit CPU ausgebremst, somit mache aus dem Word ein Cardinal und alles ist ok.
Das schlimme mit 8/16Bit Daten ist sogar das dieser Flaschenhals innerhalb der CPU die voherigen und nachfolgenden 32Bit CPU Befehle zusätzlich ausbremst, es entshene sogenannte Stalls.

Gruß Hagen