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

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

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

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

מה זה AutoFDO?

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

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

נכתב על ידי:

להמשך הקריאה