Wie gehe ich eine Aufzählung konsequent durch? - Seite 3

 
Alexey Navoykov:

Die hier gezeigten Beispiele (Fall 1: Rückgabewert1; Fall 2: Rückgabewert2; Fall 3: Rückgabewert3... Eine geeignete Person würde alle Werte in einem Array ablegen und den gewünschten Wert nur über seinen Index abrufen. Und für die umgekehrte Aufgabe würde er/sie die binäre Suche verwenden.

Ich bin mit beiden Händen für schönen Code mit Arrays. Aber beim Schreiben einer schnelleren NormalizeDouble als die reguläre, habe ich einen Optimierer-Effekt gestoßen - die schöne Lösung über const-Array war viel langsamer als die umständliche switch-case-Lösung. Ich habe die zweite Variante belassen, weil NormalizeDouble im Tester viel verwendet wird. Ich stecke es in den Indikator und schaue nicht auf dieses Monster. Aber die Backtests laufen schneller.
 
fxsaber:
Ich bin mit beiden Händen für einen schönen Code mit Arrays. Aber beim Schreiben einer schnelleren NormalizeDouble als die reguläre, habe ich einen Optimierer-Effekt gestoßen - eine schöne Lösung über const-Array war viel langsamer als eine umständliche über switch-case. Ich habe die zweite Variante belassen, weil NormalizeDouble im Tester viel verwendet wird. Ich stecke es in den Indikator und schaue nicht auf dieses Monster. Aber die Backtests laufen schneller.

Ich erinnere mich, dass es einmal einen Thread gab, in dem über Switch diskutiert wurde und die Entwickler nur über die Implementierung als binäre Suche sprachen, die natürlich viel langsamer ist als der einfache Zugriff über einen berechneten Index.Aber jetzt scheinen sie es klüger gemacht zu haben: Wenn ein Schritt konstant ist, wird der Index berechnet, andernfalls wird eine binäre Suche durchgeführt. Natürlich ist eine native Implementierung immer schneller als eine Wrapper-Implementierung.

Das hängt natürlich von Ihren Prioritäten ab. Aber imho, wenn Geschwindigkeit so wichtig ist, dass man bereit ist, Krücken zu erfinden, dann sollte man auch OOP und MQL aufgeben ;) Obwohl ich sicher bin, dass der Geschwindigkeitsunterschied bei richtiger Codierung nicht so signifikant ist. Bei Testmessungen lässt man eine Funktion einfach millionenfach in einer Schleife hin und her springen. Und in echtem Code verwenden Sie sie rationeller, nicht wahr?

 
Alexey Navoykov:

Ich erinnere mich, dass es einmal einen Thread gab, in dem über Switch diskutiert wurde und die Entwickler nur über die Implementierung als binäre Suche sprachen, die natürlich viel langsamer ist als der einfache Zugriff über einen berechneten Index.Aber jetzt scheinen sie es klüger gemacht zu haben: wenn der Schritt konstant ist, dann wird der Index berechnet, ansonsten binäre Suche. Natürlich ist die native Implementierung immer schneller als die Wrapper-Implementierung.

Der Compiler, wenn er nicht dumm ist, müsste das const-array und den einzigen Typverweis darauf durch den Index in switch-Code umwandeln.

Natürlich müssen Sie das je nach Ihren Prioritäten tun. Aber imho, wenn Geschwindigkeit so wichtig ist, dass Sie bereit sind, Krücken zu erfinden, dann sollten Sie OOP und MQL im Allgemeinen aufgeben ;) Obwohl ich sicher bin, dass bei korrekter Codierung der Geschwindigkeitsunterschied nicht so erheblich sein wird. Bei Testmessungen lassen Sie einfach eine Funktion Millionen Mal durch eine Schleife laufen. Und in echtem Code verwenden Sie es rationaler, nicht wahr?

Die Geschwindigkeit ist nicht entscheidend, aber wenn ich irrational schreibe, fühle ich mich unwohl. Es ist natürlich nicht vernünftig, OOP überhaupt nicht zu verwenden. Wie auch immer, schauen Sie sich die bescheidenen Anstrengungen in kodobase an, die Sie unternommen haben und die seit vielen Tagen nicht mehr gezählt wurden. Dort werden Sie verstehen, wo die Krücken in Form des gleichen NormalizeDouble erschienen. Es ist das Ergebnis einer zufälligen Tatsache aus manchmal irrationalen Implementierungen von Entwicklern.
 
fxsaber:
Der Compiler, wenn er nicht dumm ist, wäre gezwungen gewesen, das const-Array und den einzigen Typverweis darauf per Index in Switch-Code zu verwandeln.

Das Array ist also nur eine Konstante? Wie steht es mit der Statik? Es ist eine einfache Operation: Vergleichen Sie den Indexwert mit der Array-/Enum-Größe, und wenn er kleiner ist, ermitteln Sie die Adresse des gewünschten Elements als Array-Adresse + Index, und lesen Sie dann den Wert von dort. Ich dachte, so ein Blödsinn muss gleich kompiliert werden.

