Fehler, Irrtümer, Fragen - Seite 2160

[Vladimir Karputov]

Andrey Khatimlianskii:

Aus der Sicht von MQ offenbar zu Recht. Wie immer entscheiden wir, was für uns bequemer ist.

Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien

Es sind keine Nachrichten im Profil vorhanden.

Renat Fatkhullin, 2018.03.08 10:31

Vorübergehend entfernt, um den Umfang der im Kompatibilitätsmodus funktionierenden Funktionen zu verringern.

Wir werden neue Funktionen hinzufügen, sobald die Migration abgeschlossen ist.

Dies ist ein neues, sehr umfangreiches und funktionsreiches System.

Es werden neue Chaträume eingeführt.

[Vladimir Pastushak]

Andrey Khatimlianskii:

Aus der Sicht von MQ offenbar zu Recht. Wie immer hat er für uns entschieden, wie wir es bequemer haben können.

Wir gehen auf die Ebene der Telepathie über... )))))

[SEM]

Unklarer Fehler im Hauptindikator. Erscheint nur auf Zeitskalen unterhalb von H1 und nur beim Start des Terminals. Text von Fehler "S-v5 (EURUSD,M10) array out of range in 'S-v5.mq5' (211,54)" . Die Zeichnung ist korrekt, aber in umgekehrter Reihenfolge, obwohl das Zeitreihenkennzeichen für alle Puffer gesetzt ist.

