מאת: Haim Cohen, Freescale Semiconductor Israel Limited.
מעבד הליבה היחידה הגיע לתקרת הביצועים שלו בשל נושאים הקשורים באנרגיה, בחום ובהספק. על מנת להתמודד עם נושאים אלו שגורמים לקשיים בתכנון, רבים מבין מתכנני ההתקנים המשובצים מעבירים יישומים משובצים מליבה יחידה לריבוי ליבות. מאמר זה מספק תיאור של אסטרטגיה לקידום תוכנה מליבה אחת לשתי ליבות ויותר, בעזרת השימוש בקו המוצרים QorIQ של Freescale המתבסס על הטכנולוגיה Power Architecture
איור 1: מימוש של מערכת בריבוי ליבות
איור 2: מעבר ליותר מאשר שתי ליבות
איור 3: תרשים הבלוקים של המעבד QorIQ p1022
חוק מור מאבד את כוחו
כולנו שיערנו במהלך השנים האחרונות שזה עומד להתרחש – ההכפלה של טרנזיסטורים ותדירות מדי 18 חודשים, לא נשארה במסלול המתוכנן שלה. ככל שממדי הטרנזיסטורים התכווצו, אפשר היה להציב יותר מהם על אותה פרוסה של סיליקון. ואולם, התדירות אינה עומדת בקצב של חוק מור וגורמת לעיכובו של השיפור בביצועים ברבים מבין היישומים המשובצים.
אם לומר זאת בפשטות, ליבה יחידה יכולה להיחשב ליישום בתהליכון יחיד. לפי ההגדרה, לא חשוב מה מספר המשימות שניתן לבצע, רק ליבה אחת יכולה לבצע את המשימה. מפתח התוכנה יצטרך להשתמש בכל הכלים הקיימים בקידוד מונחה עצמים, על מנת להבטיח שהמעבד יפעל בצורתו האופטימלית. ובמקרה שנדרשים ביצועים נוספים, ייתכן שיהיה צורך לבצע כמה כיוונונים בשפת אסמבלי.
כאשר התדר במגה-הרץ הייתה אמת המידה היחידה בעלת משמעות, הדרישה למעבדים בריבוי ליבות הייתה מוגבלת. יישום משובץ יכול היה פשוט לסדר בטור את כל המשימות, בזו אחר זו, ולהפעיל אותן בתהליכון יחיד, כשהוא מסתמך על צינור עיבוד הנתונים במעבד ועל תדירות אות השעון כדי לדחוף אותן אל היישום, בדרך שיש בה כוח ואלימות. פתרונות לבעיית החום התפתחו והתמודדו עם החום המופק ממעברים מרובים של אות השעון, אך תכנונים של ספקי כוח נאבקו כדי לעמוד בקצב של דרישות הזרם של אותם מעבדים הפועלים בתדר גבוה.
תלות ההספק בתדר אינה עקומה ליניארית חלקה שמתעקלת מעלה וימינה, כמו זו שמתקבלת במשוואה של הספק דינמי (Pdynamic=aCV2f). אם נוסיף ונבחן את הדברים, התקני CMOS נצמדים לכלל של השורש השלישי, שמרמז שההספק עומד ביחס ישר לתדירות בחזקה שלישית. במציאות, מתקבל כאן “מחבט הוקי” בשל התלות בתדירות: ככל שאות השעון מהיר יותר, ההספק יהיה גבוה יותר. ובנוסף, ככל שהממדים הגיאומטריים של הטרנזיסטורים קטנים יותר, ההספק הסטטי יהיה גדול יותר, בשל זליגה שמתקיימת באפס עבודה. שני הגורמים מסתכמים להספק הכולל, כך שהם יוצרים שימוש בכמויות גדולות יותר של אנרגיה. טרנזיסטורים הפועלים ב-5 ג’יגה הרץ אינם נחשבים לאפשרות מציאותית, ושוקי ההתקנים המשובצים אינם יכולים להסתמך על תדירויות גבוהות יותר אם הקטנת האנרגיה הופכת להיות דרישה מחויבת מבחינת התכנון.
בעקבות תקנות ממשלתיות ולחץ ציבורי, צריכת הספק וצריכת אנרגיה נבחנות בקפידה בכל רמות המערכת. החל במעגל LRC הפסיבי ועד מצבים אקטיביים ומצבים רדומים של מערכת על שבב (SoC), מתכנן של מערכות משובצות חייב להבטיח את העמידה בכללים הכרחיים אלו בעלות סבירה. פעולות השיווק של מערכות אלו השתנו אף הן במידה ניכרת, והן מנופפות כל הזמן ביתרונות הירוקים שלהם. תדירויות ליבה אינן מהוות עוד את צורת המדידה העיקרית של הבידול. כיום, חיסכון באנרגיה וממשק המשתמש הם הערכים הנחשבים במפרט הטכני, ואותם חשוב להדפיס על גבי המארז ובדף הנתונים הטכניים. תדירויות אות השעון הפכו להיות הערת שוליים בלבד.
כל הרכיבים במערכת חייבים לפעול יחד, כדי להקטין את השימוש הכולל באנרגיה, ובאופן מיוחד תכנון מערכת על שבב חייב להשתמש בכל ההתפתחויות הטכנולוגיות הקיימות, כדי למזער את צריכת ההספק. אחד המנגנונים האלו הוא הקטנת התדירות. ואולם, אם ליישום יש צורך בפעולות עיבוד רבות יותר, איך ניתן יהיה לקבל את מחזורי העבודה מהמעבד ולהקטין למינימום את ההספק? התשובה היא דרך ריבוי ליבות.
תדירות אינה שוות ערך לביצועים
בשוקי היישומים המשובצים של היום, לקוחות מתחילים לראות במגה-הרץ מידה שעבר זמנה המשמשת למדידות בקרב ספקי הסיליקון. מבחני ביצועים שמבוססים אך ורק על מגה הרץ יובילו לתוצאות מטעות ולהחלטות ארכיטקטוניות שגויות במהלך שלב התכנון. לדוגמה, הפעלה של מבחן ביצועים של יישום פשוט שנמצא כולו בזיכרון מטמון L1 של מעבד CPU, תניב תמיד תוצאות טובות יותר במהירויות אות שעון מהירות יותר. אך לא חשוב עד כמה משובץ יהיה היישום, הפסיקות, תקיעויות של המעבד ופעולות גישה לזיכרון חיצוני יתרחשו בכל היישומים.
ליישומים משובצים יש מבחני ביצועים ייחודיים שמבוססים על שוק מסוים. לפעמים אלו הם חבילות מידע בשנייה, או עמודים בשנייה, או קילוואט בשעה. ואולם, תהיה צורת המדידה הנבחרת אשר תהיה, חשוב שספק הסיליקון יספק נתונים בעלי משמעות שמבוססים על יישומים מהחיים הממשיים ולא על רצפים “מומצאים” של קוד, שלא יבוצעו לעולם, בעולם הממשי. הדרך שבה נתונים רבי משמעות אלו מסופקים, אינה – וגם לא צריכה להיות – כזו המגיעה מתדירויות אות השעון.
הספק וביצועים – לא עוד פשרה
בתחילת תהליך פיתוח של יישום, קיימת התמקדות תכנון עצומה בנושא הביצועים, עד אשר דרישות המפרט מתמלאות. לאחר מכן, ההתמקדות של מתכנני תוכנה עוברת לחיזוק תכונות ולתיקוני שגיאות. ארכיטקטורות חדשות דורשות כוונוני ביצועים בדרכים חדשות, אך מרגע שהמטרה הושגה, הביצועים משתפרים בקלות עם העלייה בתדירויות של היע”מ (CPU). מפתח התוכנה המוצלח מחפש עתה דרך אחרת להגדלת הביצועים של היישום שלו.
פיתוח תוכנה הוא מרכיב מפתח בהגירה מוצלחת להתקן בריבוי ליבות. החלקים האינטגרליים ביותר של ארכיטקטורה, הם לעתים אלו, אשר לצורך הפיתוח שלהם נדרש היה הזמן הרב ביותר. אלו הם פיסות יקרות ערך של נכסים אינטלקטואליים, שאותם החברה יכולה לנטוש בחוסר רצון לטובת ארכיטקטורת ליבה חדשה או כדי לפתוח אותם ולשנות אותם לצורך התאמה והעברה להתקן בריבוי ליבות. עם עזרתה של Freescale Semiconductor ועם המעבדים QorIQ, מתכנן התקנים משובצים יכול לזכות בביצועים המבוקשים ולהקל על ההשקעה בפיתוח תוכנה בזמן המעבר של הארכיטקטורה.
הגישה ‘הפשוטה’ היא ליצור ביישום ריבוי תהליכונים, כדי להקל את העומס ב’נקודות החמות’ ומעל משימות שיכולות לפעול במקביל. באופן תיאורטי גישה זו פשוטה וברורה, אך באופן מעשי היא עצומה ואדירה. עשרות שנים של השקעה כרוכות ביישום משובץ הנסמך על האופי הסדרתי של מעבדים בעלי ליבה יחידה.
אנו נמצאים בנקודת המפנה, שבה הגירה לריבוי ליבות היא החלטה שבה מנהל התכנון המשובץ חייב להחליט מתי ואם המתכננים שלו יעבירו את התוכנה שלהם למעבד בריבוי ליבות. בהחלטה זו יש לקחת בחשבון כמה מצבי תלות או גורמים: מערכת ההפעלה (OS), החומרה, התוכנה, מודל התכנות במרחב של המשתמש, המורכבות, יכולת השדרוג והזמן הנדרש לביצוע כל אלו באופן שיעמדו בדרישות עתידיות. תכנון כהלכה של ארכיטקטורת הליבה הכפולה יכול להבטיח שאפשר יהיה לשבץ יותר משתי ליבות בצורה קלה ופשוטה למדי.
תכנון עבור ריבוי ליבות
מתכנני החומרה ומתכנני התוכנה של יישומים משובצים צריכים לשאול את עצמם כמה שאלות חשובות למדי:
מהן המשימות ביישום שלך שהן בעדיפות גבוהה יותר מנקודת מבט של הערך המוסף שהם מעניקים לחברה/ לארגון?
-במשימות אלו כדאי להשקיע תשומת לב לפני הכל.
אלו משימות דורשות מעגלים היקפיים מסוימים ומהם המעגלים האלו?
-בצע חלוקה למחיצות של כניסות ויציאות, בהתאמה.
לאלו משימות יש צורך במהירות אות שעון מרבית?
-הגדר את תדירויות הליבה בהתבסס על דרישות ביצועים של יישומים ממשיים, ולא על מבחני ביצועים אקראיים.
לאלו משימות נדרש שימוש בשיתוף בין ליבות?
-התשובה לשאלה זו עלולה לגרום למורכבות של מפות הזיכרון.
אלו משימות יכולות לפעול במקביל למשימות אחרות?
-הגדר את המשימות, אשר אינן משפיעות במשהו על משימות אחרות (אורתוגונליות).
לאלו משימות יש צורך בתפוקה נוספת?
-קבע אם ניתן לשכפל את התוצאה בקלות.
לאלו משימות נדרש פחות זמן אחזור?
– הגדר בתוך יישום מהן הנקודות החמות ומהן ההזדמנויות האפשריות להגדלת הביצועים.
לאלו משימות יש דרישות למערכת הפעלה ייחודית?
– הגדר את דרישות זמן אמת, את הצרכים המסורתיים ואת הדרישות שמציב משתמש הקצה עבור הערך המוסף שלו.
כל אחת מהתשובות תעזור לך בתהליך הגדרת מפת דרכים, עבור אנשי צוות פיתוח התוכנה, שתאפשר את השימוש בהשקעת משאבים מדורגת בריבוי ליבות. חלק מתשובות לשאלות אלו יעזור לך לקבל תובנות נוספות לגבי דרישות התכנון הייחודיות שלך, ותשובות אחרות יעזרו לך לקבוע את אסטרטגיית התכנון המקיפה. במאמר זה, נתמקד בשלוש מבין השאלות שהוזכרו לעיל. איור 1 מציג גישה של תרשים בלוקים למימוש מערכת בריבוי ליבות.
אלו משימות יכולות לפעול במקביל למשימות אחרות?
ביישום שדורש ממשק משתמש, חיבור לרשת ויישום ראשי, חלוקה פשוטה למחיצות יכולה להציב את ממשק המשתמש (UI) ואת הרשת על ליבה 0 ואת היישום הראשי על ליבה 1. בדרך זו תוכל להחליט איזו מערכת הפעלה נדרשת עבור כל אחת מהליבות. האם כאשר אותה מערכת הפעלה פועלת עבור שתי הליבות אפשר לראות בכך עיבוד סימטרי בריבוי ליבות (SMP)? האם כאשר כל אחת מהליבות פועלת על מערכת הפעלה משל עצמה, אפשר לראות בכך עיבוד א–סימטרי בריבוי ליבות (AMP)? אם זהו עיבוד א-סימטרי בריבוי ליבות, האם יש חשיבות לכך שהליבות יעבירו ביניהן נתונים או ישתפו נתונים? בכל המקרים, פעולה הכרוכה בפיצול המשימה בעלת העדיפות הנמוכה יותר בין הליבות תהיה שיטה קלה יותר וניתנת לניהול באופן פשוט יותר לטיפול בריבוי ליבות.
לאלו משימות יש צורך בתפוקה נוספת?
אם היישום שלך יכול להפיק תועלת מתפוקה רבה יותר, טופולוגיית המערכת המועדפת היא פשוט הפעלה של מופעים מרובים של אותו יישום על כמה ליבות. כל עוד התפוקה אינה תלויה בתפוקה של ליבות אחרות, התוצאות יהיו אותן תוצאות כאילו היית מפעיל יישומים רבים על מחשבים שונים. גם כאן, כפי שהיה בדוגמה הקודמת, קיימת שאלת מערכת ההפעלה, למעט נקודת השוואה אחת והיא שכדי להפעיל עוד תוכניות מחשב קטנות (widget), אתה לעתים קרובות נאלץ פשוט להפעיל “קווי הרכבה” נוספים. השימוש בליבה שפועלת בסרק – כמוהו כאיוש של “קו הרכבה” נוסף.
לאלו משימות נדרש פחות זמן אחזור?
אם היישום שלך יכול להפיק תועלת מפחות זמן אחזור, טופולוגיית המערכת פשוטה באותה מידה, אם כי פיתוח המערכת יכול להפוך לאתגר. מפתחי תוכנה יצטרכו להגדיר אותן נקודות חמות ביישומים, אשר יכולות לפעול גם בתהליכונים נפרדים, ולהסיט את העומס של משימות אלו אל ליבה אחרת או אל ליבות אחרות. פעולה זו יכולה לדרוש השקעה רבה יותר במשאבים והארכת לוח הזמנים הנדרש, אך היתרונות של הקטנת זמן האחזור עולים בערכם, הרבה מעבר לטרחה ולעלות הכרוכים במעבר.
המעבר מליבה כפולה ליותר מאשר שתי ליבות יכול להיות קל ופשוט באופן יחסי, אם אנשי הצוות העוסקים בארכיטקטורת התוכנה מודעים למפות הדרכים של התקני המוליכים למחצה. מערכת יחסים טובה שקיימת בין מתכנן היישומים המשובצים לספק הסיליקון יכולה להבטיח התאמה ארכיטקטונית.
מדוע כדאי להשתמש בריבוי ליבות?
אם נחזור לרגע לשאלות המופיעות לעיל, הרי שסדר הפעולות הרצוי הוא, הגדרת מצבי התלות החשובים עבור היישום שלך, תכנון ולאחר מכן, ביצוע. פזר את היישום המשובץ כולו על פני כל הליבות, בצורה יעילה. לדוגמה, השתמש בליבה אחת לשירותים, השתמש בליבה שנייה לבקרה והשתמש בליבות שנותרו לנתונים. (איור 2 מציג דוגמה שבה יש אף יותר מאשר שתי ליבות.) בטכנולוגיה הקיימת כיום, לא תמצא מעבד של 5 ג’יגה הרץ שיכול להעניק חיים חדשים ליישום הנוכחי שלך, הפועל בתהליכון יחיד. אך לעומת זאת, תוכל לראות ריבוי ליבות של 1 ג’יגה הרץ בפעולה במערכת על שבב (SoC) יחידה, שיכולה לספק לך את שווה הערך של עיבוד ב-5 ג’יגה הרץ, במעטפת צריכת הספק קטנה יותר, במארז שמתחמם פחות בהרבה, ועם יכולות משולבות רבות יותר.
מתוך נתונים ממשיים שנאספו אודות מעבד QorIQ® p1022 (עיין באיור 3), ניתן לראות שאם יישום מתוכנן בארכיטקטורה שבאה לנצל את הליבה השנייה, הביצועים שלו יגדלו באותה מידה כאילו היינו מפעילים ב-1.6 ג’יגה הרץ מעבד שפועל ב-1.0 ג’יגה הרץ. גידול של 60% בביצועים שמתקבל בעזרת גוף קירור פסיבי קטן ועם הספק כולל נמוך יותר בהרבה מאשר בשימוש בליבה יחידה.
מדוע כדאי להשתמש בטכנולוגיה QorIQ?
בעזרת טכנולוגיה QorIQ – עלות ההתקנים בשילוב עם רמות גבוהות יותר של אינטגרציה, מקטינים במידה רבה מאוד את עלות החומרים שבשימוש, בהשוואה לעלות של מעבדים הפועלים על ליבה יחידה. בנוסף, בעזרת טכנולוגיה QorIQ – המעבר לריבוי ליבות יכול להתרחש באופן הדרגתי ובצורה מאובטחת, כשהוא מותיר לאנשי צוות פיתוח התוכנה את הזמן, שאותו הם צריכים כדי לבצע בתשומת לב ובצורה שיטתית את ההגירה למעבדים בריבוי ליבות.
זה המעבר שמתרחש בתעשיית ההתקנים המשובצים שאותו מתכנני יישומים חייבים לעשות. טרנזיסטורים מהירים יותר אינם התשובה לביצועים טובים יותר. שימוש חכם יותר בטרנזיסטורים מהירים דיים מספק את הגורמים הנדרשים, כדי לספק יישום בעל ביצועים טובים יותר ללקוח המרוצה. קו המוצרים QorIQ של Freescale, עוזר להבטיח שיתקיים ההספק הנדרש, כדי שהפשרה בתחום הביצועים תהיה בלתי משמעותית, הוא גם מספק את החומרה הדרושה שמסתמכת על הטכנולוגיה Power Architectureשמאפשרת פתרונות תוכנה יעילים ואפקטיביים ליישומים בריבוי ליבות.
השאלה אם יישומים משובצים יעברו להתקנים בריבוי ליבות, כבר אינה קיימת עוד. השאלה היא ‘מתי’. הראשונה – מתי נעביר את החומרה שלנו לריבוי ליבות? והשנייה – מתי נעביר את התוכנה שלנו לריבוי ליבות? הראשונה כרוכה בהשקעה כספית קטנה, ולעומתה השנייה יכולה באמת להפחיד את מתכנן התקנים המשובצים, ולהבריח אותו מתהליך המעבר לריבוי ליבות. תמיכה אמיצה ומערך שלם של דוגמאות המקיף תיעוד קפדני יכולים להתאחד לאסטרטגיה מתאימה, שיכולה לסלק פחדים אלו.