Wie dem auch sei, schauen Sie sich die bescheidenen Bemühungen in kodobase an, die ich angelegt habe und seit vielen Tagen nicht mehr gezählt habe. Dort werden Sie verstehen, wo die Krücken in Form von eben jenem NormalizeDouble auftauchten. Sie ist das Ergebnis einer zufälligen Tatsache aus manchmal irrationalen Implementierungen der Entwickler.
Und übrigens, wie lange ist es her, dass Sie diese Vergleiche durchgeführt haben? Vielleicht war der Compiler damals noch "dumm"?
 
Alexey Navoykov:

Das Array ist also nur eine Konstante? Wie steht es mit der Statik? Es ist eine einfache Operation: Vergleichen Sie den Indexwert mit der Array-/Enum-Größe, und wenn er kleiner ist, ermitteln Sie die Adresse des gewünschten Elements als Array-Adresse + Index, und lesen Sie dann den Wert von dort. Ich dachte, so ein Blödsinn muss auf die gleiche Weise kompiliert werden.

Ich weiß nicht mehr genau, ob Sie statische Arrays mit const-Methoden erstellen können - mit Sicherheit nicht. Ich habe prinzipiell Konstanten und keine Statik gemacht. Verlassen Sie sich auf die Intelligenz des Compilers. Nach der Kompilierung sollte in den Eingeweiden kein Hinweis auf ein Array mehr zu finden sein. Eine statik ist eine viel kompliziertere Struktur als const. Deshalb war ich sicher, dass der Compiler mit der statik nicht zurechtkommen würde. Aber ich werde es versuchen müssen.

Mir ist nicht ganz klar, welche "Bemühungen" Sie meinen. Und übrigens, wie lange ist es her, dass Sie diese Vergleiche durchgeführt haben? Vielleicht war der Compiler damals noch "dumm"?
Der Aufwand wird sichtbar, sobald einer der Moderatoren ein paar Knöpfe drückt und grünes Licht für die Veröffentlichung des Codes in kodobase gibt. Ich habe eine bequeme Lösung für mich selbst gefunden, ohne an die Leistung zu denken, und habe einen Gewinn von fast einer Größenordnung im Build 1383 32-Bit erzielt.
 
fxsaber:

Ich weiß nicht mehr genau, ob statische Arrays konstant gemacht werden können. Im Prinzip habe ich Konstanten gemacht, keine Statik. Verlassen Sie sich auf die Intelligenz des Compilers. Nach der Kompilierung sollte in den Eingeweiden kein Hinweis auf ein Array mehr zu finden sein. Eine statik ist eine viel kompliziertere Struktur als const, so dass ich sicher war, dass der Compiler mit der statik nicht zurechtkommen würde. Aber ich werde es versuchen müssen.

Oh, das erklärt es. Sie sollten sich nicht auf die übermäßige Intelligenz des Compilers verlassen, dass er eine schlecht konzipierte Lösung für Sie weiter optimiert. Wenn Sie selbst zu faul sind, es richtig zu machen, und sagen, dass "Statik viel komplizierter ist" (obwohl ich nicht verstehe, was daran kompliziert sein soll), warum beschuldigen Sie dann den Compiler?

 
Alexey Navoykov:

Oh, das erklärt es. Sie sollten sich nicht auf die übermäßige Intelligenz des Compilers verlassen, denn er wird eine schlecht konzipierte Lösung für Sie optimieren. Wenn Sie selbst zu faul sind, es richtig zu machen, und sagen: "Statik ist viel komplizierter" (obwohl ich nicht verstehe, was daran kompliziert ist), warum beschuldigen Sie dann den Compiler?

Ich habe dem Array static hinzugefügt. Es funktionierte fast dreimal schneller als der Schalter! Werfen Sie den Schalter weg. Danke für den Tipp!
 
fxsaber:
Ich habe dem Array static hinzugefügt. Es funktionierte fast dreimal schneller als der Schalter! Schmeißen Sie diesen Schalter weg. Danke für den Tipp!

Gern geschehen. Das wird mir eine Lehre für die Zukunft sein, dass ich 7 Mal nachdenken sollte, bevor ich herumlaufe und Krücken erfinde).

Es stellt sich nun heraus, dass ich den Schalter bzw. seine Entwickler zu früh gelobt habe, so dass dort alles nur durch binäre Suche implementiert ist, auch wenn die Aufzählung mit Vielfachen geht. Nicht gut.

 
Alexey Navoykov:

Gern geschehen. Es wird eine Lehre für die Zukunft sein, 7 Mal nachzudenken, bevor man losrennt und Krücken erfindet).

Fast viermal schneller als Standard NormalizeDouble (Build 1395)... ist eine Krücke der Entwickler.

 
fxsaber:
Fast viermal schneller als Standard NormalizeDouble (Build 1395)... ist eine Krücke der Entwickler.

Nicht jeder ist ohne Sünde )