Fehler, Irrtümer, Fragen - Seite 1952
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Compiler hilft hier nicht - getestet - lokales Objekt wird bei Rückgabe dupliziert und dann festgenagelt. In diesem Fall gibt es keinen optimalen Zug.
Haben Sie Geschwindigkeitstests durchgeführt? Oder nur die Diagnose der Objekterstellung? Wenn es das zweite ist, wird natürlich nichts aus dem Code entfernt, weil Sie selbst dies mit Ihren Prüfungen verhindern.
Haben Sie Geschwindigkeitstests durchgeführt? Oder diagnostizieren Sie nur die Tatsache, dass ein Objekt erstellt wurde? In letzterem Fall wird natürlich nichts aus dem Code herausgeschnitten, da Sie selbst dies durch Ihre Kontrollen verhindern.
Wie war das? Alle meine Prüfungen bestehen nur aus Spuren, die in Konstruktoren und Destruktoren gesetzt werden. Wenn zusätzliche Kopien erstellt und gelöscht werden, ist das für mich Beweis genug, dass es keine Optimierung gibt.
Haben Sie Tests zur Geschwindigkeitsmessung durchgeführt? Oder diagnostizieren Sie nur die Tatsache der Objekterstellung? Im zweiten Fall wird natürlich nichts aus dem Code herausgeschnitten, weil Sie dies mit Ihren Prüfungen selbst verhindern.
Nun, wenn man keine Linien bewegen kann, kann man auch keine komplexeren Objekte bewegen.
Wie ist das? Alle meine Prüfungen bestehen nur aus Spuren, die in Konstruktoren und Destruktoren gesetzt werden. Wenn zusätzliche Kopien erstellt und gelöscht werden, ist das für mich ein ausreichender Beweis für eine fehlende Optimierung.
In OnTesterInit können Sie nun Optimierungsbereiche für jeden Eingabeparameter festlegen. Der Prüfer erstellt dann selbst eine Durchgangstabelle, teilt sie in die Anzahl der Agenten/Pakete auf und sendet sie an die Agenten. Diese Tabelle ist jetzt nicht mehr bearbeitbar.
Bei der Optimierung ist es jedoch sehr üblich, sich zunächst mit Durchgängen zu befassen, bei denen sich ein wichtiger Parameter ändert, dann ein anderer, usw. Wenn es möglich wäre, eine generierte Tabelle von Pässen zu bearbeiten (um die Plätze von Elementen (Sätzen von Eingabeparametern) zu ändern) oder sie selbst zu generieren, wäre es möglich, die notwendige Priorität festzulegen, wenn die interessantesten Pässe zuerst an Agents gehen würden und dann - weniger interessante Pässe.
Daher schlage ich vor, OnTesterInit die Möglichkeit hinzuzufügen, die Standardtabelle der Pässe zu ändern:
Der Optimierer wird nicht in der Lage sein, den Abschnitt zu schneiden, in dem sich Ihre Kurve befindet.) Sie kann nur Dinge herausschneiden, die die Logik des Werks nicht beeinträchtigen.
Nun, das Thema ist vorbei ;-). Ich denke, dass die Optimierung in diesem Fall nur an der Codestelle erfolgen kann, an der der Rückgabewert auftritt, und in keiner Weise davon abhängt, was im Konstruktor geschrieben wird.
C++11-Standard: Wenn bestimmte Kriterien erfüllt sind, darf eine Implementierung die Copy/Move-Konstruktion eines Klassenobjekts auslassen, selbst wenn der Copy/Move-Konstruktor und/oder Destruktor für das Objekt Seiteneffekte haben. In solchen Fällen behandelt die Implementierung die Quelle und das Ziel des ausgelassenen Kopier-/Verschiebevorgangs einfach als zwei verschiedene Arten, auf dasselbe Objekt zu verweisen, und die Zerstörung dieses Objekts erfolgt zu dem späteren Zeitpunkt, zu dem die beiden Objekte ohne die Optimierung zerstört worden wären.
Nun, das Thema ist vorbei ;-). Meiner Meinung nach könnte die Optimierung in diesem Fall nur an der Stelle des Codes stattfinden, an der die Wertrückgabe erfolgt, und sie hängt in keiner Weise davon ab, was im Konstruktor geschrieben steht.
Wie auch immer, ich muss leider zugeben, dass der MQL-Compiler bei weitem nicht so clever ist, wie ich dachte.) Ich würde sogar sagen, dass es überhaupt nicht intelligent ist. ) Ich habe versucht, einige einfache Beispiele zu erstellen, und es stellte sich heraus, dass selbst wenn ich ein Dummy-Objekt erstelle, das nirgendwo verwendet wird und nichts tut, der Compiler sich nicht darum kümmert. Es ist überhaupt nicht optimiert. Ich urteile allein nach der Geschwindigkeit. Und aus irgendeinem Grund funktioniert es in neuen Builds langsamer als in alten Builds.
Hier ist ein trivialer Code:
Nun, ich muss leider zugeben, dass der MQL-Compiler nicht so schlau ist, wie ich dachte) Ich würde sogar sagen, es ist überhaupt nicht klug).
Haben Sie schon einmal darüber nachgedacht, dass es so eingestellt werden könnte, dass es die realen Dinge optimiert, die die meisten Menschen benutzen, und nicht den Unsinn, der einfach aus der Luft gegriffen ist?
Nun, das Thema ist vorbei ;-). Meiner Meinung nach könnte die Optimierung in diesem Fall nur an der Stelle des Codes stattfinden, an der die Rückgabe des Wertes erfolgt, und hängt in keiner Weise davon ab, was im Konstruktor geschrieben wird.
Erst vor 2 Jahren wurden die Kopierkonstrukteure eingeführt.
Als nächstes folgen RVO (Return Value Optimization) und NRVO (Named Return Value Optimization)...
Haben Sie schon einmal darüber nachgedacht, dass man das System so schärfen könnte, dass es die wirklichen Dinge optimiert, die die meisten Menschen benutzen, und nicht den Schwachsinn, den sie aus der Luft gegriffen haben?