המעבר למעבד מרובה-ליבות

אבי כהן, פרטק אמבדד סולושנס

טכנולוגיות מרובות-שבבים, מרובות-מעבדים ומרובות נתיבי ביצוע היו קיימות במהלך עשרות בשנים ושימשו לפיתרון בעיות מורכבות ולשיפור הביצועים. מאחר שטכנולוגיה של ליבה יחידה יכלה לספק את הרוב הגדול של צורכי מחשוב עם ביצועים המשתפרים בהתמדה, הכלים ותשומת-הלב התמקדו במעבדים בעלי ליבה יחידה.
עולם המחשוב משתנה, כדרך הטבע. שלושה גורמים המשפיעים על השינוי הוסיפו להיות גורמי-מפתח:
1. הספק: הגדלת התדרים במגה-הרצים עבור ליבה יחידה מתקרבת לגבולות הפיזיקאליים שלה. אם המוצר מוזן בסוללות או בעזרת חיבור לספק-כוח, המפתחים שואפים לשפר את יחס הביצועים/ואט.
2. ביצועים: התכונות והפונקציונליות של היישומים יוסיפו להתפתח ולגרום לשיפור ביצועי המחשוב.
3. מיזוג: התקדמות יכולות נוספות על שבב יחיד. יישומים הפועלים כעת על מעבדים מרובים יעברו לליבות מרובות, ויישומים הפועלים על ליבות מרובות יעברו לשבבים מרובי-ליבות צפופים יותר.
דגם התכנות שנבחר עבור יישומים מרובי-ליבות צריך להתאפיין בגמישות השימוש בכל שלושת הגורמים. בעוד הפנייה להספק שימשה כמוקד של יישומי ליבה-יחידה מרובים העוברים למרובי-ליבות, הדיון המוצג כאן מתייחס לשני הגורמים האחרים – מיזוג וביצועים.
המגוון הרחב של טכנולוגיות פלטפורמה מציע למתכנן בחירות של הפלטפורמה אשר יתאימו בצורה הטובה ביותר לדרישות המפרט. דוגמה של אופציות חומרה כוללת: מעבדים מרובי-ליבות הומוגניים והטרוגניים, מעבדים בעלי שילוב תאוצה כמו גם מעבדים בעלי מנגנונים מיוטבים עבור תקשורות (הובלות) בין המעבדים/ליבה (IPC). גם לפרדיגמות התוכנה הפועלות על מעבדים מרובי-ליבות יש גרסאות שונות כגון SMPi (Symmetric Multiprocessing), (Asymmetric Multiprocessing) AMPii, דמיון ווירטואליזציה ל-CPU, בתוספת הצירוף והפרמוטציות של הדגמים המוזכרים לעיל.

איור 1

{MCAPI initialization}
{MCAPI receive data}

[DSP Application Code]

{MCAPI send data}

איור 2

דגם התכנות
דגם התכנות המשמש בכל פאראדיגמה של תוכנה מרובת-ליבות חייב להיות עקבי, בעל הגמישות לגדול ולאפשר ייטוב על-גבי פלטפורמות חומרה ותוכנה שונות מרובות-ליבה ומרובות-מעבדים הזמינות כיום והעתידות להתפתח.
ה-API של Multicore Association (MCA)iii – MCAPI וה-DSPs של TI משמשים להצגת דגם תכנות עבור יישומים הממזגים אל מעבדים צפופים יותר והמחפשים לאחר מכן דרכים טובות יותר לבצע את היישום בסביבה מרובת-ליבות.
ל-MCAPI יש קונספט המכונה קשר (node) והמוגדר כהפשטה לוגית הניתנת למיפוי לישויות רבות iv דוגמת עיבוד, הליך לביצוע (thread), מאיץ חומרה או ליבת מעבד. בדוגמה זו, הקשר יהווה היישום המלא הפועל על-גבי DSP יחיד.
היישום נאטם (encapsulated) בקריאות MCAPI ואנחנו מניחים שהובלות IPC זמינות. (ראה איור 1)
כעת בשעה שהיישום מתוכנן עבור MCAPI כמודולים אטומים, ניתן לבצע את הצעד הראשון בבדיקה תוך שימוש באחת הסביבות הבאות:
1. חלונות (Windows) בתנאי שמטפלים בקריאות שלא-מחלונות – דוגמת מדמה OS על חלונות.
2. מדמה חומרה כאשר חיבורי התקשורת מדומים
3. חומרה חד-ליבה קיימת
4. חומרה מרובת-ליבות
הבדיקה הראשונית על חומרת המטרה עשויה להיות מאתגרת, בשל מספר המשתנים המוכנסים ונושא זה מיטיב להיות מטופל על-ידי מומחי ניפוי. סביבה מדומה מספקת יתר בקרה. אולם, יתכן שהיישום יועבר לפלטפורמת המטרה.

