Get best of the week

حوسبة GPU - لماذا ومتى وكيف. بالإضافة إلى بعض الاختبارات

لقد عرف الجميع منذ فترة طويلة أنه على بطاقات الفيديو لا يمكنك فقط لعب الألعاب ، ولكن أيضًا أداء أشياء لا تتعلق بالألعاب ، على سبيل المثال ، تدريب شبكة عصبية ، أو تذكر العملة المشفرة أو إجراء حسابات علمية. كيف حدث ذلك ، يمكنك قراءته هنا ، لكني أردت أن أتطرق إلى موضوع لماذا قد تكون GPU مثيرة للاهتمام بالنسبة للمبرمج العادي (غير المرتبط بـ GameDev) كيفية التعامل مع التطوير على GPU دون قضاء الكثير من الوقت في ذلك ، قرر ما إذا انظر في هذا الاتجاه ، و " اكتشف على أصابعك" ما هو الربح الذي يمكنك الحصول عليه. 



تمت كتابة المقالة بناءً على عرضي التقديمي في HighLoad ++. يناقش بشكل رئيسي التقنيات التي تقدمها NVIDIA. ليس لدي أي غرض للإعلان عن أي منتجات ، بل أعطيها كمثال ، وبالتأكيد يمكن العثور على شيء مماثل في الشركات المصنعة المنافسة.

لماذا الاعتماد على GPU؟


يمكن مقارنة معالجين وفقًا لمعايير مختلفة ، ولعل الأكثر شيوعًا هو تردد وعدد النوى ، وحجم ذاكرة التخزين المؤقت ، وما إلى ذلك ، ولكن في النهاية ، نحن مهتمون بعدد العمليات التي يمكن للمعالج إجراؤها لكل وحدة زمنية ، ونوع العملية هذا ، ولكن سؤال منفصل مقياس شائع هو عدد عمليات النقطة العائمة في الثانية - يتخبط. وعندما نريد المقارنة بين الدفء والناعمة ، وفي حالتنا GPU مع وحدة المعالجة المركزية ، فإن هذا المقياس مفيد.

يوضح الرسم البياني أدناه نمو هذه التقلبات نفسها بمرور الوقت للمعالجات وبطاقات الفيديو.


(يتم جمع البيانات من مصادر مفتوحة ، ولا توجد بيانات للسنوات 2019-20 ، لأنه ليس كل شيء جميل جدًا هناك ، لكن GPUs لا تزال تفوز)

حسنًا ، إنها مغرية ، أليس كذلك؟ نحول جميع الحسابات من وحدة المعالجة المركزية إلى وحدة معالجة الرسومات ونحصل على أفضل أداء ثمانية أضعاف!

ولكن ، بالطبع ، ليس كل شيء بهذه البساطة. لا يمكنك فقط نقل كل شيء ونقله إلى وحدة معالجة الرسومات ، لماذا سنتحدث أكثر.

بنية GPU ومقارنتها مع وحدة المعالجة المركزية


أحمل للكثيرين صورة مألوفة مع بنية وحدة المعالجة المركزية والعناصر الأساسية:


وحدة المعالجة المركزية الأساسية

ما هو خاص جدا؟ جوهر واحد ومجموعة من الكتل المساعدة.

الآن دعونا نلقي نظرة على بنية GPU:


GPU Core

تحتوي بطاقة الفيديو على الكثير من نوى المعالجة ، وعادة ما تكون عدة آلاف ، ولكن يتم دمجها في كتل ؛ بالنسبة لبطاقات فيديو NVIDIA ، عادة 32 لكل منها ، ولها عناصر مشتركة ، بما في ذلك ويسجل. إن بنية نواة GPU والعناصر المنطقية أبسط بكثير من وحدة المعالجة المركزية ، أي أنه لا توجد أجهزة إحضار مسبقة ومتنبئات غداء وأكثر من ذلك بكثير.

حسنًا ، هذه هي النقاط الرئيسية للاختلاف في بنية وحدة المعالجة المركزية ووحدة معالجة الرسومات ، وفي الواقع ، تفرض قيودًا أو ، على العكس ، تفتح الاحتمالات لما يمكننا قراءته بشكل فعال على وحدة معالجة الرسومات.

