קליק על צוק - CTO של Cratus (חיישני IoT לשיפור תהליכים), מייסד ומייסד שותף של מספר סטארטאפים (כולל Rocket Realtime School, Neurensic ו-H2O.ai) עם כמה אקזיטים מוצלחים. קליף כתב את המהדר הראשון שלו בגיל 15 (פסקל ל-TRS Z-80)! הוא ידוע בעיקר בזכות עבודתו על C2 בג'אווה (ים הצמתים IR). מהדר זה הראה לעולם ש-JIT יכול לייצר קוד באיכות גבוהה, שהיה אחד הגורמים להופעתה של Java כאחת מפלטפורמות התוכנה המודרניות העיקריות. ואז קליף עזר ל- Azul Systems לבנות מיינפריים של 864 ליבות עם תוכנת ג'אווה טהורה שתמכה בהפסקות GC בערימה של 500 ג'יגה-בייט בתוך 10 מילישניות. באופן כללי, קליף הצליח לעבוד על כל ההיבטים של ה-JVM.

 
ההבראפוסט הזה הוא ראיון נהדר עם קליף. נדבר על הנושאים הבאים:

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

הראיון נערך על ידי:

• אנדריי סאטרין משירותי האינטרנט של אמזון. בקריירה שלו הוא הספיק לעבוד בפרויקטים אחרים לגמרי: הוא בדק את מסד הנתונים המבוזר NewSQL ב-Yandex, מערכת זיהוי ענן במעבדת קספרסקי, משחק מרובה משתתפים ב-Mail.ru ושירות לחישוב מחירי מט"ח בדויטשה בנק. מעוניין בבדיקת מערכות עורפיות ומערכות מבוזרות בקנה מידה גדול.
• ולדימיר סיטניקוב מ-Netcracker. עשר שנים של עבודה על הביצועים והמדרגיות של מערכת ההפעלה NetCracker, תוכנה המשמשת מפעילי טלקום לאוטומציה של תהליכי ניהול ציוד רשת ורשת. מתעניין בבעיות ביצועים של Java ו-Oracle Database. מחבר של יותר מתריסר שיפורי ביצועים במנהל ההתקן הרשמי של PostgreSQL JDBC.

מעבר למיטובים ברמה נמוכה

אנדרו: אתה שם גדול בעולם הידור JIT, Java ועבודת ביצועים בכלל, נכון? 

צוּק: זה ככה!

אנדרו: נתחיל בכמה שאלות כלליות על עבודת ביצוע. מה אתה חושב על הבחירה בין אופטימיזציות ברמה גבוהה לנמוכה כמו עבודה ברמת המעבד?

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

איך לעשות שיפוץ גדול

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

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

מודל עלות

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

צוּק: בוודאי. נולדתי בעידן שבו ביצועי המעבד היו חשובים ביותר. והעידן הזה חוזר שוב - הגורל אינו חף מאירוניה. התחלתי לחיות בימי מכונות שמונה סיביות; המחשב הראשון שלי עבד עם 256 בתים. בדיוק בייטים. הכל היה קטן מאוד. היה צריך לספור את ההוראות, וכשהתחלנו להתקדם בערימת שפות התכנות, השפות תפסו יותר ויותר. היה אסמבלר, אחר כך Basic, ואז C ו-C טיפלו בהרבה מהפרטים, כמו הקצאת פנקס ובחירת הוראות. אבל הכל היה די ברור שם, ואם הייתי מצביע על מופע של משתנה, אז הייתי מקבל עומס, והעלות של ההוראה הזו ידועה. החומרה מייצרת מספר מסוים של מחזורי מכונה, כך שניתן לחשב את מהירות הביצוע של דברים שונים פשוט על ידי חיבור כל ההוראות שאתה הולך להפעיל. כל השוואה/בדיקה/סניף/קריאה/טעינה/חנות אפשר להוסיף ולומר: זה זמן הביצוע בשבילך. כאשר עובדים על שיפור הביצועים, בהחלט תשימו לב לאילו מספרים מתאימים למחזורים חמים קטנים. 
אבל ברגע שאתה עובר ל-Java, Python ודברים דומים, אתה מהר מאוד מתרחק מחומרה ברמה נמוכה. מה העלות של קריאה לגטר ב-Java? אם JIT ב-HotSpot נכון משולב, הוא ייטען, אבל אם הוא לא עשה זאת, זו תהיה קריאת פונקציה. מכיוון שהקריאה נמצאת בלולאה חמה, היא תעקוף את כל שאר האופטימיזציות בלולאה זו. לכן, העלות האמיתית תהיה הרבה יותר גבוהה. ומיד אתה מאבד את היכולת להסתכל על פיסת קוד ולהבין שעלינו לבצע אותה מבחינת מהירות השעון של המעבד, הזיכרון והמטמון בשימוש. כל זה הופך למעניין רק אם אתה באמת נכנס לביצועים.
כעת אנו מוצאים את עצמנו במצב שבו מהירות המעבד כמעט לא עלתה במשך עשור. הימים ההם חזרו! אתה כבר לא יכול לסמוך על ביצועים טובים עם חוט בודד. אבל אם אתה פתאום נכנס למחשוב מקביל, זה קשה להפליא, כולם מסתכלים עליך כמו ג'יימס בונד. תאוצות פי עשרה כאן מתרחשות בדרך כלל במקומות שבהם מישהו פישל משהו. במקביל דורש עבודה רבה. כדי להשיג את המהירות הזו פי XNUMX, אתה צריך להבין את מודל העלות. מה וכמה זה עולה? וכדי לעשות זאת, עליך להבין כיצד הלשון מתאימה לחומרה הבסיסית.
מרטין תומפסון בחר מילה נהדרת לבלוג שלו סימפטיה מכנית! אתה צריך להבין מה החומרה הולכת לעשות, איך בדיוק היא תעשה את זה, ולמה היא עושה את מה שהיא עושה מלכתחילה. באמצעות זה, די קל להתחיל לספור הוראות ולהבין לאן הולך זמן הביצוע. אם אין לך את ההכשרה המתאימה, אתה פשוט מחפש חתול שחור בחדר חשוך. אני רואה אנשים מייעלים ביצועים כל הזמן שאין להם מושג מה לעזאזל הם עושים. הם סובלים הרבה ולא מתקדמים הרבה. וכשאני לוקח את אותה פיסת קוד, מכניס כמה פריצות קטנות ומקבל מהירות של פי חמישה או עשרה, הם אומרים: טוב, זה לא הוגן, כבר ידענו שאתה טוב יותר. מדהים. על מה אני מדבר... מודל העלות הוא על איזה סוג קוד אתה כותב וכמה מהר הוא פועל בממוצע בתמונה הגדולה.

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

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

