AMD oder Intel sowie die Speichermarke - Seite 62

 

Neue Antworten und neue Fragen - Sie sind immer noch schneller, als Sie sein sollten. Und der Grund ist ebenso offensichtlich - die Transaktionen sind immer noch geringer als meine (43012 bei den gleichen Einstellungen)... Allerdings ist der Unterschied nicht mehr so groß - etwa 10 %.

Aber was man sonst damit machen soll - das weiß ich noch nicht.

Ich habe Änderungen an der Tabelle vorgenommen.

Mathematik, führen Sie einen Test mit Parametern wie in Peters Beitrag - wie viele Geschäfte werden sein?

 
GUT. Berechnen Sie das Verhältnis von Geschäften / Zeit. Das wäre ein Indiz. Natürlich sollte der Zähler die Summe aller Gewerke sein, aber das ist in Ordnung.
 

Peter, ist das Ihre maximale Anzahl von Geschäften? Ich meine die Sortierung der Ergebnisse nach der Anzahl der Gewerke?

 
Mathemat >> :

Peter, ist das Ihre maximale Anzahl von Geschäften? Ich meine die Sortierung der Ergebnisse nach der Anzahl der Gewerke?


Nein. Dies ist nur die erste Iteration der Optimierung. Interessieren Sie sich für Extremwerte nach Zahlen? Dann muss ich den Test erneut durchführen - ich habe das Terminal bereits verlassen. Aber ich kann - der Computer ist noch nicht besetzt. Brauche ich das so?

 

510 -12767.51 8719 0 .72 -1.46 13779.51 1.38% MovingPeriod=55 MovingShift=10 Lots=0.1 MaximumRisk=0.02 DecreaseFactor=3
1 -56968.97 39923 0 .61 -1.43 57046.37 5.70% MovingPeriod=5 MovingShift=1 Lots=0.1 MaximumRisk=0.02 DecreaseFactor=3
Nun, das war, seltsamerweise, die erste und letzte Iteration.

Was kann ich sonst noch tun? Ich kann die Exportdatei der Historie (22 m Archiv - 150 unkomprimiert) posten und Sie können Ihren Test durchführen, indem Sie sie importieren. Mein Spread zum Zeitpunkt der Optimierung (ich war offline unterwegs) lag bei 17 Pips im fünfstelligen Bereich von Alpari. Sie können es auch selbst einrichten - ich habe Ihnen den Link zu der Software gegeben.

 

Mein Test ist derselbe: 9:05 Uhr.

1 -56631.66 41959 0.62 -1.35 56711.86 5.67% MovingPeriod=5 MovingShift=1 Lots=0.1 MaximumRisk=0.02 DecreaseFactor=3
Es scheint, Peter, dass du nach der Anzahl der Geschäfte sortiert hast, denn meine externen Parameter sind die gleichen wie deine (blau markiert). Nun, wir haben 5% weniger, aber das stellt mich nicht zufrieden...

BARS rät hier, eine externe Grafikkarte einzusetzen (die integrierte Karte verbraucht Speicher). Ich werde das überprüfen können.

Und ich glaube, es gibt noch einen weiteren Faktor - die Synchronisierung des FSB von Stein und Speicher. Die maximale Leistung wird erreicht, wenn beide gleich sind, aber dazu müsste ich den Stein eineinhalb Mal übertakten, also auf etwa 3,8 GHz. Der Stein kann das aushalten, er ist fähig, aber mein Board ist nicht das richtige, nicht für Übertaktung...

Und die Speicher-Timings sind nicht allzu kritisch, ich glaube, ich habe irgendwo auf ixbt gelesen.

P.S. Ich habe auch Alpari, aber ich habe die Daten vom metaquot Server heruntergeladen.

 

Ich habe insgesamt 6.710.383 Trades und dementsprechend einen Pass-Durchschnitt von 13157,61

 
Mathemat писал(а) >>

BARS riet mir, eine externe Grafikkarte einzubauen (die integrierte Karte frisst Speicher). Ich werde das überprüfen können.

Und ich glaube, es gibt noch einen weiteren Faktor - die Synchronisierung von FSB des Steins und des Speichers. Die maximale Leistung wird erreicht, wenn beide gleich sind, aber dazu müsste ich den Stein eineinhalb Mal übertakten, also auf etwa 3,8 GHz. Der Stein kann das aushalten, er ist fähig, aber mein Board ist nicht das richtige, nicht für Übertaktung...

Ich habe irgendwo auf ixbt gelesen, dass die Speicher-Timings nicht allzu kritisch sind.

Bei einer solchen Speichergeschwindigkeit und 2 verfügbaren Kanälen kann das integrierte Video vernachlässigt werden - es wird nur in 3D stark verlangsamt. Auf dem Desktop liegt sie innerhalb der Fehlermarge der Messung.

Für den synchronen Betrieb von FSB-Prozessor und Speicher ist es möglich, den Multiplikationsfaktor zu verringern. 7*400 sind zum Beispiel nur 2,8 GHz.

Die Sensibilität für Zeitangaben hängt in erster Linie von der jeweiligen Aufgabe ab. Einige Anwendungen werden die Zeitverschiebung überhaupt nicht bemerken, während andere recht deutlich darauf reagieren werden.

 

GUT.

Da wir bei den Geschwindigkeitstests der Tester Realismus anstreben und uns nicht mit nutzlosen und irrelevanten Nicht-Handelsexperten sowie nutzlosen kugelförmigen Pferden herumschlagen wollen, sollten wir abschätzen, wie viel Zeit wofür aufgewendet wird.

1. Der Overhead für die Terminaloperation und den darin enthaltenen Optimierer. t1

2. Zeitpunkt des Schreibens des Protokolls in die Datei. t2

3. Expert Advisor Ausführungszeit, voller 1 Zyklus auf dem Balken void start(). t3

Gesamtdauer:

T=k*Balken*(t1+t2+t3)

k-Anzahl der Durchläufe im Optimierer, gleich für alle

Balken - Anzahl der Balken in der Geschichte, der Unterschied zwischen den Testteilnehmern beträgt nicht mehr als 1% (denke ich), es kann mit einer guten Genauigkeit angenommen werden, const

t1 - hängt nicht von externen Faktoren ab (Wetter, Wirtschaftskrise usw.), sondern nur von der zu prüfenden Hardware.

t2 hängt vom Eisen ab.

t3 - hängt von vielen Faktoren ab, die nicht direkt mit dem Eisen zusammenhängen und die Genauigkeit der Ergebnisse aufgrund des Inhalts im Code der Handelsfunktionen beeinflussen.

Welche der drei Komponenten können wir beeinflussen, um gleiche Bedingungen für alle Testteilnehmer zu schaffen?

Nun, wahrscheinlich t3.

Die Anzahl der Gewerke ist schwer zu bewältigen. Wir können jedoch einen Block "sehr nützlicher" Berechnungen in den Code des Expert Advisors einfügen, um den Einfluss negativer Faktoren auf ein Minimum zu reduzieren. So würde der Block der "sehr nützlichen" Berechnungen 95-99 % der Gesamtzeit in Anspruch nehmen. Das ist alles. Die Aufgabe ist gelöst. Wir werden eine ausreichend hohe Genauigkeit für unsere Experimente erreichen.


zy. Über das kugelförmige Pferd alias Script. Ich habe eine Menge Aufgaben, die nichts mit der Optimierung von Expert Advisors im Optimierer zu tun haben. Es handelt sich sowohl um ressourcenintensive Indikatoren als auch um komplexe mathematische Berechnungen in Skripten. Mein Indikator verwendet zum Beispiel ns mit 400-600-200 Neuronen. Insgesamt werden 360800 Gewichte verwendet. Ich verwende ein separates Skript, um dieses Schwergewicht zu trainieren. Der Indikator liest fertige Gewichte aus der Datei. Es ist klar, dass wir, wenn wir das Training im Indikator selbst implementieren, Probleme mit der Chartdarstellung haben werden. Sie können weitere Beispiele nennen.

 

Autsch, genau das wollte ich übrigens auch. Ich habe 6.577.074 Transaktionen, etwas weniger als Sie, Docent.

P.S. Ich habe es gerade noch einmal überprüft. Meine Zeit war 8:18 (498 Sekunden!!!), obwohl ich absolut nichts gemacht habe. Aber das Problem (ich hatte mich zuvor etwa eine Minute lang über die Optimierung "gewundert") war verschwunden.

Ich habe beide benötigten Dateien gelöscht (aus dem Cache und dem Verlauf). Ich verstehe gar nichts. Ich werde versuchen, wieder eine Grafikkarte einzubauen.

Grund der Beschwerde: