תרומה ל-OpenXLA

כל אחד יכול לתרום ל-OpenXLA, ואנחנו מעריכים את התרומה של כולם. יש כמה דרכים להוסיף תוכן, כולל:

• מענה על שאלות בפורומים לדיונים של OpenXLA ‏ (openxla-discuss)

• שיפור או הרחבה של התיעוד של OpenXLA

• תרומה לבסיס הקוד של OpenXLA

• תרומה לאקוסיסטם הרחב יותר של ספריות שמבוססות על OpenXLA באחת מהדרכים שלמעלה

פרויקט OpenXLA פועל בהתאם להנחיות הקהילה של Google בנושא קוד פתוח.

לפני שמתחילים

חתימה על הסכם הרישיון של Contributor

כל התוכן שמועלה לפרויקט הזה חייב להיות מלווה בהסכם רישיון ליוצרים (CLA). אתם (או המעסיק שלכם) שומרים על זכויות היוצרים של התוכן שאתם תורמים. אנחנו מקבלים מכם רק הרשאה להשתמש בתוכן הזה ולהפיץ אותו מחדש כחלק מהפרויקט.

אם אתם או המעסיק הנוכחי שלכם כבר חתמתם על Google CLA (גם אם זה היה עבור פרויקט אחר), כנראה שלא תצטרכו לעשות זאת שוב.

בכתובת <https://cla.developers.google.com/> אפשר לראות את ההסכמים הנוכחיים או לחתום על הסכם חדש.

קוראים את קוד ההתנהגות

הפרויקט הזה פועל בהתאם לקוד ההתנהגות של TensorFlow.

תהליך התרומה

מדריך למפתחים

במדריך למפתחים מוסבר איך להגדיר סביבת פיתוח ל-OpenXLA, כולל קבלת קוד, יצירה, הפעלת בדיקות ושליחת שינויים.

מדריך להוספת תוכן

ארכיטקטורת הקומפיילר מורכבת מהרכיבים הבאים.

שלבי אופטימיזציה

שלבי האופטימיזציה מבצעים טרנספורמציות ב-HLO כדי לשפר את היעילות החישובית. השינויים האלה כוללים שיפורים כלליים שלא תלויים בארכיטקטורה, וגם התאמות ספציפיות לחומרה (למשל, עבור מעבדי GPU של NVIDIA).

מה אנחנו בדרך כלל מקבלים:

• הצלחה בבדיקות שמוכללות במגוון עומסי עבודה ומדגימות השפעה חיובית ברורה ומשמעותית על מדדי הביצועים.

מה אנחנו בדרך כלל דוחים:

• שלבים שמבצעים אופטימיזציות ייחודיות שמטרתן מודלים ספציפיים.

כרטיסי פיוז'ן

מיזוג הוא אופטימיזציה קריטית שמשלבת כמה פעולות HLO לתוך ליבה אחת כדי לצמצם את קלט/פלט הזיכרון ואת התקורה של הפעלת הליבה.

צריך להוסיף את כל כרטיסי המיזוג רק לצינור המיזוג, לא לפני או אחרי. המשמעות היא שקוד המודול של HLO שעבר אופטימיזציה מראש לא צריך להכיל הוראות מיזוג. אם המיזוג מתבצע בשלב מוקדם בצינור העיבוד, הוא הופך למחסום עבור שלבי האופטימיזציה. אם המיזוג מתבצע בשלב מאוחר, אנחנו מאבדים את היכולת לבחור את הקצה העורפי ולכוונן אותו עבור המיזוג שנוצר.

אסור למזג את השיחות המותאמות אישית, כלומר שיחות מותאמות אישית של התאמת תבניות עם producers/consumers ולשכתב אותן לשיחות המותאמות אישית החדשות. במקרה כזה, צריך להחליף אותו בכרטיס מיזוג תקין.

שינוי גודל אופקי

התרומות להרחבה אופקית כוללות אופטימיזציות של HLO, שיפורים במודל העלויות, עדכונים בספרייה ושינויים שונים בתשתית. בגלל הקושי לשחזר את שיפורי הביצועים והצורך המוגבל בהגדרות של כמה מארחים באופן פנימי, אנחנו מקפידים על קריטריונים מחמירים לאישור:

אנחנו נותנים עדיפות לשינויים שההשפעה שלהם מינימלית והסיכון שלהם נמוך.

מה אנחנו בדרך כלל מקבלים:

