Test: Performance von Types

Übersicht

BlitzBasic

Allgemein

	Casiopaya Betreff: Test: Performance von Types	Mo, Jun 30, 2008 14:24 Antworten mit Zitat
Hi, Kein Frage, nur ein Anmerkung, vllt bringts dem einen oder anderen was: Da es bei meinem Raytracer auf Speed ankommt hab ich mal ein kleines Testprogramm geschrieben, welches die Geschwindigkeit von Type-Dereferenzierungen (also immer wenn man ein "\" schreibt) im Vergleich zu normalen Variablen auflistet. Das Ergebnis: Eine Dereferenzierung benötigt an und für sich nicht viel mehr oder weniger Zeit als eine Zuweisung. Mit anderen Worten: Wer in einer Schleife oft auf Type-Member zugreift bzw. diese ließt, für den lohnt es sich evt. alle BErechnungen komplett in Variablen auszulagern, oder bei verschachtelten Types zumindest die letzte Variable zu cachen. Code: [AUSKLAPPEN] [EINKLAPPEN] Const COUNT% = 100000000 ; Test-Type: Type TestType Field int1% Field int2% Field int3% Field child1.TestType End Type ; Normale Variablen, keine Types: t1% = 0 t2% = 0 t3% = 0 i% = 0 start% = MilliSecs() For i% = 0 To COUNT% t1% = t3% + 1 t2% = t1% + 1 t3% = t2% + 1 Next ende% = MilliSecs() Print "(1) Mit Variablen: " + (ende% - start%) + " ms." ; Types, eine Dereferenzierung: test.TestType = New TestType i% = 0 start% = MilliSecs() For i% = 0 To COUNT% test\int1% = test\int3% + 1 test\int2% = test\int1% + 1 test\int3% = test\int2% + 1 Next ende% = MilliSecs() Print "(2) Mit Types (eine Dereferenzierung): " + (ende% - start%) + " ms." ; Types, eine Dereferenzierung: test.TestType = New TestType i% = 0 start% = MilliSecs() For i% = 0 To COUNT% int1% = test\int1% int2% = test\int2% int3% = test\int3% int1% = int3% +1 int2% = int1% +1 int3% = int2% +1 test\int1% = int1% test\int2% = int2% test\int3% = int3% Next ende% = MilliSecs() Print "(3) Mit Types (eine Dereferenz., ausgel.): " + (ende% - start%) + " ms." ; Types, zwei Dereferenzierungen, eine gecached: test.TestType = New TestType test\child1 = New TestType tempChild.TestType = test\child1 i% = 0 start% = MilliSecs() For i% = 0 To COUNT% tempChild\int1% = tempChild\int3% + 1 tempChild\int2% = tempChild\int1% + 1 tempChild\int3% = tempChild\int2% + 1 Next ende% = MilliSecs() Print "(4) Mit Types (zwei Dereferenz., 1. gecached): " + (ende% - start%) + " ms." ; Types, zwei Dereferenzierungen: test.TestType = New TestType test\child1 = New TestType i% = 0 start% = MilliSecs() For i% = 0 To COUNT% test\child1\int1% = test\child1\int3% + 1 test\child1\int2% = test\child1\int1% + 1 test\child1\int3% = test\child1\int2% + 1 Next ende% = MilliSecs() Print "(5) Mit Types (zwei Dereferenzierungen): " + (ende% - start%) + " ms." ; Drück mich: WaitKey() (4) ist eigentlich nur zum Spass da. Was sich beim Vergleich von (2) und (3) zeigt, ist dass sich vermutlich bei schon 3-4 Dereferenzierungen ein Auslagern in Variablen lohnt. Grüße Casiopaya

Casiopaya

Betreff: Test: Performance von Types

Mo, Jun 30, 2008 14:24
Antworten mit Zitat

Hi,

Kein Frage, nur ein Anmerkung, vllt bringts dem einen oder anderen was:

Da es bei meinem Raytracer auf Speed ankommt hab ich mal ein kleines Testprogramm geschrieben, welches die Geschwindigkeit von Type-Dereferenzierungen (also immer wenn man ein "\" schreibt) im Vergleich zu normalen Variablen auflistet. Das Ergebnis: Eine Dereferenzierung benötigt an und für sich nicht viel mehr oder weniger Zeit als eine Zuweisung. Mit anderen Worten: Wer in einer Schleife oft auf Type-Member zugreift bzw. diese ließt, für den lohnt es sich evt. alle BErechnungen komplett in Variablen auszulagern, oder bei verschachtelten Types zumindest die letzte Variable zu cachen.

Code: [AUSKLAPPEN]

Const COUNT% = 100000000

; Test-Type:
Type TestType
Field int1%
Field int2%
Field int3%
Field child1.TestType
End Type

; Normale Variablen, keine Types:
t1% = 0
t2% = 0
t3% = 0
i% = 0
start% = MilliSecs()
For i% = 0 To COUNT%
t1% = t3% + 1
t2% = t1% + 1
t3% = t2% + 1
Next
ende% = MilliSecs()
Print "(1) Mit Variablen: " + (ende% - start%) + " ms."

; Types, eine Dereferenzierung:
test.TestType = New TestType
i% = 0
start% = MilliSecs()
For i% = 0 To COUNT%
test\int1% = test\int3% + 1
test\int2% = test\int1% + 1
test\int3% = test\int2% + 1
Next
ende% = MilliSecs()
Print "(2) Mit Types (eine Dereferenzierung): " + (ende% - start%) + " ms."

; Types, eine Dereferenzierung:
test.TestType = New TestType
i% = 0
start% = MilliSecs()
For i% = 0 To COUNT%
int1% = test\int1%
int2% = test\int2%
int3% = test\int3%

int1% = int3% +1
int2% = int1% +1
int3% = int2% +1

test\int1% = int1%
test\int2% = int2%
test\int3% = int3%
Next
ende% = MilliSecs()
Print "(3) Mit Types (eine Dereferenz., ausgel.): " + (ende% - start%) + " ms."

; Types, zwei Dereferenzierungen, eine gecached:
test.TestType = New TestType
test\child1 = New TestType
tempChild.TestType = test\child1

i% = 0
start% = MilliSecs()
For i% = 0 To COUNT%
tempChild\int1% = tempChild\int3% + 1
tempChild\int2% = tempChild\int1% + 1
tempChild\int3% = tempChild\int2% + 1
Next
ende% = MilliSecs()
Print "(4) Mit Types (zwei Dereferenz., 1. gecached): " + (ende% - start%) + " ms."

; Types, zwei Dereferenzierungen:
test.TestType = New TestType
test\child1 = New TestType

i% = 0
start% = MilliSecs()
For i% = 0 To COUNT%
test\child1\int1% = test\child1\int3% + 1
test\child1\int2% = test\child1\int1% + 1
test\child1\int3% = test\child1\int2% + 1
Next
ende% = MilliSecs()
Print "(5) Mit Types (zwei Dereferenzierungen): " + (ende% - start%) + " ms."

; Drück mich:
WaitKey()

(4) ist eigentlich nur zum Spass da. Was sich beim Vergleich von (2) und (3) zeigt, ist dass sich vermutlich bei schon 3-4 Dereferenzierungen ein Auslagern in Variablen lohnt.

Grüße Casiopaya

	aMul Sieger des Minimalist Compo 01/13	Mo, Jun 30, 2008 14:51 Antworten mit Zitat
Ich denke, wenn es einem so sehr um die Geschwindigkeit geht, dass man für Berechnungen von Types auf lokale Variablen ausweicht sollte man wenn dann doch gleich eine andere schnellere Sprache nehmen (womit ich nicht sagen möchte, dass BB langsam ist). Aber wem es Spaß macht, den möchte ich natürlich nicht daran hindern seinen Code unübersichtlicher zu machen
Panic Pong - ultimate action mashup of Pong and Breakout <= aktives Spiele-Projekt, Downloads mit vielen bunten Farben! advASCIIdraw - the advanced ASCII art program <= aktives nicht-Spiele-Projekt, must-have für ASCII/roguelike/dungeon-crawler fans! Alter BB-Kram: ThroughTheAsteroidBelt - mit Quelltext! \| RGB-Palette in 32²-Textur / Farbige Beleuchtung mit Dot3 \| Stereoskopie in Blitz3D \| Teleport-Animation Screensaver

aMul

Sieger des Minimalist Compo 01/13

Mo, Jun 30, 2008 14:51
Antworten mit Zitat

Ich denke, wenn es einem so sehr um die Geschwindigkeit geht, dass man für Berechnungen von Types auf lokale Variablen ausweicht sollte man wenn dann doch gleich eine andere schnellere Sprache nehmen (womit ich nicht sagen möchte, dass BB langsam ist).

Aber wem es Spaß macht, den möchte ich natürlich nicht daran hindern seinen Code unübersichtlicher zu machen Razz

Panic Pong - ultimate action mashup of Pong and Breakout <= aktives Spiele-Projekt, Downloads mit vielen bunten Farben!
advASCIIdraw - the advanced ASCII art program <= aktives nicht-Spiele-Projekt, must-have für ASCII/roguelike/dungeon-crawler fans!
Alter BB-Kram: ThroughTheAsteroidBelt - mit Quelltext! | RGB-Palette in 32²-Textur / Farbige Beleuchtung mit Dot3 | Stereoskopie in Blitz3D | Teleport-Animation Screensaver

	Dreamora	Mo, Jun 30, 2008 14:57 Antworten mit Zitat
[diskussion über optimierungen die in wirklichkeit deoptimierungen sind für 99% der user] wer 100 Mio zugriffe hat sollte sich ohnehin Mal fragen ob der Code nicht ganz extrem schlecht strukturiert ist von den Schleifen und Datenstrukturen her. Dieses Benchmark ist, so leid mir das tut, noch wertlos als Grafikkartenbenchmarks, denn das hier hat überhaupt nix mehr mit der Realität zu tun. Die Performance deiner "normalen Variablen" hast du nur weil du zu wenige Variablen hast um den Cache der CPU zu überladen, dann würdest du nämlich feststellen dass das Fetching das wieder zu nem erheblichen Teil zunichte macht. Vor allem wirst du, wenn du um types mit Variablen rumarbeitest auch mehr globals haben, die dann doch einiges langsamer sind weil sie nur temporär im CPU Cache enden. [/diskussion über optimierungen die in wirklichkeit deoptimierungen sind für 99% der user]
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mo, Jun 30, 2008 14:57
Antworten mit Zitat

[diskussion über optimierungen die in wirklichkeit deoptimierungen sind für 99% der user]
wer 100 Mio zugriffe hat sollte sich ohnehin Mal fragen ob der Code nicht ganz extrem schlecht strukturiert ist von den Schleifen und Datenstrukturen her.

Dieses Benchmark ist, so leid mir das tut, noch wertlos als Grafikkartenbenchmarks, denn das hier hat überhaupt nix mehr mit der Realität zu tun.

Die Performance deiner "normalen Variablen" hast du nur weil du zu wenige Variablen hast um den Cache der CPU zu überladen, dann würdest du nämlich feststellen dass das Fetching das wieder zu nem erheblichen Teil zunichte macht.
Vor allem wirst du, wenn du um types mit Variablen rumarbeitest auch mehr globals haben, die dann doch einiges langsamer sind weil sie nur temporär im CPU Cache enden.

[/diskussion über optimierungen die in wirklichkeit deoptimierungen sind für 99% der user]

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	Casiopaya	Mo, Jun 30, 2008 17:47 Antworten mit Zitat
Oh Leute, seit dich nicht gleich so negativ Dreamora hat Folgendes geschrieben: wer 100 Mio zugriffe hat sollte sich ohnehin Mal fragen ob der Code nicht ganz extrem schlecht strukturiert ist von den Schleifen und Datenstrukturen her. Solche Allgemeinaussagen sind nie sinnvoll. Oft es es sicher so, in Spezialfällen programmiert man etwas, was wenig Datenstruktur und viel viel Rechnaufwand benötigt. Ich hab ja extra meinen Raytracer erwähnt, bei dem ist dies halt so. Es gibt sicher noch ein paar andere Beispiele (z.B. das Berechnen von Fraktalen), bei denen es auf auf pure, dumme Rechenpower ankommt. Dreamora hat Folgendes geschrieben: Dieses Benchmark ist, so leid mir das tut, noch wertlos als Grafikkartenbenchmarks, denn das hier hat überhaupt nix mehr mit der Realität zu tun. Lol ich hab doch nicht behauptet, das sei ein Grafikkartenbenchmark?? Es ging um den reinen Performance-Vergleich von Zuweisungen und Dereferenzierungen. Dreamora hat Folgendes geschrieben: Die Performance deiner "normalen Variablen" hast du nur weil du zu wenige Variablen hast um den Cache der CPU zu überladen Wenn man die selbe Sache immer und immer wieder berechnen muss, ohne dass sich dabei prinzipiell was ändert (bei einem Raytracer oder einem Fraktal ist das so) dann macht es eindeutig einen Performance-Vorteil. Ich habs schon ausprobiert, bei meinem Raytracer macht es einen deutlichen Unterschied. Da hab ich halt locker ein paar Millionen Zugriffe pro Frame. Falls es nicht auf Performance ankommt dann ist sauberer, strukturierter Code jeder Optimierung vorzuziehen, eine wichtige Regel lautet: "Nicht überoptimieren". Bei mancher Anwendung lohnt es sicher aber eben den Flaschenhalt zu öffnen und dadurch (in diesem Fall) z.B. Faktoren von 2 oder 3 rauszuholen

Casiopaya

Mo, Jun 30, 2008 17:47
Antworten mit Zitat

Oh Leute, seit dich nicht gleich so negativ Razz

Dreamora hat Folgendes geschrieben:

wer 100 Mio zugriffe hat sollte sich ohnehin Mal fragen ob der Code nicht ganz extrem schlecht strukturiert ist von den Schleifen und Datenstrukturen her.

Solche Allgemeinaussagen sind nie sinnvoll. Oft es es sicher so, in Spezialfällen programmiert man etwas, was wenig Datenstruktur und viel viel Rechnaufwand benötigt. Ich hab ja extra meinen Raytracer erwähnt, bei dem ist dies halt so. Es gibt sicher noch ein paar andere Beispiele (z.B. das Berechnen von Fraktalen), bei denen es auf auf pure, dumme Rechenpower ankommt.

Dreamora hat Folgendes geschrieben:

Dieses Benchmark ist, so leid mir das tut, noch wertlos als Grafikkartenbenchmarks, denn das hier hat überhaupt nix mehr mit der Realität zu tun.

Lol ich hab doch nicht behauptet, das sei ein Grafikkartenbenchmark?? Es ging um den reinen Performance-Vergleich von Zuweisungen und Dereferenzierungen.

Dreamora hat Folgendes geschrieben:

Die Performance deiner "normalen Variablen" hast du nur weil du zu wenige Variablen hast um den Cache der CPU zu überladen

Wenn man die selbe Sache immer und immer wieder berechnen muss, ohne dass sich dabei prinzipiell was ändert (bei einem Raytracer oder einem Fraktal ist das so) dann macht es eindeutig einen Performance-Vorteil.

Ich habs schon ausprobiert, bei meinem Raytracer macht es einen deutlichen Unterschied. Da hab ich halt locker ein paar Millionen Zugriffe pro Frame.

Falls es nicht auf Performance ankommt dann ist sauberer, strukturierter Code jeder Optimierung vorzuziehen, eine wichtige Regel lautet: "Nicht überoptimieren". Bei mancher Anwendung lohnt es sicher aber eben den Flaschenhalt zu öffnen und dadurch (in diesem Fall) z.B. Faktoren von 2 oder 3 rauszuholen

Cool

	Dreamora	Mo, Jun 30, 2008 18:03 Antworten mit Zitat
Einen Raytracer macht man auch nicht mit Types sondern eher mit Banks oder etwas ähnlichem das man zu späterem Zeitpuntk auch einfach via externem Code in Form einer Userlib machen kann zb, und das vor allem im RAM in einem kontinuierlichen Berech ist um zu verhindern das die CPU die ganze Zeit neue RAM Pages fetchen muss. Darüber hinaus wurde ja bereits festgestellt: Blitz taugt nicht für nen Raytracer. Da Blitz3D / Plus nicht mal Float Genaugkeit hat, gibt das leider bestenfalls einen "RayApproximator" Und nein ich sagte nicht das es ein Grafikbenchmark ist. Ich sagte das es vom Nutzen her noch wertloser ist als solche, da der Fall komplett unrealistisch ist. Niemand würden wenn in einer schleife immer wieder der gleiche wert genutzt wird, den wert immer wieder querien, sei es jetzt durch einen funktionsaufruf oder durch zugriff auf immer und immer wieder denselben Type, denn das kann nur übel enden soferns der Compiler nicht für dich optimiert, was der Blitz Compiler nicht tut, er kompiliert genau das womit du ihn fütterst. Steht sogar, wenn ich mich nicht irre, im Anfänger Guide. Man kann erstaunlicherweise mit sauber strukturiertem Code auch optimieren (häufig sogar noch viel besser), ist so ne Behauptung von faulen Leuten und C++ Hackern das Optimierung nur geht wenn man den Code dafür grausig strukturiert. Das stimmt nur wenn man auf einem sehr professionellem Level optimiert, das ist jedoch in Blitz3D / Plus garnicht möglich ist. Randbemerkung: Mit solchen unrealistischen Benchmarks zum testen hast du recht gute Chancen die eigentlichen Optimierungen total zu zerschiessen wenn du daraus schlüsse ziehen willst. Wenn du was optimieren willst, profile deinen Code und schau dir an was der flaschenhals ist, nicht unrealistische annahmen treffen.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mo, Jun 30, 2008 18:03
Antworten mit Zitat

Einen Raytracer macht man auch nicht mit Types sondern eher mit Banks oder etwas ähnlichem das man zu späterem Zeitpuntk auch einfach via externem Code in Form einer Userlib machen kann zb, und das vor allem im RAM in einem kontinuierlichen Berech ist um zu verhindern das die CPU die ganze Zeit neue RAM Pages fetchen muss.

Darüber hinaus wurde ja bereits festgestellt: Blitz taugt nicht für nen Raytracer. Da Blitz3D / Plus nicht mal Float Genaugkeit hat, gibt das leider bestenfalls einen "RayApproximator"

Und nein ich sagte nicht das es ein Grafikbenchmark ist. Ich sagte das es vom Nutzen her noch wertloser ist als solche, da der Fall komplett unrealistisch ist.
Niemand würden wenn in einer schleife immer wieder der gleiche wert genutzt wird, den wert immer wieder querien, sei es jetzt durch einen funktionsaufruf oder durch zugriff auf immer und immer wieder denselben Type, denn das kann nur übel enden soferns der Compiler nicht für dich optimiert, was der Blitz Compiler nicht tut, er kompiliert genau das womit du ihn fütterst.
Steht sogar, wenn ich mich nicht irre, im Anfänger Guide.

Man kann erstaunlicherweise mit sauber strukturiertem Code auch optimieren (häufig sogar noch viel besser), ist so ne Behauptung von faulen Leuten und C++ Hackern das Optimierung nur geht wenn man den Code dafür grausig strukturiert. Das stimmt nur wenn man auf einem sehr professionellem Level optimiert, das ist jedoch in Blitz3D / Plus garnicht möglich ist.

Randbemerkung: Mit solchen unrealistischen Benchmarks zum testen hast du recht gute Chancen die eigentlichen Optimierungen total zu zerschiessen wenn du daraus schlüsse ziehen willst. Wenn du was optimieren willst, profile deinen Code und schau dir an was der flaschenhals ist, nicht unrealistische annahmen treffen.

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Zuletzt bearbeitet von Dreamora am Mo, Jun 30, 2008 18:24, insgesamt 2-mal bearbeitet

	Casiopaya	Mo, Jun 30, 2008 18:15 Antworten mit Zitat
Hoppla, da ist wohl jemand mit dem falschen Fuß aufgestanden. Beitrag kann geschlossen werden.

Casiopaya

Mo, Jun 30, 2008 18:15
Antworten mit Zitat

Hoppla, da ist wohl jemand mit dem falschen Fuß aufgestanden.

Beitrag kann geschlossen werden.

Übersicht

BlitzBasic

Allgemein

Nach Oben

BlitzBasic Portal

Test: Performance von Types

Casiopaya

Betreff: Test: Performance von Types

aMul

Dreamora

Casiopaya

Dreamora

Casiopaya