אימון אופטימיזציה ברמה נמוכה

אנדרו: האם יש דרך קלה יותר להיכנס?

צוּק: כן ולא. החומרה שכולנו משתמשים בה לא השתנתה כל כך עם הזמן. כולם משתמשים ב-x86, למעט סמארטפונים של Arm. אם אתה לא עושה סוג של הטמעת הארדקור, אתה עושה את אותו הדבר. בסדר, תמשיך הלאה. ההוראות גם לא השתנו במשך מאות שנים. אתה צריך ללכת ולכתוב משהו באסמבלי. לא הרבה, אבל מספיק כדי להתחיל להבין. אתה מחייך, אבל אני מדבר ברצינות מוחלטת. אתה צריך להבין את ההתאמה בין שפה לחומרה. אחרי זה אתה צריך ללכת לכתוב קצת ולעשות מהדר צעצועים קטן לשפת צעצועים קטנה. דמוי צעצוע אומר שהוא צריך להיעשות בפרק זמן סביר. זה יכול להיות סופר פשוט, אבל זה חייב ליצור הוראות. פעולת הפקת הוראה תעזור לך להבין את מודל העלות של הגשר בין הקוד ברמה הגבוהה שכולם כותבים לבין קוד המכונה שפועל על החומרה. התכתבות זו תצרב במוח בזמן כתיבת המהדר. אפילו המהדר הפשוט ביותר. לאחר מכן, אתה יכול להתחיל להסתכל על Java ועל העובדה שהתהום הסמנטית שלה הרבה יותר עמוקה, והרבה יותר קשה לבנות עליה גשרים. בג'אווה הרבה יותר קשה להבין אם הגשר שלנו יצא טוב או רע, מה יגרום לו להתפרק ומה לא. אבל אתה צריך איזושהי נקודת התחלה שבה אתה מסתכל על הקוד ותבין: "כן, הטרקטור הזה צריך להיות מוטבע בכל פעם." ואז מסתבר שלפעמים זה קורה, חוץ מהמצב שהשיטה הופכת להיות גדולה מדי, וה-JIT מתחיל להטמיע הכל. ניתן לחזות את הביצועים של מקומות כאלה באופן מיידי. בדרך כלל מגברים עובדים טוב, אבל אז אתה מסתכל על לולאות חמות גדולות ומבין שיש שם כמה קריאות פונקציה שמרחפות שם שלא יודעות מה הן עושות. זו הבעיה עם השימוש הנרחב בגטרים, הסיבה לכך שהם לא משובצים היא שלא ברור אם הם גטרים. אם יש לך בסיס קוד קטן במיוחד, אתה יכול פשוט לזכור אותו ואז לומר: זה מגטר, וזה מגדיר. בבסיס קוד גדול, כל פונקציה חיה את ההיסטוריה שלה, שבאופן כללי, לא ידועה לאיש. הפרופיל אומר שאיבדנו 24% מהזמן בלולאה כלשהי וכדי להבין מה הלולאה הזו עושה, עלינו להסתכל על כל פונקציה בפנים. אי אפשר להבין זאת מבלי ללמוד את הפונקציה, וזה מאט ברצינות את תהליך ההבנה. לכן אני לא משתמש בגטרים ובסטרים, הגעתי לרמה חדשה!
היכן ניתן להשיג את מודל העלות? ובכן, אתה יכול לקרוא משהו, כמובן... אבל אני חושב שהדרך הטובה ביותר היא לפעול. יצירת מהדר קטן תהיה הדרך הטובה ביותר להבין את מודל העלות ולהתאים אותו לראש שלך. מהדר קטן שיתאים לתכנות מיקרוגל הוא משימה למתחילים. ובכן, אני מתכוון, אם כבר יש לך כישורי תכנות, אז זה אמור להספיק. כל הדברים האלה כמו לנתח מחרוזת שיש לך כביטוי אלגברי כלשהו, ​​לחלץ משם הוראות לפעולות מתמטיות בסדר הנכון, לקחת את הערכים הנכונים מרגיסטרים - כל זה נעשה בבת אחת. ובזמן שאתה עושה את זה, זה יהיה טבוע במוח שלך. אני חושב שכולם יודעים מה מהדר עושה. וזה ייתן הבנה של מודל העלות.

