Fehler, Irrtümer, Fragen - Seite 2506

[Francuz]

Vict:
Begründen Sie

Register werden in Bits und nicht in Bytes gemessen. Daher wird diese Zeile im restlichen Code falsch verwendet:

#define  CACHE_LINE_SIZE 64

[[Gelöscht]]

Francuz:

Register werden in Bits und nicht in Bytes gemessen. Daher wird diese Zeile im restlichen Code falsch verwendet:

Nein, Sie sagen etwas Seltsames. Ich werde es nicht beweisen. Sehen Sie sich die Dokumentation des Prozessors an, lesen Sie hier https://stackoverflow.com/questions/7281699/aligning-to-cache-line-and-knowing-the-cache-line-size/7284876

Auf x86 sind Cache-Zeilen 64 Bytes groß.

Ich brauche keine Register, ich spreche überhaupt nicht über sie.

[Francuz]

Vict:

Nein, Sie sagen etwas Seltsames. Ich werde es nicht beweisen. Sehen Sie sich die Dokumentation für den Prozessor an, lesen Sie hier https://stackoverflow.com/questions/7281699/aligning-to-cache-line-and-knowing-the-cache-line-size/7284876

Ich brauche keine Register, ich spreche überhaupt nicht über sie.

Hmm ... Okay. (räuspert sich) Auf jeden Fall ist der Cache von Modell zu Modell unterschiedlich. Es gibt keine Möglichkeit, die Größe über die Software zu ermitteln. Deshalb ist es unsinnig, sich daran zu orientieren. Aber alle Prozessoren haben zwei Arten von Registern, und es ist die Größe der Register, auf die sich erfahrene Programmierer konzentrieren. Und selbst diese Registerorientierung ist nicht immer erfolgreich, denn zwischen dem Programm und dem Prozessor stehen ein Compiler und ein Betriebssystem.

Außerdem wird diese Zeile falsch und ohne Register berechnet:

int index = int(CACHE_LINE_SIZE - getaddr(data[rndnum].ar[0]) % CACHE_LINE_SIZE) / sizeof(int);

[[Gelöscht]]

Francuz:

Hmm ... Ja. Auf jeden Fall ist der Cache von Prozessor zu Prozessor unterschiedlich. Und es gibt keine Möglichkeit, seine Größe über die Software zu ermitteln. Deshalb ist es albern, sich daran zu orientieren. Aber alle Prozessoren haben zwei Arten von Registern und es ist die Größe der Register, auf die sich erfahrene Programmierer konzentrieren. Und selbst die Ausrichtung auf die Registergröße bringt nicht immer eine Rettung, da der Compiler und das Betriebssystem zwischen dem Programm und dem Prozessor angesiedelt sind.

Auch hier entwickeln sich die Dinge weiter, es wird immer mehr Wert auf Multithreading gelegt, und hier ist eine std-übergreifende Bibliothek, die Ihnen alles darüber erzählt

https://en.cppreference.com/w/cpp/thread/hardware_destructive_interference_size

Außerdem ist diese Zeile falsch berechnet und berücksichtigt nicht die Register:

Vielleicht, aber bis jetzt haben Sie mich noch nicht überzeugt.

[Francuz]

Vict:

Und wieder nein, die Dinge entwickeln sich weiter, es wird immer mehr Wert auf Multithreading gelegt, und hier ist es - die cross std library wird Ihnen alles sagen

https://en.cppreference.com/w/cpp/thread/hardware_destructive_interference_size

Vielleicht, aber bis jetzt haben Sie mich noch nicht überzeugt.

Er wird es Ihnen nicht sagen, er wird es Ihnen sagen. Lesen Sie die Spezifikation sorgfältig durch.

Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien

Vielleicht, aber bis jetzt haben Sie mich noch nicht überzeugt.

Ich bin mir zwar nicht ganz sicher, welche Verschiebung Sie wollten, aber es ist leicht zu verstehen: Eine absolute Adresse ist für Berechnungen völlig unbrauchbar. Haben Sie vergessen, dass der Bezugspunkt für den Speicher die Adresse der Struktur ist? Und Sie wollten wahrscheinlich den Offset eines Arrays in einem Block des Strukturspeichers ermitteln? Und das ist es, was die Differenz zwischen den Adressen der Struktur und dem Nullelement des Arrays ergibt.

[Eugeni Neumoin]

Artyom Trishkin:

Befindet sich auf dem Balken kein Wert im Puffer, sollte er explizit in den Puffer geschrieben werden. D.h., wenn der berechnete Wert in den Puffer ausgegeben werden soll - schreiben wir ihn in den Puffer, andernfalls - schreiben wir einen leeren Wert.

Vielen Dank, Artem.

[[Gelöscht]]

Francuz:

Ich bin mir zwar nicht ganz sicher, welchen Offset Sie wollten, aber der Fehler ist leicht zu verstehen: Eine absolute Adresse ist für Berechnungen völlig nutzlos. Haben Sie vergessen, dass der Bezugspunkt für den Speicher die Strukturadresse ist? Und Sie wollten wahrscheinlich den Offset eines Arrays in einem Block des Strukturspeichers ermitteln? Und das ist der Unterschied zwischen den Adressen der Struktur und dem Nullelement des Arrays.

int index = int(CACHE_LINE_SIZE - getaddr(data[rndnum].ar[0]) % CACHE_LINE_SIZE) / sizeof(int);
                                3        1                    2                  4

Ordnungsgemäße Maßnahmen:

1 - liefert die Adresse des ersten ar[]-Elements in der aktuellen Datenstruktur.

2. seine Offsets vom Anfang der Cache-Zeile herausfinden

3. herausfinden, wie viele Bytes es bis zum Ende der Cache-Zeile sind

4. Ermitteln Sie, wie viele Bytes in diesen Raum bis zum Ende der Cache-Zeile passen.

Haben Sie es auf Ihrem Computer ausgeführt? Gibt es einen Unterschied in der Geschwindigkeit? Oder bin das nur ich?

[Francuz]

Vict:

2. seine Offsets vom Anfang der Cache-Zeile herausfinden

Wie kommen Sie darauf, dass man auf diese Weise seinen Versatz herausfinden kann?

[fxsaber]

Was ist die Ursache für diese Verlangsamung?

Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien

Wanzen, Wanzen, Fragen

fxsaber, 2019.07.09 11:13

   Data data[];
   
   ArrayResize(data, 32768);

Es findet eine 6-fache Verlangsamung statt!

[TheXpert]

fxsaber:
Wozu sind diese Bremsen da?

Ein dynamisches Array hat mehr Prüfungen, Renat schrieb einmal, ich kann den Beitrag nicht finden, nur über den Index-Zugriff zu sprechen, warum es deutlich langsamer als Pluspunkte ist