Löschen eines Arrays mit definierten Element(en) - Seite 16
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
Ich denke, die Flaggen passen gut zueinander:
http://osinavi.ru/asm/4.php
und für unnötige Operatoren/Vergleiche...
Ich komme zurück zu meinem missverstandenen Unterschied in der Ausführungszeit von fast 100% identisch in Logik und Anzahl der Prüfungen und Summen von zwei Schleifen:
Ich habe bereits oben geschrieben - ich habe weniger Vergleichsoperationen in meinem Code...
-----
Von außerhalb der Schule, irgendwo in den 90er Jahren:
1) Wenn die Bedingungen A, B und C unabhängig voneinander sind, muss man sie in die UND-Funktion schieben, wenn die Wahrscheinlichkeit steigt, und in die ODER-Funktion, wenn sie sinkt.
und wenn sie voneinander abhängig sind, dürfen sie nicht in einem einzigen Ausdruck kombiniert werden (z. B. do if (A && B) ).
2) Wenn es verschachtelte Schleifen A,B gibt, sollte die äußere kürzer sein
3) Wenn sich eine Bedingung innerhalb der Schleife befindet, sollten Sie die Schleife aufteilen und die Bedingung nach Möglichkeit aus der Schleife herausnehmen.
Ich habe bereits oben geschrieben - ich habe weniger Vergleichsoperationen in meinem Code...
-----
aus außerschulischen Studien, irgendwo in den 90er Jahren:
1) Wenn die Bedingungen A, B und C unabhängig sind, sollten sie mit steigender Wahrscheinlichkeit in die UND-Funktion und mit abnehmender Wahrscheinlichkeit in die ODER-Funktion eingeordnet werden.
und wenn sie voneinander abhängig sind, können sie nicht in einem Ausdruck kombiniert werden (d.h. do if (A && B) ).
2) Wenn es verschachtelte Schleifen A,B gibt, sollte die äußere kürzer sein
3) Wenn sich eine Bedingung innerhalb der Schleife befindet, sollten Sie die Schleife aufteilen und die Bedingung nach Möglichkeit nach draußen bringen.
1) umgekehrt, was genau das ist, was Sie getan haben. Wenn die erste Bedingung in einem zusammengesetzten UND-Operator nicht ausgeführt wird, warum sollten wir dann alle anderen Bedingungen überprüfen? Wir prüfen also zunächst die Bedingung, die höchstwahrscheinlich falsch ist.
Obwohl, ja - es ist: Sortierung nach aufsteigender Wahrscheinlichkeit der Wahrheitsaussagen in einer zusammengesetzten Bedingung.
1) andersherum, was Sie getan haben. Besonderheiten der Ausführung von bedingten Operatoren in C.
Vielleicht habe ich es falsch geschrieben, aber es ist einfacher, es für alle auf einmal zu erklären...
A && B && C
UND sollte so schnell wie möglich gefüttert werden, um alle anderen Bedingungen zu vermeiden. Der Optimierer wird dies nicht für den Programmierer tun (*), da er nicht weiß, auf welchen Daten das Programm ausgeführt wird.
A || B || C
hier ist es umgekehrt :-), denn es handelt sich um Boolesche Arithmetik. !( ((!A)&&(!B)&&(!C) ) (wenn Sie die Klammern nicht verwechseln, unterschreiben Sie erneut)
(*) Optimierende Compiler können sich auf die Tatsache verlassen, dass die Bedingungen genau so gesetzt sind, und sie bauen ihre interne Küche auf diesen Annahmen auf
Vielleicht habe ich es falsch geschrieben, aber es ist für alle auf einen Blick leichter zu verstehen...
A && B && C
UND sollte so schnell wie möglich gefüttert werden, um nicht alle anderen Bedingungen zu erfüllen. Das bedeutet, dass das erste zu setzende Prädikat dasjenige ist, das die Ausführung der gesamten weiteren Kette verhindert. Der Optimierer wird dies nicht für den Programmierer tun (*), da er/sie nicht weiß, auf welchen Daten das Programm ausgeführt werden wird
A || B || C
es ist genau umgekehrt :-), denn die boolesche Arithmetik... !( ((!A)&&(!B)&&(!C) ) (wenn wieder in Klammern, werden Zeichen nicht verwechselt)
(*) Optimierende Compiler können sich auf die Tatsache verlassen, dass die Bedingungen genau so gesetzt sind, und sie bauen ihre interne Küche auf diesen Annahmen auf
Ich stimme völlig zu.
Ich komme zurück zu meinem missverstandenen Unterschied in der Ausführungszeit von fast 100% identisch in Logik und Anzahl der Prüfungen und Summen von zwei Schleifen:
Also noch einmal, warum eine solche Variante von Kuznetsovs Code:
arbeitet mehr als doppelt so schnell wie derjenige, der genau das Gleiche tut:
Was sind die Wunder des Compilers?
Ist ein solches Design wirklich möglich?
der Compiler einen speziellen Suchbefehl des Assemblers für den Prozessor findet? Aber es gibt eine zusätzliche Prüfung i<j im Inneren, nicht wahr?
Denn die gleiche Sache durch für wird viel langsamer ausgeführt:
Der Code des Demonstrationsskripts ist beigefügt
Das ist oft der Fall. Sie beschäftigen sich mit irgendwelchem unnötigen Kram und finden etwas sehr Interessantes heraus.
Entwickler, könnten Sie einen Blick auf den ausführbaren Code werfen und sehen, was den Unterschied ausmacht?
Sie müssen die Logik des Compilers verstehen, um in Zukunft optimalere Algorithmen erstellen zu können.
Was für eine merkwürdige Situation. Ich denke, vieles hängt vom Compiler und der Maschine ab, auf der ich teste. Hier ist mein Ergebnis für Ihr Beispiel auf einem 32-Bit-Rechner
Wie Sie sehen, gibt es keinen besonderen Vorteil. Und hier ist ein Test der Array-Löschfunktionen aus der letzten Variante.
Manchmal können die Ergebnisse beim Testen ganz anders ausfallen als zuvor, und es ist unklar, warum, vielleicht hat es etwas mit einem bestimmten Unterbrechungssystem in der MQL-Codeverarbeitung zu tun
Beim Testen von Algorithmen sollte man Folgendes beachten
* oder vorbereitete Datensätze (die in etwa denen entsprechen, die tatsächlich benötigt werden),
* oder eine sehr große Anzahl von Durchläufen mit dem RNG machen,
in Tests:
* die Reihenfolge der Prüfungen zu ändern/umzuordnen und
* Pausen beobachten und alle Arten von Caches zurücksetzen
Beim Testen von Algorithmen sollte man Folgendes beachten
* oder vorbereitete Datensätze (die in etwa denen entsprechen, die tatsächlich benötigt werden),
* oder eine sehr große Anzahl von Durchläufen mit dem RNG machen,
in Tests:
* abwechselnd/gemischt Testsequenzen und
* Pausen beobachten und alle Arten von Caches zurücksetzen
gut, als ob wir vorbereitete Daten verwenden. Für alle Funktionen werden die gleichen Daten für den Test verwendet. Was das Mischen/Warteschlangenbildung betrifft, so habe ich einen Unterschied festgestellt, wenn Sie die Reihenfolge der Tests ändern. Aber wie setzt man die Caches zurück?
Beim Testen von Algorithmen sollte man Folgendes beachten
* oder vorbereitete Datensätze (die in etwa denen entsprechen, die tatsächlich benötigt werden),
* oder eine sehr große Anzahl von Durchläufen mit dem RNG machen,
in Tests:
* Abwechselnde/gemischte Testsequenzen und
* Pausen beobachten und alle Arten von Caches auslagern
Mach dich nicht über andere lustig