דוגמאות מעשיות לשיפור ביצועים

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

צוּק: מבני מידע. אגב, כן, לא לימדתי את השיעורים האלה הרבה זמן... בית ספר לרקטות. זה היה כיף, אבל זה דרש הרבה מאמץ, ויש לי גם חיים! בסדר. אז, באחת השיעורים הגדולים והמעניינים, "לאן הביצועים שלך הולכים", נתתי לתלמידים דוגמה: שניים וחצי גיגה-בייט של נתוני פינטק נקראו מקובץ CSV ואז הם היו צריכים לחשב את מספר המוצרים שנמכרו . נתוני שוק קרציות רגילים. מנות UDP שהומרו לפורמט טקסט מאז שנות ה-70. בורסת הסחורות של שיקגו - כל מיני דברים כמו חמאה, תירס, פולי סויה, דברים כאלה. היה צורך לספור מוצרים אלה, מספר העסקאות, נפח התנועה הממוצע של כספים וסחורות וכו'. זו מתמטיקה די פשוטה למסחר: מצא את קוד המוצר (שזה 1-2 תווים בטבלת ה-hash), קבל את הסכום, הוסף אותו לאחד מערכי המסחר, הוסף נפח, הוסף ערך ועוד כמה דברים. מתמטיקה פשוטה מאוד. יישום הצעצוע היה מאוד פשוט: הכל נמצא בקובץ, אני קורא את הקובץ ועובר בו, מחלק רשומות בודדות למחרוזות Java, מחפש בהן את הדברים הנחוצים ומחבר אותם לפי המתמטיקה שתוארה למעלה. וזה עובד באיזו מהירות נמוכה.

עם הגישה הזו, ברור מה קורה, ומחשוב מקביל לא יעזור, נכון? מסתבר שניתן להשיג פי חמישה בביצועים פשוט על ידי בחירת מבני הנתונים הנכונים. וזה מפתיע אפילו מתכנתים מנוסים! במקרה הספציפי שלי, החוכמה הייתה שאסור לבצע הקצאות זיכרון בלולאה חמה. ובכן, זו לא כל האמת, אבל באופן כללי - אתה לא צריך להדגיש "פעם ב-X" כאשר X גדול מספיק. כאשר X הוא שניים וחצי גיגה-בייט, לא כדאי להקצות שום דבר "פעם לכל אות", או "פעם בשורה", או "פעם לכל שדה", משהו כזה. זה המקום שבו הזמן מבלה. איך זה בכלל עובד? דמיינו אותי מתקשר String.split() או BufferedReader.readLine(). Readline יוצר מחרוזת מקבוצה של בתים שהגיעו דרך הרשת, פעם אחת עבור כל שורה, עבור כל אחת ממאות מיליוני השורות. אני לוקח את הקו הזה, מנתח אותו וזורק אותו. למה אני זורק את זה - ובכן, כבר עיבדתי את זה, זה הכל. אז עבור כל בייט שנקרא מה-2.7G האלה, שתי תווים ייכתבו בשורה, כלומר כבר 5.4G, ואני לא צריך אותם לשום דבר נוסף, אז הם נזרקים. אם מסתכלים על רוחב הפס של הזיכרון, אנחנו מעמיסים 2.7G שעובר דרך אפיק הזיכרון והזיכרון במעבד, ואז נשלח פי שניים לקו ששוכן בזיכרון, וכל זה מתפרק כאשר כל קו חדש נוצר. אבל אני צריך לקרוא את זה, החומרה קוראת את זה, גם אם הכל מתקלקל אחר כך. ואני צריך לרשום את זה כי יצרתי שורה והמטמון מלא - המטמון לא יכול להכיל 2.7G. אז על כל בייט שאני קורא אני קורא עוד שני בייטים וכותב עוד שני בייטים, ובסופו של דבר יש להם יחס של 4:1 - ביחס הזה אנחנו מבזבזים את רוחב הפס של הזיכרון. ואז מסתבר שאם כן String.split() - זו לא הפעם האחרונה שאני עושה את זה, אולי יש עוד 6-7 שדות בפנים. אז הקוד הקלאסי של קריאת CSV ולאחר מכן ניתוח המחרוזות מביא לבזבוז רוחב פס של זיכרון של בערך 14:1 ביחס למה שהיית רוצה לקבל בפועל. אם תזרוק את הבחירות האלה, תוכל לקבל מהירות של פי חמישה.

