הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מאמרים בנושא תכנה ומחשבים.
למידת מכונה פתוחה באמת, האם אני נלחם בקרב עבוד מראש?
לפני מספר שנים התחלתי פרוייקט dlprimitives - המימוש הבסיסי של פעולות Deep Learing ב־OpenCL. והמשכתי לתמיכה ב־OpenCL ב־pytorch. אני ממשיך לפתח את המודול של PyTorch על אש קטנה והאמת, הגעתי לביצועים מרשימים גם עבור כרטיסי nvidia וגם amd.
למה בעצם אני משקיע את זמני בזה:
- קודם כל, כל תעשיית ה־deep learning היום מבוססת על דברים סגורים. למרות שהכלים כמו pytorch הם פתוחים לחלוטין - למטה יושב הקוד של cudnn ששמור בכספת.
למרות שיש עוד 2 שחקנים רציניים בשוק כרטיסי המסך (AMD ולאחרונה גם Intel) והקוד שלהם פתוח - כל אחד ממציא גלגל מחדש ועושה משהו משלו. למעשה אין שום דבר משותף בין הקוד שלהם. אם אני רוצה לשפר טכניקה קיימת או להביא איזה כלי חדש אני נתקל בבעיה רצינית:
- אני חייב לשפר משהו שאין לי גישה אליו (cudnn) וזה מאוד קשה.
- אם זה תופס צריך למעשה מספר מימושים לכל אחת מהפלטפורומ האלה.
- אם מישהו רוצה להשתמש במודלים מאומנים - המימוש הוא תלוי חומרת המשתשת - למעשה צריך לתמוך בכל תשתית בנפרד nvidia-cuda, amd-rocm, intel - xpu וב־apple עוד איזו שטות - כמובן אין שום הבטחה שזה למעשה יעבוד בכל מקום.
אז אני עובד על משהו שעובד על כולם OpenCL וגם מגיע בין 60% ל־80% ממה שאפשר הגיע עם המימוש המקורי (שזה cuda/rocm).
אני ממשיך לראות את amd משפרים את rocm מצד אחד (לפי שבוע התקנתי pytorch rocm על אובונטו 24.04 בצורה יחסית חלקה וזה פשוט עובד) ומצד שני הורסים אותו - כי מוציאים תמיכה בכרטיסי ישנים ותומכים באופן רשמי רק בדברים ייעודיים. למעשה rx6600xt של גם לא נתמך באופן רשמי וצריך להשתמש במשתנה סביבה שיתייחסו אליו כמו לכרטיס הנתמך
אני רואה ש־intel גם הולכים בכיוון זה ועל פניו אפשר גם לאמן היום על הכרטיסים שלהם. אבל הם מסתמכים על על טכנולוגיה נוספת שעוד פעם לא תואמת לשום דבר אחר.
כל ההשקעות של Intel ושל AMD הן למשהו מידי שיעשה טלאי אבל לעולם לא יפתור את הבעיה האמתית של העולם ה־DL.
לכן, אני ממשיך לעבוד ורואים שהחברות האלה ממשיכות לבזבז משאבים על משהו שלא באמת עוזר מלבד לאלה שנתקעו עם מסך amd/intel וגילו שאולי גם בא להם לאמן רשתות ניירונים. ברור לכם שהם יתייאשו תוך כלום זמן ופשוט יקנו כרטיס טוב של nVidia שבאמת יעבוד כמו שצריך.
טוב, נו. אני לפעמים מנסה להרים פרוייקטים שנראים בלתי אפשריים. האם זה יצליח? לא יודע - המשאבים שלי מוגבלים: שעה־שעתיים כמה פעמים בשבוע כשאני לא עסוק בדברים אחרים. אם היה לי צוות של 5-6 מפתחים שעובדים על זה במשרה מלאה - ללא ספק זה היה מצליח. אבל אין לי משאבים כאלה.
מצד אחד אני נהנה מהצלחות קטנות - באמת, המפתחים של pytorch מאוד עוזרים. ובכל פעם זה מתקדם והופך לקל יותר להתקין או להשתמש בזה. מצד שני לפעמים זה מייאש כמה עבודה יש לי וכמה השחקנים הרציניים - האלה עם הכסף עושים שטויות גמורות במקום לשתף פעולה (אגב למען האינטרסים שלהם)
ועכשיו שאלה: מכירים שירות ענן שמאפשר לבנות חבילות ל־pip (רצוי גם לחלונות)
לחבר שני תחביבים
אני חובב אסטרונומיה. בתור חובב אסטרונומיה אני סובל ואחת הבעיות הגדולות של העולם המודרני - זיהום אור. יש המון גרמי שמיים חיוורים כמו גלסקסיות וערפיליות שפשוט לא ניתן לראות מהעיר. בשביל זה צריך לנסוע לנגב או לרמת הגולן ולבלות לילה בתצפית. זה מאוד כיף כמובן. אבל זה לא תמיד נגיש.
אחד המעקפים לבעיה זה שימוש בצילום. מצלמה שיכולה לאגור פוטונים מגלקסיות מרוחקות ומאפשרת לחדור דרך שכבת זיהום אור כבדה ולהראות לנו גרמי שמיים עמומים. זה כמובן לא תחליף לצפייה ישירה אבל גם נותן יתרונות רבים אחרים. במובן, צילום אסטרונומי הוא נושא מורכב שדורש שימוש בתוכנות ייעודיות: איסוף תמונות רבות ככל הניתן, ועיבוד שלהם (הערמה) כדי לקבל תמונה יפה של איזו ערפיליות או גלקסיה.
אמרנו לינוקס?
אז מה המצב התוכנה בתחום זה מבחינת תוכנה חופשית ולינוקס? יש ויש. חלק הארי של הכלים הם חופשיים/קוד־פתוח. יש לא מעט תוכנה ללינוקס, אם כי הדברים הטובים ביותר רצים על חלונות. רוב הדרייברים של המצלמות דווקא סגורים. אבל לרוב יש גרסאות לינוקס, Raspberry PI ועוד.
עכשיו, בצילום אסטרונומי יש נדבך חשוב שמעניין אותו במיוחד: Electronically Assisted Astronomy או EAA בקיצור. פירושו ביצוע כל הפעולות הנדרשות לצילום (כולל עיבוד, איסוף תמונות והערמה) בזמן אמת, כאשר עם כל תמונה חדשה של האובייקט, אתה מקבל את התמונה הסופית המשופרת יותר ויותר. המטרה של EAA בניגוד לצילום, לא להגיע לתמונה הטובה ביותר אפשרית, אלא להגיע לתמונה שמספיק טובה כדי לראות את האובייקט ולהנות ממנו.
למעשה, במקום לצפות באובייקט דרך עינית, צופים בו דרך המסך. ובניגוד לצילום אסטרונומי שיכול להמשך שעות ארוכות, מסתפקים בזמן איסוף כולל קצת יחסית - מעשרות שניות עד דקות בודדות - כי המטרה לראות ולעבור לאובייקט מעניין הבא. מה מצב התוכנה פה? אם בצילום היה מאתגר בלינוקס, פה המצב קשה. יש מעט מאוד פתרונות ולא כולם עובדים ונוחים.
הבעיה השניה, מבחינתי, זה ש־EAA דורשת לרוב להביא מחשב נייד לשטח כדי להפעיל את כל התוכנה המסובכת הזו. למעשה, אם תצפיתן שצופה ויזואלית יכול להביא איתו תיק אחד ובו טלסקופ, חצובה וכמה עיניות, צלם צריך להביא איתו לשטח: חצובה ממונעת, עשרות כבלים, מחשב, ספק כוח שיספיק למספר רב של שעות ועוד. הקמה וקיפול של הציוד לצילום יכולים לקחת בקלות בין חצי־שעה ולשעה בניגוד לצופים בעין - העושים הכל במספר דקות בודדות.
אבל לרובינו יש כבר מחשב די חזק ונייד: טלפון או טאבלט! לו רק יכולתי לחבר את המצלמה ישירות לאליהם...
אז הרמתי את דגל
בניתי פתרון ל־EAA עבור לינוקס ואנדרואיד ושמו OpenLiveStacker. והוא בנוי בצורה הבאה:
- הקוד כתוב ב־C++ עם שימוש ב־OpenCV לצורך עיבוד תמונה
- הממשק בנוי כ־web interface שמדבר ב־REST עם השרת - מה שמאפשר בניית ממשק בלינוקס ואנדרואיד באותה צורה וגם מקל על גישה מרחוק במקרה והתוכנה רצה על pi. כמובן שהשרת מבוסס CppCMS. מה שמאפשר חיבור קל ונוח בין הקוד שדורש ביצועים הגובהים לממשק משתמש.
- הדרייברים נטענים דינאמית:
- אחד עבור מצלמה גנרית עם פרוטוקול UVC על בסיס libusb/libuvc- שתומך במצלמות רשת או במצלמות כמו SVBony sv105 - אבל הוא מוגבל לצורכים אסטרונומיים
- דרייבר של ASI ZWO - החברה המובילה בתחום, שעובד מול SDK שלהם. לצערי הדרייבר עצמו הוא קוד סגור, אבל יש להם גרסה לאנדרואיד.
- דרייבר גנרי שיודע לקרוא קבצים מהספרייה איך שהם מגיעים - מה שמאפשר חיבור לכל מצלמה אחרת דרך כלים קיימים כמו indi/ekos.
- לצורך תמיכה באנדרואיד יש אפליקציה קטנה שעוטפת את השרת ומנהלת גישה ל־USB (כי באנדרואיד הכל צריך להיות מסובך)
- לצורך הקלה על התמצאות יש חיבור לתוכנה פופולרית מאוד בתחום אסטרונומיה: ASTAP שיש לה גם גרסה (קובץ ריצה) לאנדרואיד. הדבר המעניין בתוכנה הזו שהיא כתובה בפסקל! לא חשבתי שאתקל בדבר כזה בימינו.
מה למדתי?
- בניית אפליקציות אנדרואיד זה די סיוט וזה לא בגלל השפה אלא בגלל שצריך ללמוד פחות או יותר הכל מ־0. מזל שרוב הקוד ניתן לכתוב ב־C++.
- כמעט כל דבר באנדרואיד עובד "קצת שונה". למשל: אין לך /tmp, להריץ exe חיצוני זה סיפור שעלה לי בלילה לבן, להביא קבצים עם אפליקציה זה גם לא משהו טריוויאלי. בקיצור. זה לינוקס, אבל לא בדיוק.
- אני שונא לעבוד עם קוד סגור. אומנם ASI ZWO משחררים דרייברים לאנדרואיד, אבל הם גם הכניסו באג מעצבן שגורם ל־RTTI לא לעבוד! למעשה כל תכנת החיבור ל־SDK שלהם כתבתי ב־C+- בגלל אי זמינות של RTTI. וזה לא היה משהו מסובך אם הייתי יכול לקמפל את הדרייבר מחדש הבעיה הייתה פשוט נעלמת.
שורה תחתונה
אבל מה שחשוב, שבשורה תחתונה, יש לי פתרון פשוט - לעבוד עם טאבלט שבקושי צורך חשמל, קל ונוח.
התקדמות חשובה בתמיכה ב־OpenCL ב־pytorch.
רקע
היום pytorch היא אחת התשתיות המובילות בעולם למידה עמוקה. יש לה יתרונות רבות, אבל מבחינת המפתח זה קוד איכותי ותיעוד טוב. הקוד כתוב בצורה מאוד מודרנית עם שימוש נכון ביכולות C++ מה שמאוד מקל על הפיתוח. אני עובד בתקופה האחרונה על פיתוח מנוע עבור pytorch מבוסס OpenCL כחלופה ל־cuda.
כבר כתבתי בעבר על חשיבות התמיכה ב־OpenCL.
אבל בכל זאת אזכיר כמה נקודות מבחינת קהילת תוכנה חופשית וקוד פתוח:
- אנחנו זקוקים בתמיכה חוצת פלטפורמה בכרטיסי מסך מיצרנים שונים כמו AMD, Intel וכמובן nVidia.
- אנחנו זקוקים למימוש האלגוריתמים המרכזיים כקוד פתוח הזמין לכל (ולא כקופסה סגורה ש־nVidia נותנת)
- אנחנו רוצים לעבוד עם סטנדרטים פתוחים וזמינים כמו OpenCL ולא מימושים ספציפיים של יצרן (כמו cuda).
אז מה חדש? קלות אינטגרציה!
עם שחרור גרסה 1.13 של pytorch חל שיפור משמעותי ב־out-of-tree-backend. עכשיו הוספת מנוע אימון מבוסס OpenCL היא פשוטה מאוד ולמעשה שאלה של מספר דקות, אפילו בוונידוס העניין יחסית פשוט. המשמעות שאפשר להשתמש במנוע OpenCL בקלות רבה הן בלינוקס והן בווינדוס.
מה עם הביצועים? אם משווים מול גרסת cuda/cudnn על אותו ה־gpu מדובר בין 50 ל־70 אחוז ביצועי cuda באימון ובין כ־60 ל־80 באבלואציה (תלוי ברשת כמובן).
למרות שהמנוע עדיין ניסיוני וחסרים בו לא מעט פעולות הוא נבדק בהצלחה על עשרות רשתות כמו resnet, mobilenet ורבות אחרות.
המנוע עצמו מבוסס על ספריית dlprimitives שאני מפתח במקביל והיא חלופה ל־cuDNN על בסיס OpenCL וגם מנוע חיזוי שעובד עם מודלים בפורמט ONNX - שזה נושא גדול בפני עצמו.
מה המשמעות של זה?
משתמשי AMD יכולים לאמן רשתות. הם לא מוגבלים למספר מצומצם של דגמים ש־rocm תומך בהם או לשימוש בלינוקס בלבד. התמיכה היא גורפת מ־APUים ישנים כמו Stoney Ridge ועד ל־RDNA 2 וגם זה עובד על "חלונות" למי שמעוניין.
זו הייתה משימה כמעט ובלי אפשרית עד היום. עכשיו זה במרחק מספר פקודות
תשתית אימון היא קוד פתוח לגמרי גם אם עובדים עם nVidia (טוב חוץ מהדרייבר שלהם)
- כל מה שצריך זה דרייברי של OpenCL. לא צריך את כל המפלצת של cuda (מי שיצא לו להתקין לשדרג לגלות בעיות תאימות יבין אותי מידי)
מחפש עזרה...
מישהו יודע איך אפשר לבנות ולפרסם whl לפלטפורמות שונות? רצוי איזה שירות ענן שיעשה זאת? כדי שזה יהיה ממש במרחק של pip install :-)
רשתות נוירונים בקוד פתוח... להפשיל שרוולים
כתבתי בעבר על המצב העגום של תחום ה־deep learning בקוד פתוח - שלמעשה לא קיים. אחרי ש־Google בפועל הרגו את ה־plaidml עם keras והפיתוח של Caffe הופסק אז נוצר המצב בו אין כל דרך לאמן רשתות בעזרת פלטפורמה פתוחה - OpenCL.
יש סיבות טובות לעבוד עם OpenCL מעבר לשמירה על הקוד הפתוח. למשל לפתח תוכנה שתעבוד על כל כרטיס גרפי סביר ובכל מערכת הפעלה - בלי להסתבך.
אז הרמתי את הכפפה: https://github.com/artyom-beilis/dlprimitives
זהו פרויקט חדש בשם DLPrimitives שאמור לתת מענה לסוגיה. הוא אמור לספק ספריה בסגנון cudnn/miopen שמממשת את הפעולות הבסיסיות של Deep-Learning וגם לספק כלים ל־inference. בנוסף, הרעיון הוא להתחבר כ־backend לאחד ה־deep learning frameworks העדכניים כמו pytorch, tensorflow או mxnet.
התהליך הוא איטי וקשה. אומנם המתמטיקה היא לא מסובכת וכתיבה ל־GPU היא בסה"כ לא עניין מסובך. אבל אם רוצים להגיע לביצועים טובים הסיפור הוא מעט שונה. עם זה, התוצאות כבר כאן.
לחסרי סבלנות - הצלחתי להגיע ל־150%-200% של ביצועי caffe-opencl ו־plaidml על פלטפורמת amd ו־nvidia ולהגיע לכ־50% עד 70% של ביצועי המימושים הספציפיים שלהם על בסיס cudnn/miopen.
כל התוצאות:
https://github.com/artyom-beilis/dlprimitives/blob/master/docs/summary.md
סיכום לעצלנים - ממוצע על 5 רשתות נפוצות alexnet, resnet18, resnet50, vgg, mobilenet:
| GPU | Batch | Train, Cuda/HIP | Test, Cuda/HIP | Train, Plaidml/Caffe | Test, Plaidml/Caffe |
|---|---|---|---|---|---|
| gtx960 | 16 | 51% | 60.73% | 171% | 167.33% |
| gtx960 | 8 | 59% | 72.03% | 187% | 155.25% |
| gtx1080 | 16 | 42% | 41.34% | 207% | 137.52% |
| rtx2060s | 16 | 49% | 57.53% | 211% | 149.48% |
| rx560 | 16 | 53% | 56.82% | 153% | 115.63% |
| rx560 | 8 | 55% | 54.19% | 172% | 122.64% |
| intel-hd530 | 8 | 109% | 66.12% |
אומנם זו התחלה אבל כבר התחלה טובה!
מקוביות לכוכבים
לאחרונה רכשתי טלסקופ פשוט וחזק וצללתי לתחום שעניין אותי עוד מילדות - אסטרונומיה. בתור מתחיל אחת הבעיות הקשות ביותר זה למצוא את גרמי השמיים שאתה מעוניין לצפות בהם. מובן שיש לא מעט אפליקציות "פלניטריום" חופשיות וסוגרות כמו Google SkyMap שמקלות על החיפושים. בסופו של דבר זה לא מסובך למצוא בשמיים משהו בהיר כמו ירח, כוכב לכת או קלאסטר פליאדות - כי גם בתוך העיר רואים את הדברים הבהירים ביותר.
הבעיה זה למצוא את הדברים שעמומים יותר - שבשבילם קונים טלסקופ בקוטר גדול - שיאסוף הרבה אור. אז איך מוצאים מה שלא רואים בעיניים? יש מספר שיטות:
- לקנות טלסקופ עם חצובה רובוטית שתדע לכוון אותך לכל גרם שמיים שתרצה תמורת סוכם לא סימלי. בשביל חובב אסטרונומיה מתחיל מדובר בסוכם כסף לא מבוטל.
- זה להשתמש בשיטת star hopping.
אז במה מדבור?
הרעיון זה למצוא נקודות ייחוס - כוכבים שקל לזהות ולזוז מהם בכיוון הרצוי. לדוגמה:
אם רוצים למצוא קלאסטר M41 (שמסומן בעיגול צהוב) אז אפשר למצוא את סיריוס ואת אדרה ולכיוון את הטלסקופ למיקום של 1/3 ו־2/3 ביניהם. כמובן שזה דורש: (א) שבסביבת האוביקט שאתה מחפש יהיו כוכבים בהירים וקלים לזיהוי. (ב) שנקודות ייחסו יהיו קלות להערכה בעין. שיטה זו דורשת גם הרבה מיומנות וגם שמיים חשוכים יחסית כדי להקל על הניווט מה שלא תמיד מתאפשר בתנאי העיר.
ומה לגבי אפליקציות כמו SkyMap הרי הן יודעות לכוון אותך למקום הרצוי? הבעיה שלסנסורים של טלפון יש שגיאה המגיע עד כ־5 מעלות בערך בעוד ששדה הראיה של טלסקופ טיפוסי למתחילים נע בין 1.0 ל־2.5 מעלות. אבל זו רק חצי בעיה. השגיאה של המצפן יכולה להגיע עד עשרות מעלות. מה שהופך כל תוכנות הפלנטריום לא רלונטיות לכיוון מדויק של הטלסקופ אלא רק להערכה כללית של כיוון הצפייה.
אז עלה בראשי רעיון
אומנם הסנסורים לא מדויקים אבל לטלפון יש גם סנסור gyro. אפשר לקרוא אותם בעזרת Device Orientation Event ואז אם במקום למדוד את הכיוון האובסולטי למדוד את השינוי נוכל להגיע לדיוק יותר גבוה! גם בציר גובה בגם בציר הכיוון (מצפן)
כיוון שאני מעולם לא פיתחתי אפליקציות אז בחרתי לעבור עם WebApi ולממש הכל ב־JavaScript. בצורה זו אוכל בקלות לבנות אפליקציה גם ל־Android וגם ל־iPhone (כי הרבה חובבי אסטרונומיה אוהבים iPhoneים). בסה"כ מדובר בקצת גיאומטריה חישובית וגם בבסיס הנתונים.
כיוון שהתכוונתי לבנות אפליקצית קוד פתוח אז יכולתי לדוג קוד פחות או יותר מכל מקום כולל מכוסה ב־GPL. ומצאתי
- את הכוכבים ובעיקר קבוצות כוכבים מצאתי פה: https://github.com/eleanorlutz/western_constellations_atlas_of_space
- את אוסף ה־Deep Space Objects מצאתי כאן: https://github.com/mattiaverga/OpenNGC
- את הפנקציות לחישוב מיקום כוכבי הלכת מצאתי כאן: https://github.com/TheSiebi/SpacePointer
כל מה שנשאר לי זה להמיר את ה־csvים ל־JSON להמיר כמה פונקציות חישוביות מ־python ל־javascript ולהסתבך בהרבה טרנספורמציות לינאריות. וכמון לכתוב גם UI נחמד.
אז הנה התוצאה: https://artyom-beilis.github.io/skyhopper.html לטלפון חכם בלבד.
וכמבו הנה הקוד: https://github.com/artyom-beilis/skyhopper
אז איך זה עובד?
- אתה מחבר את הטלפון לטלסקופ
- מכוון אותו לכוכב שקל לזהות
- מבצע איפוס ע"י לחיצה על כוכב שכיוונת אליו במפת הכוכבים על המסך
- בוחר את המטרה בה אתה מעוניין לצפות
- מזיז אל הטלסקופ בהתאם להוראות והאפליקציה מודדת את התזוזה ונותנת משוב - מודדת את שינוי הזווית בגובה וברוחב הנדרש ומכוונת אותך ליעד!
בדקתי את האפליקציה כבר מספר לילות ובד"כ מגיע בדיוק למטרה! לפעמים הג'ירו מאבד כיוון אבל בכל מקרה מומלץ לבצע איפוס לפני כל תזוזה לאובייקט חדש.
כך הצלחתי למצוא מספר לא מבוטל של גרמי שמיים בתנאי עיר שבכלל לא חלמתי למצוא אותם לפני!
מסקנות מתחום כתיבת הקוד
זו נראה לי הפעם הראשונה שהשתמשתי במספר רב של מקורות שאפילו מופיעים תחת רישיון GPL. מה שׁזירז את הפיתוח בצורה דרמטית. קיבלתי מהר משוב מאנשים בתחום אסטרונומיה שעזרו לי לשפר את הממשק עם הצעות מאוד נכונות. כל זה אפשר לי להגיע לתוצאה די מוגמרת תוך מספר ערבים
