"خطأ نموذجي - قياس كل شيء على التوالي بلا عقل": مقابلة مع Andrei Akinshin حول قياس الأداء

العام الماضي ، أندريه أكينشين (صانع الاحلام) تم نشر كتاب "Pro .NET Benchmarking" : عمل مفصل حول قياس الأداء ، مفيد لكل من مطوري .NET ومتخصصي تكنولوجيا المعلومات في مجالات أخرى.

عندما بقي شهران قبل إصداره ، عقدنا مؤتمر DotNext 2019 Piter ، حيث سألنا أندريه في البث عبر الإنترنت عن الكتاب وعمومًا عن قياس الأداء. يبدو أنه منذ ذلك الحين كان يجب أن تكون هذه المقابلة قديمة: هناك يتحدثون عن الكتاب بصيغة المستقبل ، والآن هو الآن ستة أشهر. لكن على مدى الأشهر الستة الماضية ، لم تقرر البشرية خلاف ذلك أن تأخذ النسبة المئوية 99 - لذلك بالنسبة لكل شخص يمكنه استخدام قياس الأداء ، لا تزال إجابات Andrei تحتوي على الكثير من الأشياء ذات الصلة والمثيرة للاهتمام.

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

الشيء الرئيسي في الكتاب

- نرحب مرة أخرى بمشاهدي بث DotNext. هذه المرة أندري أكينشين معنا.

- تحية للجميع!

- الآن الأخبار الرئيسية المتعلقة بك هي الإعلان عن الكتاب ، والذي سيتم إصداره بحلول سبتمبر ...

- إذا سارت الأمور على ما يرام ، فسيتم إصداره في أواخر يونيو.

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

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

- ربما سمع معظم الجمهور بالفعل عن الكتاب. ولكن بالنسبة لأولئك الذين لا يعرفون ، فلنبدأ بقصة عنها.

- يسمى الكتاب "Pro .NET Benchmarking" . وهي من سلسلة Apress - وهي نفس السلسلة التي صدر فيها مؤخرًا كتاب Con .NET Coconut Pro .NET Memory Management . كما تم نشر كتاب ساشا غولدشتاين "Pro .NET Performance" - ربما سمعت عن هذا الأمر ، يتم عرضه من وقت لآخر على DotNext. وفي نفس السلسلة يأتي كتابي. يتعلق الأمر بكيفية عمل القياس من البداية إلى النهاية.

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

هناك فصل ، على سبيل المثال ، حول المعايير المرتبطة بوحدة المعالجة المركزية وحول المعايير المرتبطة بالذاكرة. هناك الكثير من دراسات الحالة المختلفة مع أمثلة لكيفية كتابة معيار معياري ل 3-4 خطوط وفي نفس الوقت تصوير نفسك في القدم بسبب بعض التأثيرات المعمارية الدقيقة لمعالجات Intel الحديثة.

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

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

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

قياس الدقة في الخفايا

- أذكر العبارة التي قرأتها في مكان ما أنه بالنسبة لأي نتيجة مرجعية على الإنترنت ، يمكنك العثور على تفسير خاطئ لهذه النتيجة. كم توافق على هذه العبارة؟

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

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

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

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

وهناك شيء من هذا القبيل حتى أن لدي تمارين خاصة في كتابي. لنفترض أن هناك خوارزميتين ، والتمرين هو هذا: أولاً ، تحتاج إلى وضع مقياس يوضح أن الخوارزمية الأولى أسرع بعشر مرات من الثانية ، ثم مقياسًا يوضح العكس. يمكنك اللعب بالبيانات المصدر ، مع البيئة ، وتغيير Mono إلى .NET Core ، أو التشغيل على Linux بدلاً من Windows - هناك مليون خيار للتخصيص. والنتيجة هي ما يلي: إذا شرعت في إظهار أن أحد البرامج يعمل بشكل أسرع من برنامج آخر ، فعلى الأرجح أن هناك طريقة للقيام بذلك.

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

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

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

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

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