וזה לא כל כך קשה. אם אתה מסתכל על הקוד מזווית נכונה, הכל הופך פשוט למדי ברגע שאתה מבין את הבעיה. אתה לא צריך להפסיק להקצות זיכרון לגמרי: הבעיה היחידה היא שאתה מקצה משהו והוא מיד מת, ועל הדרך זה שורף משאב חשוב, שבמקרה הזה הוא רוחב הפס של הזיכרון. וכל זה מביא לירידה בתפוקה. ב-x86 אתה בדרך כלל צריך לצרוב מחזורי מעבד באופן פעיל, אבל כאן שרפת את כל הזיכרון הרבה קודם. הפתרון הוא להפחית את כמות ההפרשות. 
החלק השני של הבעיה הוא שאם אתה מפעיל את הפרופיילר כשפס הזיכרון נגמר, בדיוק כשזה קורה, אתה בדרך כלל מחכה שהמטמון יחזור כי הוא מלא בזבל שהרגע הפקתם, כל השורות האלה. לכן, כל פעולת טעינה או חנות הופכת לאטית, מכיוון שהן מובילות להחמצות מטמון - המטמון כולו הפך לאיטי, מחכה לאשפה שייצא ממנו. לכן, הפרופיילר פשוט יראה רעש אקראי חם מרוח לאורך כל הלולאה - לא תהיה הוראה או מקום נפרד בקוד. רק רעש. ואם מסתכלים על מחזורי ה-GC, כולם מהדור הצעיר וסופר מהירים - מיקרו-שניות או אלפיות-שניות מקסימום. הרי כל הזיכרון הזה מת מיידית. אתה מקצה מיליארדי ג'יגה-בייט, והוא חותך אותם, חותך אותם ושוב חותך אותם. כל זה קורה מהר מאוד. מסתבר שיש מחזורי GC זולים, רעש חם לאורך כל המחזור, אבל אנחנו רוצים לקבל מהירות של פי 5. ברגע זה, משהו צריך להיסגר בראש שלך ולהישמע: "למה זה?!" גלישת רצועת זיכרון אינה מוצגת במאתר הבאגים הקלאסי; עליך להפעיל את מאתר הבאגים של מונה ביצועי החומרה ולראות אותו בעצמך ובאופן ישיר. אך לא ניתן לחשוד בכך ישירות משלושת התסמינים הללו. הסימפטום השלישי הוא כשאתה מסתכל על מה שאתה מדגיש, תשאל את הפרופיל, והוא עונה: "עשית מיליארד שורות, אבל ה-GC עבד בחינם." ברגע שזה קורה, אתה מבין שיצרת יותר מדי חפצים ושרפת את כל נתיב הזיכרון. יש דרך להבין את זה, אבל זה לא ברור. 

הבעיה היא במבנה הנתונים: המבנה החשוף שעומד בבסיס כל מה שקורה, הוא גדול מדי, הוא 2.7G בדיסק, אז יצירת עותק של הדבר הזה הוא מאוד לא רצוי - אתה רוצה לטעון אותו ממאגר הבתים של הרשת באופן מיידי לתוך האוגרים, כדי לא לקרוא-לכתוב לקו הלוך ושוב חמש פעמים. לרוע המזל, Java לא נותנת לך ספרייה כזו כחלק מה-JDK כברירת מחדל. אבל זה טריוויאלי, נכון? בעיקרו של דבר, אלו הן 5-10 שורות קוד שישמשו ליישום מטעין מחרוזת מאגר משלך, שחוזר על ההתנהגות של מחלקת המחרוזות, תוך שהוא עטוף סביב מאגר הבייטים הבסיסי. כתוצאה מכך, מסתבר שאתה עובד כמעט כאילו עם מחרוזות, אבל למעשה מצביעים למאגר נעים לשם, והבתים הגולמיים לא מועתקים לשום מקום, וכך נעשה שימוש חוזר באותם מאגרים, ו מערכת ההפעלה שמחה לקחת על עצמך את הדברים שהיא נועדה להם, כמו חציצה כפולה נסתרת של מאגרי בתים אלה, ואתה כבר לא טוחן בזרם אינסופי של נתונים מיותרים. אגב, אתה מבין שכאשר עובדים עם GC, מובטח שכל הקצאת זיכרון לא תהיה גלויה למעבד לאחר מחזור ה-GC האחרון? לכן, כל זה לא יכול להיות במטמון, ואז מתרחשת החמצה מובטחת של 100%. כשעובדים עם מצביע, ב-x86, הפחתת אוגר מהזיכרון לוקחת 1-2 מחזורי שעון, וברגע שזה קורה, אתה משלם, משלם, משלם, כי הכל פועל תשעה מטמונים – וזו העלות של הקצאת זיכרון. ערך אמיתי.