لم أذكر نقطة أخرى مهمة ، عادةً ، لا تقوم "بطاقة الفيديو" والمعالج "بالتفتيش" بينهما وكتابة البيانات إلى بطاقة الفيديو وقراءة النتيجة مرة أخرى - هذه عمليات منفصلة وقد تتحول إلى "اختناق" في نظامك ، رسم بياني لوقت الضخ مقابل الحجم يتم إعطاء البيانات لاحقًا في المقالة.

قيود وميزات GPU


ما هي القيود التي تفرضها هذه البنية على الخوارزميات القابلة للتنفيذ:

  • إذا كنا نقوم بالحساب على GPU ، فلا يمكننا تحديد نواة واحدة فقط ، فسيتم تخصيص كتلة كاملة من النوى (32 لـ NVIDIA).
  • تقوم جميع النوى بتنفيذ نفس التعليمات ، ولكن مع بيانات مختلفة (سنتحدث عن هذا لاحقًا) ، تسمى هذه العمليات الحسابية تعليمات متعددة البيانات المتعددة أو بطاقة SIMD (على الرغم من أن NVIDIA تقدم تحسينها). 
  • نظرًا لمجموعة بسيطة نسبيًا من الكتل المنطقية والسجلات العامة ، فإن GPU لا تحب التفرع ، بل المنطق المعقد في الخوارزميات.

ما هي الفرص التي يفتحها:

  • في الواقع ، تسارع حسابات SIMD نفسها. أبسط مثال هو إضافة المصفوفات بشكل عنصري ، ودعونا نحللها.

الحد من الخوارزميات الكلاسيكية لتمثيل SIMD


تحويل


لدينا صفين ، A و B ، ونريد إضافة عنصر من الصفيف B إلى كل عنصر من الصفيف A. فيما يلي مثال في C ، على الرغم من أنني آمل أن يكون واضحًا لأولئك الذين لا يتحدثون هذه اللغة:

void func(float *A, float *B, size)
{ 
   for (int i = 0; i < size; i++) 
   { 
       A[i] += B[i]
   } 
}

استرجاع كلاسيكي للعناصر في حلقة ووقت تشغيل خطي.

الآن دعونا نرى كيف سيبدو هذا الرمز عن GPU:

void func(float *A, float *B, size) 
{ 
   int i = threadIdx.x; 
   if (i < size) 
      A[i] += B[i] 
}

وهنا من المثير للاهتمام بالفعل ، ظهر متغير threadIdx ، والذي يبدو أننا لم نعلن عنه في أي مكان. نعم ، نظامنا يوفر لنا. تخيل أنه في المثال السابق يتكون الصفيف من ثلاثة عناصر ، وتريد تشغيله في ثلاثة خيوط متوازية. للقيام بذلك ، ستحتاج إلى إضافة معلمة أخرى - الفهرس أو رقم الدفق. هذا ما تفعله بطاقة الفيديو بالنسبة لنا ، على الرغم من أنها تمرر الفهرس كمتغير ثابت ويمكن أن تعمل بأبعاد متعددة في وقت واحد - x ، y ، z.

فارق بسيط آخر ، إذا كنت ستبدأ عددًا كبيرًا من التدفقات المتوازية في وقت واحد ، فيجب تقسيم التدفقات إلى كتل (ميزة معمارية لبطاقات الفيديو). يعتمد الحد الأقصى لحجم الكتلة على بطاقة الفيديو ، وسيتعين الحصول على فهرس العنصر الذي نجري الحسابات له على النحو التالي:

int i = blockIdx.x * blockDim.x + threadIdx.x; // blockIdx –  , blockDim –  , threadIdx –

ونتيجة لذلك ، ما لدينا: الكثير من الخيوط المتوازية التي تعمل على تنفيذ نفس الرمز ، ولكن مع مؤشرات مختلفة ، وبالتالي ، البيانات ، أي نفس SIMD.

