Speicherübertragungsaufwand zu und von einem Intel MIC

Question

Ich beobachte ein seltsames Verhalten und würde gerne wissen, ob es mit Intel Xeon Phi zusammenhängt oder nicht.

Ich habe einen kleinen Beispielcode, im Grunde die Matrixmultiplikation, die jeder kennt (drei verschachtelte for-Schleifen).Ich verlagere die Berechnung auf einen Intel MIC mit OpenMP 4.0 target Pragma und ordne die drei Matrizen mit zu map(to:A,B) map(tofrom:C).

Was ich nun beobachte, ist, dass für kleine Matrizen, z.Bei 1024x1024 dauerte die Speicherübertragung extrem lange.Im Vergleich zur nativen Version (gleicher Code, gleiche Parallelisierungsstrategie, nur kein Offloading) benötigt die Offload-Version etwa 320 ms mehr Zeit.Ich habe einen Aufwärmlauf des Codes durchgeführt, um den Initialisierungsaufwand zu beseitigen.

Im Vergleich zu einem Nvidia Tesla K20, bei dem die gleiche Menge Speicher unbemerkt kopiert wird, sind diese 320 ms sehr schlecht.

Gibt es einige Umgebungseinstellungen, die die Speicherübertragungsgeschwindigkeit verbessern können?

Eine zusätzliche Frage:Ich habe die Offload-Berichterstellung über die Umgebungsvariable OFFLOAD_REPORT aktiviert.Was sind die Unterschiede zwischen den beiden im Bericht gezeigten Timing-Ergebnissen:

[Offload] [HOST]  [Tag 5] [CPU Time]        26.995279(seconds)
[Offload] [MIC 0] [Tag 5] [CPU->MIC Data]   3221225480 (bytes)
[Offload] [MIC 0] [Tag 5] [MIC Time]        16.859548(seconds)
[Offload] [MIC 0] [Tag 5] [MIC->CPU Data]   1073741824 (bytes)

Welche 10 Sekunden fehlen zur MIC-Zeit (Speicherübertragung?)

Nun, eine dritte Frage.Ist es möglich, fixierten Speicher mit Intel MICs zu verwenden?Wenn ja, wie?

Answer 1

Möglicherweise nimmt die Speicherzuweisung auf MIC Zeit in Anspruch.Versuchen Sie, die drei Overhead-Quellen zu trennen, um besser zu verstehen, wo die Zeit vergeht:

// Device initialization
#pragma offload_transfer target(mic)
...
// Memory allocation and first data transfer
// This is expected to have overhead proportional to the amount of memory allocated
// Doing at least one transfer will speed up subsequent transfers
#pragma offload_transfer target(mic) in(p[0:SIZE] : alloc_if(1) free_if(0))

...
// This transfer should be faster
// For large sizes, approaching 6 GiB/s
#pragma offload_transfer target(mic) in(p[0:SIZE] : alloc_if(0) free_if(0))

Answer 2

Da Sie sagten: „Ich habe einen Aufwärmlauf des Codes durchgeführt, um den Initialisierungsaufwand zu beseitigen“, gehe ich davon aus, dass Sie die Offload-Laufzeit durch das Offloaden eines Dummy-Abschnitts gestartet haben.Ich erinnere mich, dass es eine Anpassung gibt, um es „on_offload“ (Standard) oder zum Zeitpunkt der Programminitialisierung (OFFLOAD_INIT=on_start) zu starten.Allerdings gibt es auch einen Fast-Path in der DMA-Engine.Der schnelle Weg wird gewählt, wenn die (zu übertragenden) Puffer an die Seitengröße angepasst sind.Für eine Offload-Anwendung können Sie einfach eine Umgebungsvariable zusammen mit einem Schwellenwert ganzzahlig B|K|M|G|T festlegen, wobei M für Megabyte steht (z. B. MIC_USE_2MB_BUFFERS=2M).Dieser Schwellenwert definiert die Größe des Puffers, der benötigt wird, bevor große Seiten verwendet werden.Sie erhalten also zwei Dinge:Riesige Seiten und schnellere Übertragungen!Diese Funktion ist auch dann noch von Bedeutung, wenn transparente riesige Seiten (THP) auf dem Coprozessor eingeführt werden.

Nachdem Sie einfach OFFLOAD_INIT=on_start und MIC_USE_2MB_BUFFERS=0 ausprobiert haben, möchten Sie möglicherweise die Puffer auf dem ausrichten Gastgeber Seite entsprechend (max.von.Vektorbreite und Seitengröße ;-).Denken Sie daran, dass ohne zusätzliche Offload-Klauseln (LEO;(bei OpenMP 4.0 bin ich mir aber nicht sicher) ist die Ausrichtung des Host-Puffers einfach vererbt durch einen Offload-Bereich.Die Ausrichtung auf 2 MB sollte alles abdecken (Sie können Ihre Zuweisung jedoch viel intelligenter gestalten, um die Verschwendung von Ressourcen für kleine Puffer zu vermeiden).Damit sollten Sie über genügend Schlüsselwörter verfügen, um bei Bedarf weitere Hintergrundinformationen zu finden.