Yan Vainter, Freescale
המעבד בליבה יחידה מגיע לתקרת יכולתו מבחינת ביצועים, כתוצאה מבעיות הקשורות לאנרגיה, חום והספק. על מנת למצוא פתרון לבעיות אלו, שגורמות לקשיי תכנון, רבים מבין מתכנני היישומים המשובצים מבצעים הגירה של היישומים המשובצים מליבה יחידה לריבוי יחידות. במאמר זה נחקור מתווה לאסטרטגיית תוכנה שמאפשר ביצוע ההתקדמות מליבה אחת לשתי ליבות ויותר, באמצעות קו המוצרים QorIQ המבוסס על הארכיטקטורה Power Architecture.
הליבה היחידה מאבדת תנופה
חוק Moore מאבד תנופה
בשנים האחרונות כולנו ראינו את זה מגיע – הכפלת כמות הטרנזיסטורים והתדירות בכל 18 חודשים לא נותרה במסלול המתוכנן לה. ברור שככל שקטן גודלם של הטרנזיסטורים, אפשר היה להציב יותר מהם באותו שבב הסיליקון. ואולם התדירות אינה שומרת על הקצב של חוק Moore. עובדה זו מעכבת את יתרונות הביצועים ברבים מבין היישומים המשובצים.
במילים פשוטות, אפשר להתייחס לליבה יחידה כיישום בתהליכון (thread) יחיד. לפי ההגדרה, אין זה משנה כמה משימות נמצאות בביצוע, רק ליבה אחת יכולה לבצע את המשימה. מפתח התוכנה יצטרך להשתמש בכל הכלים העומדים לרשותו בקידוד מונחה עצמים, כדי להבטיח שהמעבד פועל בצורה הטובה ביותר האפשרית. ואם יידרשו ביצועים נוספים, ייתכן שיידרשו לו כמה תחבולות בשפת Assembley.
בעיות בנושאים של הספק, אנרגיה וחום ובתכנון של ספק הכוח
כאשר ה”מגה-הרצים” היו אמת המידה היחידה החשובה, הדרישה למעבדים בעלי ריבוי ליבות הייתה מוגבלת. יישום משובץ יכול היה פשוט להעמיד את כל המשימות בשורה עורפית, ולהפעיל אותם באמצעות תהליכון יחיד, תוך כדי כך שהוא מסתמך על צינורות עיבוד נתונים (pipeline) ועל תדירויות אות שעון של המעבד, על מנת להתגבר על היישום באמצעות כוח ברוטלי. פתרונות לבעיות חום שודרגו, על מנת שיוכלו להכיל את החום שנוצר כתוצאה ממעברי אות השעון המרובים כל כך, אבל התכנונים של ספקי הכוח נאבקו כדי לעמוד בדרישות הזרם של המעבדים הללו, הפועלים בתדירויות גבוהות.
הדרישה של הציבור לשימוש באנרגיות נמוכות יותר
העקומה המתארת את ההספק בתלות בתדירות אינה ליניארית וחלקה כלפי מעלה ולצד ימין, כפי שמרמזת משוואת ההספק הדינמי . במציאות היא יכולה להיראות יותר כמו מקל הוקי קרח, כתוצאה מרכיב ההספק הסטטי . ככל שאות השעון מהיר יותר, כך גבוה יותר יהיה ההספק הדינמי שמתקזז אולי כתוצאה מתנודות מתח קטנות יותר. בנוסף, ככל שהממדים של הטרנזיסטורים קטנים יותר, גדול יותר יהיה ההספק הסטטי הנובע מהזליגה ללא ביצוע פעולה כלשהי. צירוף שני הגורמים להספק כולל עלול להוביל לשימוש גבוה יותר באנרגיה. טרנזיסטורים הפועלים בחמישה ג’יגה-הרץ אינם אפשרות ריאלית ושוקי היישומים המשובצים אינם יכולים להסתמך על תדירויות גבוהות יותר, אם הפחתת האנרגיה הופכת להיות דרישה מחויבת בתכנון.
בעקבות חקיקה של תקנות שנחקקו על ידי ממשלות ולחצים שהופעלו על ידי קבוצות חברתיות, נושאים הקשורים בצריכת הספק ואנרגיה נבחנים מקרוב בכל רמות המערכת. החל במעגלי LRC פסיביים וכלה במצבים הפעילים ובמצבי ההמתנה של מערכות על שבב (SoC), המתכננים של מערכות משובצות חייבים להבטיח את עמידתם בדרישות מחויבות אלו בד בבד עם שמירה על עלות סבירה. השיווק של מערכות אלו השתנה אף הוא במידה רבה מאוד, תוך שימת דגש על הצהרות “ירוקות”. התדירויות של הליבות כבר אינן אמת המידה העיקרית לבידול המוצר. החיסכון באנרגיה וממשק המשתמש הפכו היום לנתוני המפרטים שאותם כדאי להדפיס על האריזה ובדף הנתונים. תדירויות אות השעון הפכו להיות הערת שוליים.
כל רכיבי המערכת חייבים לפעול יחד על מנת להקטין את השימוש הכולל באנרגיה, ובתחום מערכות SoC קיימת חובה מיוחדת להשתמש בכל האמצעים הטכנולוגיים המתקדמים כדי להקטין את ההספק עד למינימום. אחד המנגנונים האלה הוא הקטנת התדירות. עם זאת, נשאלת השאלה, אם ליישום נדרש יותר עיבוד, כיצד אפשר לקבל את מחזורי העבודה מהמעבד ובה בעת להקטין למינימום את ההספק? התשובה טמונה בריבוי הליבות.
איור 1 – כמה תרשימי בלוקים המתארים שימוש בשתי ליבות למימוש מערכות בליבוי ליבות.
איור 2 – דוגמה לליבות רבות יותר מאשר שתי ליבות
תדירות אינה שווה לביצועים
ההשפעות של קוד היישום בעולם הממשי
בשוקי המערכות המשובצות של היום, צרכני הקצה מתחילים להתייחס ל”מגה-הרצים” כאל אמת מידה מיושנת להערכת היצרנים של מערכות סיליקון. מבחני ביצועים המתבססים על תדירות העבודה במגה–הרץ בלבד מובילים לתוצאות מוליכות שולל ולהחלטות גרועות בתחום הארכיטקטורה במהלך שלב התכנון. לדוגמה, הפעלה של מבחן ביצועים ליישום יחיד הנמצא במלואו בזיכרון המטמון L1 של היע”מ (CPU) תוביל תמיד לתוצאות טובות יותר, כאשר המהירויות של אות השעון יהיו גבוהות יותר. עם זאת – וללא כל קשר למידת המשובצות של היישום – פסיקות (interrupt), מצבי תקיעה (stall) של המעבד ופעולות גישה אל זיכרון חיצוני יהיו תמיד חייבים להתקיים בכל היישומים.
ליישומים משובצים יש מבחני ביצועים ייחודיים המבוססים על השוק המסוים. לעתים המבחן מבוסס על חבילות בשנייה או על דפים לדקה ולפעמים על וואטים לשעה, אך בכל סוג של אמת מידה שאותה מיישמים, חיוני ביותר שיצרן הסיליקון יספק את הנתונים בעלי המשמעות המבוססים על יישומים אמיתיים, ולא רק רצפי קוד מאולצים שלעולם לא ייתכן מצב שבו הם יופעלו בעולם הממשי.
בכל מקרה, נתונים בעלי משמעות אלו אינם צריכים להיות מסופקים – וגם אינם אמורים להיות מסופקים – בהקשר של תדירויות אות השעון.
כעת, אין כבר צורך למצוא את הפשרה בין צריכת ההספק לבין הביצועים
בעיות הכרוכות במעבר לריבוי ליבות מצדם של המתכננים
בתחילת תהליך הפיתוח של יישום יש התמקדות עצומה של התכנון בביצועים, עד שמגיעים לעמידה בדרישות המפרט. לאחר מכן, נודד המוקד של מתכנני התוכנה להרחבת התכונות ולתיקון שגיאות. לארכיטקטורות חדשות נדרש כיוון ביצועים חדש, אך מרגע שזה הושג, אפשר לשדרג בקלות את הביצועים בהעלאת תדירויות היע”מ. כעת, מפתח התוכנה המוצלח מוצא לו דרך נוספת להרחיב את ביצועי היישום.
ההוצאות על פיתוח התוכנה הם מרכיב חשוב במעבר מוצלח להתקן בעל ריבוי ליבוי. החלקים האינטגרליים ביותר של הארכיטקטורה, לעתים קרובות, יהיו אלו שלצורך הפיתוח שלהם יידרש משך הזמן הארוך ביותר. אלו הם פיסות רבות ערך של הנכסים האינטלקטואליים, שייתכן שהחברה לא תהיה מוכנה לנטוש אותם למען ארכיטקטורת ליבה חדשה, או שלא תסכים לפתוח אותם ולשנות אותם למען ההעברה להתקן בעל ריבוי ליבות.
כיצד להתגבר על ההתנגדות להגירה אל התקן ריבוי ליבות
בעזרתם של Freescale ו–QorIQ, המתכנן של מערכות משובצות יכול לקבל את יתרון הביצועים הרצויים ולהקטין את ההשקעה בפיתוח התוכנה במהלך העברה של ארכיטקטורה.
הרעיון ה”פשוט” של יצירת ריבוי תהליכונים ביישום שלך, על מנת להקל את העומס שנוצר בנקודות מוקד ובמשימות שאותן אפשר להפעיל במקביל, ברור מאליו מבחינת התיאוריה, אבל מהווה משימה ענקית בעת ביצוע בפועל. יישומים משובצים הבנויים על האופי הסדרתי של מעבדים בעלי ליבה יחידה מקפלים בתוכם עשרות שנים של השקעה בתוכנה.
אנחנו נמצאים בנקודת הברך של ההגירה לריבוי ליבות, שבה על מנהל הצוות של תכנון מערכות משובצות לקבל החלטה – אם לבצע, ומתי, העברה של התוכנה שלו אל מעבד בעל ריבוי ליבות. קיימים כמה מצבי תלות שאותם יש לקחת בחשבון. מערכת ההפעלה, החומרה, מודל התכנות של מרחב המשתמש, המורכבות, האפשרויות לשדרוג ומשך הזמן הנדרש לביצוע כל הפעולות האלו, באופן שיוכיח את עצמו בעתיד. תכנון בצורה נכונה של ארכיטקטורה עבור ליבה כפולה יכול להבטיח שאפשר יהיה להשתמש ביותר מאשר בשתי ליבות באופן יותר פשוט.
תכנון לריבוי ליבות
מתכננים של חומרה ותוכנה המיועדים למערכות משובצות צריכים להתייחס בתשומת לב לכמה נושאים, כגון:
• אלו הן המשימות שלהן ראוי לתת עדיפות גבוהה יותר?
º במשימות אלו יש לטפל בראש ובראשונה.
• אלו הן המשימות שלהן נדרשים התקנים היקפיים – ומהם התקנים אלו?
º יש לקבוע חציצת משימות (Partitioning) עבור פעולות קלט ופלט אלו בהתאם.
• אלו הן המשימות שלהן יהיה צורך במהירויות גבוהות של אות השעון?
º חשב את תדירויות הליבה בהתבסס על הדרישות הממשיות של ביצועי היישום,
ולא על פי מבחני ביצועים אקראיים.
• אלו הן המשימות שלהן יידרש שיתוף בין הליבות?
º משימות אלו עלולות להפוך את מבנה המיפוי של הזיכרון למורכב יותר.
• אלו הן המשימות שיכולות להתבצע במקביל לביצוע של משימות אחרות?
º קבע אלו מבין המשימות מצטלבות בדרך כלשהי עם משימות אחרות.
• אלו הן המשימות שלהן יש צורך בתפוקה גבוהה יותר?
º קבע אם ניתן ליצור בקלות עותקים של המוצא.
• אלו הן המשימות שלהן נדרש זמן המתנה (latency) קצר יותר?
º קבע את נקודות המוקד של העומס ואתר הזדמנויות ליתרונות בביצועים בתוך היישום.
• אלו הן המשימות שלהן יש דרישות ייחודיות ממערכת ההפעלה?
º קבע את הדרישות לפעולה בזמן אמת, את הדרישות של מערכות ישנות ואת הדרישות של צרכן הקצה מבחינת הערך המוסף שלהן.
בעזרת התשובות לכל אחת מהשאלות האלו תוכל לקבוע מפת הדרכים עבור צוותי פיתוח התוכנה, על מנת לאפשר ביצוע השקעות של משאבים באופן מתווסף אל ריבוי הליבות. חלק מהשאלות האלו גם יעזרו לך לקבל מבט מעמיק בדרישות התכנון הייחודיות שלך, וחלק אחר שלהן יעזור לך לקבוע את תכנון העל הכללי של ריבוי הליבות. בהמשך נתמקד בחלק קטן בלבד של השאלות המצוינות לעיל.
אלו הן המשימות שיכולות להתבצע במקביל לביצוע של משימות אחרות?
אם ליישום נדרשים ממשק משתמש, חיבור רשת ויישום ראשי, חציצת משימות פשוטה יכולה להיות ממשק משתמש ורשת בליבה 0 ויישום ראשי בליבה 1. האם עיבוד זה הוא עיבוד סימטרי (SMP) או האם אותן מערכות הפעלה יפעלו על פני שתי הליבות? האם עיבוד זה הוא עיבוד אסימטרי (AMP), שבו כל ליבה פועלת עם מערכת הפעלה משלה? אם העיבוד הוא עיבוד AMP – האם יש חשיבות לכך שהליבות יתקשרו ביניהן או ישתפו נתונים? בכל המקרים, הדרך של פיצול המשימות עם העדיפות הנמוכה בין הליבות היא שיטה קלה לביצוע וניתנת לניהול כדי להתמודד עם ריבוי הליבות.
אלו הן המשימות שלהן יש צורך בתפוקה גבוהה יותר?
אם היישום שלך יכול לקבל יתרון מתפוקה גבוהה יותר, טופולוגית המערכת המתאימה היא פשוט להפעיל ריבוי של יצירות מופעים (instantiation) של אותו היישום בכמה ליבות. כל עוד הפלט אינו תלוי בפלט של הליבות האחרות, התוצאות תהיינה זהות למצב שבו היית מפעיל יישומים זהים במעגלי מחשב שונים. גם כאן, שוב קיימת שאלת ההפעלה, בדומה לדוגמה הקודמת, אם כי ברור שעל מנת ליצור יותר פקדי תוכנה (widget), אתה יכול להפעיל שורות רבות יותר בשפת Assembly. השימוש בליבה שנמצאת במצב סרק, שווה ערך לאכלוס שורת קוד נוספת בשפת Assembly.
אלו הן המשימות שלהן נדרש זמן המתנה (latency) קצר יותר?
אם היישום שלך יכול לקבל יתרון מזמן המתנה קצר יותר, טופולוגית המערכת המתאימה תהיה פשוטה באותה מידה, אך פיתוח התוכנה עלול להפוך להיות מאתגר יותר. מפתחי תוכנה יצטרכו לקבוע את נקודות המוקד של העומס ביישומים, שיכולות לפעול גם בתהליכונים נפרדים, ולהפחית את העומס של המשימות האלו על ידי העברתן לליבה אחרת או לליבות אחרות. לביצוע פעולה ייתכן שתידרש השקעה גדול יותר במשאבים ובלוחות זמנים, אבל היתרונות הנובעים מקיצור זמני ההמתנה עולים בהרבה על הקשיים והעלות הכרוכים בהעברה.
המעבר משתי ליבות לליבות רבות יותר יכול להיות פעולה פשטה לחלוטין, אם צוות ארכיטקטורת התוכנה יהיה מודע למפות הדרכים של התקני המוליכים למחצה. קשרים חזקים בין מתכנני המערכות המשובצות לבין Freescale יכולים להבטיח היערכות מתאימה מבחינת הארכיטקטורה.
מדוע להשתמש בריבוי ליבות?
חזור לרשימת השאלות המופיעה לעיל וקבע את מצבי התלות החשובים ליישום שלך, תכנן ולאחר מכן, תקוף. פזר באופן יעיל את היישום המשובץ כולו על פני כל הליבות. לדוגמה, אתה יכול להשתמש בליבה אחת לפעולות השירות, להשתמש בליבה שנייה לבקרה, ולהשתמש בשאר הליבות לנתונים. אין אפשרות למצוא מעבד הפועל ב–5 ג’יגה–הרץ בטכנולוגיה של היום, שיעניק חיים חדשים ליישום הנוכחי שלך שפועל בתהליכון יחיד. עם זאת, אפשר לראות ריבוי ליבות הפועלות ב–1 ג’יגה–הרץ במערכת SoC, שיכולים לאפשר עיבוד שווה ערך ל–5 ג’יגה–הרץ במעטפת הספק קטנה יותר, במארז שיפעל בטמפרטורה נמוכה יותר ועם יכולות משולבות רבות יותר.
נתונים אמיתיים שנאספו עד כה ביחס ל–p1022 QorIQ מראים שאם הארכיטקטורה של יישום תוכננה לקבל יתרונות מהליבה השנייה, הביצועים גדלו במידה דומה לזו שמתקיימת במצב שבו מעבד שמיועד לפעול ב–1 ג’יגה–הרץ, פועל ב–1.6 ג’יגה–הרץ. הגידול בביצועים הוא ב–60% עם גוף קירור פסיבי קטן ועם הספק כולל קטן בהרבה מאשר בשימוש בליבה יחידה.
מדוע להשתמש
ב–QorIQ?
בשימוש ב–QorIQ, עלות ההתקנים בשילוב עם רמות גבוהות יותר של אינטגרציה מפחיתים בהרבה את עלות החומרים לעומת השימוש במעבדי ליבה יחידה. באופן דומה, עם QorIQ המעבר לשימוש בריבוי ליבות יכול להתבצע בהדרגה ובאופן בטוח, תוך כדי כך שהוא משאיר לצוותי פיתוח התוכנה את הזמן הדרוש כדי לבצע בזהירות ובאופן שיטתי את ההגירה למעבדים בריבוי ליבות.
קיימת מגמה של מעבר בתעשיית ההתקנים המשובצים, שאותה מתכננים של יישומים משובצים חייבים לבצע. טרנזיסטורים מהירים יותר אינם התשובה לביצועים טובים יותר. שימוש מתוחכם יותר בטרנזיסטורים מהירים דיים, מספק את הגורמים הנדרשים ליישומים שלהם יש ביצועים גבוהים יותר, ומן הסתם, ללקוחות מרוצים יותר. קו מוצרי QorIQ לא רק מבטיח שהפשרה הנעשית בין ההספק לביצועים תהיה זניחה, אלא הוא גם מספק את החומרה הנחוצה שבנויה על ארכיטקטורת Power, אשר מאפשרת השגת פתרונות יעילים עבור יישומי ריבוי ליבות.
השאלה אם היישומים המשובצים יעברו לשימוש בהתקני ריבוי ליבות אינה קיימת כלל. השאלה שבפניה אנו עומדים היא, מתי נעביר את החומרה שלנו לריבוי ליבות ומתי נעביר את התוכנה שלנו לריבוי ליבות? בשאלה הראשונה גלומה השקעה כספית קטנה לעומת השאלה השנייה שעלולה באמת להפחיד את מתכנן המערכות המשובצות ולהבריח אותו מהמעבר לריבוי הליבות.
עם התיעוד, התוצאות ודוגמאות התוכנה המצוינים ועם מערכות יחסים מעולות עם שותפים בעלי מערכות סביבתיות רחבות ומעמיקות שמיועדות לריבוי ליבות, מעבדי QorIQ של חברת Freescale יכולים להאיץ במידה רבה את היישומים בדרכים שתהיינה באמת רבות משמעות עבור הלקוחות שלך.