هذا هو أبسط مثال ، ولكن إذا كنت ترغب في العمل مع GPU ، فأنت بحاجة إلى إحضار مهمتك إلى نفس النموذج. لسوء الحظ ، هذا ليس ممكنًا دائمًا وقد يصبح في بعض الحالات موضوعًا لأطروحة دكتوراه ، ولكن مع ذلك ، لا يزال من الممكن إحضار الخوارزميات الكلاسيكية إلى هذا النموذج.

تجميع


دعونا نرى الآن كيف سيبدو التجميع إلى تمثيل SIMD:
 

لدينا مجموعة من العناصر n. في المرحلة الأولى ، نبدأ خيوط n / 2 ويضيف كل خيط عنصرين ، أي في تكرار واحد ، نضيف معًا نصف العناصر في المصفوفة. ثم في الحلقة نكرر نفس الشيء للصفيف الذي تم إنشاؤه حديثًا ، حتى نقوم بتجميع العنصرين الأخيرين. كما ترون ، كلما كان حجم المصفوفة أصغر ، كلما كانت الخيوط المتوازية أقل يمكننا أن نبدأ ، أي على GPU ، من المنطقي تجميع صفائف بحجم كبير بما فيه الكفاية. يمكن استخدام مثل هذه الخوارزمية لحساب مجموع العناصر (بالمناسبة ، لا تنس التدفق الزائد المحتمل لنوع البيانات التي تعمل معها) ، أو ابحث عن الحد الأقصى ، أو الأدنى ، أو البحث فقط.

فرز


لكن الفرز يبدو أكثر تعقيدًا بالفعل.

أكثر خوارزميات الفرز شيوعًا في وحدة معالجة الرسومات هما:

  • فرز Bitonic
  • فرز الجذر

ولكن لا يزال يتم استخدام فرز الجذر في كثير من الأحيان ، ويمكن العثور على التنفيذ الجاهز للإنتاج في بعض المكتبات. لن أحلل بالتفصيل كيفية عمل هذه الخوارزميات ؛ يمكن للمهتمين العثور على وصف لفرز الجذر على https://www.codeproject.com/Articles/543451/Parallel-Radix-Sort-on-the-GPU-using-Cplusplus- AMP و https://stackoverflow.com/a/26229897

لكن الفكرة هي أنه حتى هذه الخوارزمية غير الخطية مثل الفرز يمكن اختزالها إلى عرض SIMD.

والآن ، قبل النظر إلى الأرقام الحقيقية التي يمكن الحصول عليها من وحدة معالجة الرسومات ، دعنا نكتشف كيفية البرمجة لهذه المعجزة التكنولوجية؟

من أين أبدا


التقنية الأكثر شيوعًا التي يمكن استخدامها للبرمجة تحت GPU:

  • أوبينكل
  • كودا

OpenCL هو معيار يدعمه معظم مصنعي بطاقات الفيديو ، بما في ذلك وعلى الأجهزة المحمولة ، يمكن أيضًا تشغيل التعليمات البرمجية المكتوبة في OpenCL على وحدة المعالجة المركزية.

يمكنك استخدام OpenCL من C / C ++ ، وهناك روابط للغات أخرى.

بالنسبة لـ OpenCL ، أعجبني أكثر كتاب OpenCL في العمل . كما يصف أيضًا خوارزميات مختلفة على GPU ، بما في ذلك فرز Bitonic وفرز Radix.

CUDA هي تقنية NVIDIA الخاصة و SDK. يمكنك الكتابة في C / C ++ أو استخدام الارتباطات للغات أخرى.

إن مقارنة OpenCL و CUDA غير صحيحة إلى حد ما ، لأن واحد هو المعيار ، والآخر هو SDK بالكامل. ومع ذلك ، يختار العديد من الأشخاص CUDA لتطوير بطاقات الفيديو ، على الرغم من حقيقة أن التكنولوجيا ملكية ، على الرغم من أنها مجانية وتعمل فقط على بطاقات NVIDIA. هناك عدة أسباب لذلك:

  • API
  • , GPU, (host)
  • , ..