• עדכונים בספריות שמטפלות בתקשורת בין מעבדי GPU או בין מארחים.

• עדכונים בטבלת הביצועים לפלטפורמות חדשות.

מה אנחנו בדרך כלל דוחים:

• שינויים בזמן ריצה או שינויים ב-HLO שמותאמים למודל ספציפי.

• שינויים בתשתית שמוסיפים דגלים חדשים, חוב טכני או רגרסיות.

מערכות עורפיות וכוונון אוטומטי

מערכות עורפיות (Backend) לפעולות לא מקוננות, כמו קריאות מותאמות אישית ומיזוגים, צריכות להטמיע את הממשק 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 שאפשר לבצע בהן סריאליזציה.

כל סוגי ה-thunk החדשים צריכים להיות ניתנים לסריאליזציה, כלומר GpuCompiler או CpuCompiler צריכים להיות מסוגלים לקמפל את התוכנית, לבצע סריאליזציה שלה, כדי שבהמשך רכיב ה-XLA runner יוכל לטעון ולהריץ את התוכנית. כלומר, לא אמורים להיות מצביעים ל-HloInstruction או לחלקים אחרים של הקומפיילר או של StreamExecutor.

תקני קוד

• סגנון כתיבת הקוד: אנחנו פועלים לפי המדריך של Google לסגנון כתיבת קוד. כדאי לעיין במדריכים בנושא C/C++‎ ו-Python. כל הקוד שנשלח חייב לעמוד בדרישות של מדריכי הסגנון האלה.

• שינויים קומפקטיים: אנחנו פועלים בהתאם לשיטות העבודה המומלצות של Google בתחום ההנדסה. כדאי לקרוא באופן ספציפי את המדריך לכתיבת שינויים קומפקטיים. הפעולה הזו תגדיל משמעותית את המהירות שבה הקוד שלכם יכול להתמזג, כי היא משפרת את היכולת לבדוק את הקוד ומפחיתה את הסיכוי לתופעות לוואי לא מכוונות של השינוי. גם אם אתם רוצים לבצע שינוי גדול, יש הרבה אסטרטגיות שיעזרו לכם לחלק אותו לשינויים מצטברים קטנים יותר.