איור 3

איור 4

מימוש דגם התוכנה
הבה נתבונן בהעברת יישום מרובה-מעבדים יחיד אל מעבד מרובה-ליבות תוך שימוש ב-DSPs של (Texas Instruments (TI דוגמת ה-TMS320C6474 ולאחר מכן ה-TMS320C6678.
היישום הקיים פועל על שישה מעבדי DSP יחידים. קוד המקור עבור כל DSP נאטם בעזרת קריאות MCAPI, וכתוצאה כל קוד עבור כל DSP הופך לקשר MCAPI. על-ידי שימוש בתפריטים ובאשפים הגראפיים של Poly-Platform, האיטום מתבצע במהירות ובשלמות באמצעות הכנסת קוד והפקת קוד.
היישום המצויד ב-MCAPI מתקשר עם DSPs אחרים בארכיטקטורה שיכולה להיות DSP חד-ליבה או C6474 מרובת-ליבות. כלומר אותו קוד מקור ליישום כמו קשר(ים) ניתן להפעלה כ-:
1. DSP חד-ליבה המתקשר עם DSPs חד-ליבה אחרים.
2. DSP מרובה-ליבות המתקשר עם ליבות על אותו שבב
3. DSP חד-ליבה המתקשר עם ליבות על מעבד DSP מרובה-ליבות
4. DSP מרובה-ליבות המתקשר לליבות מקומיות או DSPs על מעבד מרובה-ליבות אחר (ראה איור 2).
בעזרת הרחבה, המעבר למעבדים צפופים יותר, כלומר, יותר ליבות על השבב, קוד המקור המצויד ב-MCAPI יכול לעבור ללא שינוי בקוד המקור (ראה איור 3).
בדוגמה הקודמת, שים לב שליישום שישה קשרים הממופים אחד-לאחד בתצורת C6474 כפולה. כאשר עוברים ל-C6678, בעלת שמונת הליבות, למתכנן/ארכיטקט שתי ליבות נוספות. ניתן להשתמש בשתי הליבות הנוספות כגיבוי או כדי להרחיב את הפונקציונאליות או כדי לשפר את ביצועי המערכת הכלליים. עבור מערכת זו, שתי הליבות ישמשו לשיפור ביצועים.

ייטוב היישום עבור מרובי-ליבות
קשרי היישום המצוידים ב-MCAPI מספקים גמישות בפריסת הקשרים בתוך המערכת. ניתן לקבץ את הקשרים לליבות עבור מערכות בעלות סביבת פעולה מוגנת על-ידי זיכרון ו/או מוכפלת כדי לשפר את ביצועי המערכת. על-ידי קיבוץ הקשרים, ארכיטקט המערכת יכול לאזן את העומס המופעל בעזרת יצירת חלוקת הקשרים בעלי צורכי משאב פחותים למשאב משותף. אם הקשר יזדקק למשאבים משמעותית רבים יותר, ניתן יהיה להציב אותו על משאב ולהכפיל אותו, דבר אשר יאפשר ליותר מערכי נתונים לעבור עיבוד במקביל.
כדי לנסות לשנות במהירות את מיפויי קשרים חלופיים לליבות, המתכנן יכול להשתמש בממשק הגראפי של המשתמש כדי לעצב מחדש את הטופולוגיה, לבנות ולהפעיל את הטופולוגיה החדשה תוך שימוש באותו קוד מקור היישום. התשתית התקשורתית מעוצבת מחדש במהירות והקוד מופק עבור הטופולוגיה החדשה.
הדיאגרמה הבאה מציגה יישום בעל ארבעה קשרים הממופים לשלוש תצורות. בתצורה העליונה כל הקשרים פועלים על ליבה יחידה. בארכיטקטורה בעלת הליבה הכפולה, לקשרים יש הקצאות שונות. המפה המרכזית מציגה תצורה מיוטבת בה עומס המשאב עבור שני הקשרים הראשונים הוא בערך זהה לזה של שני הקשרים האחרונים. במקרה שהארכיטקט ימצא שלקשרים עומסי משאב שונים מאוד, התצורה התחתונה עשויה להיות הטובה ביותר עבור היישום. חשוב לציין שהקשרים נפרסים מחדש תוך שימוש באותו קוד מקור של היישום. (ראה איור 4)
אם נשוב ליישום הפועל על DSPs של TI, ניתן להשתמש בשתי הליבות הנוספות על-ידי הקשר(ים) בעל(י) משאבים טובים יותר. נניח ש-N2 הוא בעל משאב הרבה יותר עשיר. אזי, הארכיטקט יכול להכפיל את N2 ולפרוס את N2 על ה-DSP השביעי והשמיני, וכך להשיג ביצועי מערכת משופרים. התצורה החדשה מוצגת באיור 3 לעיל.
לחילופין, הליבה הנוספת יכולה לשמש לשיפור ביצועי קשר יחיד. כאשר המפתח לומד יותר אודות התנהגות היישום, ניתן לזהות קטע “עשיר במשאב” של קשר. ניתן להפריד את הקטע ה”עשיר במשאב” מהקשר המקורי, לאטום כמתואר לעיל וליצור קשר חדש. אפשר להעביר קשר חדש זה אל ליבה (ליבות) נוספת שם אפשר להשיג שיפור בביצועים.
ניתן לכנות את הגישה של העברת פלטפורמה מרובת-ליבות וזיהוי תחומים לשם שיפור הביצועים “הפרד ומשול” – גישה מוכרת בבעיות הנדסיות. בגישה זו, המעבר למרובה-ליבות הופך לבעל-שליטה מאחר שהמפתחים מבינים את חלוקת היישום. גם הניפוי והייטוב הנוסף הופכים לנוחים יותר.

דגם התכנות עבור היום ועבור הדור הבא
פלטפורמות מרובות-ליבה נמצאות בשימוש ואנחנו יודעים שיישומים נוספים יעברו לפלטפורמות מרובות-ליבה. רוב היישומים נכתבו כמשימות או תהליכים טוריים שניתן להגדיר היטב כגושי ביצוע. ארכיטקטים יכולים להשתמש בדגם התכנות עם MCAPI המתואר במאמר זה כדי להעתיק את היישום שלהם לפלטפורמות מרובות-ליבה במאמץ מזערי.
כמו כן, ליישום המצויד ב-MCAPI יש היתרון לעבור במהירות לפלטפורמה מרובת-ליבות של הדור הבא.
לצורכי דיון זה, הקשרים נפרסו אל ליבות הומוגניות. ניתן להרחיב בנקל את דגם התכנות לליבות הטרוגניות, פלטפורמות תהליך ומערכות הפעלה. אם כן, ניתן להקצות קשר לליבה אשר תואם ביותר את עומס העבודה של הקשר. לדוגמה, ליישום יכולים להיות קשרים הפועלים על פלטפורמת-שרת המתקשרת עם קשרים הפועלים על מעבדים מובנים.
יתרונות כלכליים עבור היצרן הם בכך שבאותו קוד מקור של יישום ניתן להשתמש בקו מוצרים בו הפלטפורמה בשימוש שונה בכוח מחשוב. למוצר בעל רמת מבוא יכולה להיות פלטפורמה יחידה או בעלת ליבות פחותות. למוצר ברמה בינונית יכול להיות כוח מחשוב יותר גדול. למוצר בעל הרמה הגבוהה ביותר יכולה להיות פלטפורמה הטרוגנית. ללא קשר לפלטפורמת המוצרים בשימוש, ישמש אותו מקור יישום.
על-ידי אימוץ דגם התכנות המבוסס על תקני MCA, המפתח יכול להתחיל להשתמש בפלטפורמות מרובות-ליבות כבר כיום. בשעה שלומדים יותר על פעולת היישום, ניתן לשנות את היישום כדי לפעול כקשרים מרובים בתוצאה של השגת ביצועים משופרים וכושר גידול משופר עבור פלטפורמות-ליבה נוספות ופלטפורמות מהדור הבא. דגם התוכנה תקף עבור פלטפורמות עכשוויות ומכין את היישום עבור פלטפורמות המחר.
* * *
i SMP – http://en.wikipedia.org/wiki/Symmetric_Multi-Processing
ii AMP – http://en.wikipedia.org/wiki/Asymmetric_multiprocessing
iii MultiCore Assocation – http://www.multicore-association.org
ivMulticore Communications API Specification, MCAPI – http://www.multicore-association.org/workgroup/mcapi.php