أسوأ وقت للتنفيذ

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

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

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

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

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

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

يوجد عدد من الأدوات التجارية والأكاديمية التي تطبق أشكالاً مختلفة من التحليل الثابت.

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

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

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

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