المساهمة في OpenXLA

يمكن للجميع المساهمة في OpenXLA، ونحن نقدّر مساهمات الجميع. تتوفّر عدة طرق للمساهمة، بما في ذلك:

• الإجابة عن الأسئلة في منتديات المناقشة في OpenXLA (openxla-discuss)

• تحسين مستندات OpenXLA أو توسيع نطاقها

• المساهمة في قاعدة رموز OpenXLA

• المساهمة بأي من الطرق المذكورة أعلاه في المنظومة المتكاملة الأوسع نطاقًا للمكتبات المستندة إلى OpenXLA

يتبع مشروع OpenXLA إرشادات المنتدى المفتوح المصدر من Google.

قبل البدء

توقيع "اتفاقية ترخيص المساهم"

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

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

انتقِل إلى <https://cla.developers.google.com/> للاطّلاع على اتفاقياتك الحالية أو لتوقيع اتفاقية جديدة.

مراجعة "مدوّنة السلوك"

يتبع هذا المشروع مدوّنة السلوك في Tensorflow.

عملية المساهمة

دليل المطوِّر

للحصول على دليل حول كيفية إعداد بيئة تطوير OpenXLA، بما في ذلك الحصول على الرمز البرمجي وإنشائه وتشغيل الاختبارات وإرسال التغييرات، يُرجى الرجوع إلى دليل المطوّرين.

دليل المساهمة

تتألف بنية المترجم البرمجي من المكوّنات التالية.

عمليات التحسين

تنفّذ عمليات التحسين عمليات تحويل على HLO لتحسين كفاءة الحوسبة. وتتراوح هذه التحسينات بين تحسينات عامة لا تعتمد على بنية معيّنة، وتعديلات خاصة بالأجهزة (مثل وحدات معالجة الرسومات من NVIDIA).

المحتوى الذي نقبله بشكل عام:

• اختبارات تجتازها معظم أحمال العمل وتُظهر تأثيرًا إيجابيًا واضحًا وكبيرًا في مقاييس الأداء.

المحتوى الذي نرفضه عادةً:

• عمليات تحسين فريدة تستهدف طُرزًا معيّنة.

بطاقات الدمج

الدمج هو عملية تحسين مهمة تجمع بين عمليات HLO متعددة في نواة واحدة لتقليل عمليات الإدخال والإخراج في الذاكرة وتكاليف بدء تشغيل النواة.

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

لا يُسمح بدمج المكالمات المخصّصة، أي المكالمات المخصّصة التي تتطابق مع الأنماط مع المنتجين/المستهلكين وإعادة كتابتها في المكالمات المخصّصة الجديدة. في هذه الحالة، يجب استبدالها بتمريرة دمج مناسبة.

التوسّع الأفقي

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

نحن نعطي الأولوية للتغييرات الأقل تدخّلاً والتي تنطوي على مخاطر منخفضة.

المحتوى الذي نقبله بشكل عام:

• تعديلات على المكتبات التي تتعامل مع الاتصال بين وحدات معالجة الرسومات أو بين المضيفين

• تعديلات على جدول الأداء للمنصات الجديدة

المحتوى الذي نرفضه عادةً:

• عمليات إعادة كتابة HLO أو تغييرات وقت التشغيل المخصّصة لنموذج معيّن

• التغييرات في البنية الأساسية التي تؤدي إلى ظهور علامات جديدة أو ديون فنية أو تراجعات

الأنظمة الخلفية والضبط التلقائي

يجب أن تنفّذ الخلفيات للعمليات غير المتداخلة، مثل عمليات الدمج والاتصالات المخصّصة، واجهة CodegenBackend .

هذه الواجهة ضرورية لتفعيل اختيار الخلفية المثلى، لأنّها توفّر الطرق اللازمة لتضمين المَعلمات الخاصة بتعليمات HLO المحدّدة في مساحة البحث الخاصة بأداة التحسين التلقائي.

// Returns all supported configs for the given HLO instruction.
virtual absl::StatusOr<std::vector<std::unique_ptr<BackendConfig>>>
  GetSupportedConfigs(const HloInstruction& instr);

// Returns a default config for the given HLO instruction.
virtual absl::StatusOr<std::unique_ptr<BackendConfig>> GetDefaultConfig(
  const HloInstruction& instr);

وقت التشغيل

النتيجة النهائية لعملية تجميع XLA هي تسلسل ثنائي يمكن تسلسله.

يجب أن تكون جميع أنواع thunk الجديدة قابلة للتسلسل، أي يجب أن يتمكّن GpuCompiler أو CpuCompiler من تجميع البرنامج وتسلسله، ليتمكّن مشغّل XLA لاحقًا من تحميل البرنامج وتنفيذه. وهذا يعني أنّه يجب ألا تكون هناك أي مؤشرات إلى HloInstruction أو إلى أجزاء أخرى من المترجم أو StreamExecutor.

معايير الرمز

• نمط الترميز: نتّبع دليل نمط الترميز من Google. يمكنك الاطّلاع تحديدًا على دليلَي C/C++‎ وPython. يجب أن يتوافق كل رمز يتم إرساله بدقة مع أدلة الأسلوب هذه.

• التغييرات المدمجة: نتّبع ممارسات Google الهندسية. على وجه الخصوص، يُرجى الالتزام بالدليل حول كتابة التغييرات الموجزة. سيؤدي ذلك إلى زيادة كبيرة في سرعة دمج الرمز البرمجي بسبب تحسين إمكانية المراجعة، وتقليل احتمالية حدوث آثار جانبية غير مقصودة للتغيير. حتى إذا كان لديك تغيير كبير، هناك العديد من الاستراتيجيات لتقسيمه إلى تغييرات أكثر تدريجية.

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

  يجب أن تتضمّن جميع التغييرات نتائج قياس الأداء المناسبة في عنوان التغيير لضمان فهم الفوائد بوضوح.

• عند الشك في الاتفاقيات المتّبعة داخل الرمز، من المستحسن دائمًا فحص الرمز الحالي ومحاولة اتّباع الأنماط المتّبعة في OpenXLA.

عملية المراجعة

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

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

• يجب اجتياز جميع الاختبارات. إذا تبيّن لك أنّ أحد الاختبارات معطّل وأنّ المشكلة لا ترتبط ببيئة الإصدار أو تغييراتك، يُرجى التواصل مع المشرفين.

• حاوِل تجنُّب اتساع نطاق المراجعة أثناء عملية المراجعة. وتقع هذه المسؤولية على كلّ من مقدّم الطلب والمراجع. إذا بدأ التغيير يصبح كبيرًا جدًا، ننصحك بتقسيمه إلى عدة تغييرات.

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

الأسئلة الشائعة

"هذا التغيير في البنية الأساسية لا صلة له بطلبي. لماذا يجب أن أفعل ذلك؟"

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

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

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

"هل يمكنني الردّ على تعليقك في بيان صحفي مستقبلي؟"

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

بشكل عام، لا تسمح XLA لمؤلفي طلبات الدمج بمعالجة تعليقات المراجعة من خلال طلب دمج لاحق. عندما يقرّر المراجع أنّه يجب معالجة مشكلة في طلب سحب معيّن، نتوقّع بشكل عام أن يعالج المؤلّفون هذه المشكلة في طلب السحب هذا، حتى لو كان التغيير المطلوب كبيرًا. ينطبق هذا المعيار خارجيًا وداخليًا في Google.

هناك بضعة أسباب تجعل XLA تتّبع هذا النهج.

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

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

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