• כיסוי הבדיקות: כל השינויים צריכים לכלול בדיקות יחידה מתאימות. בדיקות יחידה לא צריכות להיות תלויות בתזמונים ספציפיים של חומרה (מעבד, מעבד גרפי וכו'), וצריך להשתמש בהן באופן נרחב ב-mocks וב-fakes כדי לבצע בדיקות דטרמיניסטיות וממוקדות. שינויים שמטרתם להרחיב קוד קיים שקשה לבדוק אותו כרגע, צריכים לשפר את יכולת הבדיקה שלו.

  כל השינויים צריכים לכלול גם תוצאות מתאימות של השוואה לשוק בשם השינוי, כדי להבטיח שהיתרונות יהיו ברורים.

• אם יש לכם ספק לגבי המוסכמות בקוד, תמיד מומלץ לבדוק קוד קיים ולנסות לפעול לפי הדפוסים שכבר קיימים ב-OpenXLA.

תהליך הבדיקה

כל ההצעות, כולל הצעות של חברי הפרויקט, דורשות בדיקה. לשם כך, אנחנו משתמשים בבקשות משיכה ב-GitHub. מידע נוסף על שימוש בבקשות משיכה זמין במאמרי העזרה של GitHub.

• לפני הבדיקה, הקוד צריך לעמוד בכל התקנים שמפורטים למעלה. השינויים האלה לא אופציונליים, ולכן חשוב מאוד שהשולח יוודא שהקוד שלו תואם לפני שהוא מבקש בדיקה, כדי להבטיח שהשינויים יתקבלו בזמן.

• כל הבדיקות חייבות לעבור. אם אתם מגלים שהבדיקה לא תקינה והבעיה לא קשורה לסביבת ה-build או לשינויים שביצעתם, עליכם לפנות למנהלים.

• כדאי להימנע מהרחבת היקף הפרויקט במהלך תהליך הבדיקה. זו האחריות של שולח הבקשה ושל הבודק. אם שינוי מסוים מתחיל להיות גדול מדי, כדאי לפצל אותו לכמה שינויים.

• לפני ששינוי ימוזג, הוא יעבור בדיקות פנימיות שמשתמשות בקוד פנימי של Google ושל ספקי חומרה אחרים. אם יש כשלים בבדיקות פנימיות שלא זוהו על ידי ה-CI הציבורי שלנו, יכול להיות שיידרשו שלבים נוספים בתהליך הבדיקה. העובד של Google שבודק את השינוי יעדכן אותך לגבי כל כשל בבדיקה הפנימית ויסביר מה צריך לתקן.

שאלות נפוצות

"השינוי בתשתית לא קשור ליחסי הציבור שלי. למה כדאי לי לעשות את זה?"

לצוות XLA אין צוות תשתית ייעודי, ולכן כולנו צריכים לבנות ספריות עזר ולהימנע מחוב טכני. אנחנו רואים בזה חלק רגיל בתהליך השינויים ב-XLA, וכולם צפויים להשתתף. בדרך כלל אנחנו בונים תשתית לפי הצורך כשכותבים קוד.

יכול להיות שהבודקים של XLA יבקשו מכם ליצור תשתית מסוימת (או לבצע שינוי גדול בבקשת משיכה) בנוסף לבקשת משיכה שכתבתם. יכול להיות שהבקשה הזו תיראה לכם מיותרת או לא קשורה לשינוי שאתם מנסים לבצע. הסיבה לכך היא כנראה חוסר התאמה בין הציפיות שלכם לגבי כמות התשתית שאתם צריכים לבנות לבין הציפיות של הבודק לגבי אותה כמות.

זה בסדר אם יש פער בין הציפיות שלכם לבין מה שקורה בפועל. זה צפוי כשמצטרפים לפרויקט חדש (ולפעמים זה קורה גם לנו, הוותיקים). יכול להיות שלפרויקטים שעבדתם עליהם בעבר היו ציפיות שונות. זה גם בסדר וצפוי. זה לא אומר שאחד מהפרויקטים האלה מבוסס על גישה שגויה, אלא שהגישות פשוט שונות. אנחנו מזמינים אותך להתייחס לבקשות בנושא תשתית לצד כל שאר ההערות לבדיקה כהזדמנות ללמוד מה אנחנו מצפים בפרויקט הזה.

"אפשר להתייחס לתגובה שלך ב-PR עתידי?"

שאלה נפוצה לגבי בקשות לתשתית (או בקשות גדולות אחרות) ב-PR היא אם השינוי חייב להתבצע ב-PR המקורי, או שאפשר לבצע אותו כמעקב ב-PR עתידי.

באופן כללי, ב-XLA אסור לכותבי בקשות למיזוג להגיב על הערות בביקורת באמצעות בקשה למיזוג המשך. כשבודק מחליט שצריך לטפל במשהו בבקשת מיזוג מסוימת, בדרך כלל אנחנו מצפים מהמחברים לטפל בבעיה בבקשת המיזוג הזו, גם אם מדובר בשינוי גדול. התקן הזה חל על גורמים חיצוניים וגם על גורמים פנימיים ב-Google.

יש כמה סיבות לכך ש-XLA פועל בגישה הזו.

• אמון: חשוב מאוד שהכותב ייתן בכם אמון. בפרויקט קוד פתוח, התורמים יכולים להופיע או להיעלם כרצונם. אחרי שאנחנו מאשרים בקשת משיכה, אין לבוחנים דרך לוודא שפעולות ההמשך שהובטחו אכן מתבצעות.

• השפעה על מפתחים אחרים: אם שלחתם בקשת מיזוג שמשפיעה על חלק מסוים ב-XLA, יש סיכוי טוב שאנשים אחרים בודקים את אותו חלק. אם נאשר את החוב הטכני בבקשת משיכת השינויים, כל מי שיעיין בקובץ הזה יושפע מהחוב הזה עד שנשלח את המעקב.

• עומס עבודה על הבודקים: דחיית שינוי לטיפול בהמשך מטילה על הבודקים שלנו, שכבר עמוסים בעבודה, עלויות רבות. בזמן ההמתנה לבדיקה הבאה, בודקים כנראה ישכחו על מה היה ה-PR הראשון, ולכן הבדיקה הבאה תהיה קשה יותר. בנוסף, הבודקים צריכים לעקוב אחרי פעולות ההמשך הצפויות ולוודא שהן מתבצעות בפועל. אם אפשר לבצע את השינוי כך שהוא יהיה אורתוגונלי באמת לבקשת ה-PR המקורית, כדי שבודק אחר יוכל לבדוק אותו, רוחב הפס יהיה פחות בעייתי. מהניסיון שלנו, זה קורה לעיתים רחוקות.