وتشمل الخصائص حقيقة أن CUDA تأتي مع مترجم خاص بها ، والذي يمكنه أيضًا تجميع كود C / C ++ القياسي.

كان كتاب CUDA الأكثر شمولاً الذي صادفته هو البرمجة الاحترافية CUDA C ، على الرغم من أنه قديم بعض الشيء ، إلا أنه يناقش الكثير من الفروق الفنية في البرمجة لبطاقات NVIDIA.

ولكن ماذا لو كنت لا أرغب في قضاء شهرين في قراءة هذه الكتب ، وكتابة برنامجي الخاص لبطاقة الفيديو ، والاختبار والتصحيح ، ثم اكتشفت أن هذا ليس لي؟ 

كما قلت ، هناك عدد كبير من المكتبات التي تخفي تعقيد التطوير تحت GPU: XGBoost و cuBLAS و TensorFlow و PyTorch وغيرها ، سننظر في مكتبة الدفعنظرًا لأنها أقل تخصصًا من المكتبات الأخرى المذكورة أعلاه ، ولكنها في نفس الوقت تنفذ الخوارزميات الأساسية ، على سبيل المثال ، الفرز والبحث والتجميع ، ومع احتمالية عالية يمكن أن تكون قابلة للتطبيق في مهامك.

Thrust هي مكتبة C ++ تهدف إلى "استبدال" خوارزميات STL القياسية بخوارزميات تستند إلى GPU. على سبيل المثال ، سيبدو ترتيب مصفوفة أرقام باستخدام هذه المكتبة على بطاقة فيديو كما يلي:

thrust::host_vector<DataType> h_vec(size); //    
std::generate(h_vec.begin(), h_vec.end(), rand); //   
thrust::device_vector<DataType> d_vec = h_vec; //         
thrust::sort(d_vec.begin(), d_vec.end()); //    
thrust::copy(d_vec.begin(), d_vec.end(), h_vec.begin()); //   ,

(لا تنس أن المثال يجب أن يتم تجميعه بواسطة مترجم من NVIDIA)

كما ترون ، فإن thrust :: sort مشابه جدًا لخوارزمية مماثلة من STL. تخفي هذه المكتبة العديد من الصعوبات ، ولا سيما تطوير برنامج فرعي (بتعبير أدق ، النواة) ، والذي سيتم تنفيذه على بطاقة الفيديو ، ولكن في الوقت نفسه يحرم من المرونة. على سبيل المثال ، إذا أردنا فرز عدة غيغابايت من البيانات ، فسيكون من المنطقي إرسال جزء من البيانات إلى البطاقة لبدء الفرز ، وأثناء إجراء الفرز ، أرسل المزيد من البيانات إلى البطاقة. يُطلق على هذا النهج اسم "إخفاء زمن الوصول" ويسمح باستخدام أكثر فعالية لموارد خريطة الخادم ، ولكن للأسف ، عندما نستخدم مكتبات عالية المستوى ، تظل هذه الفرص مخفية. ولكن بالنسبة للنماذج الأولية وقياس الأداء ، فهي متشابهة تمامًا ، خاصة مع الدفع الذي يمكنك قياسه الذي يوفره نقل البيانات.

لقد كتبت معيارًا صغيرًا باستخدام هذه المكتبة ، التي تدير العديد من الخوارزميات الشائعة بكميات مختلفة من البيانات على GPU ، دعنا نرى ما هي النتائج.

نتائج خوارزمية GPU


لاختبار GPU ، أخذت مثيلًا في AWS مع بطاقة فيديو Tesla k80 ، هذه ليست أقوى بطاقة خادم حتى الآن (أقوى Tesla v100) ، ولكنها الأكثر بأسعار معقولة وعلى متنها:

  • 4992 كودا نواة
  • 24 جيجا بايت من الذاكرة
  • 480 جيجابايت / ثانية - عرض نطاق الذاكرة 

وبالنسبة للاختبارات على وحدة المعالجة المركزية ، أخذت مثيلًا مع معالج Intel Xeon CPU E5-2686 v4 @ 2.30GHz

تحويل



وقت تنفيذ التحويل على GPU و CPU في ms

