פרק 342 רן ואורי מארחים את איתן יזם ו CTO ב Optibus 1:05 איתן מספר על עצמו ועל הרקע המקצועי שלו2:18 איתן מספר על Optibus, מתמקדים בתחום הסעת ההמונים, לוקחים דאטה מעיר שלמה ומוציאים תכנית פעולה לרכבים ונהגים כדי לעמוד בביקוש התחבורה בעיר תחת אילוצים וחוקים רבים למשל טעינת רכב חשמלי או מנוחת נהג6:20 נקודת ההתחלה למערכת שלהם היא כאשר הנסיעות כבר תוכננו אבל לא יודע איך הולכים לבצע את הנסיעות בהינתן המשאבים הקיימים, שיבוץ רכבים, נהגים ומשאבים נוספים למסימות הקיימות, זוהי בעיה NP קשה, ובצורה נאיבית מחשב לא יצליח לשבץ בזמן סביר8:05 הפרויקט התחיל כאשר איתן ועמוס השותף שלו היו במהלך תואר במתמטיקה ומדעי המחשב, ונחשפו לעולם הבעיה הזה, ובהתחלה התמקדו בבעיה מצומצמת יותר בה יש רק רכבים ומתעלמים מהנהגים והשתמשו בפתרונות מעולם הגרפים בה כל נסיעה היא קודקוד בגרף, וקשת בין  2 נסיעות מסמנת רכב היכול לבצע נסיעה אחת ואחריה את הנסיעה השניה9:50 כאשר רוצים לכסות את כל הנסיעות בגרף כזה בעל עשרות אלפי קודקודים ומליוני קשתות, אפשר לתאר את זה על ידי כיסוי הגרף במסילות כאשר מסילה היא רצף קודקודים מחובר ורוצים כמה שפחות מסילות המכסות כמה שיותר קודקודים, זוהי הפשטה של הבעיה בה הם התחילו11:05 בעולם האמיתי הבעיה מסובכת יותר למשל לא דובר על חניונים ואיפה הרכב חונה, רכבים צריכים להיטען ונכנסים למורכבות של שיטות חיפוש בשילוב המון משתנים12:55 הכניסה של נהגים הופכת את הבעיה למורכבת בהרבה כי החוקים והאילוצים על נהגים הם רבים בדומה לבעיות של תכנון לינארי רק בסקייל גדול מאוד, נהג יכול לבצע חתיכת עבודה מרכב מסוים לרדת מהרכב להפסקה ולעבור רכב, אז צריך לחלק את המסילות לתתי-מסילות ולייצר סידור עבודה לרכבים, פה נכנסים לתכנון לינארי עם מיליארדי משתנים, החוכמה היא לצמצם את עולם החיפוש בצורה חכמה ולבזר את פתרון הבעיה להרבה מחשבים14:35 אחד הדברים המייחדים את Optibus היא היכולת לתת תכנית לעיר שלמה בסידרי גודל של שניות עד דקות בשונה מימים בפתרונות אחרים16:30 איתן ועמוס הקימו את החברה ב2014 ממרתף בנתניה, כאשר די בהתחלה כבר הייתה להם עיסקה עם אגד והתחילו בגיוס כספים, כיום הם מונים מעל 50 איש ויושבים בתל אביב ועובדים בארה״ב אנגליה אוסטרליה וסינגפור19:45 מעבר לתכנון בהנתן דאטה ידוע, הם מקבלים דאטה מסיגנלים של GPS ומזה מקבלים תובנות על איך התנהלה התכנית בשטח ומה הקורלציה בין התכנית לבין הביצוע בפועל, על המידע הזה מריצים אלגוריתמים של למידת מכונה ומקבלים פרדיקציה על איך התכנית הולכת להתנהג בפועל24:20 יש דמיון רב לתכנון טיסות, ההבדלים העיקריים הם שתכנון טיסות זה סקייל הרבה יותר קטן, ובאוטובוס נסיעה ריקה למשך כמה תחנות היא יותר נסבלת מלהוציא טיסה ריקה28:30 רן מסכם שיש פה בעיה אלגוריתמית קשה הדורשת הרבה כח חישוב, חלק מהבעיות הן NP קשות, ושואל איך ניתן לפתור את הבעיות האלה בזמנים של שניות29:20 יש הרבה דברים בהם השתמשו כדי לבצע את זה, דבר ראשון עובדים בפייתון, וכאשר עשו בנצ׳מארק מול שפות אחרות פייתון יצא איטי בסדר גודל, אבל כאשר השתמשו ב pypy שהוא אינטרפטר לפייתון העושה JIT compilation הגיעו לביצועים בסדר גודל של Node 31:45 בנוסף כאשר רצו לעשות רדוקציה לבעיה בגרף או למדל בעיה מתמטית כתבו בעצמם ב CPP32:20 את הדאטה טרום חישוב שומרים בMongoDB, את הדאטה שמייצרים תוך כדי אופטימיזציה מתחלק לחלק בזיכרון וחלק בדיסק כתלות בביזור33:30 ניצלו את היכול של Linux לעשות fork ל process ולהצביע על אותו מקום בזכרון כאשר לא כותבים אליו וכך חסכו סריאליזציה ודי-סריאליזציה של דאטה , זה מאפשר לנצל הרבה cores במחשב אחד35:50 כשרצו למקבל על כמה מכונות היה שלב בו השתמשו הרבה ב EFS כי היה נח שמי שמתחיל את העבודה כותב קובץ של כמה מאות מגה ושאר התהליכים קוראים אותו36:35 כעת חשבו על מיקבול גדול יותר, פה נכנס הקונספט של serverless, מכיוון שאופי העבודה הוא ספורדי ואפשר לקבל מספר אדיר של cores ברגע ולשלם רק על זמן העבודה37:55 אמזון מגבילים את מספר הקורים והמכונות ועכשיו הם נמצאים בשלב של poc עם בינאריס שנותנים latency נמוך ואפשרות להבנה של הסטייט39:45 על מנת לחסוך זמן החימום של ה process שיכול להגיע לעשר שניות ובסקייל של Optibus זה סדר גודל של יום בגלל מספר התהליכים, משתמשים ב snapshot של ה process לאחר חימום42:20 רן שואל האם השימוש ב copy-on-write ישים גם ב lambda, איתן מסביר שה serverless infra לא נותן מספיק cores ל process על מנת לנצל את זה45:05 איתן מציין שסוג החברות שעודות איתם הם לא רק חברות תחבורה, אלא כל חברה שצריכה הסעות המונים, למשל Facebook שצריכים להסיע את העובדים שלהם, ולדעתו התחום לקראת פריחה רצינית