سؤال

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

هناك عدد قليل من التقنيات التي تجعل كل هذا ممكنا:

1.) كودا بواسطة نفيديا. يبدو أنه الأكثر شهرة وموثقة جيدا. لسوء الحظ، لن يعمل فقط على بطاقات فيديو NVIDIA. لقد قمت بتنزيل SDK، جربت بعض العينات، وهناك بعض الأشياء الرائعة التي يتم إجراؤها في CUDA. لكن حقيقة أنها تقتصر على بطاقات نفيديا تجعلني سؤال مستقبلها.

2.) مجرى بواسطة ATI. تعادل ATI CUDA. كما قد تتوقع، فإنه سيعمل فقط على بطاقات ATI.

3.) opencl - وضعت مجموعة Khronos هذه المعيار ولكنها لا تزال في مراحل الطفولة. أنا أحب فكرة opencl على الرغم من. الأمل هو أنه ينبغي دعمه من قبل معظم الشركات المصنعة لبطاقات الفيديو ويجب أن يجعل تطوير بطاقة الفيديو عبر الفيديو أسهل بكثير.

ولكن ما هي التقنيات الأخرى لبرمجة GPU غير الرسومية قادمين وما الذي يدل على أكثر الوعد؟ وهل ترى أو هل ترغب في رؤية هذه التقنيات التي يتم بناؤها في بعض أطر التنمية الرئيسية مثل .NET لجعلها أسهل بكثير؟

هل كانت مفيدة؟

المحلول

أتوقع أن تصبح هذه التكنولوجيا شعبية وتعميمية، لكنها ستستغرق بعض الوقت للقيام بذلك. تخميني حوالي 5 إلى 10 سنوات.

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

أما بالنسبة لدمجها مع C # وغيرها من اللغات المدارة الرفيعة المستوى - سيستغرق ذلك وقتا أطول قليلا، لكن XNA يوضح بالفعل أن التظليل المخصص والبيئة المدارة يمكن أن تخلط معا - إلى حد ما. بالطبع، لا يزال رمز Shader غير موجود في C #، وهناك العديد من العقبات الرئيسية للقيام بذلك.

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

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

نصائح أخرى

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

من تجربتي، تكون GPUs سريعة للغاية بالنسبة للخوارزميات التي يسهل التوازي. لقد قمت مؤخرا بتحسين خوارزمية لتغيير حجم الصورة الخاصة في CUDA لتكون أكثر من 100 مرة بشكل أسرع على GPU (وليس حتى نهاية عالية) من معالج Intel رباعي النواة. كانت المشكلة تحظى بالبيانات إلى GPU ثم جلب النتيجة إلى الذاكرة الرئيسية، كلا الاتجاهين المحدود من خلال سرعة MEMCPY () على هذا الجهاز، والتي كانت أقل من 2 غيغابايت / ثانية. نتيجة لذلك، كانت الخوارزمية أسرع قليلا من إصدار وحدة المعالجة المركزية ...

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

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

مونت كارلو متوازي بشكل محرج، لكنه تقنية أساسية في الحوسبة المالية والعلمية.

أحد المجيبين غير صحيح قليلا أن نقول إن معظم التحديات العالمية الحقيقية لا تتحلل بسهولة في هذه الأنواع من المهام.

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

لمجرد أنه اسمه "بشكل محرج" لا يعني موازاة أنه ليس حقلا مهما للغاية.

لقد عملت في العديد من المنازل المالية، ونحن نستطيع أن نتخلص من المزارع من 1000+ محركات مونتيكارلو (تصطف العديد من مداخن شفرات معا) لعدة منشآت NVIDIA CUDA الكبيرة - تقليل تكاليف الطاقة والحرارة بشكل كبير في مركز البيانات.

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

لكن هذه التقنيات هذه هي على مستوى من التجريد أقل من لغة وقت التشغيل المدارة مثل C #، ونحن نتحدث عن أجهزة الأجهزة التي تدير التعليمات البرمجية الخاصة بها على معالجاتها الخاصة.

يجب أولا القيام بالتكامل أولا مع MATLAB، Mathematica أتوقع، جنبا إلى جنب مع APIS C للطبع ...

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