كما ترى ، فإن التحول المعتاد لعناصر الصفيف هو نفسه تقريبًا في الوقت ، سواء على GPU أو على CPU. و لماذا؟ نظرًا لأن الحمل الزائد لإرسال البيانات إلى البطاقة والعودة يستهلك تعزيز الأداء بالكامل (سنتحدث عن النفقات العامة بشكل منفصل) ، وهناك حسابات قليلة نسبيًا على البطاقة. أيضًا ، لا تنس أن المعالجات تدعم أيضًا تعليمات SIMD ، ويمكن للمجمعين في الحالات البسيطة استخدامها بشكل فعال. 

دعنا الآن نرى كيف يتم التجميع بكفاءة على GPU.

تجميع



وقت تنفيذ التجميع على وحدة معالجة الرسومات ووحدة المعالجة المركزية بالميلي ثانية

في مثال التجميع ، نرى بالفعل زيادة كبيرة في الأداء مع زيادة في حجم البيانات. من الجدير أيضًا الانتباه إلى حقيقة أننا نضخ كمية كبيرة من البيانات في ذاكرة البطاقة ، ولا يتم استرداد سوى قيمة مجمعة واحدة فقط ، أي الحمل الزائد لنقل البيانات من البطاقة إلى ذاكرة الوصول العشوائي هو الحد الأدنى.

دعنا ننتقل إلى المثال الأكثر إثارة للاهتمام - الفرز.

فرز



وقت الفرز لوحدة معالجة الرسومات ووحدة المعالجة المركزية بالميلي ثانية على

الرغم من حقيقة أننا نرسل مجموعة البيانات بالكامل إلى بطاقة الفيديو والعكس بالعكس ، فإن الفرز إلى وحدة معالجة الرسوم 800 ميجابايت من البيانات أسرع بنحو 25 مرة من المعالج.

النفقات العامة لنقل البيانات


كما يتبين من مثال التحويل ، ليس من الواضح دائمًا ما إذا كانت وحدة معالجة الرسومات ستكون فعالة حتى في تلك المهام التي تتوازى بشكل جيد. والسبب في ذلك هو حمل عام لنقل البيانات من ذاكرة الوصول العشوائي للكمبيوتر إلى ذاكرة بطاقة الفيديو (في وحدات التحكم في الألعاب ، بالمناسبة ، تتم مشاركة الذاكرة بين وحدة المعالجة المركزية ووحدة معالجة الرسومات ، ولا توجد حاجة لنقل البيانات). إحدى خصائص بطاقة الفيديو هي عرض النطاق الترددي للذاكرة أو عرض النطاق الترددي للذاكرة ، والذي يحدد عرض النطاق الترددي النظري للبطاقة. بالنسبة إلى Tesla k80 ، تبلغ 480 جيجابايت / ثانية ، أما بالنسبة إلى Tesla v100 فهي بالفعل 900 جيجابايت / ثانية. أيضًا ، سيؤثر إصدار PCI Express وتنفيذ كيفية نقل البيانات إلى البطاقة على معدل النقل ، على سبيل المثال ، يمكن القيام بذلك في العديد من التدفقات المتوازية.

دعونا نلقي نظرة على النتائج العملية التي تم الحصول عليها لبطاقة رسومات Tesla k80 في سحابة Amazon:


حان الوقت لنقل البيانات إلى وحدة معالجة الرسومات ، وفرز البيانات ونقلها إلى ذاكرة الوصول العشوائي في MS

HtoD - نقل البيانات إلى

تنفيذ بطاقة فيديو GPU - الفرز على بطاقة الفيديو

DtoH - نسخ البيانات من بطاقة الفيديو إلى ذاكرة الوصول العشوائي

أول شيء يجب ملاحظته هو أن قراءة البيانات من بطاقة الفيديو أسرع من أكتبها هناك.

والثاني - عند العمل باستخدام بطاقة فيديو ، يمكنك الحصول على الكمون من 350 ميكروثانية ، وقد يكون هذا كافياً بالفعل لبعض التطبيقات ذات الكمون المنخفض.