Die Zusammensetzung der Vorlage - der Hauptindikator (#1) (wo der Fehler auftritt), zusätzlicher Indikator (#2) (Kombination von mehreren Griffen des Hauptindikators mit verschiedenen Parametern (Zeitrahmen), Indikator (#3), der Pfeile im Hauptdiagramm auf die Signale von Indikator #1 anzeigt), Indikator (#4), der Pfeile im Hauptdiagramm auf die Signale von Indikator #2 anzeigt.

Wechsel des Zeitrahmens, erneute Anwendung der Vorlage, wenn Sie 2 beliebige Indikatoren von 2 bis 4 oder nur bei Nummer 1 entfernen, die Ausgabe eines neuen Symbols aus der Marktübersicht und Anwendung dieser Vorlage - der Fehler wird nicht reproduziert und die Darstellung aller Indikatoren ist korrekt.

[A100]

Kompilierungsfehler

#import "Test1.ex5"
       void f1();
#import "Test2.dll"
       void f2();
#import
typedef void (*fn)();
void OnStart()
{
    fn fn1 =        f1; //нормально
    fn fn2 =        f2; //Error: 'f2' - pointer to this function type is not supported yet
    fn fn3 = Test2::f2; //нормально
}

[A100]

Die Fehlermeldung erlaubt es nicht, die Ursache in dem umfangreichen Code zu verstehen

struct A {
    void f( int    ) {}
    void g( int fn ) { f( fn ); } //Error: ')' - unexpected token ???
};
typedef void (*fn)();

unten ist klar

struct A {
    void f( int    ) {}
    void g( int fn ) { f( fn ); } //Error: 'fn' - identifier already used
};
struct fn {};

[A100]

Keine Fehlermeldung

typedef void (*fn)();
void f( int i ) { Print( __FUNCTION__, ":", i ); }
void OnStart()
{
    f( fn() );
}

Außerdem läuft sie und es gibt sogar ein Ergebnis (!)

In dieser Variante:

typedef int (*fn)();
void OnStart() { Print( fn() ); }

kein Sprung in die Fehlerzeile (mit Enter)

[A100]

Kompilierungsfehler

    void g(  int ) {}
    void g( uint ) {}
#import "Test.ex5"
    void f(  int );
    void f( uint );
#import
typedef void (*fn1)(  int );
typedef void (*fn2)( uint );
void OnStart()
{
    fn1 g1 = g; /*нормально и результат*/ g1( 1 ); //совпадает с ожидаемым
    fn2 g2 = g; /*нормально и результат*/ g2( 1 ); //совпадает с ожидаемым
    fn1 f1 = f; //Error: 'f' - cannot resolve function address
    fn2 f2 = f; /*нормально и результат*/ f2( 1 ); //совпадает с ожидаемым
                                                   //при наличии Test.ex5
}

[Nikolai Semko]

Bei dem Versuch, die Erstellung dieses Beispiels zu beschleunigen, bin ich zufällig auf eine Merkwürdigkeit gestoßen, die ich einfach beiseite gelegt habe.

Und als ich nun versuchte, mit dieser Merkwürdigkeit umzugehen, wurde ich noch verwirrter.

Bei der Berechnung verwende ich also die Quadratwurzelfunktion sqrt(), die ich durch die Erstellung eines Double-Arrays umgehen möchte.

Da ich immer die Quadratwurzel aus ganzen Zahlen ziehe, sieht die Erstellung eines Arrays wie folgt aus:

   double SQRT[];
   int ss=Width*Width+Height*Height;
   ArrayResize(SQRT,ss);
   for(double w=0;w<ss;w++) SQRT[(int)w]=sqrt(w);

Es ist logisch anzunehmen, dass das Lesen aus dem Array SQRT[x] schneller ist als die Verwendung der Funktion sqrt(x).
Und dies wird durch den Prüfcode bestätigt:

   double Sum1=0,Sum2=0;
   ulong t=GetMicrosecondCount();
   for(int i=0;i<ss;i++) Sum1+=sqrt(double(i));   // Находим сумму квадратных корней всех целых чисел от 0 до ss
   t=GetMicrosecondCount()-t;
   Print("Время на сумму "+IntegerToString(ss)+" значений функций = "+IntegerToString(t)+" мкс, Сумма = "+DoubleToString(Sum1));
   t=GetMicrosecondCount();
   for(int i=0;i<ss;i++) Sum2+=SQRT[(int)(i)];    // Находим сумму квадратных корней всех целых чисел от 0 до ss через сложение элементов массива SQRT[]
   t=GetMicrosecondCount()-t;
   Print("Время на сумму "+IntegerToString(ss)+" значений массива = "+IntegerToString(t)+" мкс, Сумма = "+DoubleToString(Sum2));

Das Ergebnis zeigt einen Geschwindigkeitsgewinn um das 1,5-fache:

Aber wenn ich die Funktion sqrt() im Code durch das Lesen der Array-Elemente SQRT[] ersetze, erhalte ich statt einer Beschleunigung schreckliche Verzögerungen.

Das Lesen eines Elements aus dem Array SQRT[] dauert um ein Vielfaches, vielleicht sogar um eine Größenordnung länger als die Ausführung von sqrt().

Und ich verstehe nicht, wo der Geschwindigkeitsverlust auftritt. Der obige Prüfcode sagt Ihnen etwas anderes.

Wir können annehmen, dass der Compiler auf ein großes Array auf eine seltsame Art und Weise zugreift und es bei jeder Schleifenumdrehung zu "vergessen" scheint und jedes Mal seine eigene Dienstindexierung durchführt.

Aber das ist entweder ein logischer oder ein strategischer Compilerfehler. Und Sie sollten natürlich etwas dagegen tun, denn dieses Geschwindigkeitsleck ist sehr bedeutend und schwer zu entdecken, weil es nicht so offensichtlich ist.

Ich füge den Skriptcode bei, um diese Merkwürdigkeit zu demonstrieren.

In der Standardausführung (arr=false) wird sqrt() berechnet, aber wenn Sie arr auf true ändern, wird der Quadratwurzelwert aus dem Array genommen.

WAS IST SCHLECHT? WARUM IST ES SO LANGSAM?

[Renat Fatkhullin]

Nikolai Semko:

In dem Versuch, die Dinge zu beschleunigen, bin ich bei der Erstellung dieses Beispiels zufällig auf eine Merkwürdigkeit gestoßen, die ich einfach beiseite gelegt habe.

Es ist logisch anzunehmen, dass das Lesen aus dem Array SQRT[x] schneller ist als die Berechnung von sqrt(x).

Bei einer dynamischen Anordnung ist das nicht der Fall.

Außerdem befindet sich die Übernahme der Wurzel bereits in der Befehlsebene des SQRTSD-Prozessors. Das heißt, Sie können eine Prozessorimplementierung mit bekannten Zugriffskosten in einem dynamischen Array nicht schlagen.

Und dies wird durch den Verifizierungscode bestätigt:

Das Ergebnis zeigt einen Geschwindigkeitsgewinn um das 1,5-fache:

Ich bezweifle, dass dies bestätigt ist.

Der Code dieser Art ist wie aus einem Lehrbuch für Schleifenoptimierung. Der Code-Optimierer könnte daraus ein Bonbon machen, weil es ein sehr einfacher Fall ist:

   for(int i=0;i<ss;i++) 
      Sum2+=SQRT[i];

Das heißt, die Leistungsmessung bei der Anwendung der absichtlich perfekt optimierten Fälle muss in einem klaren Zusammenhang mit den Zielen des Tests stehen.

Der Test ist in diesem Fall falsch.

Es dauert ein Vielfaches, vielleicht sogar eine Größenordnung länger, ein Element aus dem Arraya SQRT[] zu lesen, als die Funktion sqrt() auszuführen.

Und ich verstehe nicht, wo die Geschwindigkeitsverluste auftreten. Immerhin sagt der obige Testcode etwas anderes.

Ohne den endgültigen Assembler-Code gesehen zu haben, neige ich dazu:

1. sqrt ist tatsächlich schnell (wir haben einen sehr effizienten Generator für nativen Code, sqrt wird zu reinem SQRTSD)
2. der Prüfcode zu einfach ist und Verzögerungen durch Optimierung ausgleicht

Lassen Sie uns den gesamten Code sorgfältig prüfen. Es ist interessant herauszufinden, was der wahre Grund dafür ist.

[Nikolai Semko]

Renat Fatkhullin:

Aus einer dynamischen Anordnung, nicht aus einer Tatsache.

Ohne den endgültigen Assembler-Code gesehen zu haben, neige ich dazu:

1. sqrt ist tatsächlich schnell (wir haben einen sehr effizienten Generator im nativen Code, sqrt wird zu reinem SQRTSD)
2. Checker-Code zu einfach ist und Verzögerungen durch Optimierung ausgleicht

Ich habe es mit einem statischen Array versucht - dasselbe Ergebnis.

So schnell wie sqrt ist, fällt es mir schwer zu glauben, dass diese Funktion 10-mal schneller sein kann als das einfache Lesen eines Array-Elements.

Außerdem, wenn in meinem Beispiel die Leinwandgröße reduziert wird, sagen wir 50x50 (dafür gibt es einen Eingabeparameter Größe, Sie müssen 50 statt 0 einstellen),

und die Anordnung viel kleiner ist (5000 Elemente), ändert sich das Geschwindigkeitsbild dramatisch. Es gibt keinen so starken Kontrast mehr.

Aber ich verstehe nicht: Beeinflusst die Größe des Arrays die Geschwindigkeit des Zugriffs auf seine Elemente?

Vielleicht haben Sie Recht, was die Einfachheit des Prüfcodes betrifft.

Ich habe versucht, es ein bisschen komplizierter zu machen, und das Ergebnis ist ganz anders:

for(int i=0;i<ss;i++) Sum1+=i*sqrt(double(i));
....
for(int i=0;i<ss;i++) Sum2+=i* SQRT[(int)(i)];