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