- في هذا DotNext في مقابلة مع دميتري نيستيروك (mezastel) قلنا أنه عادة ما تصبح كتب تكنولوجيا المعلومات عفا عليها الزمن بسرعة ، ولكن إذا كتب عن أنماط التصميم ، فلن يتغير كل شيء هناك كل عام. وماذا عن قياس الأداء: قد لا يكون هذا الكتاب قديمًا أيضًا لفترة طويلة جدًا ، أو هل كنت قد كتبت شيئًا آخر قبل عامين؟

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

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

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

والجزء الآخر مرتبط بالفعل بميزات وقت التشغيل ، وميزات .NET. الآن (لدينا الكثير عن هذا في الكتاب) ، لدينا .NET Framework ، هناك .NET Core ، وهناك Mono. يمكن أن تختلف قياسات الأداء في أوقات التشغيل المختلفة أو حتى في نسختين متجاورتين من نفس وقت التشغيل. إذا كنت تستخدم .NET Core 2.2 و .NET Core 3.0 القادم ، فإن بعض أحمال العمل تختلف تمامًا مثل النهار والليل. إنها تقوم بتحسينات رائعة بحيث يتم ببساطة تسريع أبسط السيناريوهات 10 مرات ، 50 مرة.

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

والذي يتغير ، يتغير بشكل أساسي فيما يتعلق بجميع هذه الإصدارات ، تظهر تحسينات جديدة. على سبيل المثال ، ستظهر النفث المتدرج في .NET Core 3.0 . أي أن وقت التشغيل يمكن أن يولّد أولاً تطبيقًا أصليًا بسيطًا (وليس فعالًا جدًا) للطريقة بواسطة الشفرة. وبعد ذلك ، عندما يلاحظ وقت التشغيل أنك تسمي هذه الطريقة عدة مرات ، فسيقضي وقتًا أطول في الخلفية ويعيد إنشاء رمز أكثر إنتاجية. تقريبًا حقيقة أنه في Java في HotSpot هناك بالفعل العديد من السنوات ، في عالم .NET سيظهر في الإصدار المتضمن افتراضيًا هذا العام في النصف الثاني من العام (ملاحظة المحرر: نذكركم ، تم إجراء المقابلة في 2019) .

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

هذه الأشياء تتغير. قريبا سيكون لدينا وقت التشغيل متحد ، سيكون هناك .NET 5. واحد أفترض أنه سيتم إعادة تسميته بشكل مختلف بطريقة أو بأخرى ، أن هذا اسم وسيط. ربما لن يكون 5 ، ولكن 6 ، لأن لدينا بالفعل إصدار من .NET Core 5.0.

- حسنًا ، كما نعلم من Windows ، لا تمثل مشكلة بالنسبة لشركة Microsoft تخطي الرقم في الإصدار.

- نعم. بالفعل في وقت DNXكانت هناك أطر عمل مستهدفة مع خامس .NET الأساسي ، والآن تم استخدام "5.0" كثيرًا حيث يوجد الكثير من المنشورات القديمة. لذا ، لا أدري ، أنهم سيصنعون الإصدار الخامس بعد الإصدار الثالث ، لكنني كنت سأفتقد ليس فقط الأربعة ، ولكن الخمسة أيضًا ، وسأفوز بالسادس على الفور. ومع الأخذ في الاعتبار حقيقة أنهم يريدون الآن ، في رأيي ، جعل الإصدارات الفردية مستقرة LTS ، وحتى تلك التي ليست مستقرة للغاية ، سيكون من الممكن سبعة على الفور.

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

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

التفاعل مع BenchmarkDotNet و Rider

- من الواضح أن العمل في مكتبة BenchmarkDotNet قد أعطاك الكثير من الخبرة ، لذا فمن المنطقي أن تكون أنت من كتب الكتاب عن موضوع قياس الأداء. وهنا يبرز السؤال: هل الكتاب مرتبط بطريقة ما بنش مارك دوت نت ، أم أنه "أداة معرفة"؟

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