במילים אחרות, מבני נתונים הם הדבר שהכי קשה לשנות. וברגע שאתה מבין שבחרת במבנה הנתונים הלא נכון שיהרוג את הביצועים בהמשך, בדרך כלל יש הרבה עבודה לעשות, אבל אם לא תעשה זאת, המצב יחמיר. קודם כל, אתה צריך לחשוב על מבני נתונים, זה חשוב. העלות העיקרית כאן נופלת על מבני נתונים שמנים, שמתחילים להיות בשימוש בסגנון "העתקתי את מבנה הנתונים X למבנה הנתונים Y כי אני אוהב יותר את הצורה של Y." אבל פעולת ההעתקה (שנראית זולה) למעשה מבזבזת את רוחב הפס של הזיכרון ושם קבור כל זמן הביצוע המבוזבז. אם יש לי מחרוזת ענקית של JSON ואני רוצה להפוך אותה לעץ DOM מובנה של POJOs או משהו כזה, הפעולה של ניתוח המחרוזת הזו ובניית ה-POJO, ואז לגשת שוב ל-POJO מאוחר יותר, תגרום לעלות מיותרת - זה לא זול. אלא אם אתה מתרוצץ סביב POJOs לעתים קרובות יותר מאשר אתה מתרוצץ סביב מחרוזת. במקום זאת, אתה יכול לנסות לפענח את המחרוזת ולחלץ משם רק את מה שאתה צריך, מבלי להפוך אותו לשום POJO. אם כל זה קורה בנתיב שממנו נדרשים ביצועים מקסימליים, בלי POJOs בשבילך, אתה צריך איכשהו לחפור ישירות בקו.

למה ליצור שפת תכנות משלך

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

צוּק: לא שפה, אלא מהדר. שפה ומהדר הם שני דברים שונים. ההבדל הכי חשוב הוא בראש שלך. 

אנדרו: אגב, עד כמה שידוע לי, אתה מתנסה ביצירת שפות משלך. בשביל מה?

צוּק: כי אני יכול! אני חצי פנסיונר, אז זה התחביב שלי. כל חיי יישמתי שפות של אנשים אחרים. עבדתי הרבה גם על סגנון הקידוד שלי. וגם כי אני רואה בעיות בשפות אחרות. אני רואה שיש דרכים טובות יותר לעשות דברים מוכרים. והייתי משתמש בהם. פשוט נמאס לי לראות בעיות בעצמי, ב-Java, ב-Python, בכל שפה אחרת. אני כותב עכשיו ב-React Native, JavaScript ו-Elm כתחביב שלא עוסק בפרישה, אלא בעבודה פעילה. אני כותב גם ב-Python, וככל הנראה, אמשיך לעבוד על למידת מכונה עבור קצה ג'אווה. יש הרבה שפות פופולריות ולכולן יש תכונות מעניינות. כל אחד טוב בדרכו שלו ואתה יכול לנסות לרכז את כל התכונות האלה ביחד. אז, אני לומד דברים שמעניינים אותי, התנהגות השפה, מנסה להמציא סמנטיקה סבירה. ועד עכשיו אני מצליח! כרגע אני נאבק בסמנטיקה של זיכרון, כי אני רוצה שזה יהיה כמו ב-C וב-Java, ולקבל מודל זיכרון חזק וסמנטיקה של זיכרון לעומסים וחנויות. במקביל, יש להסיק סוג אוטומטי כמו ב- Haskell. כאן, אני מנסה לערבב מסקנות מסוג Haskell עם עבודת זיכרון גם ב-C וגם ב-Java. זה מה שעשיתי ב-2-3 החודשים האחרונים, למשל.

אנדרו: אם אתה בונה שפה שלוקחת היבטים טובים יותר משפות אחרות, אתה חושב שמישהו יעשה את ההיפך: לקחת את הרעיונות שלך ולהשתמש בהם?

צוּק: כך בדיוק מופיעות שפות חדשות! מדוע Java דומה ל-C? כי ל-C היה תחביר טוב שכולם הבינו וג'אווה קיבלה השראה מהתחביר הזה, הוסיפו בטיחות סוג, בדיקת גבולות מערך, GC, והם גם שיפרו כמה דברים מ-C. הם הוסיפו דברים משלהם. אבל הם קיבלו השראה די הרבה, נכון? כולם עומדים על כתפי הענקים שבאו לפניכם – כך מתקדמת.

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

