نقل الذاكرة من وإلى Intel MIC

Question

ألاحظ سلوكًا غريبًا وأرغب في معرفة ما إذا كان مرتبطًا بمعالج Intel Xeon Phi أم لا.

لدي مثال صغير على التعليمات البرمجية بشكل أساسي ضرب المصفوفة التي يعرفها الجميع (ثلاث حلقات متداخلة).أقوم بإلغاء تحميل الحساب إلى Intel MIC مع OpenMP 4.0 target براغما وخريطة المصفوفات الثلاث مع map(to:A,B) map(tofrom:C).

الآن، ما ألاحظه هو أنه بالنسبة للمصفوفات الصغيرة على سبيل المثال.1024x1024 استغرق نقل الذاكرة وقتًا طويلاً للغاية.بالمقارنة مع الإصدار الأصلي (نفس الكود، نفس استراتيجية الموازاة، فقط بدون تفريغ)، يستهلك إصدار التفريغ حوالي 320 مللي ثانية من الوقت.لقد قمت بإجراء عملية إحماء للكود لإزالة حمل التهيئة.

بالمقارنة مع Nvidia Tesla K20 حيث يتم نسخ نفس مقدار الذاكرة دون ملاحظة أن 320 مللي ثانية سيئة للغاية.

هل هناك بعض إعدادات البيئة التي قد تعمل على تحسين سرعة نقل الذاكرة؟

سؤال إضافي:لقد قمت بتمكين الإبلاغ عن التفريغ عبر متغير البيئة OFFLOAD_REPORT.ما هي الاختلافات بين نتيجتي التوقيت الموضحتين في التقرير:

[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)

ما هي تلك الثواني العشر المفقودة في MIC Time (نقل الذاكرة؟)

حسنا السؤال الثالث.هل من الممكن استخدام الذاكرة المثبتة مع ميكروفونات Intel؟إذا كانت الإجابة بنعم، كيف؟

Answer 1

ربما يكون تخصيص الذاكرة على MIC هو الذي يستغرق وقتًا.حاول فصل المصادر الثلاثة للنفقات العامة لفهم أين يذهب الوقت بشكل أفضل:

// 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

نظرًا لأنك قلت "لقد قمت بإجراء عملية إحماء للكود لإزالة حمل التهيئة"، أفترض أنك بدأت وقت تشغيل إلغاء التحميل عن طريق إلغاء تحميل قسم وهمي.أتذكر أن هناك تعديلًا لبدء تشغيله "on_offload" (افتراضي) أو في وقت تهيئة البرنامج (OFFLOAD_INIT=on_start).على أية حال، هناك أيضًا مسار سريع في محرك DMA.يتم اتخاذ المسار السريع عندما تتم محاذاة المخازن المؤقتة (المراد نقلها) مع حجم الصفحة.بالنسبة لتطبيق إلغاء التحميل، يمكنك ببساطة تعيين متغير بيئة مع عدد صحيح للحد B|K|M|G|T حيث M هو ميجابايت (على سبيل المثال، MIC_USE_2MB_BUFFERS=2M).تحدد هذه العتبة حجم المخزن المؤقت المطلوب قبل استخدام الصفحات الضخمة.إذن تحصل على شيئين:صفحات ضخمة وعمليات نقل أسرع!لا تزال هذه الميزة ذات معنى حتى مع تقديم الصفحات الضخمة الشفافة (THP) على المعالج المساعد.

بعد تجربة OFFLOAD_INIT=on_start وMIC_USE_2MB_BUFFERS=0، قد ترغب في محاذاة المخازن المؤقتة على يستضيف الجانب وفقًا لذلك (الحد الأقصى.ل.عرض المتجه وحجم الصفحة ؛-).تذكر، بدون شروط إلغاء التحميل الإضافية (LEO؛ولكن لست متأكدًا من OpenMP 4.0) فإن محاذاة المخزن المؤقت للمضيف هي ببساطة وارث بواسطة قسم التفريغ.يجب أن تغطي المحاذاة إلى 2 ميجابايت كل شيء (ولكن يمكنك جعل تخصيصك أكثر ذكاءً لتجنب إهدار الموارد في المخازن المؤقتة الصغيرة).وبهذا يجب أن يكون لديك ما يكفي من الكلمات الرئيسية للعثور على المزيد من الخلفية إذا كنت في حاجة إليها.