יום עיון על Multi Core Tools אוניברסיטת תל אביב, חלק שני

27 ביוני 2009

אין תגובות

בשלב הבא עלה לבמה ערן סוחר מאוניברסיטת תל אביב ודיבר על Modeling the impact of interconnect technology on CMP architecture performance – RF-Interconnect as a test case. כשהוא התחיל לתאר את המחקר, חשבתי בהתחלה שהוא צוחק עלי. לקח לי כמה דקות לתפוס למה הפרויקט הזה בעצם מאד הגיוני. אז אני אנסה להוליך אתכם בתהליך שעברתי, צעד אחר צעד, כדי שתבינו מדוע. יש למחקר הזה כמובן תוצאת לואי, שכשהמעבד שערן הציג יהיה מסחרי, נצטרך להזהר עוד יותר, מלשים את המחשב הנייד על הברכיים (וזאת כמובן למען עתיד הגנום האנושי).

אז ככה, זה שיש לנו הרבה ליבות שצריכות לדבר אחת עם השניה, כבר הבנתם מהחלק הראשון. אז איך כמה מאות ליבות מתקשרות אחת עם השניה. הסתכלות תמימה אומרת בוא ונעשה את מה שאנחנו עושים כבר שנים במחשב שלנו, נשים Bus ונחבר אותם על ה Bus. זה עבד טוב ב ISA וב EISA וב IDE ואפילו ב SCSI אז החיים טובים. אז מסתבר שלא. אתה לא יכול לחבר כמה מאות יחידות על אותו Bus בלי Switch – ים ו Ruter – ים. אפילו USB נשבר באיזה שהוא שלב. מה שמוליך אותנו לזה שצריכה להיות בין הליבות רשת שלמה של חוטים ולא ניתן לשים את כולם על Bus אחד פשוט בלי מתווכים. עכשיו תוסיפו לבעיה של הטופולוגיה גם את ה Scale, ואתה נתקל בבעיה, שלא משנה איך תבנה את הרשת הזו, להעביר מידע מצד אחד של הפיסה לצד השני, יכול להיות תהליך שגם לוקח הרבה זמן, וגם צורך הרבה אנרגיה (המון פריקות וטעינות של קבלים).

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

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

Juval 025

למי שרוצה לראות איך נראה ג'וק כזה (כן כבר עשו אחד כזה, יש Proof of concept ואפילו Prototype) אז הנה:

Juval 022

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

 Juval 031

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

ואז, בדיוק שגמרתי את ארוחת הצהריים, נתקלתי פתאום ביורם אור-חן מהטכניון. יורם אור-חן והמעבדה לעיבוד אותות בטכניון היו ישות אחת, בדיוק כמו שאהוד והמעבדה הספרתית היו ישות אחת. הרבה מהסטודנטים שעשו את תרגיל החובה במעבדה הספרתית על ה 68000 של מוטורולה, הרבה שנים אחרי שעזבתי. לא ידעו שזה היה אחד הפרויקטים שעשיתי לאהוד. גם המעבדה של יורם, היתה מקום שבו שרצתי הרבה. מי שלא ראה את ציפי מכניסה באמצעות המפסקים את ה Rim Loader לאקליפס, לא ראה עבודת תכנות יפה מימיו. במעבדה של יורם עשיתי שם את ההנחיה הראשונה שלי, של פרויקט שנעשה על ה 29K של AMD. אם זה מעניין מישהו, זה היה כשלון טוטאלי. אבל יורם הבטיח לי שהוא סלח לי על זה.

Juval 036

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

לאחר הארוחה עלה על הבמה צביקה גוז מהטכניון. והציג לכולם את Simics.

Simics

במבט ראשון זה נראה לי כמו סוג של מכונה וירטואלית כמו ה Virtual PC של מיקרוסופט או ה Vmware Workstation של Vmware או ה Virtual Box של Sun ואפילו התלהבתי והתחלתי לשאול על התמיכה בגרפיקה. אבל פיספסתי את הנקודה לחלוטין. להגנתי אני רק יכול לומר שלא הייתי היחידי שפיספס את הנקודה, היו עוד כמה אנשי תעשיה בקהל, שהלכו לכיוון הזה (צרת רבים, נחמת טפשים). אז מה זה Simics בסופו של דבר ? מסתבר שזה זה:

Juval 040

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

Juval 055

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

המרצה הבא היה דב לבנגליק מחברת Freescale שזה תעשיה ולא אקדמיה. מי שלא יודע מה עושה Freescale מוזמן להציץ באתר שלהם. בסופו של דבר זה משהו שנקרא Embedded semiconductor solutions. הלקוח צריך מעבד יעודי, אז לוקחים מהספריה CPU, Uart, Timer קצת זכרון ועוד כמה דברים כאלה, מערבבים את זה טוב טוב עם קצת חול (למי שלא יודע אז רוב המעבדים כיום זה בעצם חול ים מזוהם בכמה חומרים כימיים). ומקבלים ג'וק אחד, שעושה את כל העבודה. קלאסי לטלפוניה, מכוניות, רשתות, ועוד כמה כאלה, שמעדיפים ג'וק אחד שעושה הכל, על הרבה ג'וקים מחוברים ביניהם על מעגל מודפס.

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

Juval 060

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

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

Juval 067

ואוו, אני שוב פעם ארוך מדי, ואני כידוע שונא פוסטים ארוכים, אז ההסתבכות שלי עם עולם ה Java תחכה לפוסט הבא.

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

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *