همه میتوانند در OpenXLA مشارکت کنند و ما برای مشارکت همه ارزش قائلیم. روشهای مختلفی برای مشارکت وجود دارد، از جمله:
پاسخ به سوالات در انجمنهای گفتگوی OpenXLA (openxla-discuss)
بهبود یا گسترش مستندات OpenXLA
مشارکت در کدبیس OpenXLA
مشارکت به هر یک از روشهای فوق در اکوسیستم گستردهتر کتابخانههای ساخته شده بر روی OpenXLA
پروژه OpenXLA از دستورالعملهای انجمن متنباز گوگل پیروی میکند.
قبل از اینکه شروع کنی
توافقنامه مجوز مشارکتکننده را امضا کنید
مشارکتها در این پروژه باید با یک توافقنامه مجوز مشارکتکننده (CLA) همراه باشد. شما (یا کارفرمای شما) حق چاپ مربوط به مشارکت خود را حفظ میکنید؛ این به ما اجازه میدهد تا از مشارکتهای شما به عنوان بخشی از پروژه استفاده و توزیع مجدد کنیم.
اگر شما یا کارفرمای فعلیتان قبلاً توافقنامه همکاری گوگل (CLA) را امضا کردهاید (حتی اگر برای پروژه دیگری بوده باشد)، احتمالاً نیازی به انجام دوباره آن ندارید.
برای مشاهده توافقنامههای فعلی خود یا امضای توافقنامه جدید، به < https://cla.developers.google.com/ > مراجعه کنید.
بررسی آییننامه رفتاری
این پروژه از اصول اخلاقی Tensorflow پیروی میکند.
فرآیند مشارکت
راهنمای توسعهدهنده
برای راهنمایی در مورد نحوه راهاندازی یک محیط توسعه برای OpenXLA، شامل دریافت کد، ساخت آن، اجرای تستها و ارسال تغییرات، لطفاً به راهنمای توسعهدهندگان مراجعه کنید.
راهنمای مشارکت
معماری کامپایلر از اجزای زیر تشکیل شده است.
مراحل بهینهسازی
بهینهسازی، تبدیلات را روی HLO اجرا میکند تا کارایی محاسباتی را افزایش دهد. این تبدیلات از بهبودهای سطح بالای معماری تا تنظیمات خاص سختافزار (مثلاً برای پردازندههای گرافیکی NVIDIA) را شامل میشود.
آنچه ما عموماً میپذیریم:
- گذرهایی که در چندین حجم کاری تعمیم داده میشوند و تأثیر مثبت واضح و قابل توجهی بر معیارهای عملکرد نشان میدهند.
آنچه ما عموماً رد میکنیم:
- پاسهایی که بهینهسازیهای منحصر به فردی را با هدف قرار دادن مدلهای خاص انجام میدهند.
عبورهای فیوژن
فیوژن یک بهینهسازی حیاتی است که چندین عملیات HLO را در یک هسته واحد ترکیب میکند تا سربار ورودی/خروجی حافظه و راهاندازی هسته را کاهش دهد.
تمام مراحل ادغام باید فقط به خط لوله ادغام اضافه شوند، نه قبل یا بعد از آن. این همچنین بدان معنی است که ماژول HLO از پیش بهینه شده نباید حاوی دستورالعملهای ادغام باشد. اگر ادغام در اوایل خط لوله شکل بگیرد، به مانعی برای مراحل بهینهسازی تبدیل میشود. اگر ادغام دیر شکل بگیرد، ما توانایی انتخاب و تنظیم backend برای ادغام تولید شده را از دست میدهیم.
ادغام در فراخوانیهای سفارشی، یعنی تطبیق الگو با فراخوانیهای سفارشی تولیدکنندگان/مصرفکنندگان و بازنویسی آنها در فراخوانیهای سفارشی جدید مجاز نیست. در این صورت، باید با یک گذر ادغام مناسب جایگزین شود.
مقیاسبندی افقی
مشارکتها در مقیاسبندی افقی شامل بهینهسازیهای HLO، بهبود مدل هزینه، بهروزرسانیهای کتابخانه و اصلاحات مختلف زیرساخت میشود. با توجه به دشواری بازتولید دستاوردهای عملکرد و نیاز محدود به پیکربندیهای چند میزبانه داخلی، ما به معیارهای پذیرش سختگیرانهای پایبند هستیم:
ما تغییرات کمتهاجمی که ریسک پایینی دارند را در اولویت قرار میدهیم.
آنچه ما عموماً میپذیریم:
بهروزرسانیهایی برای کتابخانههایی که ارتباطات بین پردازندههای گرافیکی یا بین میزبانها را مدیریت میکنند.
بهروزرسانیهای جدول عملکرد برای پلتفرمهای جدید.
آنچه ما عموماً رد میکنیم:
بازنویسیهای HLO یا تغییرات زمان اجرا متناسب با یک مدل خاص.
تغییرات زیرساختی که باعث ایجاد مشکلات جدید، بدهی فنی یا پسرفت میشوند.
بکاندها و تنظیم خودکار
بکاندهای مربوط به عملیاتهای غیرتودرتو، مانند فراخوانیها و ادغامهای سفارشی، باید رابط CodegenBackend را پیادهسازی کنند.
این رابط برای فعال کردن انتخاب بهینه backend ضروری است، زیرا روشهایی را برای گنجاندن پارامترهای دستورالعملهای HLO داده شده در فضای جستجوی autotuner فراهم میکند.
// 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 است که میتواند سریالی شود.
همه انواع جدید thunk باید قابلیت سریالی شدن داشته باشند، یعنی GpuCompiler یا CpuCompiler باید بتوانند برنامه را کامپایل و سریالی کنند، به طوری که بعداً اجراکننده XLA بتواند برنامه را بارگذاری و اجرا کند. این بدان معناست که نباید هیچ اشارهگری به HloInstruction یا سایر قسمتهای کامپایلر یا StreamExecutor وجود داشته باشد.
استانداردهای کد
سبک کدنویسی : ما از راهنمای سبک کد گوگل پیروی میکنیم. به طور خاص به راهنماهای C/C++ و Python مراجعه کنید. تمام کدهای ارسالی باید کاملاً با این راهنماهای سبک مطابقت داشته باشند.
تغییرات فشرده : ما از شیوههای مهندسی گوگل پیروی میکنیم. به طور خاص، لطفاً راهنمای نوشتن تغییرات فشرده را رعایت کنید. انجام این کار سرعت ادغام کد شما را به دلیل بهبود قابلیت بررسی و کاهش احتمال عوارض جانبی ناخواسته تغییر، تا حد زیادی افزایش میدهد. حتی اگر تغییر بزرگی داشته باشید، استراتژیهای زیادی برای تقسیم آن به تغییرات تدریجیتر وجود دارد.
پوشش تست : همه تغییرات باید شامل تستهای واحد مناسب باشند. تستهای واحد نباید به زمانبندی سختافزار خاص (CPU، GPU و غیره) وابسته باشند و باید از نمونههای آزمایشی (mocks) و جعلی (fakes) به طور آزادانه استفاده کنند تا تستهای قطعی و متمرکز انجام دهند. تغییراتی که به دنبال گسترش کد موجود هستند که در حال حاضر تست آنها دشوار است، باید بهبودهای مناسبی در قابلیت تست ایجاد کنند.
همه تغییرات باید شامل نتایج معیار مناسب و همچنین در عنوان تغییر باشند تا اطمینان حاصل شود که مزایا به وضوح درک شدهاند.
وقتی در مورد قراردادهای درون کد شک دارید، همیشه ایده خوبی است که کد از پیش موجود را بررسی کنید و سعی کنید الگوهای موجود در OpenXLA را دنبال کنید.
فرآیند بررسی
تمام موارد ارسالی، از جمله موارد ارسالی توسط اعضای پروژه، نیاز به بررسی دارند. ما برای این منظور از درخواستهای pull در گیتهاب استفاده میکنیم. برای اطلاعات بیشتر در مورد استفاده از درخواستهای pull، به راهنمای گیتهاب مراجعه کنید.
کد باید قبل از بررسی، تمام استانداردهای ذکر شده در بالا را رعایت کند. این موارد اختیاری نیستند و بسیار مهم است که ارسالکننده قبل از درخواست بررسی، از مطابقت کد خود با آنها اطمینان حاصل کند تا پذیرش به موقع تغییرات تضمین شود.
همه آزمایشها باید با موفقیت انجام شوند . اگر متوجه شدید که آزمایشی خراب است و مشکل به محیط ساخت شما یا تغییرات شما مربوط نمیشود، لطفاً با پشتیبانان تماس بگیرید.
سعی کنید در طول فرآیند بررسی از خزش دامنه (scope creep) جلوگیری کنید. این مسئولیت هم بر عهدهی ارسالکننده و هم بر عهدهی بررسیکننده است. اگر تغییری بیش از حد بزرگ شد، آن را به چندین تغییر تقسیم کنید.
قبل از ادغام یک تغییر، آن تغییر تحت آزمایش داخلی قرار میگیرد که از کد داخلی گوگل و سایر فروشندگان سختافزار استفاده میکند. این امر میتواند در صورت وجود نقص در آزمایشهای داخلی که CI عمومی ما آن را تشخیص نمیدهد، مراحل اضافی به فرآیند بررسی اضافه کند. گوگلری که تغییر شما را بررسی میکند، هرگونه نقص در آزمایش داخلی را گزارش میدهد و آنچه را که باید اصلاح شود، شرح میدهد.
سوالات متداول (FAQ)
«این تغییر زیرساخت ربطی به روابط عمومی من ندارد. چرا باید این کار را انجام دهم؟»
تیم XLA تیم زیرساخت اختصاصی ندارد، بنابراین ساخت کتابخانههای کمکی و جلوگیری از بدهی فنی به همه ما بستگی دارد. ما این را بخشی عادی از ایجاد تغییرات در XLA میدانیم و انتظار میرود همه در آن مشارکت کنند. ما معمولاً هنگام نوشتن کد، زیرساخت را در صورت نیاز ایجاد میکنیم.
داوران XLA ممکن است از شما بخواهند که علاوه بر PR که نوشتهاید، زیرساختهایی نیز بسازید (یا در غیر این صورت تغییر بزرگی در PR ایجاد کنید). این درخواست ممکن است غیرضروری یا متعامد با تغییری که میخواهید ایجاد کنید، به نظر برسد. این احتمالاً به دلیل عدم تطابق بین انتظارات شما در مورد میزان زیرساخت مورد نیاز برای ساخت و انتظارات داور شما در این مورد است.
عدم تطابق در انتظارات اشکالی ندارد! وقتی در یک پروژه تازهکار هستید، این انتظار میرود (و گاهی اوقات حتی برای ما که با هم کار میکنیم هم اتفاق میافتد). احتمالاً پروژههایی که در گذشته روی آنها کار کردهاید، انتظارات متفاوتی دارند. این هم اشکالی ندارد و قابل انتظار است! این به آن معنا نیست که هیچکدام از این پروژهها رویکرد اشتباهی دارند؛ آنها فقط متفاوت هستند. از شما دعوت میکنیم درخواستهای مادون قرمز را در کنار سایر نظرات بررسی، به عنوان فرصتی برای یادگیری انتظارات ما از این پروژه، بپذیرید.
«آیا میتوانم در مصاحبهی بعدیام به نظر شما پاسخ بدهم؟»
یک سوال رایج در رابطه با درخواستهای زیرساختی (یا سایر درخواستهای بزرگ) در PRها این است که آیا تغییر باید در PR اصلی انجام شود یا اینکه میتوان آن را به عنوان پیگیری در PR آینده انجام داد.
به طور کلی، XLA به نویسندگان PR اجازه نمیدهد که نظرات بررسی را با یک PR پیگیری کنند. وقتی یک داور تصمیم میگیرد که چیزی باید در یک PR مشخص مورد توجه قرار گیرد، ما معمولاً انتظار داریم نویسندگان آن را در آن PR مطرح کنند، حتی اگر آنچه درخواست شده تغییر بزرگی باشد. این استاندارد هم در خارج از گوگل و هم در داخل آن اعمال میشود.
چند دلیل وجود دارد که XLA این رویکرد را اتخاذ میکند.
اعتماد: جلب اعتماد داور یک جزء کلیدی است. در یک پروژه متنباز، مشارکتکنندگان میتوانند به دلخواه ظاهر یا ناپدید شوند. پس از تأیید PR توسط ما، داوران هیچ راهی برای اطمینان از انجام هرگونه پیگیری وعده داده شده ندارند.
تأثیر بر سایر توسعهدهندگان: اگر شما یک PR ارسال کردهاید که به بخش خاصی از XLA اشاره دارد، احتمال زیادی وجود دارد که افراد دیگری نیز در حال بررسی همان بخش باشند. اگر ما بدهی فنی را در PR شما بپذیریم، هر کسی که به این فایل نگاه میکند تا زمان ارسال پیگیری، تحت تأثیر این بدهی قرار خواهد گرفت.
پهنای باند بررسیکننده: به تعویق انداختن یک تغییر به یک پیگیری، هزینههای متعددی را به بررسیکنندگانی که از قبل هم با حجم کاری زیادی مواجه بودهاند، تحمیل میکند. بررسیکنندگان احتمالاً در حین انتظار برای پیگیری، فراموش میکنند که اولین PR در مورد چه چیزی بوده است و بررسی بعدی را دشوارتر میکند. همچنین، بررسیکنندگان باید پیگیریهای مورد انتظار را پیگیری کنند و مطمئن شوند که واقعاً اتفاق میافتند. اگر تغییر بتواند به گونهای ایجاد شود که واقعاً عمود بر PR اصلی باشد تا بررسیکننده دیگری بتواند آن را بررسی کند، پهنای باند مشکل کمتری ایجاد میکند. طبق تجربه ما، این مورد به ندرت اتفاق میافتد.