צוּק: ובכן, אני כותב C כבר עידן ועידנים, עם כל ה-malloc הזה וחינמי, ומנהל ידנית את כל החיים. אתה יודע, 90-95% מזמן החיים בשליטה ידנית יש אותו מבנה. וזה מאוד מאוד כואב לעשות את זה באופן ידני. הייתי רוצה שהמהדר פשוט יגיד לך מה קורה שם ומה השגת עם הפעולות שלך. לגבי דברים מסוימים, בודק ההשאלה עושה זאת מחוץ לקופסה. והוא אמור להציג מידע באופן אוטומטי, להבין הכל, ואפילו לא להכביד עליי בהצגת ההבנה הזו. הוא חייב לבצע לפחות ניתוח בריחה מקומי, ורק אם הוא נכשל, אז הוא צריך להוסיף הערות טיפוס שיתארו את אורך החיים – וסכמה כזו היא הרבה יותר מורכבת מבוקר שאווה, או בעצם כל בודק זיכרון קיים. הבחירה בין "הכל בסדר" לבין "אני לא מבין כלום" - לא, חייב להיות משהו יותר טוב. 
לכן, כמי שכתב הרבה קוד ב-C, אני חושב שתמיכה בשליטה אוטומטית לכל החיים היא הדבר החשוב ביותר. נמאס לי גם מכמה ש-Java משתמשת בזיכרון והתלונה העיקרית היא ה-GC. כאשר תקצה זיכרון ב-Java, לא תקבל בחזרה את הזיכרון שהיה מקומי במחזור ה-GC האחרון. זה לא המקרה בשפות עם ניהול זיכרון מדויק יותר. אם אתה מתקשר ל-malloc, אתה מקבל מיד את הזיכרון שבדרך כלל היה בשימוש. בדרך כלל אתה עושה כמה דברים זמניים עם הזיכרון ומיד מחזירים אותו בחזרה. והוא חוזר מיד לבריכת המלוק, ומחזור המלוק הבא שולף אותו שוב. לכן, השימוש בפועל בזיכרון מצטמצם למכלול החפצים החיים בזמן נתון, בתוספת דליפות. ואם הכל לא דולף בצורה מגונה לחלוטין, רוב הזיכרון מסתיים במטמונים ובמעבד, וזה עובד מהר. אבל דורש הרבה ניהול זיכרון ידני עם malloc ו-free call בסדר הנכון, במקום הנכון. חלודה יכולה להתמודד עם זה כראוי בעצמה, ובמקרים רבים לתת ביצועים טובים עוד יותר, שכן צריכת הזיכרון מצטמצמת רק לחישוב הנוכחי - בניגוד להמתנה למחזור ה-GC הבא כדי לפנות זיכרון. כתוצאה מכך, קיבלנו דרך מעניינת מאוד לשפר ביצועים. ודי חזק - זאת אומרת, עשיתי דברים כאלה בעת עיבוד נתונים עבור פינטק, וזה איפשר לי לקבל מהירות של בערך חמש פעמים. זו דחיפה די גדולה, במיוחד בעולם שבו המעבדים לא נעשים מהירים יותר ואנחנו עדיין מחכים לשיפורים.

קריירה מהנדס ביצועים

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

צוּק: אני מתכנת די הרבה זמן והצלחתי לקחת הרבה שיעורים שונים. וכשאנשים אומרים: "הו, אתה זה שעשית JIT עבור ג'אווה!", זה תמיד מצחיק. אבל לפני כן, עבדתי על שיבוט של PostScript - השפה שבה השתמשה אפל פעם עבור מדפסות הלייזר שלה. ולפני כן עשיתי יישום של שפת Forth. אני חושב שהנושא המשותף עבורי הוא פיתוח כלים. כל חיי יצרתי כלים שאיתם אנשים אחרים כותבים את התוכניות המגניבות שלהם. אבל הייתי מעורב גם בפיתוח מערכות הפעלה, דרייברים, מאפי באגים ברמת ליבה, שפות לפיתוח מערכת הפעלה, שהתחילו טריוויאליים, אבל עם הזמן הפכו מורכבים יותר ויותר. אבל הנושא העיקרי הוא עדיין פיתוח כלים. חלק גדול מהחיים שלי עבר בין אזול לסאן, וזה היה על ג'אווה. אבל כשנכנסתי ל-Big Data ולמידת מכונה, החזרתי את הכובע המפואר שלי ואמרתי, "אוי, עכשיו יש לנו בעיה לא טריוויאלית, ויש הרבה דברים מעניינים שקורים ואנשים שעושים דברים." זהו נתיב פיתוח מצוין.

