אנחנו צוות Android LLVM toolchain. אחד מהיעדים העיקריים שלנו הוא לשפר את הביצועים של Android באמצעות טכניקות אופטימיזציה במערכת האקולוגית של LLVM. אנחנו מחפשים כל הזמן דרכים להפוך את Android למהירה, חלקה ויעילה יותר. רוב עבודת האופטימיזציה שלנו מתבצעת במרחב המשתמש, אבל ליבת המערכת היא עדיין הלב של המערכת. היום אנחנו שמחים לשתף איך אנחנו מביאים את Automatic Feedback-Directed Optimization (AutoFDO) לליבת Android כדי לספק למשתמשים שיפורים משמעותיים בביצועים.

מה זה AutoFDO?

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

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

כדי להבין את ההשפעה של האופטימיזציה הזו, כדאי לעיין בעובדות העיקריות הבאות:

• ב-Android, הליבה אחראית לכ-40% מזמן ה-CPU.
• אנחנו כבר משתמשים ב-AutoFDO כדי לבצע אופטימיזציה של קובצי הפעלה וספריות מקומיים במרחב המשתמש, ומשיגים שיפור של כ-4% בהפעלת אפליקציות במצב 'הפעלה קרה' וקיצור של 1% בזמן האתחול.

שיפורים בביצועים בעולם האמיתי

השגנו שיפורים מרשימים במדדים מרכזיים של Android באמצעות פרופילים מסביבות מעבדה מבוקרות. הפרופילים האלה נאספו באמצעות סריקה והפעלה של אפליקציות, ונמדדו במכשירי Pixel עם ליבות 6.1,‏ 6.6 ו-6.12.

בהמשך מפורטים השיפורים הבולטים ביותר. פרטים על פרופילי AutoFDO לגרסאות הליבה האלה זמינים במאגרי ליבת Android המתאימים לליבות android16-6.12 ו-android15-6.6.

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

איך זה עובד: הצינור

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

שלב 1: איסוף פרופילים

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

• כלים וסביבה: אנחנו מבצעים פלאשינג למכשירי בדיקה עם תמונת הליבה העדכנית ומשתמשים ב-simpleperf כדי לתעד זרמי ביצוע של הוראות. התהליך הזה מסתמך על יכולות החומרה כדי לתעד את היסטוריית ההתפצלות, ובאופן ספציפי על  ARM Embedded Trace Extension (ETE) ועל ARM Trace Buffer Extension (TRBE) במכשירי Pixel.
• עומסי עבודה: אנחנו יוצרים עומס עבודה מייצג באמצעות 100 האפליקציות הפופולריות ביותר מתוך חבילת הבדיקות של תאימות אפליקציות ל-Android‏ (C-Suite). כדי לקבל את הנתונים הכי מדויקים, אנחנו מתמקדים ב:
  • הפעלת אפליקציות: אופטימיזציה של עיכובים בהצגת האפליקציה למשתמשים
  • סריקת אפליקציות מבוססת-AI: הדמיה של אינטראקציות רציפות ומתפתחות של משתמשים
  • מעקב בכל המערכת: תיעוד לא רק של פעילויות באפליקציה שפועלת בחזית, אלא גם של עומסי עבודה קריטיים ברקע ותקשורת בין תהליכים
• אימות: עומס העבודה המסונתז הזה מציג דמיון של 85% לדפוסי ביצוע שנאספו מהצי הפנימי שלנו.
• נתונים ממוקדים: על ידי חזרה על הבדיקות האלה מספיק פעמים, אנחנו מצליחים לתעד דפוסי ביצוע ברמת דיוק גבוהה שמייצגים בצורה מדויקת את האינטראקציה של משתמשים בעולם האמיתי עם האפליקציות הפופולריות ביותר. בנוסף, המסגרת הניתנת להרחבה הזו מאפשרת לנו לשלב בצורה חלקה עומסי עבודה ונקודות השוואה נוספים כדי להרחיב את הכיסוי שלנו.

שלב 2: עיבוד הפרופיל

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

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

שלב 3: בדיקת הפרופיל

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

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

עדכונים רציפים

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

• רענון רגיל: אנחנו מרעננים את הפרופילים בענפי LTS של ליבת Android לפני כל מהדורה של GKI, כדי לוודא שכל בנייה כוללת את נתוני הפרופיל העדכניים ביותר.
• הרחבה עתידית: אנחנו מפיצים כרגע את העדכונים האלה בענפים android16-6.12 ו-android15-6.6, ונרחיב את התמיכה לגרסאות חדשות יותר של GKI, כמו android17-6.18 שיושק בקרוב.

שמירה על יציבות

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

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

מבט לעתיד

אנחנו פורסים כרגע את AutoFDO בענפים android16-6.12 ו-android15-6.6. בנוסף להשקה הראשונית הזו, אנחנו רואים כמה דרכים מבטיחות לשיפור נוסף של הטכנולוגיה:

• היקף רחב יותר: אנחנו מתכננים לפרוס פרופילים של AutoFDO בגרסאות חדשות יותר של ליבת GKI וביעדי בנייה נוספים מעבר לתמיכה הנוכחית ב-aarch64.
• אופטימיזציה של מודול GKI: כרגע, האופטימיזציה שלנו מתמקדת בקובץ הבינארי הראשי של הליבה (vmlinux). הרחבת AutoFDO למודולים של GKI יכולה להניב שיפורים בביצועים של חלק גדול יותר ממערכת המשנה של הליבה.
• תמיכה במודולים של ספקים: אנחנו גם מעוניינים לתמוך ב-AutoFDO במודולים של ספקים שנבנו באמצעות ערכת הכלים לפיתוח דרייברים (DDK). התמיכה כבר זמינה במערכת build שלנו (Kleaf) ובכלי הפרופילים (simpleperf), כך שהספקים יכולים להחיל את אותן טכניקות אופטימיזציה על מנהלי ההתקנים הספציפיים של החומרה שלהם.
• כיסוי רחב יותר של פרופילים: יש פוטנציאל לאיסוף פרופילים ממגוון רחב יותר של מסלולים קריטיים להמרת לקוח (CUJ) כדי לבצע אופטימיזציה שלהם.

הוספנו את AutoFDO לליבת Android כדי לוודא שהבסיס של מערכת ההפעלה מותאם לאופן שבו אתם משתמשים במכשיר שלכם מדי יום.