نحو مستقبل أكثر إشراقا للمترجمين الذكية

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

أين بالضبط تحاول تطبيق أساليب التعلم الآلي عند إنشاء المجمعين؟ ولماذا لم يصبح المترجمون "الأذكياء" جزءًا من الحياة اليومية للمطور؟

خيارات لاستخدام التعلم الآلي في تطوير برنامج التحويل البرمجي

لنبدأ بالسؤال الأول حول الاستخدامات المحددة للتعلم الآلي. الحقيقة هي أن المجمعين الحديثين هم أنظمة معقدة مع عدد كبير من التحسينات التي تسمح لك بالحصول على كود أكثر كفاءة للماكينة. ومع ذلك ، فإن بعض التحسينات والمهام الأخرى ، مثل تخصيص التسجيل ، هي NP-Complete ، مما يفرض على مطوري برنامج التحويل البرمجي استخدام خوارزميات الاستدلال. نتيجة لذلك ، تحتوي معظم برامج التحويل البرمجي على عدد كبير من إشارات التحسين التي تسمح لك بتكوين الأساليب البحثية المستخدمة. في LLVM ، يحتوي كل مقطع تقريبًا على العديد من الخيارات المخفية التي يمكن أن تؤثر على تشغيله ، ويمكن استخدامها إما باستخدام علامة –mllvm عند استدعاء clang ، أو في opt opt. ومع ذلك ، يتم إخفاء هذه المجموعة المتنوعة من الأعلام خلف الخيارات الأكثر استخدامًا والتي تحتوي على العديد من الإعدادات في وقت واحد وعادة ما تسمى مستويات التحسين. بالنسبة إلى برامج التحويل البرمجي C / C ++ ، هذه معروفة لمعظم -O1 ، -O2 ، -O3 لتحسين وقت التشغيل و -Os لتحسين حجم الرمز. ولكن لسوء الحظ ، لا تكون النتيجة هي الكود الأمثل دائمًا (يمكن لخبراء المجمّع إعادة كتابة الكود الذي تم إنشاؤه بأفضل طريقة) ، يعتمد الكثير على الكود المصدري بلغة عالية المستوى أو بنية المعالج أو ميزات اللغة ، إلخ.

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

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

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

البحوث والحلول الحالية

بطبيعة الحال ، كانت مشكلة الاختيار الآلي لخيارات التجميع موضع اهتمام الباحثين لسنوات عديدة. أحد أكثر المشاريع شهرة هو تطوير G. Fursin والباحثين من فريق MILEPOST GCC الخاص به ، والذي هو نسخة من برنامج التحويل البرمجي gcc الذي يمكنه تحديد مسارات النجاح على أساس التدريب السابق على عينة البيانات التي تم الحصول عليها. في هذا العمل ، استخدمنا مجموعة من 55 خاصية لحل المشكلة ونموذج بسيط إلى حد ما يعتمد على فكرة توزيع حلول جيدة تستند إلى خوارزمية K لأقرب الجيران. لقد كان هذا التطور هو الذي أظهر أن تمريرات تحسين التوليف يمكن أن تؤدي إلى رمز يساوي ضعف سرعة الكود الذي تم الحصول عليه باستخدام خيار التحسين الأقصى القياسي -O3.

هناك أيضًا دراسات قام بها G. Pekhimenko و A.D. Brown لـ TPO من IBM ( Optimizer Portable Toronto ). كانت مهمتهم الرئيسية هي اختيار القيم القابلة للاختيار من الناحية الاسترشادية للتحسينات ومجموعة التحويلات البرمجية ذاتها. للتنفيذ ، تم استخدام الانحدار اللوجستي ، مما جعل من الممكن إعداد غرامات فعالة للتدريب بشكل أسرع. تم بناء المصنف في ماتلاب. تم احتساب احتمال الاستخدام لكل تمريرة ، وتم استخدامه إذا كان أكثر من 50٪. كنتيجة للخاصية التي حاولوا تقليلها في هذه الدراسة ، كان وقت التجميع الثابت.

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

هناك أيضًا دراسات قام بها M. Stephenson و S. Amarasinge لاختيار تحسينات لبعض الخوارزميات المهمة بشكل خاص (تخصيص السجلات ، إعداد البيانات ، HYPERBLOCK FORMATION). لكل وظيفة ، تم استخدام خصائصها وفقا لذلك. بالنسبة للحل ، تم استخدام خوارزمية جينية. تم إجراء اختبار للمنتج المطوَّر في برنامج Open Research Compiler (ORC).

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

أحد الأبحاث المرتبطة مباشرة بـ LLVM هو LLVMTuner ، وهو منتج برمجي تم تطويره في جامعة إلينوي بواسطة إ. شين و دبليو آدوي. في عام 2017 ، تم تقديم تقرير يصف النتائج المتاحة في ذلك الوقت. في هذا العمل ، قمنا بتحسين الدورات الفردية "الساخنة". تم تصميم هذا الإطار للتكوين الآلي للبرامج الكبيرة. يعمل LLVMTuner على الوسيطة LLVM IR ، ويستخدم التوصيف لتحديد الحلقات الساخنة ، ثم يقوم تلقائيًا بضبط الاستدلال لهم. ينصب التركيز على دورات المستوى الأعلى. يتم نقل الدورات المحددة وأي وظائف اتصال إلى وحدة منفصلة ، والتي تخضع لمزيد من التحسينات اللازمة. يتيح لك هذا الحل الحصول على أداء محسّن في البرامج الكبيرة.

المشاكل الحالية

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

نظرًا لأن تطوير المجمعين يجب أن يكون فعالًا ومجديًا في وقت قصير إلى حد ما ، فمن الطبيعي أن تقوم الشركات الكبيرة بتطوير المجمعين الصناعيين على أساس حلول جاهزة. يمكن تقسيم معظم الحلول الحديثة إلى فئتين: التشغيل على الأجهزة الظاهرية ، على سبيل المثال ، المجمعين JVM - JIT ، والمترجمين المعتمدين على LLVM ، وهو نظام يقوم بتطبيق جهاز ظاهري بتعليمات تشبه RISC - برامج تجميع ثابتة وديناميكية. بالطبع ، لا تزال هناك حلول خاصة بالشركات ، لكنها أصبحت أقل قدرة على المنافسة بسبب عدم وجود مجتمع كبير يشارك في تطوير التقنيات المستخدمة فيها. نتيجة لذلك ، تستخدم العديد من الشركات الكبرى مثل Google و Apple و Adobe و ARM LLVM لتطوير حلولها الخاصة. بالطبع ، تظل gcc هي المترجم الرئيسي لـ C / C ++ ، توجد حلول أخرى للغات الأخرى ، ولكن على أي حال ، على سبيل المثال ، إذا تم العثور على حل لل LLVM ، فسوف يغطي بالفعل جزءًا لائقًا من المترجمين الحاليين حاليًا.

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

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

• AST مقرها الواجهة الأمامية التجزئة
• الأرقام الفريدة المعينة في تحليل الواجهة الأمامية
• تم إنشاء رقم 64 بت على أساس الأقواس في CFG (الرسم البياني لتدفق التحكم) باستخدام المجموع الاختباري (على غرار PGO (تحسين التوجيه الشخصي) في LLVM)

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

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



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

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