في ما يلي حالتا استخدام ، وحاولت القيام بالباقي بقدر المستخلص من BenchmarkDotNet. بحيث يكون الكتاب مفيدًا ليس فقط لمطوري .NET ، ولكن أيضًا ، على سبيل المثال ، لمطوري Java. نظرًا لأن جميع الميكانيكا الشائعة يتم نقلها بسهولة إلى أي نظام أساسي آخر ، فإن .NET و BenchmarkDotNet تُستخدم كأداة لتوضيح المفهوم.

- وفي الاتجاه الآخر كان التأثير؟ ماذا ، في عملية العمل على الكتاب ، هل فهمت أخيرًا ما عليك القيام به في BenchmarkDotNet مثل هذا؟

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

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

يحتوي BenchmarkDotNet على خوارزمية رائعة تحدد تلقائيًا أن التوزيع متعدد الوسائط ويحذر المستخدم: "Dude! انظر إلى الرسم البياني! كل شيء سيء هنا! هذا هو المكان الذي ظهر فيه متوسط ​​القيمة في العمود ، لا تنظر إليه! لا يتوافق مع أي شيء ، انظر إلى الرسم البياني! "

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

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

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

- من الصعب أن نتخيل ، ولكن بالإضافة إلى الكتاب و BenchmarkDotNet ، في حياتك هناك أيضًا عمل على رايدر - ومن المحتمل أن تكون هناك أيضًا مرجعية. هل يمكنك التحدث عن هذا؟ هل كان لديك على الصور تويتر للماك بوك في الثلاجة و بجانب المدفأة ، والتحقق كيف يؤثر على الأداء - كان للعمل، أو كتاب، أو كليهما في آن واحد؟

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

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

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

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

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

لذلك ، بشكل مشروط ، إذا كان هناك شك بعد التحلل في تكرار واحد ، ولكن لا توجد ثقة بنسبة 100 ٪ ، يجدر القيام بالتكرار الثاني. بعد الثانية ، يمكنك أن تقرر أن كل شيء على ما يرام معنا ، فقط عن طريق الصدفة أن شيئًا ما حدث. يمكنك القول أننا الآن على يقين من تدهور الأداء وحظر المسيرة. ويمكنك القول: "لا ، تكراران لا يزالان غير كافيين ، نحتاج إلى الانتقال إلى الثالث." حسنا وهلم جرا.

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

وحول جهاز macbook الموجود في الثلاجة - كل هذا للعمل أيضًا. الآن أحد المشاريع الصغيرة التي أقوم بها كثيرًا هو دراسة نماذج الاختناق الحراري. الوضع كما يلي: عندما يقوم المعيار المعياري المرتبط بوحدة المعالجة المركزية بتحميل الأجهزة بشكل كبير للغاية ، ترتفع درجة حرارة وحدة المعالجة المركزية ، وعندما تصل إلى قيمة عتبة معينة ، يقول معالج Intel أو نظام التشغيل: "Ay-yy-yy! نحن نفرط في الحرارة! " - لبعض الوقت يقلل من التردد. وبعد ذلك ، على سبيل المثال ، يتم الحصول على 2-3 تكرارات ، حيث من المفترض أن يكون تدهور الأداء مرئيًا. ونحن مثل: "أوه ، أوه ، أوه ، أوه! كل شيء سيء! لن نحمل هذا الغداء. " ولكن في الواقع ، لدينا عامل أداء محموم.

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

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

ونماذج الاختناق الحراري مختلفة تمامًا: أولاً ، يعتمد الكثير على المعالج وعلى تكوين كل المكواة ، وثانيًا ، على نظام التشغيل. على سبيل المثال ، خذ جهاز Mac: لدينا الكثير من اختبارات Mac ، لأن هناك الكثير من المستخدمين ولا يريدون أن يتباطأ Rider. وهناك نموذج خنق حراري شديد العدوانية.

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

مستقبل

"يجب أن أقاطعك ، لأن الوقت ينفد". ولكن بالنسبة لأولئك الذين هم مفتونون: هل ستكتب مشاركة مدونة حول هذه المواد؟

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

, . — , , .

— DotNext 2020 Piter -. , , , . -, , . -, . — .

Source: https://habr.com/ru/post/undefined/