הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מאמרים בנושא פיתוח.
לחבר שני תחביבים
אני חובב אסטרונומיה. בתור חובב אסטרונומיה אני סובל ואחת הבעיות הגדולות של העולם המודרני - זיהום אור. יש המון גרמי שמיים חיוורים כמו גלסקסיות וערפיליות שפשוט לא ניתן לראות מהעיר. בשביל זה צריך לנסוע לנגב או לרמת הגולן ולבלות לילה בתצפית. זה מאוד כיף כמובן. אבל זה לא תמיד נגיש.
אחד המעקפים לבעיה זה שימוש בצילום. מצלמה שיכולה לאגור פוטונים מגלקסיות מרוחקות ומאפשרת לחדור דרך שכבת זיהום אור כבדה ולהראות לנו גרמי שמיים עמומים. זה כמובן לא תחליף לצפייה ישירה אבל גם נותן יתרונות רבים אחרים. במובן, צילום אסטרונומי הוא נושא מורכב שדורש שימוש בתוכנות ייעודיות: איסוף תמונות רבות ככל הניתן, ועיבוד שלהם (הערמה) כדי לקבל תמונה יפה של איזו ערפיליות או גלקסיה.
אמרנו לינוקס?
אז מה המצב התוכנה בתחום זה מבחינת תוכנה חופשית ולינוקס? יש ויש. חלק הארי של הכלים הם חופשיים/קוד־פתוח. יש לא מעט תוכנה ללינוקס, אם כי הדברים הטובים ביותר רצים על חלונות. רוב הדרייברים של המצלמות דווקא סגורים. אבל לרוב יש גרסאות לינוקס, 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 :-)
מעשה בשני NaNים
לאחרונה ניסיתי להריץ אימון של GAN על pytorch עם תמיכה ב־dlprimitives. אחד דברים הלא נעימים באימון של GANים באופן כללי זה שהם לא ממש יציבים ומתבדרים בקלות.
שמתי לב שבגרסת cuda הוא רץ ללא דופי ובגרסה שלי הוא נתקע. נתקע על ביצוע backpropogation ב־convolution. אחד ההבדלים העיקריים באגלוריתם בהשוואה לשאר היה שימוש בפעולות אטומיות לחישוב סכום (טריק מאוד נפוץ במימוש קונבולוציה)
אחרי זמן מה הגעתי למסקנה שהחישובים מגיעים ל־NaN באיזהו מקום ואז הכל נתקע. לא הבנתי למה פעולת חיבור אטומית פשוטה נתקעת. בכל מקרה איתרתי באג האחר שהביא לחישוב ה־NaN והכל הסתדר. אבל בכל זאת נושא התקיעה הטריד אותי.
כתבתי שאלה ב־Stackoverflow העתקתי קטע קוד... ואז נפל האסימון
float oldv = *ptr;
for(;;) {
float newv = oldv + v;
float prev = as_float(atomic_cmpxchg((__global volatile int *)(ptr),as_int(oldv),as_int(newv)));
if(prev == oldv)
return;
oldv = prev;
}
קחו לכם כמה דקות.
פעולת comxchg ב־OpenCL עובדת רק על int. לכן הייתי צריך לעשות bit-casting ל־int ובחזרה (as_float ו־as_int בדיוק עושים את זה). ואז תנאי הבדיקה prev==old ביצעתי ב־float במקום בשלמים.
כך שאם הערכים שווים אז ההחלפה הצליחה. אבל מה שכחתי? NaN == NaN תמיד נותן false! ולכן תקעתי בלולאה אינסופית כי התנאי לעולם לא ייתקיים. החלפתי לבדיקה בערכים שלמים (קרי ייצוג בינארי) והכל עבד חלק.
מסקנה NaN הוא טריקי... יש לכבדו
התחלתי להתקדם לאימון בקוד פתוח: pytorch עם תמיכה ב־OpenCL
תקציר: הצלחתי לבצע inference של AlexNet ב־pytorch ב־OpenCL. הביצועים זהים לפעלה ישירה של dlprimitives.
הדרך עוד ארוכה אבל פחות קצת יותר ברורה מה לעשות. המאמר המלא באנגלית בבלוג הפיתוח:
http://blog.dlprimitives.org/post/5
השוואה בין תפוחים ירוקים ואדומים
כשמודבר ב־Deep Learning זה מאוד קשה להשוות בין GPU של החברות המובילות AMD ו־NVidia. בניגוד למשחקי מחשב שנותנים לך מדדים ברורים על עלות מול תועלת, תחום DL נשלט באופן בלעדי ע"י NVidia. גם אם קיימים פתרונות של AMD הם לא תמיד עובדים. למשל כרטיסי RDNA/RDNA2 עדיין לא נתמכים ע"י AMD לטובת Deep Learning - והם בעצם הכרטיסים הזמינים היחידים היום בשוק.
ובכן כחלק מפרויקט DLPrimitives עשיתי השוואה כזו:
http://blog.dlprimitives.org/post/1
וכן גם השקתי בלוג חדש לטובת עדכונים על הפרויקט.
