Nigel Day, Enea AB
במאמרים קודמים, ניתחנו את האילוצים המובילים לאימוץ הנרחב של חומרה מרובת-ליבות (multicore) במערכות משובצות כמו גם במחשבים לשימוש כללי, ובחנו את המסגרות הארכיטקטוניות של מערכות הפעלה (OS) המשמשות להספקת מסגרת ליצירת מערכות מרובות-ליבות. במאמר זה, נדון במספר סוגיות הדורשות בחינה כאשר מפתחים יישומים העתידיים לרוץ ביעילות במערכות כאלה.
מה רץ היכן?
מערכות מרובות-ליבות ומרובות-מעבדים אחדות דואגות יותר ל-”הגינות” ולהיענות מאשר לביצועים הכוללים של יישומים מיוחדים. לדוגמה, מחשב ביתי חד-ליבה עשוי להיראות “מוקפא” בשעה שמופעלת סריקת וירוסים של הדיסק הקשיח, אולם במערכת מרובת-ליבות SMP המחשב יכול להישאר פעיל (אולם פתיחת יישום חדש תדרוש עדיין זמן בשל הפניות הנוספות לגישה לדיסק). עבור מערכת משובצת, אם התוכנה שלך היא מודולרית כראוי ובעלת ממשקים מוגדרים בבהירות, אזי אימוץ פשוט של ארכיטקטורת תוכנה SMP (תוך השארת התזמון וההסדרה תחת בקרת ה-OS) עשוי לענות לצורכי הביצועים שלך.
במקרים אחרים גישה הדורשת הפעלה ידנית יותר כדי להחליט היכן רצים התהליכים היא יותר מתאימה. היא לא רק יעילה יותר, אלא ששתי ארכיטקטורות התוכנה המוגבלת (SMP) והלא-סימטרית (AMP) מאפשרות לך למצב את התהליכים במגמה למזער את ההפרעה בתהליכים הקריטיים-בזמן. גישות אלו מספיקות לעתים קרובות כאשר משתמשים בריבוי-הליבות כדי לשפר את ה-scalability (היכולת לשנות קנה-מידה) בעומסים כבדים (לדוגמה, כדי לאפשר טיפול של מערכת טלקום ביותר שיחות בו-זמנית).
מהו צוואר-הבקבוק?
לעתים, אמנם, לא מספיק רק לפזר את התהליכים לליבות מרובות כדי להשיג את הביצועים שאתה רוצה: אתה עשוי להידרש לתכנן או לכתוב מחדש רכיבים קריטיים כדי לנצל טוב יותר את היתרונות של ריבוי הליבות. דרושה כאן תשומת-לב – קל לבחור במיטוב הלא-נכון! (ראה את המסגרת עבור דוגמה). הנושא הוא רחב מדי כדי לכסות אותו במאמר קצר כמו זה, אולם יש מספר עקרונות שיש לזכור:
•טפל ברכיבים הקריטיים-בזמן הדורשים יותר מידי זמן, ורכז מאמצי שיפור בהם! במיוחד, אתר אילו מהם שכיחים יותר. אם אינך עושה זאת, אתה עשוי לגלות שאתה מבזבז מאמצים במיטובים הלא-נכונים – או לבחור אלגוריתם המקנה רק יתרון מוגבל (ראה מסגרת).
•הימנע מלנעול דברים ליותר מידי זמן. כאשר דברים רצים במקביל, יש להסדיר את הגישה למבני נתונים קריטיים באמצעות מנגנונים דוגמת הרמזורים –(semaphores) וזה עשוי להתבטא בכך שתהליכים בליבות נפרדות מאורגנים בטור תוך המתנה לגישה אל משאב משותף. במקרים מסוימים טכניקות דוגמת המטמון-((caching עשויות להועיל; אם לדוגמה בסיס נתונים משמש ליישומי טלקום כדי לעקוב אחר חלוקת העומס לכרטיסי קו שונים, אזי אסטרטגיה אופטימית תממש יישומים המשתמשים בנתוני מטמון כדי לנקוט בהחלטות אודות מיקום העומס, ולגבות אותם על-ידי בדיקת אבטחה סופית כדי לוודא שהכרטיס הנבחר איננו סובל מעומס-יתר (אם בדיקת האבטחה מצביעה על בעיה, רענון המטמון וחישוב מחודש יפתרו את הבעיה). דבר זה עשוי לא ליצור איזון ממוטב של עומס העבודה, אך האם זה משנה?
•השתמש במבני נתונים מתאימים. לדוגמה, אם עצמים מסודרים פשוט יחדיו ברשימה מקושרת, חיפוש של כל אלה עשוי לספק תנאי מסוים בתהליך ליניארי. אם במקום זאת (או בנוסף) הם קשורים יחדיו על-ידי שרשרת רעש (hash chain), תהליכון נפרד עשוי לאתר שרשראות רעש שונות ולנצל את הליבות המרובות.
שים לב שבמערכת חד-ליבה דבר זה עשוי להאט את העבודה ולדרוש יותר מקום מאשר מתוכנן בקוד הנועד לשימוש במכונות בעלות ליבה אחת. למשל, האלגוריתמים המשמשים בגרסה המקבילית עשויים להיות פחות יעילים מאשר אלה המשמשים בגרסאות בעלות תהליכון (thread) יחיד, הזיכרון על-השבב עשוי להיות פחות יעיל בשל המבנה החדש של גישה לזיכרון, והשימוש ברמזורים עשוי להיות מיותר.
המאמר האחרון מתוך סדרה קצרה זו דן במגבלות מסוימות בשימוש בליבות מרובות.