האתגרים והפתרונות בתוכנות לעיבוד מרובה ליבות

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

.

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

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

מודלים להפשטה של תוכנות לעיבוד מרובה ליבות

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

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

ה-AMP (עיבוד מקבילי אסימטרי) מציע ארכיטקטורת תוכנה לביזור פונקציות, שבה לכל ליבה יש תפקיד קבוע ומוגדר מראש. בפרשנות הצרה יותר של הארכיטקטורה, מודל זה חוזה את הפריסה של סביבות הפעלה נפרדות ובלתי תלויות על ליבות בלתי תלויות. במקרים מסוימים מתייחסים אל מערכת כאל AMP כאשר הסימטריה הלוגית "מפורקת" ומייחסים תפקידים ספציפיים לליבות ספציפיים, לדוגמה, באמצעות הפניית כל הפסיקות לליבה אחת.
בנוסף, ניתן לשלב ארכיטקטורות תוכנה מסוג AMP ו-SMP במודל היברידי אסימטרי. כל מעבדי ה-MPCore מבית ARM תומכים בכל שילוב שהוא של ארכיטקטורות תוכנה אלה (AMP, SMP והיברידי).

כיצד נאפשר ריבוי מעבדים באופן מפורש

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

בהתאם למאפייני היישום, ניתן להשתמש בכמה שיטות שונות:

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

השימוש בספריות threading

מערכת ההפעלה הנבחרת חייבת לספק תמיכה בריבוי תהליכים (multithreading), וקריאות המערכת הרלוונטיות ברמה נמוכה חייבות להיות מופשטות בתצוגה ברמת היישום באמצעות API של ספריית threading שבו יכול המתכנת להשתמש. הסטנדרט בתעשייה בתחום זה הם ה- POSIX Threads. התהליכים הללו מגדירים יותר מ-60 קריאות API לצורך יצירה ומניפולציה של תהליכים (threads). API חלופי מוכר הוא ה-OpenMP.

ניהול משאבים משותפים

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

המנגנון המשמש בדרך כלל להגנה על משאבים משותפים מוכר כ"מניעה הדדית" (mutual exclusion). קטע הקוד שאותו מסוגלת לבצע יחידת עיבוד אחת בזמן נתון מוכר כ"קטע קריטי" (critical section). מצב שבו יש הפרה של מניעה הדדית על-ידי שתי משימות בו-זמניות מוכר כ"מרוץ תהליכים" (race condition).

כשמדובר במערכת מסורתית בעלת מעבד אחד ניתן להשיג מניעה הדדית באמצעות נטרול של פסיקות בתוך הקטעים הקריטיים. במערכת מרובת ליבות, לעומת זאת, מנגנון זה לא יעבוד כיוון שהקוד עשוי להתבצע על יחידות עיבוד אחרות. תחת זאת ניתן להשתמש בתפיסה של "מנעולי spinlock": בתוך לולאה הדוקה משתמשים בפעולת test-and-set בלתי ניתנת לחלוקה של דגל משותף כדי להמתין עד שמעבד (או תהליכון) אחר מפנה את הדגל. באופן כללי היישום (המשתנה התלוי הארכיטקטוני) של מנגנון הנעילה עובר הפשטה על-ידי מערכת ההפעלה. המתכנת הוא האחראי לוודא שנעשה שימוש נכון ויעיל במנגנון הנעילה. חשוב מאוד להימנע ממצבים כמו "מבוי סתום" (deadlock – שני תהליכונים או יותר שכל אחד מהם ממתין שהאחר ישחרר משאב כלשהו) או livelock (מצב שבו כמה תהליכים ממשיכים לרוץ – מבלי להיחסם לגמרי כמו במבוי הסתום – אבל המערכת באופן כללי איננה מסוגלת להתקדם בגלל תבניות חוזרות של מלחמה לא פרודוקטיבית על משאבים). ניתן להימנע ממצבים של deadlock ושל livelock אם מתכננים את התוכנה בצורה קפדנית או לחלופין אם משתמשים במנגנונים ללא נעילות.

ולבסוף, פונקציות (לרבות טיפול בפסיקות) שיכולות לשמש כמה תהליכונים בו-זמנית חייבות להיות מוגנות כ-thread-free ו-re-entrant.

מסקנות

מעבדים מרובי ליבות כדוגמת ה- ARM11 MPCoreוה- Cortex-A9 MPCore מספקים פתרונות חוסכי אנרגיה וגמישים המסייעים להגדיל באופן דרמטי את עצמת העיבוד. תלוי ביישום היעד, ניתן לכוונן את המערכת באופן ידני באמצעות הקצאה של תפקידים ספציפיים לכל ליבה (מודל AMP), או לחלופין להשתמש באשכול שלם כחוות עיבוד מדרגית שקופה (מודל SMP).

כאשר משתמשים במערכת הפעלה מסוג SMP ניתן ליצור איזון עומסים של היישומים והפסיקות בכל המשאבים הזמינים. כדי למצות את היתרונות של עצמת העיבוד הנוספת וכדי לנצל את הטכנולוגיות חוסכות האנרגיה, כדוגמת Adaptive Shutdown (כיבוי אדפטיבי) ו-DVFS, ייתכן שיהיה צורך לתכנן או לתכנן מחדש אלגוריתמים בתוכנה באמצעות חשיפה מכוונת ומפורשת של המקביליות. אפשר לעשות זאת באמצעות מתודולוגיות פירוק שכיחות (פירוק נתונים, משימות ובלוקים פונקציונליים) הנתמכות על-ידי ספריות threading סטנדרטיות בתעשייה (PThreads ו-OpenMP).

מעבדי ה-MPCore של ARM תוכננו מא' עד ת' כדי לאפשר שיפור ביצועים מדרגי תוך צמצום צריכת ההספק והקניית היתרונות שמספק התכנון מרובה הליבות.

באותו הנושא באתר chiportal:

• ג'יימס ריינדרס, אוונגליסט התוכנה הראשי של אינטל:האתגר היום הוא לפתח יכולות עיבוד מקבילי לטיפול בנתונים