Alternative Implementierungen von Standardfunktionen/-ansätzen - Seite 11
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
Können Sie mir bitte den Link schicken?
Ich habe es nicht behalten. Erwähnt im Forum hier. Ich habe selbst die Suchmaschinen durchforstet.
Ich habe es nicht behalten. Erwähnt im Forum hier. Ich habe selbst die Suchmaschinen durchsucht.
Offensichtlich wurden alle diese Fahrräder viele Male überholt. Es wurden sogar Bücher veröffentlicht, bis hin zu asm-Implementierungen.
Heutzutage sind die Grundlagen schwer zu finden, da fast jeder für alle Gelegenheiten entsprechende APIs verwendet.
Sie müssen sich also nur in Foren anmelden und herumfragen.
Offensichtlich wurden alle diese Fahrräder viele Male überholt. Es wurden sogar Bücher veröffentlicht, bis hin zu asm-Implementierungen.
Nun sind die Grundlagen schwer zu finden, da fast jeder für alle Gelegenheiten entsprechende APIs verwendet.
Sie müssen sich also nur in Foren anmelden und fragen.
Warum verwenden Sie nicht LONG_MAX/MIN? Das würde irgendwie schöner aussehen. Es sieht gut aus, finde ich. Ich habe Ihre Tests mit gcc gespielt (mit min Modifikation, natürlich, Compiler ist sehr alt 5.4.0, was ich zur Hand hatte):
Nun, ja, das ist nicht schön. AberLONG_MAX= 9223372036854775807 ist mehr als 9007199254740992. Und hexadezimale Form dieser Zahl - 0x20000000000000 wird beschimpft, weil es nur für ulong Typ sein muss. Ich weiß nicht einmal, wie ich es noch deutlicher machen kann. Ich kann nicht (ulong)(1<<53) schreiben, weil das eine zeitraubende Operation ist.
Der Typ double beginnt, ganze Zahlen ohne Nachkommastellen nicht ab demLONG_MAX-Wert, sondern ab der maximal möglichen Mantisse zu enthalten. Aber 53 Bits sind für die Mantisse erlaubt, d.h. 2^53=9007199254740992.
Das Timing Ihres Codes schlägt fehl - die Ausgabe erfolgt in Millisekunden (nicht in Nanosekunden), und ich verstehe immer noch nicht, warum wir minus t0 brauchen.
t0 ist die Zeit eines vollen Zyklus von 1000000 Durchläufen der Summe der Primzahl-Doppelgänger
während t die Zeit desselben Zyklus der Summe derselben Doppelwerte ist, die jedoch durch die Funktionen ceil, ceil, round usw. geleitet werden.
Ich bin von der Logik ausgegangen, dass die Differenz (t-t0) die für diese Funktionen aufgewendete Nettozeit ist.
Eine größere Objektivität kann natürlich nur durch mehrere Messungen erreicht werden.
- Im Nanobereich rechne ich auf der Grundlage der Zeit, die benötigt wird, um eine von 1.000.000 Funktionen auszuführen. Genau in nano ist richtig.
pavlick_:
Ich lief Ihre Tests auf gcc (mit min Änderung, natürlich, Compiler ist sehr alt 5.4.0, was zur Hand war):
1. Kompilieren mit -O3.
2. Zusammenstellung mit -Ofast
Nicht (ulong)(1<<53) zu schreiben, da dies bereits eine zeitaufwändige Operation ist.
Diese Operation ist nicht zeitaufwendig, wie alle Operationen mit Konstanten, einschließlich Zeichenketten.
Diese Operation ist zeitlos wie alle Konstanten, einschließlich Zeichenketten.
Wow - cool! Danke. Und ich dachte, das zählt jedes Mal. Ja, das ist logisch, das kann man schon zur Kompilierzeit berechnen.
Nun, das war's dann:
Es wäre jedoch korrekter,DBL_MANT_DIG anstelle von 53 zu schreiben
Fall des minimalen Gewinns, wenn alle Werte von double gebrochen sind.
Das hat sich herausgestellt. Dass der kompilierte MQL5-Code schneller arbeitet als sogar Ofast? Es fällt mir schwer zu glauben, dass Sie einen 32-Bit-Compiler gehabt haben müssen.
Ich habe das Minus t0 aus allem herausgenommen (ich dachte, es sei eine Art Fehler), und meine Ausgabe hat die gesamte Schleife gemessen, nicht nur einen einzigen Durchgang. Wenn wir in Ihre Form der Ausgabe in Nanosekunden pro Iteration umrechnen (in der ersten Zeile "Zykluszeit ohne Rundung" - wir haben die gleiche Zählweise), erhalten wir:
Es gibt nicht viel Beschleunigung auf gcc (und noch langsamer auf -Ofast). Auf mcc gibt es eine signifikante Beschleunigung nach Ihrem Test zu urteilen, aber:
haben Sie 985'651 von 1'000'000, d.h. fast alle Iterationen erfüllen die Bedingung x < MIN || x > MAX.
-Ofast deaktiviert alle inf/nan-Prüfungen, errno-Einstellung, d.h. die bloße Rundung auf der fpu bleibt erhalten. Und diese bloße Rundung kann nicht durch einen einfachen Vergleich von x < MIN || x > MAX überwunden werden.
Es gibt nicht viel Beschleunigung auf gcc (und noch langsamer auf -Ofast). Auf µl ist das signifikant.
Aber es ist schwer zu sagen. Wir haben t0 für schöne Zahlen rausgeschmissen und 20-fache Differenz bekommen. Selbst minimaler zusätzlicher Code in Form einer Schleife (+t0) macht das schöne Ergebnis in mehreren Dutzend Mal zu weniger attraktiv in etwa zwei Mal. Und was kann man sagen, wenn es nicht nur eine Schleife ist, sondern ein echter Algorithmus, der etwas Nützliches tut? Der Unterschied wird überhaupt nicht sichtbar sein, er wandert irgendwo weit hinter dem Komma und wird kaum zu einem Engpass werden. In einer realen Anwendung sind Mutex-Pickup, CPU-Sperren und Speicherzuweisung viel kostspieliger als Rundungen. Alles in allem ist es das Risiko nicht wert, finde ich.
Ja, der Unterschied wird überhaupt nicht sichtbar sein, liegt irgendwo weit hinter dem Komma und wird wahrscheinlich keinen Engpass darstellen. In einer realen Anwendung sind Mutex, CPU-Barrieren und Speicherzuweisung viel kostspieliger als Rundungen. Alles in allem ist es das Risiko nicht wert, finde ich.
Das trifft in 99 % der Fälle zu, ja.
Bevor Sie optimieren, sollten Sie sich vergewissern, dass Sie etwas zum Optimieren haben.
In meiner Praxis kann ich mich nur an einen einzigen Fall erinnern, in dem meine eigene Implementierung von atof wirklich geholfen hat. Obwohl ich den Eindruck hatte, dass es so war.
Und Sie sollten bedenken, dass jede Optimierung (außer ***) nicht kostenlos ist.