هل من السابق لأوانه البدء في التصميم للمكتبة الموازية للمهمة؟

Question

لقد تابعت تطوير مكتبة .NET Task Parallel Library (TPL) باهتمام كبير منذ أن أعلنت Microsoft لأول مرة.

ليس هناك شك في ذهني أننا سنستفيد في النهاية من TPL. ما أتساءل عنه هو ما إذا كان من المنطقي البدء في الاستفادة من TPL عندما يتم إصدار Visual Studio 2010 و .NET 4.0 ، أو ما إذا كان من المنطقي الانتظار لفترة أطول.

لماذا تبدأ الآن؟

• يبدو أن المكتبة الموازية للمهمة .NET 4.0 مصممة بشكل جيد وبعض الاختبارات البسيطة نسبيًا توضح أنها تعمل بشكل جيد على وحدات المعالجة المركزية متعددة النواة اليوم.
• لقد كنت مهتمًا جدًا بالمزايا المحتملة لاستخدام خيوط متعددة خفيفة الوزن لتسريع برنامجنا منذ شراء أول معالج رباعي Dell Poweredge 6400 منذ حوالي سبع سنوات. أشارت التجارب في ذلك الوقت إلى أنه لا يستحق هذا الجهد ، الذي عززه إلى حد كبير إلى النفقات العامة لنقل البيانات بين ذاكرة التخزين المؤقت لكل وحدة المعالجة المركزية (لم يكن هناك مخبأ مشترك في ذلك الوقت) وذاكرة الوصول العشوائي.
• ميزة تنافسية - لا يمكن أن يحصل بعض عملائنا على أداء كافٍ وليس هناك شك في أنه يمكننا بناء منتج أسرع باستخدام TPL اليوم.
• يبدو مضحكا. نعم ، أدرك أن بعض المطورين يفضلون أن يكونوا في العين بعصا حادة ، لكننا نتمتع حقًا بتعظيم الأداء.

لماذا الانتظار؟

• هل تمثل شركة Intel Nehalem CPUS اليوم من حيث نضرب الدعم متعدد النواة؟ يمكنك شراء وحدة المعالجة المركزية Nehalem مع 4 نوى تشترك في ذاكرة التخزين المؤقت من المستوى 3 واحد اليوم ، وعلى الأرجح يتم إصدار وحدة المعالجة المركزية الأساسية 6 تقاسم ذاكرة التخزين المؤقت من المستوى 3 بحلول الوقت الذي يتم فيه إصدار Visual Studio 2010 / .NET 4.0. من الواضح أن عدد النوى سيرتفع بمرور الوقت ، ولكن ماذا عن الهندسة المعمارية؟ مع ارتفاع عدد النوى ، هل ما زالوا يشاركون ذاكرة التخزين المؤقت؟ إحدى المشكلات مع Nehalem هي حقيقة أنه على الرغم من وجود اتصال سريع للغاية بين النوى ، فإن لديهم وصولًا غير موحد للذاكرة (NUMA) والذي يمكن أن يؤدي إلى انخفاض الأداء ونتائج أقل قابلية للتنبؤ بها. هل ستتمكن البنى المستقبلية متعددة النواة من التخلص من NUMA؟
• وبالمثل ، هل ستتغير المكتبة الموازية لمهمة .NET أثناء نضوجها ، مما يتطلب تعديلات على التعليمات البرمجية للاستفادة منها بالكامل؟

محددات

• محركنا الأساسي هو 100 ٪ C# ويجب تشغيله دون ثقة كاملة ، لذلك نحن محصورون باستخدام .NET APIs.

Answer 1

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

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

اعتمادًا على تطبيقك ، قد ترغب أيضًا في النظر إليه الامتدادات التفاعلية, الذي يعمل جنبًا إلى جنب مع PFX.

Answer 2

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

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

Answer 3

حسنًا - يبدو أن السبب الرئيسي الخاص بك ضد استخدام TPL اليوم هو ما يلي:
أنت لا تعرف ما إذا كان TPL سيأخذ الحد الأقصى من المستقبل متعدد النحاس.

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

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

وأين البدائل؟ باستخدام threadpool؟ حسنًا - ثم TPL أكثر تحديثًا. لذلك ، سيكون الرمز الخاص بك أكثر مقاومة في المستقبل عند استخدامه IMHO. على سبيل المثال ، تبدو العروض التوضيحية لميزات تصحيح الأخطاء لعام 2010 لطيفة للغاية.

بالإضافة إلى ذلك ، يبدو أن TPL مرن تمامًا في عيني - إذا لم يتناسب مع موقف معين ، فلا يتعين عليك استخدامه هناك. من ناحية أخرى ، فإنه يبسط التطور Mushc في مواقع أخرى.

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

لذلك ، استنتاجي: استخدمه!

Answer 4

سأذهب لذلك أيضًا. التغيير الكبير في رأيي هو التحول "النموذجي" من "لقد فعلنا ذلك بهذه الطريقة خلال السنوات الثماني الماضية" إلى برمجة أكثر وظيفية/خالية من التأثير الجانبي.

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

فيما يتعلق بتغييرات هندسة وحدة المعالجة المركزية: لا يمكنني التعليق حقًا على تلك ، إلا أنه في رأيي ، سيؤدي استثمارك الآن إلى ميزة تجارية الآن+x شهرًا. ربما يكون X أصغر من الوقت حتى تحدث التغييرات الرئيسية في تطوير وحدة المعالجة المركزية -> أنت تفوز.

Answer 5

لن أنتظر أيضًا.

في الواقع ، سأذهب إلى أبعد من ذلك وأقول لا تنتظر VS2010/.NET 4.0. TPL متاح لـ .NET 3.5 الآن كجزء من الامتدادات التفاعلية لـ .NET.