הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מאמרים בנושא בינה מלאכותית.
למידה עמוקה מחוץ לקופסת nVidia
לפני 3 וחצי שנים סקרתי את מצב הלמידה העמוקה בקוד פתוח (מחוץ לעולם nVidia) והמצב היה בכי רע.
גם עכשיו המצב לא מזהיר. לפני מספר שנים רכשתי AMD rx6600XT ולא מזמן בתור ניסוי קניתי Intel Arc a380.
נתחיל מפתרון מבית AMD - השכפול של cuda בשם hip
קודם כל בניגוד לשנים הקודמות בהן אפילו לא הייתה תמיכה בכרטיסי RNDA התקנתי לאחרונה אובונטו 22.04 התקנתי rocm הורדתי pytorch מתאים - וזה עבד (כמעט היה צריך להגדיר משתנה סביבה כדי שיכיר בכרטיס שלא נתמך באופן רשמי) אבל זה עבד. לא נתקלתי עד עכשיו במשהו שלא עבד. שזה בהחלט התקדמות מרשימה. כמובן גם כל הקוד של AMD הוא פתוח שזה יתרון ענק.
אבל... הם זרקו תמיכה ב-GCN4 זאת אומרת הכרטיס הישן rx560 כבר לא עובד עם rocm ואפילו דרייבר OpenCL שלהם קורס. דרייבר Mesa פשוט גרוע ו-rustocl קטסטרופה אחת גדולה, אבל הצלחתי להתקין amdgpu-pro הישן והלא נתמך - אבל לפחות עובד.
כלומר בעלי RDNA נראה יהנו, אולי גם אלה עם Vega (אבל לא APU) ורק אם משתמשים בלינוקס.
השחקנית החדשה בשוק היא Intel Arc
בניגוד ל-AMD הם לא שכתבו cuda אלא עובדים עם pytorch כ-plugin. ההתקנה קצת יותר מסובכת אבל הצלחתי. להבנתי החל מ-pytorch 2.5 או 2.6 זה כבר אמור להיות שקוף יותר. הכרטיס עובד. האימונים? תלוי עד כמה הקוד שאתה מנסה להריץ תלוי בעבודה ישירה מול cuda בלבד. אבל הצלחתי אפילו להריץ yolo ועוד כל מיני רכיבים. כך שהמצב נראה טוב יחסית. אבל כמובן Intel החליטו ללכת בדרך ה-nית שאף אחד לא עובד עם זה sycl... טוב לפחות זה תקן פתוח (שתכל'ס רק Intel עובדים איתו)
מה לגבי ביצועים. טוב. עשיתי השוואה בין gtx960 לבין arc a380. מבחינת המפרט
- לשניהם יש 1024 מעבדים
- מהירות הזכרון של אינטל כ-143GB/s לעומת כ84GB/s בנבידיה
- השעון הוא 2450MHz לאינטל לעומת כ-1506MHz משמע: יש כ-5020GFlops מול 3080GFlops יתרון
איך הביצועים... לא בדיוק טובים לעומת מה שכתוב על הנייר
למרות שהמהירות התיאורתית אמורה להיות יותר טובה בכ-%63 בפועל באימון היתרון היה סה"כ 38% באימון בממוצע ו-48% בחיזוי. אם לוקחים חציון המצב עוד יותר גרוע. 13% שיפור באימון ו-40% בחיזוי.
סיכום
אז המצב השתפר פלאים לעומת מה שהיה. זה רחוק מהליות מושלם אבל יש התקדמות ומה שחשוב שההתקדמות החדשה היא בתחום קוד פתוח.
עכשיו מה לא טוב? עדיין כל אחת מהחברות הגדולות בוחרת בפתרון משלה...
- nVidia זה cuda
- AMD זה hip/rocm (העתק של cuda)
- Intel זה - sycl אבל לפחות יש תמיכה גם ב-opencl ב-onednn
- Apple זה metal
- microsoft זה DirectML
נפלתם על הראש? ברור ש-nvidia תהיה מונופול בשוק.
ומה אני עושה?
ממשיך לעשות את הבלתי אפשרי ושחררתי עוד גרסה מספר 0.2.0 של OpenCL backend ל-Pytorch עם הרבה תיקונים.
מוזמנים לנסות - אבל הדרך עוד ארוכה
למידת מכונה פתוחה באמת, האם אני נלחם בקרב עבוד מראש?
לפני מספר שנים התחלתי פרוייקט 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 (רצוי גם לחלונות)
התקדמות חשובה בתמיכה ב־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 הוא טריקי... יש לכבדו
עדכוני dlprimitives
מספר עדכונים:
התקדמות יפה עם pytorch - בוצעה ולידציה של מרבית הרשתות של סיווג הנמצאות ה־torchvision:
alexnet
resnet18
resnet50
vgg16
densenet161
googlenet
squeezenet1_0
inception_v3
shufflenet_v2_x1_0
mobilenet_v2
mobilenet_v3_large
mobilenet_v3_small
resnext50_32x4d
wide_resnet50_2
mnasnet1_0
efficientnet_b0
efficientnet_b4
regnet_y_400mf
מה שאומר שניתן לאמן עכשיו הרבה סוגי רשתות. על הדרך מצאתי לא מעט באגים ותיקנתי אותם
ניסיתי לעשות אינטגרציה עם OneDNN של אינטל (מאין cudnn ל־GPU שלהם) רק כדי לגלות שהביצועים שלהם בפורמט NCHW גרועים. כיוון שרוב התשתיות עובדות עם הפורמט הזה pytorch, caffe, mxnet ועוד אז OneDNN לא ממש רלוונטי בינתיים. אחזור לשם כשיקרה אחד מהשניים:
- אינטל יתקנו את הביצועים עבור הפורמט הנפוץ
- אני אפתח תמיכה ב־NHWC לטובת TensorFlow בו זה פורמט ברירת מחדל
המשך יבוא