يوضح الرسم البياني أدناه النفقات العامة لمزيد من البيانات:


حان الوقت لنقل البيانات إلى وحدة معالجة الرسومات ، وفرز البيانات ونقلها إلى ذاكرة الوصول العشوائي في مللي ثانية

استخدام الخادم


السؤال الأكثر شيوعًا هو كيف تختلف بطاقة فيديو اللعبة عن الخادم؟ وفقًا للخصائص ، فهي متشابهة جدًا ، لكن الأسعار تختلف بشكل كبير.


الاختلافات الرئيسية بين الخادم (NVIDIA) وبطاقة اللعبة:

  • ضمان المصنّع (بطاقة اللعبة غير مصممة لاستخدام الخادم)
  • المشاكل الافتراضية المحتملة لبطاقة رسومات المستهلك
  • توفر آلية تصحيح الخطأ على بطاقة الخادم
  • عدد سلاسل العمليات المتوازية (وليس نوى CUDA) أو دعم Hyper-Q ، والذي يسمح لك بالعمل مع البطاقة من عدة سلاسل محادثات على وحدة المعالجة المركزية ، على سبيل المثال ، تحميل البيانات إلى البطاقة من سلسلة محادثات وبدء العمليات الحسابية من أخرى

ربما هذه هي الاختلافات الرئيسية التي وجدتها.

تعدد


بعد أن اكتشفنا كيفية تشغيل أبسط خوارزمية على بطاقة الفيديو والنتائج التي يمكن توقعها ، فإن السؤال المنطقي التالي هو كيف ستتصرف بطاقة الفيديو عند معالجة عدة طلبات متوازية. كإجابة ، لدي رسمان بيانيان للحوسبة على وحدة معالجة الرسومات ومعالج مع 4 و 32 مركزًا:


الوقت المستغرق لإجراء العمليات الحسابية على وحدة معالجة الرسومات ووحدة المعالجة المركزية بمصفوفات 1000 × 60 في مللي ثانية.

على هذا الرسم البياني ، يتم إجراء العمليات الحسابية بمصفوفات 1000 × 60 عنصرًا. تبدأ الحسابات من العديد من تدفقات البرنامج ، ويتم إنشاء دفق منفصل لوحدة معالجة الرسومات لكل دفق وحدة معالجة مركزية (يتم استخدام Hyper-Q نفسه). 

كما ترى ، يتعامل المعالج مع هذا الحمل بشكل جيد للغاية ، في حين أن الكمون لطلب واحد لكل GPU يزيد بشكل كبير مع زيادة في عدد الطلبات المتوازية.


الوقت لإجراء العمليات الحسابية على GPU ووحدة المعالجة المركزية مع المصفوفات 10000 × 60 في مللي ثانية.

على الرسم البياني الثاني ، نفس الحسابات ، ولكن مع المصفوفات أطول 10 مرات ، وتتصرف GPU بشكل أفضل في ظل هذا الحمل. هذه الرسوم البيانية إرشادية للغاية ، ويمكننا أن نستنتج: يعتمد السلوك تحت الحمل على طبيعة الحمل نفسه. يمكن للمعالج أيضًا التعامل مع حسابات المصفوفة بكفاءة عالية ، ولكن إلى حد معين. بالنسبة لبطاقة الفيديو ، من المميز أنه بالنسبة لحمل الحوسبة الصغيرة ، ينخفض ​​الأداء بشكل خطي تقريبًا. مع زيادة الحمل وعدد الخيوط المتوازية ، تتواءم بطاقة الفيديو بشكل أفضل. 

من الصعب افتراض كيف ستتصرف GPU في مواقف مختلفة ، ولكن كما ترى ، في ظروف معينة ، يمكن لبطاقة الخادم معالجة الطلبات من العديد من التدفقات المتوازية بكفاءة عالية.

سنناقش بعض الأسئلة الإضافية التي قد تكون لديك إذا كنت لا تزال تقرر استخدام GPU في مشاريعك.

حد الموارد


كما قلنا من قبل ، المصدران الرئيسيان لبطاقة الفيديو هما النوى والذاكرة.

