הבלוג של ארתיום :: תכנה חופשית http://artyom.cppcms.com/ בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא! תמיכה בחצובה או סיפורי הסבת indi ו-indigo לאנדרואיד http://artyom.cppcms.com/post/346 http://artyom.cppcms.com/post/346 <div style="direction:rtl"> <h2>מה שטוב בסטנדרטים זה שיש הרבה כאלה...</h2> <p>אחרי תקופה ארוכה של פיתוח תוכנה/אפליקציית OpenLiveStacker המיועדת לצילום אסטרונימי בזמן אמת, הגעתי לנקודה שמעבר לתמיכה במצלמה נדרשת תמיכה בחצובה ובמצלמה גנרית. אז איך מתחברים במשהו גנרי? משתמשים בממשק סטנדרטי! בעולם "חלונות" יש ASCOM. בעולם הלינוקס המצב נותן מגוון רחב של סטנדרטים</p> <p> <a href="/post/346">המשך...</a> </p> </div> הפצה? למי איכפת. האמת שכן http://artyom.cppcms.com/post/345 http://artyom.cppcms.com/post/345 <div style="direction:rtl"> <p>אני יודע שימי מלחמת הפצות לינוקס כבר פחות מעניינים - כי כולם בסופו של דבר +/- אותו הדבר. אבל החלטתי להיזכר מה הייתה הדרך שלי.</p> <p>התחלתי עם Fedora 3 - הנתנה לי הרגשה מה זה לינוקס מודרני (אז). אבל מהר מאוד התייאשתי - כי הרעיון לשדרג כל 6 חודשים להפצה חצי יציבה - כי זו מעבדתי ניסויים של Red Hat - לא קסם לי.</p> <p>המשכתי ל־Debian - ה־stable אז היה ממש ישן עברתי ל־testing שאומנם עבד אבל... היה קשה וגם חיכיתי המון לגרסה "יציבה" שהייתה ישנה עם ההגעה.</p> <p>כשרכשתי מחשב מחדש 64 ביט התקנתי עליו גרסת LTS הראשונה של Ubuntu 6.06 ומשם בבית אני עם גרסאות LTS - למה? כי לא בא לי להתעסק יותר מידי בלינוקס.</p> <p>בעבודה עבדתי עם RHEL וגם עם CentOS וגם עם גרסאות שונות ומשונות של Ubuntu. שורה תחתונה. זה עובד וזהו. לא משנה מה.</p> <p>העיקר שיהיה יציב שלא ישגע עם שדרוגים יותר מידי ויעבוד. ונחמד כשזה נתמך ע"י תוכנה מסחרית</p> </div> למידה עמוקה מחוץ לקופסת nVidia http://artyom.cppcms.com/post/344 http://artyom.cppcms.com/post/344 <div style="direction:rtl"> <p>לפני <a href="http://artyom.cppcms.com/post/328">3 וחצי שנים</a> סקרתי את מצב הלמידה העמוקה בקוד פתוח (מחוץ לעולם nVidia) והמצב היה בכי רע.</p> <p>גם עכשיו המצב לא מזהיר. לפני מספר שנים רכשתי AMD rx6600XT ולא מזמן בתור ניסוי קניתי Intel Arc a380.</p> <h2>נתחיל מפתרון מבית AMD - השכפול של cuda בשם hip</h2> <p>קודם כל בניגוד לשנים הקודמות בהן אפילו לא הייתה תמיכה בכרטיסי RNDA התקנתי לאחרונה אובונטו 22.04 התקנתי rocm הורדתי pytorch מתאים - וזה עבד (כמעט היה צריך להגדיר <a href="https://discuss.linuxcontainers.org/t/rocm-and-pytorch-on-amd-apu-or-gpu-ai/19743">משתנה סביבה</a> כדי שיכיר בכרטיס שלא נתמך באופן רשמי) אבל זה עבד. לא נתקלתי עד עכשיו במשהו שלא עבד. שזה בהחלט התקדמות מרשימה. כמובן גם כל הקוד של AMD הוא פתוח שזה יתרון ענק.</p> <p>אבל... הם זרקו תמיכה ב-GCN4 זאת אומרת הכרטיס הישן rx560 כבר לא עובד עם rocm ואפילו דרייבר OpenCL שלהם קורס. דרייבר Mesa פשוט גרוע ו-rustocl קטסטרופה אחת גדולה, אבל הצלחתי להתקין amdgpu-pro הישן והלא נתמך - אבל לפחות עובד.</p> <p>כלומר בעלי RDNA נראה יהנו, אולי גם אלה עם Vega (אבל לא APU) ורק אם משתמשים בלינוקס.</p> <h2>השחקנית החדשה בשוק היא Intel Arc</h2> <p>בניגוד ל-AMD הם לא שכתבו cuda אלא עובדים עם pytorch כ-plugin. ההתקנה קצת יותר מסובכת אבל הצלחתי. להבנתי החל מ-pytorch 2.5 או 2.6 זה כבר אמור להיות שקוף יותר. הכרטיס עובד. האימונים? תלוי עד כמה הקוד שאתה מנסה להריץ תלוי בעבודה ישירה מול cuda בלבד. אבל הצלחתי אפילו להריץ yolo ועוד כל מיני רכיבים. כך שהמצב נראה טוב יחסית. אבל כמובן Intel החליטו ללכת בדרך ה-nית שאף אחד לא עובד עם זה sycl... טוב לפחות זה תקן פתוח (שתכל'ס רק Intel עובדים איתו)</p> <p>מה לגבי ביצועים. טוב. עשיתי השוואה בין gtx960 לבין arc a380. מבחינת המפרט</p> <ul> <li>לשניהם יש 1024 מעבדים</li> <li>מהירות הזכרון של אינטל כ-143GB/s לעומת כ84GB/s בנבידיה</li> <li>השעון הוא 2450MHz לאינטל לעומת כ-1506MHz משמע: יש כ-5020GFlops מול 3080GFlops יתרון</li> </ul> <p>איך הביצועים... <a href="https://github.com/artyom-beilis/pytorch_dlprim/blob/master/benchmarks/v0.2.0/summary.md">לא בדיוק טובים לעומת מה שכתוב על הנייר</a></p> <p>למרות שהמהירות התיאורתית אמורה להיות יותר טובה בכ-%63 בפועל באימון היתרון היה סה"כ 38% באימון בממוצע ו-48% בחיזוי. אם לוקחים חציון המצב עוד יותר גרוע. 13% שיפור באימון ו-40% בחיזוי.</p> <h2>סיכום</h2> <p>אז המצב השתפר פלאים לעומת מה שהיה. זה רחוק מהליות מושלם אבל יש התקדמות ומה שחשוב שההתקדמות החדשה היא בתחום קוד פתוח.</p> <p>עכשיו מה לא טוב? עדיין כל אחת מהחברות הגדולות בוחרת בפתרון משלה...</p> <ul> <li>nVidia זה cuda</li> <li>AMD זה hip/rocm (העתק של cuda)</li> <li>Intel זה - sycl אבל לפחות יש תמיכה גם ב-opencl ב-onednn</li> <li>Apple זה metal</li> <li>microsoft זה DirectML</li> </ul> <p>נפלתם על הראש? ברור ש-nvidia תהיה מונופול בשוק.</p> <h2>ומה אני עושה?</h2> <p>ממשיך לעשות את הבלתי אפשרי ו<a href="https://github.com/artyom-beilis/pytorch_dlprim/releases/tag/0.2.0">שחררתי עוד גרסה מספר 0.2.0</a> של OpenCL backend ל-Pytorch עם הרבה תיקונים.</p> <p>מוזמנים לנסות - אבל הדרך עוד ארוכה</p> </div> כשכבר מזמן לא איכפת לך מה גרסת מערכת ההפעלה שלך כל עוד זה לינוקס http://artyom.cppcms.com/post/343 http://artyom.cppcms.com/post/343 <div style="direction:rtl"> <p>לאור רכישת מחשב חדש התקנתי מערכת הפעלה על נקי. כבר מספר שנים (כ-6) הרצתי Ubuntu 18.04 וזה כבר התחיל לתת אותות התיישנות, לא בגלל שמשהו חסר לי אלא פתאום כבר אין תמיכה בכל מיני דברים חדשים.</p> <p>אז הורדתי גרסה עדכנית של Kubuntu התקנתי הכל עבד יחסית חלק מערכת הפעלה חדשה נקיה, התקנתי כל כלי הפיתוח סידרתי Steam וקצת משחקים אחרים. התקנתי rocm כך שאני יכול להריץ pytorch על כרטיס AMD עם הפתרון הרשמי שלהם (וזה אפילו עבד חלק).</p> <p>את המחשב הקודם הישן (בן 8 אבל עדיין טוב וחזק) הכנתי לבת שלי (שהגיע הזמן) גם התקנתי את ה-Kubuntu ופתאום קלטתי שבמהלך ההתקנה מופיע 22.04 ולא 24.04 - איזה באג מוזר. נו. סיימתי התקנה ואז החלטתי לבדוק. זה 22.04 ולא 24.04 - הלכתי למחשב שהתקנתי לפני שבועיים - גם כן! איך פספסתי! הסתכלתי על iso שהורדתי וזה באמת 22.04 והייתי כל הזמן בטוח ששמתי 24.04.</p> <p>האמת, זה כל-כך לא משנה. כל עוד הדברים עובדים. רק צריך יהיה מתישהו לשדרג (אני שונא שדרוגים)</p> </div> למידת מכונה פתוחה באמת, האם אני נלחם בקרב עבוד מראש? http://artyom.cppcms.com/post/342 http://artyom.cppcms.com/post/342 <div style="direction:rtl"> <p>לפני מספר שנים התחלתי פרוייקט dlprimitives - המימוש הבסיסי של פעולות Deep Learing ב־OpenCL. והמשכתי לתמיכה ב־OpenCL ב־pytorch. אני ממשיך <a href="https://github.com/artyom-beilis/pytorch_dlprim/">לפתח את המודול של PyTorch על אש קטנה</a> והאמת, הגעתי ל<a href="https://dev-discuss.pytorch.org/t/rocm-vs-opencl-dlprimitives/2351">ביצועים מרשימים</a> גם עבור כרטיסי nvidia וגם amd.</p> <p>למה בעצם אני משקיע את זמני בזה:</p> <ol> <li>קודם כל, כל תעשיית ה־deep learning היום מבוססת על דברים סגורים. למרות שהכלים כמו pytorch הם פתוחים לחלוטין - למטה יושב הקוד של cudnn ששמור בכספת.</li> <li><p>למרות שיש עוד 2 שחקנים רציניים בשוק כרטיסי המסך (AMD ולאחרונה גם Intel) והקוד שלהם פתוח - כל אחד ממציא גלגל מחדש ועושה משהו משלו. למעשה אין שום דבר משותף בין הקוד שלהם. אם אני רוצה לשפר טכניקה קיימת או להביא איזה כלי חדש אני נתקל בבעיה רצינית:</p> <ul> <li>אני חייב לשפר משהו שאין לי גישה אליו (cudnn) וזה מאוד קשה.</li> <li>אם זה תופס צריך למעשה מספר מימושים לכל אחת מהפלטפורומ האלה.</li> </ul> </li> <li>אם מישהו רוצה להשתמש במודלים מאומנים - המימוש הוא תלוי חומרת המשתשת - למעשה צריך לתמוך בכל תשתית בנפרד nvidia-cuda, amd-rocm, intel - xpu וב־apple עוד איזו שטות - כמובן אין שום הבטחה שזה למעשה יעבוד בכל מקום.</li> </ol> <p>אז אני עובד על משהו שעובד על כולם OpenCL וגם מגיע בין 60% ל־80% ממה שאפשר הגיע עם המימוש המקורי (שזה cuda/rocm).</p> <p>אני ממשיך לראות את amd משפרים את rocm מצד אחד (לפי שבוע התקנתי pytorch rocm על אובונטו 24.04 בצורה יחסית חלקה וזה פשוט עובד) ומצד שני הורסים אותו - כי מוציאים תמיכה בכרטיסי ישנים ותומכים באופן רשמי רק בדברים ייעודיים. למעשה rx6600xt של גם לא נתמך באופן רשמי וצריך להשתמש במשתנה סביבה שיתייחסו אליו כמו לכרטיס הנתמך</p> <p>אני רואה ש־intel גם הולכים בכיוון זה ועל פניו אפשר גם לאמן היום על הכרטיסים שלהם. אבל הם מסתמכים על על טכנולוגיה נוספת שעוד פעם לא תואמת לשום דבר אחר.</p> <p>כל ההשקעות של Intel ושל AMD הן למשהו מידי שיעשה טלאי אבל לעולם לא יפתור את הבעיה האמתית של העולם ה־DL.</p> <p>לכן, אני ממשיך לעבוד ורואים שהחברות האלה ממשיכות לבזבז משאבים על משהו שלא באמת עוזר מלבד לאלה שנתקעו עם מסך amd/intel וגילו שאולי גם בא להם לאמן רשתות ניירונים. ברור לכם שהם יתייאשו תוך כלום זמן ופשוט יקנו כרטיס טוב של nVidia שבאמת יעבוד כמו שצריך.</p> <p>טוב, נו. אני לפעמים מנסה להרים פרוייקטים שנראים בלתי אפשריים. האם זה יצליח? לא יודע - המשאבים שלי מוגבלים: שעה־שעתיים כמה פעמים בשבוע כשאני לא עסוק בדברים אחרים. אם היה לי צוות של 5-6 מפתחים שעובדים על זה במשרה מלאה - ללא ספק זה היה מצליח. אבל אין לי משאבים כאלה.</p> <p>מצד אחד אני נהנה מהצלחות קטנות - באמת, המפתחים של pytorch מאוד עוזרים. ובכל פעם זה מתקדם והופך לקל יותר להתקין או להשתמש בזה. מצד שני לפעמים זה מייאש כמה עבודה יש לי וכמה השחקנים הרציניים - האלה עם הכסף עושים שטויות גמורות במקום לשתף פעולה (אגב למען האינטרסים שלהם)</p> <p>ועכשיו שאלה: מכירים שירות ענן שמאפשר לבנות חבילות ל־pip (רצוי גם לחלונות)</p> </div> למה אני לא מרוויח כסף מאפליקציות שאני מפתח? http://artyom.cppcms.com/post/340 http://artyom.cppcms.com/post/340 <div style="direction:rtl"> <p>לפני קצת יותר משנתיים התחלתי לפתח את <a href="https://artyom-beilis.github.io/astrohopper.html">אסטרוהופר</a> - אפליקצית וובּ שעוזרת למצוא גרמי שמיים. יש הרבה מפות כוכבים אינטרקטיביות, אבל רובן ככולן לא מדויקות מספיק לצרכים אסטרונומיים. אני בניתי מנגנון איפוס והנדסת אנוש מתאימה והיום זו אפליקציה מאוד פופולרית בעולם האסטרונומיה שעוזרת למשתמשים רבים חדשים וותיקים. כמובן פיתחתי אותה כקוד־פתוח.</p> <p>אנשים רבים שלא באים מתחום קוד פתוח שואלים אותי. למה אתה לא מוכר את האפליקציה? יכולת להרוויח מזה כסף! <em>האומנם?</em></p> <p>אז בוא נעשה ניתוח עסקי קצר בדיעבד</p> <h2>ניתוח הכנסות פוטנציאליות</h2> <p>נכנסתי ל־google analytics לעקוב אחר מספר המשתמשים בשנה האחרונה, הנה המספרים:</p> <ul> <li>סה"כ כ־24,500 מתשמשים</li> <li>בישראל 250 משתמשים בשנה האחרונה</li> </ul> <p>אז אם הייתי גובה מכל אחד נגיד $5 (שזה מחיר מוגזם) אז על הנייר זה $122500. האם זה חישוב נכון?</p> <p>ניכנס לניתוח לפי מערכת ההפעלה:</p> <ul> <li>אנדרואיד זה כ־10,500 משתמשים</li> <li>iOS זה כ־10,000 משתמשים</li> <li>שאר זה משתמשים של מחשבים - לא רלוונטי לתחשיב</li> </ul> <p>כבר הורדני כ־1/5 משתמשים וירדנו לכ־$100K שזה מספר מכובד.</p> <p>אבל אם נסתכל על משתמשים בישראל - 250. במקרה קהילה של האסטרונומיה בארץ היא קטנה ורובינו מכירים זה את זה. לכן, היא מהווה מדגם נהדר. יש לי קבוצת ווטסאפ בשם "קבוצת התמיכה ב־AstroHopper" בה 15 חברים מהקהילה ישראלית (חלקם היו מעורבים בשלבי בטא מוקדמים)... כמי שיורד לתצפיות באופן (כמעט) קבוע ונפגש עם אנשים אני יכול להגיד שמספר המשתמשים ברשימת ווטסאפ הוא די מייצג - כי אני די מכיר את רובם. אז אולי פספסתי ואני נותן הערכת חסר אז נגיד יש לא 15 אלא 50 משתמשים (ומההכרות שלי עם הקהילה זה מספר מוגזם)</p> <p>אז אם ניקח את זה כמדגם מייצר - כנראה בהערכה האופטימית ביותר, מתוך 20 אלף משתמשים ב־google analytics בפועל זה אולי 4000 משתמשים פעילים אמתיים. האם זה מספר קרוב מציאות?</p> <p>אם נסתכל על מידע ב־google play של SkySafari Pro גרסה 6 ו־7 - יש להם כ־10 אלף הורדות. וזו אפליקציה הרבה יותר פופולרית מאסטרוהופר והרבה יותר מושקעת כי יש בה עוד המון פיצ'רים נוספים.</p> <p>אז כנראה הערכה של 4000 משתמשים היא הערכת נכונה מבחינת סדר גודל. הייתי אומר אפילו הערכה אופטימית ביותר. אז לאיזה סכום הגענו (במקרה הטוב) של כ־$20K...</p> <h2>ניתוח הוצאות והשקעה</h2> <p>אני לא מחזיק ב־iOS ולא ב־Mac. לכן, כדי לתמוך בבניית אפליקציית ל־AppStore הייתי צריך לרכוש אותם. וגם להשקיע בפיתוח של אותה האפליקציה פעמיים - פעם עבור iOS ופעם לאנדרואיד. מחשב אפל הזול ביותר שאשפר למצוא היום הוא כ־3000₪ ונגיד לקנות טלפון יד שניה זה עוד 1000₪ שזה מביא למשהו כמו $1000 הוצאות עוד לפני שהרווחתי פרוטה. או להפסיד 1/2 מהכנסות או אופילו יותר.</p> <p>זמן פיתוח - לפי הניסיון שלי אני לא אוכל לבנות מעטפת קטנה סביב דפדפן בגלל בעייתיות גישה לחיישני תנועה. לכן במקרה הטוב אולי אוכל לשתף חלק מהקוד. או אולי להשתמש במשהו חוצה פלטפורמה קיים, אבל עדיין המצב מסובך.</p> <h2>פיתוח נוסף</h2> <p>אני משתמש במספר בסיסי נתונים זמינים:</p> <ul> <li>OpenNGC זמין תחת CC By SA</li> <li>בסיסי נתונים של קבוצות כוכבים שזמינות תחת GPL</li> </ul> <p>שנהים דורשים פתיחת קוד המקור של האפליקציה, זאת אומרת אני צריך לעשות אחד משתיים</p> <ul> <li>לבנות בסיסי נתונים בעצמי ע"י הצלבה של מספר רב של מקורות עם רישיונות יותר נוחים</li> <li>לרכוש כאלה</li> </ul> <h2>הפיל שבחדר - אם האפליקציה לא הייתה חופשית האם היא הייתה מצליחה?</h2> <p>זאת שאלה נהדרת! אחרי שהתחלתי לכתוב אפליקציה גיליתי שיש אחת בשם SkEye שעושה משהו דומה מאוד ויש לה גרסה חינמית ופרו. אבל היא הסתמכה בעיקר על מגנטומטר ולפחות לי היא לא עבדה. אבל עוד פעם זו לא רק אפליקצית ניווט אלא עוד.</p> <p>היום גיליתי עוד אחת ל־iOS שעושה משהו מאוד דומה (לא בחינם) ומסתבר שקיימת מ־2016! רק שלא שמעתי עליה וכמעט ואף אחד לא הזכיר אותה (וכבר שכחתי את שמה).</p> <p>אם זאת לא הייתה אפליקציה חופשית אני לא חושב שהייתי מקבל סיוע כל־כך רחב מהקהילה בפיתוח ובהפצה. לפני כחצי שנה <a href="https://www.youtube.com/@reflactor">Youtuber בשם Reflacotor‏</a> <a href="https://www.youtube.com/watch?v=6-_58mSGz1Q">עשה סקירה נהדרת</a> של האפליקציה. אחת הסיבות שהוא התלהב ממנה שהאפליקציה הייתה קוד־פתוח וזמינה לכל. הסקירה הזו הקפיצה את תפוצה בסדר גודל.</p> <p>הסיבה שזה הצליח - העובדה שהאפליקצייה חופשית (ולא רק חינמית). שקיבלתי המון עזרה מהקהילה בבדיקות והשמשת אפליקציה. עובדה שלא הייתי צריך להחזיק iPhone ביד כדי לגרום לה לעבוד.</p> <h2>נגיד היא הייתה בכל זאת מצליחה האם זה רווחי?</h2> <p>האם זה היה רווחי? הזמן שהשקעתי הוא לא קטן. תחזוקה, טיפול בבעיות, הפיתוח הראשוני. אני לא יודע להעריך כמה שעות עבודה השקעתי בפיתוח, אבל בואו נגיד ככה, לאורך הזמן זה הצטרב ללא מעט. אין לי מספר מדויק, אבל גם לא הייתי יכול לבנות על $20000 אולי זה היה יותר דומה ל$5000 אולי $10000. האם זה שווה את הזמן השקעתי? כנראה שלא. בעבודה רגילה הייתי מרוויח יותר לפי שעה (בהערכה גסה)</p> <h2>אז למה בכל זאת עשיתי את זה?</h2> <p>מאותה סיבה שאני מידי פעם יורד למדבר וצופה בכוכבים. מאותה הסיבה שאני מסתכל בפורומים של אסטרונומיה ועונה על השאלות. מאותה סיבה שאני משקיע כספי על רכישת טלסקופים, חצובות, מצלמות ודלק לנסיעות ועוד כדי לראות את האפלוליות בשמיים.</p> <p>כי זה פשוט מעניין. כתיבת הקוד זה גם תחביב. לבנות משהו שעובד שאף אחד לא עשה לפני זה כיף. העובדה שהמקצוע שלי זה גם התחביב שלי הופכים אותי לאיש מקצוע שאני היום. ואם התחביב גם עוזר לאנשים אחרים הרי גם הרווחתי. אולי לא כסף, אבל לא הכל בעולם הזה הוא כסף.</p> <p>וכן, ניסיתי להפוך חלק מהפרוייקטים שעבדתי עליהם למסחריים ואפילו הצלחתי חלקית. אבל בסוף לפעמים זה סתם כיף ותאמינו לי אם יום אחד אראה גם הזדמנות עסקית - לא אוותר עליה. אבל אם הייתי מסתכל רק על הפן העסקי כנראה לא הייתי נהנה מהדרך</p> </div> לחבר שני תחביבים http://artyom.cppcms.com/post/338 http://artyom.cppcms.com/post/338 <div style="direction:rtl"> <p>אני חובב אסטרונומיה. בתור חובב אסטרונומיה אני סובל ואחת הבעיות הגדולות של העולם המודרני - זיהום אור. יש המון גרמי שמיים חיוורים כמו גלסקסיות וערפיליות שפשוט לא ניתן לראות מהעיר. בשביל זה צריך לנסוע לנגב או לרמת הגולן ולבלות לילה בתצפית. זה מאוד כיף כמובן. אבל זה לא תמיד נגיש.</p> <p>אחד המעקפים לבעיה זה שימוש בצילום. מצלמה שיכולה לאגור פוטונים מגלקסיות מרוחקות ומאפשרת לחדור דרך שכבת זיהום אור כבדה ולהראות לנו גרמי שמיים עמומים. זה כמובן לא תחליף לצפייה ישירה אבל גם נותן יתרונות רבים אחרים. במובן, צילום אסטרונומי הוא נושא מורכב שדורש שימוש בתוכנות ייעודיות: איסוף תמונות רבות ככל הניתן, ועיבוד שלהם (הערמה) כדי לקבל תמונה יפה של איזו ערפיליות או גלקסיה.</p> <h2>אמרנו לינוקס?</h2> <p>אז מה המצב התוכנה בתחום זה מבחינת תוכנה חופשית ולינוקס? יש ויש. חלק הארי של הכלים הם חופשיים/קוד־פתוח. יש לא מעט תוכנה ללינוקס, אם כי הדברים הטובים ביותר רצים על חלונות. רוב הדרייברים של המצלמות דווקא סגורים. אבל לרוב יש גרסאות לינוקס, Raspberry PI ועוד.</p> <p>עכשיו, בצילום אסטרונומי יש נדבך חשוב שמעניין אותו במיוחד: Electronically Assisted Astronomy או EAA בקיצור. פירושו ביצוע כל הפעולות הנדרשות לצילום (כולל עיבוד, איסוף תמונות והערמה) בזמן אמת, כאשר עם כל תמונה חדשה של האובייקט, אתה מקבל את התמונה הסופית המשופרת יותר ויותר. המטרה של EAA בניגוד לצילום, לא להגיע לתמונה הטובה ביותר אפשרית, אלא להגיע לתמונה שמספיק טובה כדי לראות את האובייקט ולהנות ממנו.</p> <p>למעשה, במקום לצפות באובייקט דרך עינית, צופים בו דרך המסך. ובניגוד לצילום אסטרונומי שיכול להמשך שעות ארוכות, מסתפקים בזמן איסוף כולל קצת יחסית - מעשרות שניות עד דקות בודדות - כי המטרה לראות ולעבור לאובייקט מעניין הבא. מה מצב התוכנה פה? אם בצילום היה מאתגר בלינוקס, פה המצב קשה. יש מעט מאוד פתרונות ולא כולם עובדים ונוחים.</p> <p>הבעיה השניה, מבחינתי, זה ש־EAA דורשת לרוב להביא מחשב נייד לשטח כדי להפעיל את כל התוכנה המסובכת הזו. למעשה, אם תצפיתן שצופה ויזואלית יכול להביא איתו תיק אחד ובו טלסקופ, חצובה וכמה עיניות, צלם צריך להביא איתו לשטח: חצובה ממונעת, עשרות כבלים, מחשב, ספק כוח שיספיק למספר רב של שעות ועוד. הקמה וקיפול של הציוד לצילום יכולים לקחת בקלות בין חצי־שעה ולשעה בניגוד לצופים בעין - העושים הכל במספר דקות בודדות.</p> <p>אבל לרובינו יש כבר מחשב די חזק ונייד: טלפון או טאבלט! לו רק יכולתי לחבר את המצלמה ישירות לאליהם...</p> <h2>אז הרמתי את דגל</h2> <p>בניתי פתרון ל־EAA עבור לינוקס ואנדרואיד ושמו <a href="https://github.com/artyom-beilis/OpenLiveStacker">OpenLiveStacker</a>. והוא בנוי בצורה הבאה:</p> <ul> <li>הקוד כתוב ב־C++‎ עם שימוש ב־OpenCV לצורך עיבוד תמונה</li> <li>הממשק בנוי כ־web interface שמדבר ב־REST עם השרת - מה שמאפשר בניית ממשק בלינוקס ואנדרואיד באותה צורה וגם מקל על גישה מרחוק במקרה והתוכנה רצה על pi. כמובן שהשרת מבוסס CppCMS. מה שמאפשר חיבור קל ונוח בין הקוד שדורש ביצועים הגובהים לממשק משתמש.</li> <li>הדרייברים נטענים דינאמית: <ul> <li>אחד עבור מצלמה גנרית עם פרוטוקול UVC על בסיס libusb/libuvc- שתומך במצלמות רשת או במצלמות כמו SVBony sv105 - אבל הוא מוגבל לצורכים אסטרונומיים</li> <li>דרייבר של ASI ZWO - החברה המובילה בתחום, שעובד מול SDK שלהם. לצערי הדרייבר עצמו הוא קוד סגור, אבל יש להם גרסה לאנדרואיד.</li> <li>דרייבר גנרי שיודע לקרוא קבצים מהספרייה איך שהם מגיעים - מה שמאפשר חיבור לכל מצלמה אחרת דרך כלים קיימים כמו indi/ekos.</li> </ul> </li> <li>לצורך תמיכה באנדרואיד יש אפליקציה קטנה שעוטפת את השרת ומנהלת גישה ל־USB (כי באנדרואיד הכל צריך להיות מסובך)</li> <li>לצורך הקלה על התמצאות יש חיבור לתוכנה פופולרית מאוד בתחום אסטרונומיה: ASTAP שיש לה גם גרסה (קובץ ריצה) לאנדרואיד. הדבר המעניין בתוכנה הזו שהיא כתובה בפסקל! לא חשבתי שאתקל בדבר כזה בימינו.</li> </ul> <h2>מה למדתי?</h2> <ul> <li>בניית אפליקציות אנדרואיד זה די סיוט וזה לא בגלל השפה אלא בגלל שצריך ללמוד פחות או יותר הכל מ־0. מזל שרוב הקוד ניתן לכתוב ב־C++‎.</li> <li>כמעט כל דבר באנדרואיד עובד "קצת שונה". למשל: אין לך ‎/tmp, להריץ exe חיצוני זה סיפור שעלה לי בלילה לבן, להביא קבצים עם אפליקציה זה גם לא משהו טריוויאלי. בקיצור. זה לינוקס, אבל לא בדיוק.</li> <li>אני שונא לעבוד עם קוד סגור. אומנם ASI ZWO משחררים דרייברים לאנדרואיד, אבל הם גם הכניסו <a href="https://bbs.astronomy-imaging-camera.com/d/16038-asi-zwo-android-sdk-critical-bugs">באג מעצבן</a> שגורם ל־RTTI לא לעבוד! למעשה כל תכנת החיבור ל־SDK שלהם כתבתי ב־C+-‎ בגלל אי זמינות של RTTI. וזה לא היה משהו מסובך אם הייתי יכול לקמפל את הדרייבר מחדש הבעיה הייתה פשוט נעלמת.</li> </ul> <h2>שורה תחתונה</h2> <p>אבל מה שחשוב, שבשורה תחתונה, יש לי פתרון פשוט - לעבוד עם טאבלט שבקושי צורך חשמל, קל ונוח.</p> <p><img src="https://user-images.githubusercontent.com/14816918/229337011-72031279-8de8-4be0-b1a1-61d592525230.jpeg" width="450" height="400"></p> </div> התקדמות חשובה בתמיכה ב־OpenCL ב־pytorch. http://artyom.cppcms.com/post/337 http://artyom.cppcms.com/post/337 <div style="direction:rtl"> <h2>רקע</h2> <p>היום pytorch היא אחת התשתיות המובילות בעולם למידה עמוקה. יש לה יתרונות רבות, אבל מבחינת המפתח זה קוד איכותי ותיעוד טוב. הקוד כתוב בצורה מאוד מודרנית עם שימוש נכון ביכולות C++‎ מה שמאוד מקל על הפיתוח. אני עובד בתקופה האחרונה על פיתוח מנוע עבור pytorch מבוסס OpenCL כחלופה ל־cuda.</p> <p>כבר כתבתי <a href="http://blog.dlprimitives.org/post/2">בעבר</a> על חשיבות התמיכה ב־OpenCL.</p> <p>אבל בכל זאת אזכיר כמה נקודות מבחינת קהילת תוכנה חופשית וקוד פתוח:</p> <ol> <li>אנחנו זקוקים בתמיכה חוצת פלטפורמה בכרטיסי מסך מיצרנים שונים כמו AMD, Intel וכמובן nVidia.</li> <li>אנחנו זקוקים למימוש האלגוריתמים המרכזיים כקוד פתוח הזמין לכל (ולא כקופסה סגורה ש־nVidia נותנת)</li> <li>אנחנו רוצים לעבוד עם סטנדרטים פתוחים וזמינים כמו OpenCL ולא מימושים ספציפיים של יצרן (כמו cuda).</li> </ol> <p><a href="https://github.com/artyom-beilis/pytorch_dlprim">הפרוייקט ב־github‏</a></p> <h2>אז מה חדש? קלות אינטגרציה!</h2> <p>עם שחרור גרסה 1.13 של pytorch חל שיפור משמעותי ב־out-of-tree-backend. עכשיו הוספת מנוע אימון מבוסס OpenCL היא פשוטה מאוד ולמעשה שאלה של מספר דקות, אפילו בוונידוס העניין יחסית פשוט. המשמעות שאפשר להשתמש במנוע OpenCL בקלות רבה הן בלינוקס והן בווינדוס.</p> <p>מה עם הביצועים? אם משווים מול גרסת cuda/cudnn על אותו ה־gpu מדובר בין 50 ל־70 אחוז ביצועי cuda באימון ובין כ־60 ל־80 באבלואציה (תלוי ברשת כמובן).</p> <p>למרות שהמנוע עדיין ניסיוני וחסרים בו לא מעט פעולות הוא נבדק בהצלחה על עשרות רשתות כמו resnet, mobilenet ורבות אחרות.</p> <p>המנוע עצמו מבוסס על ספריית <a href="https://github.com/artyom-beilis/dlprimitives">dlprimitives‏</a> שאני מפתח במקביל והיא חלופה ל־cuDNN על בסיס OpenCL וגם מנוע חיזוי שעובד עם מודלים בפורמט ONNX - שזה נושא גדול בפני עצמו.</p> <h2>מה המשמעות של זה?</h2> <ul> <li><p>משתמשי AMD יכולים לאמן רשתות. הם לא מוגבלים למספר מצומצם של דגמים ש־rocm תומך בהם או לשימוש בלינוקס בלבד. התמיכה היא גורפת מ־APUים ישנים כמו Stoney Ridge ועד ל־RDNA 2 וגם זה עובד על "חלונות" למי שמעוניין.</p> <p> זו הייתה משימה כמעט ובלי אפשרית עד היום. עכשיו זה במרחק מספר פקודות</p></li> <li><p>תשתית אימון היא קוד פתוח לגמרי גם אם עובדים עם nVidia (טוב חוץ מהדרייבר שלהם)</p></li> <li>כל מה שצריך זה דרייברי של OpenCL. לא צריך את כל המפלצת של cuda (מי שיצא לו להתקין לשדרג לגלות בעיות תאימות יבין אותי מידי)</li> </ul> <h3>מחפש עזרה...</h3> <p>מישהו יודע איך אפשר לבנות ולפרסם whl לפלטפורמות שונות? רצוי איזה שירות ענן שיעשה זאת? כדי שזה יהיה ממש במרחק של pip install <code>:-)</code></p> </div> מעשה בשני NaNים http://artyom.cppcms.com/post/336 http://artyom.cppcms.com/post/336 <div style="direction:rtl"> <p>לאחרונה ניסיתי להריץ אימון של GAN על pytorch עם תמיכה ב־dlprimitives. אחד דברים הלא נעימים באימון של GANים באופן כללי זה שהם לא ממש יציבים ומתבדרים בקלות.</p> <p>שמתי לב שבגרסת cuda הוא רץ ללא דופי ובגרסה שלי הוא נתקע. נתקע על ביצוע backpropogation ב־convolution. אחד ההבדלים העיקריים באגלוריתם בהשוואה לשאר היה שימוש בפעולות אטומיות לחישוב סכום (טריק מאוד נפוץ במימוש קונבולוציה)</p> <p>אחרי זמן מה הגעתי למסקנה שהחישובים מגיעים ל־NaN באיזהו מקום ואז הכל נתקע. לא הבנתי למה פעולת חיבור אטומית פשוטה נתקעת. בכל מקרה איתרתי באג האחר שהביא לחישוב ה־NaN והכל הסתדר. אבל בכל זאת נושא התקיעה הטריד אותי.</p> <p>כתבתי שאלה ב־Stackoverflow העתקתי קטע קוד... ואז נפל האסימון</p> <pre><code>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; } </code></pre> <p>קחו לכם כמה דקות.</p> <p>פעולת comxchg ב־OpenCL עובדת רק על int. לכן הייתי צריך לעשות bit-casting ל־int ובחזרה (<code>as_float</code> ו־<code>as_int</code> בדיוק עושים את זה). ואז תנאי הבדיקה <code>prev==old</code> ביצעתי ב־float במקום בשלמים.</p> <p>כך שאם הערכים שווים אז ההחלפה הצליחה. אבל מה שכחתי? NaN == NaN תמיד נותן false! ולכן תקעתי בלולאה אינסופית כי התנאי לעולם לא ייתקיים. החלפתי לבדיקה בערכים שלמים (קרי ייצוג בינארי) והכל עבד חלק.</p> <p>מסקנה NaN הוא טריקי... יש לכבדו</p> </div> חצי שנה אחרי פיתוח אפליקציה AstroHopper, הידוע גם בשם SkyHopper http://artyom.cppcms.com/post/335 http://artyom.cppcms.com/post/335 <div style="direction:rtl"> <p>לפני <a href="http://artyom.cppcms.com/post/329">כחצי שנה</a> התחלתי לפתח <a href="https://github.com/artyom-beilis/skyhopper/">אפליקצייה</a> שעוזרת למצוא אובייקטים מעניינים בשמיים. הרעיון היה פשוט: לשלב מספר חיישנים הזמינים ב־Web API, ביניהם חיישני התנועה של טלפון חכם שהשתפרו פלאים בשנים אחרונות, GPS וכמובן גישה לבסיסי נתונים פתוחים. כל זה כדי למדוד שינוי זווית של הטלפון כדי להכוון לאובייקט רצוי כמו גלקסיה או צביר כלשהו מכוכב ידוע.</p> <p>הרעיון זכה להצלחה רבה. עשרות משתמשים ידועים נתנו משוב, ביקורת וכיוונים לשיפור. היום אפשר להגיד בבטחון שזוהי אפליקציית ניווט מוצלחת שמקלה הן על אסטרונומים צעירים והן על וותיקים כאחד.</p> <p>אבל מה שאני רציתי דווקא לדבר עליו זה המשוב שקיבלתי מהמשתמשים. עד היום רוב הקוד הרציני כתבתי לטובת מתכנתים עצמם: cppcms, boost, cppdb ופה ושם היו כמו פרויקט לקהלים פחות טכניים biditex, makeahmap אבל כולם בסופו של דבר עבדו דרך "קובץ הגדרות". לעומתם AstroHopper זהו היישום קוד פתוח הראשון בו באמת השקעתי בכתיבת ממשק משתמש גרפי. יותר מזה מדובר בממשק לטלפון נייד.</p> <p>אני קיבלתי המון הערות והצעות שיפור בונות שאת רובם יישמתי וראיתי כיצד זה שיפר את חווית המשתמש (שלי ושל אחרים)</p> <ul> <li>לשנות צורה של בחירת נק' איפוס</li> <li>כיצד להקל על איפוס אחרי איפוס</li> <li>לבטל כפתורים מיותרים</li> <li>להתאים את ממשק למסכים קטנים</li> <li>לשפר את תיבת החיפוש וההתנהגות שלה</li> <li>לשנות בחירת הפרמטרים לתצוגה</li> <li>אפשר שליטה על גודל הפונטים במפה (שהסתבר מאוד קריטית לאלו שמשתמשים במשקפיים וגם לי כי בלילה בחושך פונטים כגודלים יותר עוזרים)</li> <li>לעשות איפוס על כוכבי הלכת ולא רק כוכבים ואפילו על גרמי שמיים עמוקים אחרים</li> <li>גם עזרו בלעשות תיקונים ל־iPhone אפילו שלא היה ברשותי</li> </ul> <p>היו בטח עוד הרבה שאני כבר לא זוכר. אני בטוח שיש עוד כל מיני דברים שאפשר וצריך לשפר. אין זה ממשק יפה במיוחד או מעוצב במיוחד - אבל הוא עושה את העבודה.</p> <p>יש עוד דברים שאפשר לשפר כמו לעשות zoom in-out בעזרת תנועת pinch שמסתבר <a href="https://www.cloudynights.com/topic/761416-need-help-with-validation-of-a-smart-phone-web-application-for-star-hopping-that-works-like-cell-phone-based-digital-setting-circles/?p=11349574">לא כל־כך קלה</a> למימוש. אבל בכל הסיפור הזה הבנתי דבר פשוט - שאולי יישמע טרויוואלי למי שמפתח UI למחייתו:</p> <p>הקשיבו למשתמשים שלך. יש להם הרבה רעיונות טובים שעוזרים לשפר את חווית המשתמש. אני חושב שזו אחת האינטרקציות הפרודוקטיביות ביותר שהיו לי עם משתמשי התוכנה שלי - אולי שבגלל שאנשים אהבו את הרעיון וניסו לתת ביקורת בונה. אולי בגלל שקהילת האסטרונומיה היא מתאפיינת מטבע הדברים הו בשיתוף הפעולה והן בהבנה טכנית עמוקה.</p> <p>שורה תחתונה - זה אחד הפרויקטים היותר מיוחדים שעבדתי עליו; וגם אחד הקטנים בהיקף הקוד בצורה מפתיעה - רק כ־2,500 שורות הקוד כולל התיעוד!</p> </div>