חדשות על מוצרים

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

משך הקריאה: 4 דקות
Yabin Cui
מהנדס תוכנה

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

מה זה AutoFDO?

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

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

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

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

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

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

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

boosting_2.png

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

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

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

boosting_3.png

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

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

  • כלים וסביבה: אנחנו מבצעים צריבת ROM‏ (flash) של מכשירי בדיקה עם תמונת הליבה העדכנית ומשתמשים ב-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 מבטיחה שהבסיס של מערכת ההפעלה יעבור אופטימיזציה באופן שמתאים לשימוש היומיומי שלכם במכשיר.

נכתב על ידי:

להמשך הקריאה