على سبيل المثال ، لدينا العديد من العمليات أو الحاويات باستخدام بطاقة الفيديو ، ونود أن نتمكن من مشاركة بطاقة الفيديو بينهما. لسوء الحظ ، لا توجد واجهة برمجة تطبيقات بسيطة لهذا. تقدم NVIDIA تقنية vGPU ، لكنني لم أجد بطاقة Tesla k80 في قائمة البطاقات المدعومة ، وبقدر ما أستطيع أن أفهم من الوصف ، فإن التكنولوجيا تركز أكثر على الشاشات الافتراضية أكثر من الحسابات. ربما تقدم AMD شيئًا أكثر ملاءمة.

لذلك ، إذا كنت تخطط لاستخدام GPU في مشاريعك ، فيجب عليك الاعتماد على حقيقة أن التطبيق سيستخدم بطاقة الفيديو حصريًا ، أو ستتحكم برمجيًا في حجم الذاكرة المخصصة وعدد النوى المستخدمة للحسابات.

حاويات وجرافيك


إذا اكتشفت حد الموارد ، فإن السؤال المنطقي التالي: ماذا لو كان هناك العديد من بطاقات الفيديو في الخادم؟

مرة أخرى ، يمكنك تحديد مستوى GPU الذي ستستخدمه على مستوى التطبيق.

طريقة أخرى أكثر ملاءمة هي حاويات Docker. يمكنك استخدام الحاويات العادية ، لكن NVIDIA تقدم حاويات NGC ، مع إصدارات محسنة من البرامج والمكتبات وبرامج التشغيل المختلفة. بالنسبة لحاوية واحدة ، يمكنك تحديد عدد وحدات معالجة الرسومات المستخدمة ورؤيتها للحاوية. النفقات العامة على استخدام الحاويات حوالي 3٪.

اعمل في مجموعة


سؤال آخر ، ماذا تفعل إذا كنت تريد تنفيذ مهمة واحدة على العديد من وحدات معالجة الرسومات داخل نفس الخادم أو الكتلة؟

إذا اخترت مكتبة مشابهة للتوجه أو حل أقل مستوى ، فيجب حل المهمة يدويًا. تدعم الأطر عالية المستوى ، على سبيل المثال ، للتعلم الآلي أو الشبكات العصبية ، عادةً القدرة على استخدام بطاقات متعددة خارج الصندوق.

بالإضافة إلى ذلك ، أود أن أشير إلى أنه ، على سبيل المثال ، توفر NVIDIA واجهة لتبادل البيانات المباشر بين البطاقات - NVLINK ، وهو أسرع بكثير من PCI Express. وهناك تكنولوجيا للوصول المباشر إلى ذاكرة البطاقة من أجهزة PCI Express الأخرى - GPUDirect RDMA ، incl. و الشبكة .

التوصيات


إذا كنت تفكر في استخدام GPU في مشاريعك ، فمن المرجح أن تكون GPU مناسبة لك إذا:

  • يمكن اختزال مهمتك إلى عرض SIMD
  • من الممكن تحميل معظم البيانات على الخريطة قبل الحسابات (ذاكرة التخزين المؤقت)
  • يشمل التحدي الحوسبة المكثفة

يجب عليك أيضًا طرح الأسئلة مسبقًا:

  • كم عدد الاستعلامات الموازية ستكون 
  • ما الكمون الذي تتوقعه
  • هل تحتاج إلى بطاقة واحدة للتحميل الخاص بك؟ هل تحتاج إلى خادم به عدة بطاقات أو مجموعة من خوادم GPU 

هذا كل شيء ، آمل أن تكون المواد مفيدة لك وتساعدك على اتخاذ القرار الصحيح!

المراجع


المعيار والنتائج على github - https://github.com/tishden/gpu_benchmark/tree/master/cuda

بالإضافة إلى الموضوع ، تسجيل لتقرير "قواعد بيانات GPU - العمارة والأداء وآفاق الاستخدام"

NVIDIA NGC Containers Webinar - http : //bit.ly/2UmVIVt أو http://bit.ly/2x4vJKF

More articles:


All Articles