على سبيل المثال، يتضمن Stream 2.0 SDK إصدار مكتبة Blas (Algebra الخطية (الخطية) مع بعض الحسابات المنفذة على GPU. واجهة برمجة التطبيقات هي نفسها تماما مثل إصدار CPU فقط من المكتبة التي يتم شحنها لسنوات وسنوات؛ كل ما هو مطلوب هو إعادة ربط التطبيق، ويستخدم GPU ويدير بشكل أسرع.

وبالمثل، تعمل دان كامبل في GTRI على تنفيذ CUDA لمعيار VSipl لمعالجة الإشارات. (على وجه الخصوص، نوع من الإشارات ومعالجة الصور الشائعة في أنظمة الرادار والأشياء ذات الصلة مثل التصوير الطبي.) مرة أخرى، هذه واجهة قياسية، والتطبيقات التي تم كتابتها من أجل تطبيقات vsipl على المعالجات الأخرى يمكن إعادة ترجمة ببساطة مع هذا واستخدام قدرة GPU عند الاقتضاء.

في الممارسة العملية، هذه الأيام بالفعل الكثير من البرامج العددية عالية الأداء لا تقوم برمجة ذات مستوى منخفض، ولكن تعتمد على المكتبات. على أجهزة Intel، إذا كنت تقوم بتدحرج الأرقام، فمن الصعب عموما التغلب على مكتبات Intel Math (MKL) لمعظم الأشياء التي تنفذها - والاستخدام منها يعني أنه يمكنك الحصول على مزايا جميع إرشادات ناقلات و الحيل الذكية في معالجات X86 الأحدث، دون الحاجة إلى التخصص في الكود الخاص بك لهم. مع أشياء مثل GPUs، أظن أن هذا سيصبح أكثر انتشارا.

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

(تحيز إخلاء المسئولية: تعمل شركتي أيضا على ميناء CUDA مكتبة Vsipl ++، لذلك أنا أميل إلى الاعتقاد بأن هذه فكرة جيدة!)

أيضا، في اتجاه مختلف تماما، قد ترغب في التحقق من بعض الأشياء التي تقوم بها RapidMind. تم تصميم منهاجهم في البداية لأنظمة Multicore CPU من نوعها، لكنهم كانوا يقومون بعمل جيد من العمل يمتدونها إلى حسابات GPU أيضا.

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

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

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

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

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

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

وأيضا، ضع في اعتبارنا أنه كلما ذكر أي شخص تسريع تنفيذ GPU لتنفيذ وحدة المعالجة المركزية، فمن غير مقارنة عادلة تقريبا. أن نكون عادلين حقا، يجب على المنفذين أولا أن يقضون الوقت لإنشاء تنفيذ وحدة المعالجة المركزية المحسنة حقا. يمكن تحقيق وحدة المعالجة المركزية واحدة Intel Core I7 965 XE حوالي 70 Gigaflops بدقة مزدوجة اليوم. يمكن ل GPUS الحالي الراقية أن تفعل 70-80 Gigaflops بدقة مزدوجة وحوالي 1000 بدقة واحدة. وبالتالي فإن تسريع أكثر من 15 قد يعني تنفيذ وحدة المعالجة المركزية غير فعالة.

واحد تحذير مهم مع حوسبة GPU هو أنه "مقياس صغير" حاليا. مع وجود منشأة فائقة البلوبات، يمكنك تشغيل خوارزمية متوازية على المئات أو حتى الآلاف من CPU CORES. في المقابل، تقتصر مجمعات GPU "مجموعات" حاليا على حوالي 8 GPUs متصلة بجهاز واحد. بالطبع، يمكن دمج العديد من هذه الآلات معا، ولكن هذا يضيف تعقيدا إضافيا لأن البيانات يجب ألا تمر فقط بين أجهزة الكمبيوتر ولكن أيضا بين GPUs. أيضا، لا يوجد أي ما يعادل MPI الذي يتيح للعمليات على نطاق شفاف إلى GPUs متعددة عبر أجهزة متعددة؛ يجب أن تنفذ يدويا (ربما بالاشتراك مع MPI).

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

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

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

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

الناس يعملون بالفعل على ربط .NET ل CUDA. يرى هنا. وبعد ومع ذلك، مع ضرورة العمل على مستوى منخفض، لا أعتقد أن الحوسبة GPU جاهزة للجماهير حتى الآن.

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

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

سأكرر الإجابة التي أعطيتها هنا.

على المدى الطويل وأعتقد أن GPU سيتوقف عن الوجود، كمعالجات للأغراض العامة تتطور لتولي تلك الوظائف. إنتل لارابي هي الخطوة الأولى. لقد أظهر التاريخ أن الرهان ضد X86 هو فكرة سيئة.

يضيف الباحثون GHC (Haskell) (العمل في Microsoft Research) دعما لمتوازي البيانات المتداخلة مباشرة إلى لغة برمجة غرض عام. تتمثل الفكرة في استخدام النوى المتعددة و / أو GPUs على النهاية الخلفية، لكنها تعرض صفيفات بيانات متوازية للبيانات كنوع أصلي باللغة، بغض النظر عن وقت التشغيل لتنفيذ التعليمات البرمجية بالتوازي (أو التسلسلي لحركة وحدة المعالجة المركزية الفردية).

http://www.haskell.org/haskellwiki/ghc/data_parallel_haskell.

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

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

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

قصيرة جدا، يمكن أن يكون GPU سريعا بشكل مثير للدهشة للمشاكل التي يمكنك فيها تقسيم البيانات بشكل صحيح ومعالجة الأقسام بشكل مستقل. انها ليست قوية جدا في المهمة (موضوع) المستوى التوازي.

مشكلة كبيرة في تكنولوجيا GPU هي أنه بينما لديك الكثير من القدرة على حساب هناك، فإن الحصول على البيانات في (والخروج منها) أمر فظيع (من أمر الأداء). ومشاهدة بعناية لأي معايير مقارنة ... في كثير من الأحيان مقارنة دول مجلس التعاون الخليجي (مع الحد الأدنى من التحسين، لا يوجد أي عيار) على نظام معالج واحد إلى GPU.

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

أنا متحمس جدا لهذه التكنولوجيا. ومع ذلك، أعتقد أن هذا لن يؤدي إلا إلى تفاقم التحدي الحقيقي للمهام الموازية الكبيرة، أحد النطاق الترددي. إضافة المزيد من النوى سوف تزيد فقط من الخلاف للذاكرة. لا تقدم OpenCL وغيرها من مكتبات تجريد GPGPU أي أدوات لتحسين ذلك.

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

صحيح أن GPUS يمكن أن تحقق أرقام أداء عالية جدا في مواقف متوازية لمستوى البيانات، كما ذكر الكثير هنا. ولكن كما أراها، لا يوجد استخدام كبير في مساحة المستخدم الآن. لا أستطيع المساعدة في الشعور بأن كل هذه الدعاية GPGPU تأتي من مصنعي GPU، والتي ترغب فقط في العثور على أسواق جديدة واستخدامات منتجاتها. وهذا aboumutelly حسنا. هل سبق لك أن تساءلت لماذا لم تشمل Intel / AMD بعض النوى Mini-X86 بالإضافة إلى القياسية القياسية (دعنا نقول - طراز مع أربعة كور X86 و 64 مصغرة X86-CORE)، فقط لتعزيز إبطال معايبات لغة البيانات؟ بالتأكيد يمكن أن تفعل ذلك، إذا أرادت. تخميني هو أن هذه الصناعة فقط لا تحتاج إلى هذا النوع من الطاقة في آلات سطح المكتب / الخادم العادية.

قد تبقى GPUs أو لا تبقى شعبية كما هي الآن، لكن الفكرة الأساسية أصبحت نهجا شائعا إلى حد ما لمعالجة الطاقة العالية. اتجاه واحد يأتي الآن هو "التسجيل" الخارجي لمساعدة وحدة المعالجة المركزية مع وظائف الفاصلة العائمة الكبيرة. GPU هو مجرد نوع واحد من مسرع.

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

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

تصورك أن GPUs أسرع من وحدة المعالجة المركزية يعتمد على الخاطئة الخاطئة التي تم إنشاؤها بواسطة بعض التطبيقات الموازية المحصورة مطبقة على أمثال أجهزة PS3 و NVIDIA و ATI.

http://en.wikipedia.org/wiki/embarrassly_parallel.

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

أتوقع نفس الأشياء التي تستخدمها cpus؟

أنا فقط يعني أن هذا يبدو وكأنه وسيلة للتحايل إلي. أتردد في القول "هذا ليس في أي مكان" عندما يتعلق الأمر بالتكنولوجيا ولكن وظيفة GPUS الأساسية هي تقديم الرسومات ووظيفة CPUS الأساسية هي كل المعالجة الأخرى. وجود GPU تفعل أي شيء آخر يبدو تماما.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top