כן, אני מאוד אוהב מחשוב מבוזר. העבודה הראשונה שלי הייתה כסטודנטית ב-C, בפרויקט פרסום. זה הופץ מחשוב על שבבי Zilog Z80 שאספו נתונים עבור OCR אנלוגי, שהופק על ידי מנתח אנלוגי אמיתי. זה היה נושא מגניב ומטורף לגמרי. אבל היו בעיות, חלק מסוים לא זוהה נכון, אז היית צריך להוציא תמונה ולהראות לאדם שכבר היה יכול לקרוא בעיניים ולדווח מה כתוב, ולכן היו עבודות עם נתונים, והעבודות האלה הייתה להם שפה משלהם. היה backend שעיצב את כל זה - Z80s פועלים במקביל למסופי vt100 פועלים - אחד לאדם, והיה מודל תכנות מקביל ב-Z80. איזו פיסת זיכרון משותפת המשותף לכל ה-Z80s בתצורת כוכב; גם המטוס האחורי היה משותף, ומחצית מזיכרון ה-RAM חולק בתוך הרשת, וחצי נוסף היה פרטי או הלך למשהו אחר. מערכת מבוזרת מקבילה מורכבת משמעותית עם זיכרון משותף... חצי משותף. מתי זה היה... אני אפילו לא זוכר, אי שם באמצע שנות ה-80. לפני די הרבה זמן. 
כן, נניח ש-30 שנה זה די הרבה זמן. בעיות הקשורות למחשוב מבוזר קיימות כבר די הרבה זמן; אנשים היו במלחמה עם ייוולף-אשכולות. אשכולות כאלה נראים כמו... לדוגמא: יש אתרנט וה-x86 המהיר שלך מחובר ל-Ethernet הזה, ועכשיו אתה רוצה להשיג זיכרון משותף מזויף, כי אף אחד לא יכול היה לעשות קידוד מחשוב מבוזר אז, זה היה קשה מדי ולכן יש היה זיכרון משותף מזויף עם דפי זיכרון הגנה ב-x86, ואם כתבת לדף הזה, אז אמרנו למעבדים אחרים שאם הם ניגשים לאותו זיכרון משותף, יהיה צורך לטעון אותו ממך, ובכך משהו כמו פרוטוקול לתמיכה קוהרנטיות מטמון הופיעה ותוכנה לכך. קונספט מעניין. הבעיה האמיתית, כמובן, הייתה משהו אחר. כל זה עבד, אבל מהר מאוד קיבלת בעיות ביצועים, כי אף אחד לא הבין את המודלים של הביצועים ברמה מספיק טובה - אילו דפוסי גישה לזיכרון היו שם, איך לוודא שהצמתים לא ינגנו זה לזה בלי סוף וכו'.

מה שהגעתי אליו ב-H2O הוא שהמפתחים עצמם הם שאחראים לקבוע היכן מקביליות מסתתרת ואיפה לא. הגעתי למודל קידוד שהפך את כתיבת קוד בעל ביצועים גבוהים לקלה ופשוטה. אבל כתיבת קוד שרץ לאט זה קשה, זה ייראה רע. אתה צריך לנסות ברצינות לכתוב קוד איטי, תצטרך להשתמש בשיטות לא סטנדרטיות. קוד הבלימה נראה במבט ראשון. כתוצאה מכך, אתה בדרך כלל כותב קוד שרץ מהר, אבל אתה צריך להבין מה לעשות במקרה של זיכרון משותף. כל זה קשור למערכים גדולים וההתנהגות שם דומה למערכים גדולים שאינם נדיפים בג'אווה מקבילה. כלומר, תארו לעצמכם ששני שרשורים כותבים למערך מקביל, אחד מהם מנצח, והשני, בהתאם, מפסיד, ואתם לא יודעים איזה מהם. אם הם לא הפכפכים, אז ההזמנה יכולה להיות מה שאתה רוצה - וזה עובד ממש טוב. לאנשים באמת אכפת מסדר הפעולות, הם שמים תנודתיות במקומות הנכונים, והם מצפים לבעיות ביצועים הקשורות לזיכרון במקומות הנכונים. אחרת, הם פשוט היו כותבים קוד בצורה של לולאות מ-1 עד N, כאשר N הוא כמה טריליונים, בתקווה שכל המקרים המורכבים יהפכו אוטומטית מקבילים - וזה לא עובד שם. אבל ב-H2O זה לא ג'אווה ולא סקאלה; אתה יכול לראות את זה "ג'אווה מינוס מינוס" אם אתה רוצה. זהו סגנון תכנות מאוד ברור ודומה לכתיבת קוד פשוט של C או Java עם לולאות ומערכים. אך יחד עם זאת, ניתן לעבד זיכרון בטרה-בייט. אני עדיין משתמש ב-H2O. אני משתמש בו מדי פעם בפרויקטים שונים – ועדיין הוא הדבר המהיר ביותר, מהיר עשרות מונים מהמתחרים שלו. אם אתה עושה ביג דאטה עם נתונים עמודים, קשה מאוד לנצח את H2O.

אתגרים טכניים

אנדרו: מה היה האתגר הכי גדול שלך בכל הקריירה שלך?

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

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

