Pracht und Armut der PLO - Seite 6
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
Er zeigte, dass direkte oder virtuelle Anrufe bei realen Projekten keine Wirkung haben.
Der größte Teil der Kosten entsteht durch den Aufruf von Systemfunktionen, wo MQL-Programme fast ihre gesamte Zeit verbringen. Die Kosten für die Vermittlung der Anrufe sind im Vergleich zur Nutzlast vernachlässigbar.
Wo hat er das gezeigt? Ist eine Tabelle mit einigen Funktionsnamen und Messwerten ein Argument? Wir sind hier keine telepathischen Experten. Sie müssen den Code der Funktionen sehen, und dann können Sie etwas sagen.
Wo hat er es gezeigt? Eine Tabelle mit einigen Funktionsnamen und Abmessungen - ist das ein Argument? Wir sind hier keine telepathischen Experten. Sie müssen den Code der Funktionen sehen, dann können wir über etwas anderes reden.
Er zeigte, dass bei realen Projekten direkte oder virtuelle Anrufe keine Auswirkungen haben.
Der größte Teil der Kosten entsteht durch Systemfunktionsaufrufe, wo MQL-Programme die meiste Zeit verbringen. Die Kosten für die Vermittlung der Anrufe sind im Vergleich zur Nutzlast vernachlässigbar.
+100 Ja, das stimmt!
Außerdem habe ich festgestellt, dass, wenn ich die ausufernden Klassen so umschreiben musste, dass einige ihrer Funktionen von anderen Klassen ausgeführt wurden (Einbindung/Zerlegung), die Gesamtleistung stieg und die Kontrolle über den Code zunahm. Mit anderen Worten, in der Praxis sehen wir das Gegenteil von dem, was uns Integer- und Old-School-C-Fans zu beweisen versuchen: die Anzahl der Klassen wächst, die Anzahl der Methoden wächst, und die Leistung nimmt im Gegenteil zu.
Wo hat er es gezeigt? Eine Tabelle mit einigen Funktionsnamen und Abmessungen - ist das ein Argument? Wir sind hier keine telepathischen Experten. Sie müssen den Code der Funktionen sehen, dann können wir über etwas anderes reden.
+100 Ja, das ist richtig!
Außerdem habe ich festgestellt, dass sich die Gesamtleistung erhöht und die Kontrolle über den Code verbessert, wenn ich ausufernde Klassen so umschreiben muss, dass einige ihrer Funktionen von anderen Klassen ausgeführt werden (Einschluss/Zerlegung). Mit anderen Worten, in der Praxis sehen wir das Gegenteil von dem, was uns Integer- und Old-School-C-Fans zu beweisen versuchen: die Anzahl der Klassen wächst, die Anzahl der Methoden wächst, und die Leistung nimmt im Gegenteil zu.
Eine neue Art der Selbstverwöhnung? Komm schon, komm schon.
Vasily, du hättest allerdings lesen sollen, was ich hier zu beweisen versuchte (und was immer du darüber denkst, es ist bewiesen).
Beachten Sie jedoch, dass Sie mit dem Quellcode noch nichts anfangen können. Die kumulative Komplexität ist nicht dieselbe. Selbst nach der Analyse der Quellen würden Sie sagen: "Nun, irgendetwas wird dort genannt, irgendetwas wird gezählt, irgendetwas wird von irgendwoher genommen, aber was genau, ist nicht klar, also ist wieder nichts bewiesen.
Im Großen und Ganzen haben Sie wahrscheinlich recht, einzelne Funktionen werden Ihnen wahrscheinlich nicht viel sagen. Was bringt es, überhaupt über Ihre Software zu sprechen, wenn sie für alle anderen die Katze im Sack ist.
Wir interessieren uns vor allem für die Gesamtzahl der Durchläufe durch virtuelle Methoden und die dafür aufgewendete Zeit. In Ihrer Tabelle ist eine schattierte Funktion 5 Millionen Mal ausgeführt worden. Ich weiß nicht, was es ist, vielleicht ist es nur eine virtuelle Methode mit der einfachsten Aktion. 5 Millionen sind allerdings eine Kleinigkeit. Ich nehme an, Sie haben keine schweren Berechnungen in Ihrem Programm, also gibt es nicht viel zu besprechen. Angenommen, Sie berechnen ein System linearer Gleichungen 30000x300000 und greifen auf Matrixelemente über virtuelle Methoden zu, dann gäbe es etwas zu besprechen.
Eine neue Art der Selbstbeeinflussung? Komm schon, komm schon.
Vasily, Sie sollten doch lesen, was ich hier zu beweisen versucht habe (und was immer Sie darüber denken, es ist bewiesen).
Dimitri, ich bin weder für Sie noch gegen Sie. Um es zu verstehen, muss man das Innenleben des Compilers inline kennen, aber diese Informationen für MQ zu öffnen ist gleichbedeutend mit der Hilfe beim Schreiben eines Decompilers.
Der Einzige, der hier (unter den Diskutierenden) über solche Informationen verfügt, ist Renat, also müssen wir uns auf sein Wort verlassen. Ich sehe keinen anderen Weg.
Wenn er sagt, dass Sie den Test nicht richtig einstellen, ist das wahrscheinlich der Fall.
Die Frage ist eine andere, nur MQ kann den Test in einem solchen Fall korrekt einstellen, das ist es, was getan werden muss.
Wie man so schön sagt: Test gegen Test, mein Wort gegen Ihres. Und Sie versuchen, das Unbeweisbare zu beweisen. Es ist unmöglich, Ihre Behauptungen zu beweisen oder zu widerlegen, ohne etwas zum Vergleich zu haben.
Der Decompiler kommt hier nicht in Frage.
Man muss nur die Techniken der optimierenden Compiler verstehen und kennen, um zu vermeiden, dass vereinfachte entartete Fälle getestet werden, die brutal optimiert werden und zu linearem Code entarten. Wir haben die vierte Generation von Compilern für nichts freigegeben.
Das ist genau das, worüber wir hier sprechen.
Wenn wir beispielsweise ein lineares Gleichungssystem von 30000x300000 berechnen und der Zugriff auf die Matrixelemente über virtuelle Methoden erfolgt, gibt es bereits etwas zu besprechen.
In solchen Fällen würde das erste Refactoring einen hundertfachen Geschwindigkeitsgewinn bringen. Und der virtuelle Anruf würde bei den Kosten an zehnter Stelle stehen.
Das heißt, das Beispiel ist unrealistisch.
Dann sollten wir alles in Assembler schreiben. Es wäre ohnehin schneller.
Ich verstehe das Problem nicht. Ich habe noch nie einen Expert Advisor oder Indikator mit 1 MB Code gesehen.
Auch der Aufruf einer Funktion nimmt einige Zeit in Anspruch. Lassen Sie uns auch Funktionen aufgeben!
Die Kontrolle über große Projekte ist mit OOP viel einfacher.
Außerdem ist die Geschwindigkeit der Code-Ausführung oft nicht so entscheidend wie die Ping-Zeit an den Makler und die Antwort auf den Auftrag des Maklers.
Sehen Sie sich die HFT-Algorithmen an. Sie erfordern maximale Geschwindigkeit, aber Sie werden dort keine komplexen Berechnungen finden.
PS. Normalerweise braucht man kein Superauto oder Schneemobil, um von A nach B zu kommen. Ein Moped reicht aus! Ein Moped ist genug!