HexToDec optimieren

[himitsu]

Daß die Varianten mit und ohne Ofset gleich schnell sind, hatte ich fast erwartet, wobei das früher aber auch mal von der größe des Offsets abhing, da kleinere Vielfache von 2 direkt in einem Index-Befehl kombiniert werden können.

Aber daß nun Byte und Integer gleich schnell sind, war bissl überraschen, aber das liegt wohl an der Ivy-Architektur.
Eigentlich sind ja zusätzliche umkopieroperationen nötig, um nochmal aus den Byte einen Integer zu machen.

Vorallem war ich etwas überascht, daß Zugriffe auf ein dynamisches Array manchmal schneller waren, als auf ein statisches Array, und selbst bei aktivierter Indexprüfung nicht viel langsamer wurden.

> i7

Code:

3:

HexB0 = 219
HexB1 = 203
HexI0 = 218
HexI1 = 218
HexS = 219
HexD = 327
Math = 312

B:

HexB0 = 203
HexB1 = 219
HexI0 = 218
HexI1 = 203
HexS = 203
HexD = 312
Math = 421

Random:

HexB0 = 234
HexB1 = 234
HexI0 = 219
HexI1 = 234
HexS = 218
HexD = 343
Math = 1529

Rein logisch sollte doch das Ergbnis im Random der Durchschnitt aus 3 und 8 sein, was beim Math bedeutet JUMP oder nicht JUMP und stattdessen DEC,
also 10/16-tel von 3 und 6/16-tel vom B.



Und wir hatten hier über die Jahre schon oftmals den Fall, wo man zwanghaft versuchte den Code via Assembler selber zu optimieren.
Abgesehn davon, daß man jetzt den Spaß hat und sich nicht mehr nur überlegen muß "Windows" und später auch noch "Windows 64" und dann bei speziallfällen noch Intel, AMD und welche Revision davon usw.
Jetzt auch noch OSx, iOS, Android, welcher Handyhersteller, .........

Aber das Krasseste war, daß oft sogar die Codeoptimierung vom Delphi schon so gut war, daß man manchmal nichtmal 'ne Millisekunde rausholen konnte.

[Dejan Vu]

Sehr schön, wenn man das einfach ausprobiert. Alles unter 5% würde ich als Rauschen erachten. Bei der Messdauer von 200ms pro Durchlauf bist Du aber bei einer Genauigkeit von +-18ms, sodaß ich hier die Anzahl der Durchläufe so erhöhen würde das ein Durchlauf mindestens 1-2 Sekunden dauert.

Ferner würde ich den Zugriff an die Erfordernisse anpassen, also nicht konstant immer auf den selben Array-Index zugreifen (man sieht sehr schön, wie Cache und Prediction hier zuschlagen) sondern eben z.B. zufällig.

Ich habe die Durchlaufzahl verdreifacht und bei mir kommt dann raus:

Code:

3:
HexB0 = 1467
HexB1 = 1450
HexI0 = 1046
HexI1 = 920
HexS = 905
HexD = 920
Math = 921

B:
HexB0 = 904
HexB1 = 921
HexI0 = 920
HexI1 = 905
HexS = 920
HexD = 921
Math = 1061

Random:
HexB0 = 999
HexB1 = 1372
HexI0 = 1576
HexI1 = 1560
HexS = 1560
HexD = 1779
Math = 7644

[himitsu]

Ich hatte das auch schon länger laufen lassen.

Aber ich hatte natürlich auch schon das verhalten, daß bei mehreren Durchgängen heute teilweise andere Ergebnisse rauskommen, als vor ein paar Stunden.


Außer beim Math sollten die Werte der jeweiligen 3 und B-Durchläufe im Durchschnitt gleich sein und Random im gleichen Verhältnis ein bissl ansteigen.
Und bei Math kommt es dann auf die CPU an. In einem uralten 8086 würde Dieses bestimmt plötzlich mit großer Sicherheit das Schnellste sein.