הבעיה היא שאם אתה מוסיף שיטות הכפופות ל-inlining, הגדלה והגדלה של שטח ה-inlining, ערכת הערכים המשומשת עולה מיידית על מספר הרשמים, ואתה צריך לחתוך אותם. הרמה הקריטית מגיעה בדרך כלל כשהמקצה מוותר, ומועמד טוב אחד לשפוך שווה אחר, אתה תמכור כמה דברים פראיים בדרך כלל. הערך של inlining כאן הוא שאתה מאבד חלק מהתקורה, תקורה להתקשרות ולשמירה, אתה יכול לראות את הערכים בפנים ויכול לייעל אותם עוד יותר. עלות ההטמעה היא שנוצרים מספר רב של ערכים חיים, ואם מקצה הרישום שלך נשרף יותר מהנדרש, אתה מפסיד מיד. לכן, לרוב המקצים יש בעיה: כאשר ה-inlining חוצה קו מסוים, כל דבר בעולם מתחיל להצטמצם וניתן לשטוף את הפרודוקטיביות באסלה. מי שמיישם את המהדר מוסיפים כמה היוריסטיות: למשל, להפסיק את ההטמעה, החל מגודל גדול מספיק, מכיוון שהקצאות יהרסו הכל. כך נוצר קינק בגרף הביצועים - אתה מוטבע, מוטבע, הביצועים לאט לאט גדלים - ואז בום! - הוא נופל למטה כמו ג'ק מהיר כי הנחתת יותר מדי. כך הכל עבד לפני הופעת ג'אווה. ג'אווה דורשת הרבה יותר אינליין, אז נאלצתי להפוך את ה-allocator שלי להרבה יותר אגרסיבי כך שהוא יתיישר ולא יקרוס, ואם אתה מכניס יותר מדי, הוא מתחיל להישפך, אבל אז עדיין מגיע הרגע של "לא יותר לשפוך". זו תצפית מעניינת והיא פשוט הגיעה אלי משום מקום, לא מובן מאליו, אבל זה השתלם היטב. השתמשתי ב-inlining אגרסיבי וזה לקח אותי למקומות שבהם הביצועים של Java ו-C עובדים זה לצד זה. הם ממש קרובים - אני יכול לכתוב קוד ג'אווה שהוא מהיר משמעותית מקוד C ודברים כאלה, אבל בממוצע, בתמונה הגדולה של הדברים, הם בערך ברי השוואה. אני חושב שחלק מהכשרון הזה הוא מקצין הרשומות, שמאפשר לי לשלב בצורה טיפשית ככל האפשר. אני פשוט מצרפת את כל מה שאני רואה. השאלה כאן היא האם המקצה עובד טוב, האם התוצאה היא קוד שעובד בצורה חכמה. זה היה אתגר גדול: להבין את כל זה ולגרום לזה לעבוד.

קצת על הקצאת רישום ורב ליבות

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

צוּק: בהחלט! הקצאת רישום היא תחום שבו אתה מנסה למצוא כמה היוריסטיות כדי לפתור בעיה שלמה NP. ואתה אף פעם לא יכול להשיג פתרון מושלם, נכון? זה פשוט בלתי אפשרי. תראה, קומפילציה של Ahead of Time - זה גם עובד גרוע. השיחה כאן עוסקת בכמה מקרים ממוצעים. על ביצועים טיפוסיים, אז אתה יכול ללכת למדוד משהו שאתה חושב שהוא ביצועים טיפוסיים טובים - אחרי הכל, אתה פועל לשפר אותו! הקצאת רישום היא נושא שכולו ביצועים. ברגע שיש לך את אב הטיפוס הראשון, הוא עובד ומצייר את מה שצריך, עבודת הביצוע מתחילה. אתה צריך ללמוד למדוד היטב. למה זה חשוב? אם יש לך נתונים ברורים, אתה יכול להסתכל על אזורים שונים ולראות: כן, זה עזר כאן, אבל שם הכל נשבר! עולים כמה רעיונות טובים, מוסיפים היוריסטיות חדשות ופתאום הכל מתחיל לעבוד קצת יותר טוב בממוצע. או שזה לא מתחיל. היו לי חבורה של מקרים שבהם נלחמנו על הביצועים של חמישה אחוזים שהבדילו את ההתפתחות שלנו מהמקצה הקודם. ובכל פעם זה נראה כך: איפשהו אתה מנצח, איפשהו אתה מפסיד. אם יש לך כלים טובים לניתוח ביצועים, תוכל למצוא את הרעיונות המפסידים ולהבין מדוע הם נכשלים. אולי כדאי להשאיר הכל כמו שהוא, או אולי לנקוט בגישה רצינית יותר לכיוונון עדין, או לצאת ולתקן משהו אחר. זה מלא של דברים! הכנתי את הפריצה המגניבה הזו, אבל אני צריך גם את זה, ואת זה, ואת זה - והשילוב הכולל שלהם נותן כמה שיפורים. ומתבודדים יכולים להיכשל. זה האופי של עבודת ביצועים על בעיות שלמות NP.

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

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

ולדימיר: מה אתה חושב על ריבוי ליבות, כאשר יש אלפי ליבות בבת אחת? האם זה דבר שימושי?

צוּק: הצלחת ה-GPU מראה שהוא שימושי למדי!

ולדימיר: הם די מיוחדים. מה לגבי מעבדים לשימוש כללי?

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

האתגר הכי גדול בחיים

ולדימיר: מה לגבי אתגרים לא טכניים?

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

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

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

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

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

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

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

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

מקור: www.habr.com