שיפור הביצועים ב-Android: הכירו את AutoFDO לליבה

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

מה זה AutoFDO?

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

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

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

• ב-Android, ליבת המערכת אחראית לכ-40% מזמן המעבד.
• אנחנו כבר משתמשים ב-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 כדי לוודא שהבסיס של מערכת ההפעלה מותאם לאופן שבו אתם משתמשים במכשיר מדי יום.