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

25 ביוני 2009

אין תגובות


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


Juval 006 Juval 005


אני מניח שיש מי ששואל את עצמו מה לעזזל אני עושה בכנס הזה. אז ככה. ברגע שאתה יכול לקנות בשוק החופשי מעבדים עם 4 ליבות ואו טו טו 8 ליבות ובקנה כבר מדברים על הרבה יותר. נושא ריבוי ליבות הופך להיות למה שנקרא בלע"ז Main Stream. חוק מור אמר שכל שנתיים ניתן יהיה לדחוס פי שניים טרנזיסטורים על כל גוק. אז תרשמו לכם את חוק גדי (שהוא תולדה ישירה של חוק מור), כל שנתיים מספר הליבות במעבד יגדל לפחות פי שניים. אז למי ששכח מה זה אקספוננטה, אז אחרי 8 בא 16 ואחר כך 32 ואז 64 ודרך אגב, זה לא תמיד יהיה כפולות יפות של שניים, בגלל שבאיזה שהוא שלב, מישהו בטח יעשה קלסטריזציה של העסק, ולכל קלסטר יהיה מעבד ניהול משלו, ואזור זכרון משלו, כך שפקטור שניים הוא רק המלצה וגבול תחתון שמרני.


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


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


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


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


Juval 007


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


בשלב הבא עלתה על הבמה מריאנה ביברשטיין מהמרכז המדעי של IBM בחיפה ודיברה על Clock Synchronization in Cell BE Traces. לקח לי קצת זמן להבין על מה היא דיברה, כי שכחתי שאני באקדמיה, ויש עוד עולמות חוץ מאינטל ו AMD. אז היא דיברה על המכונה הזו:


Untitled


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


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


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


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


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


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


Juval 015


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


Juval 037


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


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


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

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

כתיבת תגובה

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