AMD oder Intel sowie die Speichermarke - Seite 73
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
Warum? Ich interessiere mich auch sehr für die Geschwindigkeit der Berechnung von schwerwiegenden Dingen
Dann sind wir ja schon drei. Das ist immer noch nicht viel.
Ich habe Ihre Idee sehr gut verstanden. Aber ich glaube, wir belasten das Prüfgerät auf die falsche Weise. Was ich hingegen sagen wollte, scheinen Sie nicht verstanden zu haben. Aber im Großen und Ganzen spielt das keine Rolle. Zur Orientierung, sozusagen "vor Ort", ist auch der letzte Experte geeignet.
GUT. Das ist doch kein casus belli für anständige Ehemänner, oder? ))) Ich bin auch an der Geschwindigkeit der Code-Ausführung interessiert, da meine Indikatoren (plötzlich, haben gesehen) sind ziemlich ressourcenintensiv auch in der öffentlichen Ausführung.
Ich glaube, grasn würde es auch begrüßen, wenn er schneller zählen könnte.
Nein. Abgesehen von der Arbeit des Optimierers werden ressourcenintensive Aufgaben in MT einfach nicht wahrgenommen. Und selbst wenn sie sie haben, verwenden sie sie nicht bei ihrer täglichen Arbeit. Zumindest die meisten von ihnen. Aber das macht nichts. Ich werde auf MT5 warten. Die Geschwindigkeit des Codes ist dort mit bloßem Auge zu erkennen. Und dann ist da noch CUDA. Ich habe von der nVidia-Website Toolkits heruntergeladen und werde sie studieren. Und es ist kein Problem, den Code in dll zu übertragen.
Was CUDA betrifft, so habe ich Beispiele für Berechnungen gesehen, die um einen Faktor 10-100 beschleunigt wurden. Für einige medizinische Anwendungen. Und die CUDA-Programmierung wird bereits an Universitäten gelehrt. Aber es ist sehr mühsam. D.h. C ist eine ähnliche Sprache, aber es ist notwendig, die Aufgabe richtig aufzuteilen, die Besonderheiten der GPU und der Integer-Berechnungen zu berücksichtigen. Es stellt sich heraus, dass es sich um eine sehr einfache Programmierung handelt. Und nicht alle Aufgaben lassen sich einfach auf diese Art von Aufgaben reduzieren, um nach sechs Monaten Arbeit einen echten Gewinn zu erzielen. Obwohl z. B. Operationen mit ganzzahligen Matrizen nahezu perfekt auf CUDA übertragen werden können.
Es gibt das OpenCL-Projekt, das eine verteilte Rechenumgebung darstellt. Fast jeder ist daran beteiligt, auch AMD und nVidia. Es handelt sich um eine höhere Abstraktionsebene. Der Link enthält ein Codebeispiel, das, wie Sie sehen können, in C (dem C99-Standard) geschrieben ist.
Ich habe die Quellen studiert und werde am Nachmittag Bericht erstatten, denn es ist jetzt Schlafenszeit.
Die Ergebnisse sind mehr oder weniger eindeutig.
Ich werde versuchen, meine Erkenntnisse kurz zu beschreiben.
Bei der Optimierung des Expert Advisors verbraucht das Testgerät mehrere Dutzend MB Speicherplatz. Ich habe zum Beispiel eine fxt-Datei für ein Jahr mit Protokollen von Eröffnungen für etwa 36 MB. Dieser Verlauf ist im Speicher abgelegt und wird mehr oder weniger zufällig abgerufen. In diesem Modus bietet der Speicher nicht genügend Leistung, um den Prozessor mit der Datenmenge zu versorgen, die er im "Idealfall" verarbeiten könnte. Hier spielt der Cache eine wichtige Rolle.
Hier beginnt der interessanteste Teil.
1) Es liegt auf der Hand, dass bei Cache-Misses die Geschwindigkeit und die Latenzzeit der Speicherzugriffe eine wichtige Rolle spielen. Hier können die Prozessoren in 2 Gruppen unterteilt werden:
a) Atom und Core 2 - der Speichercontroller befindet sich im "North Bridge"-Chipsatz (NB).
b) alle anderen mit integriertem (in den Prozessor) Speichercontroller - ICP.
Die Prozessoren der Gruppe "a" können in diesem Fall deutlich gegenüber den Prozessoren der Gruppe "b" verlieren. Allerdings ist der Core i7 ICP wesentlich effizienter als AMD-Prozessoren. Dies ist einer der Gründe für den unangefochtenen Sieg des Core i7.
2) Damit ein Cache die Latenz effektiv maskieren kann, muss er so groß wie möglich sein, assoziativ (x-way in den CPU-Z-Screenshots) und eine geringe intrinsische Latenz aufweisen.
Und hier liegen die Prozessoren in Bezug auf die Geschwindigkeit in Abhängigkeit vom Cache-Volumen (bei ansonsten gleichen Bedingungen) deutlich gleichauf.
- Die langsamste CPU ist der Celeron mit 512 KB Cache (ich berücksichtige den Atom nicht - seine Architektur ist eher auf Wirtschaftlichkeit als auf Leistung ausgelegt);
- Athlons - ihre geringen Cache-Größen haben weniger Auswirkungen aufgrund von ICP;
- Celeron 900 mit 1 MB Cache;
- Core-2-Prozessoren mit 3-6 MB Cache; Modelle mit größerem Cache-Volumen liegen etwas neben der Spur;
- Phenom II, hier werden 6 MB Cache (und mit maximaler Assoziativität - so viel wie 48-way!) mit ICP kombiniert;
- und die schnellste - Core i7 - hier kombiniert es alle die fortschrittlichsten Dinge - 3-Kanal (und im Allgemeinen sehr schnell) RPC und die größte (und wieder sehr schnell) L3-Cache mit 8 MB.
Was die Frage angeht, warum die Effizienz des Phenom beim Übertakten sinkt und die des Core i7 steigt.
Bei diesen beiden Prozessoren werden der ICP und der L3-Cache separat getaktet (während der L1/L2-Cache immer mit der CPU-Frequenz läuft).
Belfords Methode der Übertaktung besteht jedoch darin, den Multiplikator der CPU zu erhöhen (er hat einen Prozessor der BE - Black Edition Serie - mit einem freien Multiplikator, normalerweise ist der Multiplikator oben begrenzt), ohne den L3-Cache zu übertakten.
Die Übertaktung des Core i7 (mit Ausnahme des XE) ist hingegen nur durch Erhöhung der Basisfrequenz (BCLK) möglich. Dadurch werden auch ICs mit L3-Cache übertaktet (beim Core ix wird dies als Uncore bezeichnet).
Die L3-Geschwindigkeit des Phenom von Belford ist also immer auf 2009,1 MHz festgelegt. Und bei YuraZ beschleunigt er von 2,13 GHz bei Nennleistung auf 3,2 GHz, wenn der Prozessor auf 4 GHz übertaktet wird. (CPU BCLK x 20, Uncore BCLK x 16). Und der Xeon, mit einer CPU-Frequenz von 3,33 GHz, läuft der Uncore mit 2,66 GHz.
Dabei läuft der L3-Cache des Core i7 selbst bei 2,13 GHz spürbar schneller als der L3-Cache des Phenom bei 2 GHz. Und natürlich viel schneller mit 3,2 GHz, was die hervorragende Skalierbarkeit des Core i7 in diesem Test gewährleistet.
Dies ist jedoch nur eine Spekulation, da ich keine detaillierten Nachforschungen angestellt habe. Es scheint jedoch, dass die Optimierungsgeschwindigkeit stark von der Cache-Größe und -Leistung abhängt, und etwas weniger von der Prozessorfrequenz.
Ich werde versuchen, meine Erkenntnisse kurz zu beschreiben.
Bei der Optimierung des Expert Advisors verbraucht das Testgerät mehrere Dutzend MB Speicherplatz. Ich habe zum Beispiel eine fxt-Datei für ein Jahr mit Protokollen von Eröffnungen für etwa 36 MB. Dieser Verlauf ist im Speicher abgelegt und wird mehr oder weniger zufällig abgerufen. In diesem Modus bietet der Speicher nicht genug Leistung, um den Prozessor mit der Datenmenge zu versorgen, die er im "Idealfall" verarbeiten könnte. Hier spielt der Cache eine wichtige Rolle.
Hier beginnt der interessanteste Teil.
1) Es liegt auf der Hand, dass bei Cache-Misses die Geschwindigkeit und die Latenzzeit der Speicherzugriffe eine wichtige Rolle spielen. Hier können die Prozessoren in 2 Gruppen unterteilt werden:
a) Atom und Core 2 - der Speichercontroller befindet sich im "North Bridge"-Chipsatz (NB).
b) alle anderen mit integriertem (in den Prozessor) Speicher-Controller - ICP.
Die Prozessoren der Gruppe "a" können in diesem Fall deutlich gegenüber den Prozessoren der Gruppe "b" verlieren. Allerdings ist der Core i7 ICP wesentlich effizienter als AMD-Prozessoren. Dies ist einer der Gründe für den uneingeschränkten Sieg des Core i7.
2) Damit ein Cache die Latenz effektiv maskieren kann, muss er so groß wie möglich sein, assoziativ (x-way in den CPU-Z-Screenshots) und eine geringe intrinsische Latenz aufweisen.
Und hier liegen die Prozessoren in Bezug auf die Geschwindigkeit in Abhängigkeit vom Cache-Volumen (bei ansonsten gleichen Bedingungen) deutlich gleichauf.
- Die langsamste CPU ist der Celeron mit 512 KB Cache (ich berücksichtige den Atom nicht - seine Architektur ist eher auf Wirtschaftlichkeit als auf Leistung ausgelegt);
- Athlons - ihre geringen Cache-Größen haben weniger Auswirkungen aufgrund von ICP;
- Celeron 900 mit 1 MB Cache;
- Core-2-Prozessoren mit 3-6 MB Cache; Modelle mit größerem Cache-Volumen liegen etwas neben der Spur;
- Phenom II, hier werden 6 MB Cache (und mit maximaler Assoziativität - so viel wie 48-way!) mit ICP kombiniert;
- und die schnellste - Core i7 - hier kombiniert alle die meisten progressiven - 3-Kanal (und in der Regel sehr schnell) RPC und die größte (und wieder sehr schnell) L3-Cache von 8 MB.
Was die Frage angeht, warum die Effizienz des Phenom beim Übertakten sinkt und die des Core i7 steigt.
Bei diesen beiden Prozessoren werden der ICP und der L3-Cache getrennt getaktet (während der L1/L2-Cache immer mit der CPU-Frequenz läuft).
Belfords Methode der Übertaktung besteht jedoch darin, den Multiplikator der CPU zu erhöhen (er hat einen Prozessor der BE - Black Edition Serie - mit einem freien Multiplikator, normalerweise ist der Multiplikator oben begrenzt), ohne den L3-Cache zu übertakten.
Die Übertaktung des Core i7 (mit Ausnahme des XE) ist hingegen nur durch Erhöhung der Basisfrequenz (BCLK) möglich. Dadurch werden auch ICs mit L3-Cache übertaktet (beim Core ix wird dies als Uncore bezeichnet).
Die L3-Geschwindigkeit des Phenom ist also immer auf 2009,1 MHz festgelegt. Und bei YuraZ beschleunigt er von 2,13 GHz bei Nennleistung auf 3,2 GHz, wenn der Prozessor auf 4 GHz übertaktet wird. (CPU BCLK x 20, Uncore BCLK x 16). Und der Xeon, mit einer CPU-Frequenz von 3,33 GHz, läuft der Uncore mit 2,66 GHz.
Dabei läuft der L3-Cache des Core i7 selbst bei 2,13 GHz spürbar schneller als der L3-Cache des Phenom bei 2 GHz. Und natürlich viel schneller mit 3,2 GHz, was die hervorragende Skalierbarkeit des Core i7 in diesem Test gewährleistet.
Dies ist jedoch nur eine Spekulation, da ich keine detaillierten Nachforschungen angestellt habe. Es scheint jedoch, dass die Optimierungsgeschwindigkeit stark von der Cache-Größe und -Leistung abhängt, und etwas weniger von der Prozessorfrequenz.
Ich danke Ihnen. Ich denke, das ist sehr überzeugend. Ich stimme zu.
Eine kleine Klarstellung. Wäre es richtig anzunehmen, dass die Geschwindigkeit der Optimierung mehr von der Cache-Größe und der Leistung als von der CPU-Frequenz abhängt ?
Eine kleine Klarstellung. Ist es richtig anzunehmen, dass die Optimierungsgeschwindigkeit mehr von der Cache-Größe und -Leistung als von der Prozessorfrequenz abhängt ?
Es stellt sich heraus, dass dies der Fall ist. Aber im Moment ist es noch eine Vermutung, und das habe ich in meinem Beitrag betont!