Schätzung der Zyklen pro Anweisung

Question

Ich habe ein kleines C++ - Programm, das mit MSVC v140 kompiliert wurde, zerlegt und versuche die Zyklen pro Anweisung zu schätzen, um besser zu verstehen, wie Code-Design die Leistung beeinflusst. Ich habe Mike Actons CppCon 2014 Talk auf "Data-Oriented Design and C++" verfolgt, speziell den Teil, den ich verlinkt habe.

Darin weist er diese Zeilen aus:

movss 8(%rbx), %xmm1 
movss 12(%rbx), %xmm0 

Er behauptet dann, dass diese 2 x 32-Bit liest sind wahrscheinlich auf der gleichen Cache-Zeile kostet damit in etwa ~ 200 Zyklen.

Die Intel 64 and IA-32 Architectures Optimization Reference Manual war eine große Ressource, insbesondere "Anhang C - Befehlswartezeit und Durchsatz". Allerdings auf Seite C-15 in "Tabelle C-16. Streaming SIMD Extension Gleitkomma-Anweisungen mit einfacher Genauigkeit" es besagt, dass Movss ist nur 1 Zyklus (es sei denn, ich verstehe, was Latenz bedeutet hier falsch ... Wenn ja, wie lese ich dieses Ding?)

Ich weiß, dass ein theoretical prediction of execution time nie richtig sein wird, aber dennoch ist dies wichtig zu lernen. Wie lauten diese beiden Befehle 200 Zyklen, und wie kann ich lernen, über die Ausführungszeit hinauszugehen, die über dieses Snippet hinausgeht?

Ich habe begonnen, einige Dinge über CPU-Pipelining zu lesen ... vielleicht wird die Mehrheit der Zyklen dort abgeholt?

PS: Ich bin nicht daran interessiert, Hardware Leistungsindikatoren hier zu messen. Ich suche nur, wie man vernünftige Sicht ASM und Zyklen liest.

Answer 1

Wie Sie bereits erwähnt haben, liegt der theoretische Durchsatz und die Latenz eines MOVSS-Befehls bei 1 Zyklus. Sie haben sich das richtige Dokument angeschaut (Intel Optimization Manual). Agner Fog (in den Kommentaren erwähnt) hat in seiner Intruction Tables für Intel-CPUs dieselben Zahlen gemessen (AMD hat eine höhere Latenz).

Dies führt uns zum ersten Problem: Welche spezifische Mikroarchitektur untersuchen Sie? Dies kann selbst für den gleichen Anbieter einen großen Unterschied machen. Agner Fog berichtet, dass MOVSS je nach Quelle und Ziel eine 2-6cy Latenz auf dem AMD Bulldozer hat (Register vs. Speicher). Dies ist wichtig, wenn man die Leistung von Computerarchitekturen betrachtet.

Die 200cy sind höchstwahrscheinlich Cache-Misses, wie bereits in den Kommentaren erwähnt wird. Die Zahlen, die Sie aus dem Optimierungshandbuch für Speicherzugriffsanweisungen erhalten, gehen alle davon aus, dass sich die Daten im Cache der ersten Ebene (L1) befinden. Nun, wenn Sie die Daten nie durch vorherige Anweisungen berührt haben, muss die Cache-Zeile (64 Bytes mit Intel und AMD x86) aus dem Speicher in den Cache der letzten Ebene geladen werden, dort in den Cache der zweiten Ebene, dann in L1 und schließlich in das XMM-Register (innerhalb von 1 Zyklus). Übertragungen zwischen L3-L2 und L2-L1 haben einen Durchsatz (keine Latenz!) Von zwei Zyklen pro Cache-Zeile auf aktuellen Intel-Mikroarchitekturen. Und die Speicherbandbreite kann verwendet werden, um den Durchsatz zwischen L3 und Speicher zu schätzen (z. B. hat eine 2 GHz-CPU mit einer erreichbaren Speicherbandbreite von 40 GB/s einen Durchsatz von 3,2 Zyklen pro Cachezeile). Cache-Zeilen oder Speicherblöcke sind typischerweise die kleinsten Einheits-Caches, und Speicher kann arbeiten, sie unterscheiden sich zwischen Mikroarchitekturen und können sogar innerhalb der Architektur unterschiedlich sein, abhängig von dem Cache-Level (L1, L2 usw.).

Jetzt ist das alles Durchsatz und nicht Latenz, die Ihnen nicht helfen wird abzuschätzen, was Sie oben beschrieben haben. Um dies zu überprüfen, müssten Sie die Anweisungen immer wieder ausführen (für mindestens 1/10s), um zyklusgenaue Messungen zu erhalten. Indem Sie die Anweisungen ändern, können Sie entscheiden, ob Sie Latenzen messen möchten (indem Sie Abhängigkeiten zwischen Anweisungen einfügen) oder den Durchsatz (indem Sie die Anweisungen unabhängig vom Ergebnis früherer Anweisungen eingeben). Um Caches und Speicherzugriffe zu messen, müssten Sie vorhersagen, ob ein Zugriff auf einen Cache erfolgt oder nicht, dies kann unter Verwendung von layer conditions erfolgen.

Ein Tool zur Schätzung der Befehlsausführung (sowohl Latenz als auch Durchsatz) für Intel-CPUs ist die Intel Architecture Code Analyzer, die mehrere Mikroarchitekturen bis hin zu Haswell unterstützt. Die Latenzvorhersagen sind mit der Körnung des Salzes zu treffen, da es viel schwieriger ist, die Latenz als der Durchsatz zu schätzen.