פריצת דרך בעולם ההאצה הגראפית - cache - כרטיסי מסך - HWzone פורומים
עבור לתוכן
  • צור חשבון

פריצת דרך בעולם ההאצה הגראפית - cache


nec_000
 Share

Recommended Posts

  • תגובות 39
  • נוצר
  • תגובה אחרונה

משתתפים בולטים בדיון

תודה רבה על ההסבר המפורט! כיף לראות פה בפורום גם מידע מקצועי מפעם לפעם...

 

דבר ראשון, רציתי לשאול: האם יהיה יתרון ב512MB? הרי לcache של המעבד אנחנו צריכים הרבה בלוקים קטנים כי התוכנית קוראת מהRAM לא בהכרח ברצף, אבל כיוון שהGPU מעבד frame frame זה ברצף בזיכרון, כך שלכאורה נרוויח מהכפלת הcache רק במידה שתוכפל מידת המקבילות של הGPU, לדוגמ' שבמקום לעבד טקסטורה אחת כל פעם הוא יעבד שתיים (המספרים להמחשה בלבד), או שנכפיל את הרזולוציה.

 

דבר שני, למעשה זה קצת עצוב עבורנו כצרכנים. כי זה בעצם אומר שאין כמעט שיפור בRDNA2 לבד מזה, מה שאומר שבדור הבא (?) כשNVIDIA תאמץ את הטכנולוגיה גם היא שוב נגיע לGEFORCE 40 חזק פי שתיים מNAVI 3. מכיוון שאם אני מבין נכון, 30 חזק יותר מBIG , רק שהיתרון של הcache מציב אותם באותה רמה.

קישור לתוכן
שתף באתרים אחרים

 

שאפו,

יפה ונעים לראות חברים שמגיעים מעולמי ומסוגלים להעריך. אינך רק מפגין ידע ברמה גבוהה של מדעי המחשב ראיתי

בשרשורים אחרים (גם), אלא שואל (פה) את השאלות הנבונות והנכונות ביותר. אהבתי 👍

 

לשאלותיך אחת אחת: (טקסט שלך בשחור מענה שלי בכחול)

דבר ראשון, רציתי לשאול: האם יהיה יתרון ב512MB? הרי לcache של המעבד אנחנו צריכים הרבה בלוקים קטנים כי התוכנית קוראת מהRAM לא בהכרח ברצף, אבל כיוון שהGPU מעבד frame frame זה ברצף בזיכרון, כך שלכאורה נרוויח מהכפלת הcache רק במידה שתוכפל מידת המקבילות של הGPU, לדוגמ' שבמקום לעבד טקסטורה אחת כל פעם הוא יעבד שתיים (המספרים להמחשה בלבד), או שנכפיל את הרזולוציה.

פגעת בול - להבדיל מ CPU שבו אפיון הקריאות הוא מסוג random access to the memory, בעבוד גראפי זה

הרבה יותר מסודר. המעבד הגראפי קורא מקטעים די ספציפיים בכל אטרציה של פעולה. ולכן פחות חשובה יכולת

random access memory עבור GPU, והרבה יותר חשוב לו זה  memory access to specific memory

addresses ברובד של קריאות.  כתיבות זה לא מעניין, הוא כותב למרחב מצומצם של frame buffer.

ומשכך, כל עוד בכל איטרצה של סוג של פעולה חישובית, מרחב הכתובות שהוא זקוק להם יכול להתחם על ידי buffer

בגודל ברור וקבוע, הגדלת אותו buffer לא ממש תשפיע על הביצוע. ולכן, אם נמצא ש- 128MB מספקים את הצורך

עבור , ועבור גודל הטקסטורות שבהם עורכים שמוש בתעשיית ההאצה הגראפית דהיום, אזי הגדלת נפח ה- buffer 

מעבר לכך בקושי תשפיע אם בכלל. אבל מה כן, אם ישתמשו ברזולוציות גבוהות יותר לדוגמא , היא לבדה צורכת רק

עבור frame buffer פי 4 נפח מ- , שמשמעו 128MB לפריים בודד!   ואז 128MB cache אינו מספק עוד וזה מצב

שיחייב מעבר ל- 256 או 512MB לפחות.  עוד אפשרות היא עליה באיכות הויזואלית של טקסטורות, לגדולות יותר,

שתופסות יותר נפח בתורן, מה ששוב עשוי לאלץ להגדיל את ה- cache למעל 128MB. אז נסכם כך:

כל עוד לא עולים ברזלוציות למעל , וכל עוד גודלן של הטקסטורות אינו עולה משמעותית מהנפחים המקובלים

בתעשיה כיום, כנראה שלא יהיה ערך מוסף ממשי ב- cache גדול יותר מעל 128MB הנוכחי.

 

דבר שני, למעשה זה קצת עצוב עבורנו כצרכנים. כי זה בעצם אומר שאין כמעט שיפור בRDNA2 לבד מזה, מה שאומר שבדור הבא (?) כשNVIDIA תאמץ את הטכנולוגיה גם היא שוב נגיע לGEFORCE 40 חזק פי שתיים מNAVI 3. מכיוון שאם אני מבין נכון, GeForce 30 חזק יותר מBIG Navi, רק שהיתרון של הcache מציב אותם באותה רמה.

כן ולא וזו יותר הערכה שלנו. הדבר הראשון הוא נכון, מכיוון שאי אפשר להגן על הטמעת ה- cache כיישום בעבוד גראפי

וכל אחד יכול להטמיע כרצונו, ומשהשיטה הזו והיתרון שלה ברורים מאליו בעוצמתם, למעשה יחייבו את כולם להטמיע

במוקדם או במאוחר anyway, סביר מאד אם לא די וודאי , שנוידיאה מיישמת אותו כבר בסבב הבא סדרת 4000. ואז גם

היא תהנה מאותו יתרון עצום כמו ש- navi21 נהנה. משמע שגם נוידיאה תוריד מסדר היום את בעיית מגבלת הרוחב

פס  ותמגר את הלחץ הזה סופית.

 

כמו כן אין ספק שהפטנט החדש מאפשר לליבה של navi21 לעבוד בנצילות גבוה יותר מ- ga102 ורוב הזמן אולי נצילות

100% ממש שהיא למעשה נדירה. ולכן יכולה לחלץ יותר ביצועים מפחות בוכנות במנוע.

 

במקרה ששתי המתחרות אינן סובלות ממגבלת רוחב פס כמו שיהיה בדור הבא, עולים על פני השטח וכדבריך, אך

ורק הפערים הביצועיים של הליבות. טענת שסדרה 3000 חזקה יותר מ- big . אני לא בטוח שזו קביעה שניתן

לעשותה היום בוודאות, אם כי קו המחשבה שלך מובן לי, לאור מה שצריך לפצות בצד נוידאה על הנצילות המופחתת

ברובד . חסר לנו מידע מספק להבין איזו מהליבות ga102 או navi21 חזקות יותר. יחסי המרכיבים שכל אחת הטמיע

שונים, לכל אחת מהליבות לבטח יתרונות במקומות אחרים על פני האחרת.

 

למשל אני כבר ער לכך שהשבבים של navi21 כנראה חזקים יותר ברזולוציות נמוכות, והשבבים של ga102 חזקים יותר

ככל שהרזולוציה עולה. הדבר עשוי לנבא לנו כי מרכיב הגאומטריה אצל navi21 עדיף לעומת מרכיב הרסטריזציה, בעוד

שאצל נוידיאה זה הפוך וזה כבר משהו שאנו יודעים שהם שינו בסדרה 3000 לעומת הסדרות הקודמות.

בקיצור, כששתי החברות תאמצנה את ה cache ולא רק , נהיה חכמים יותר. עוד שנתיים ?

נמתין בסבלנות.

 

מה שבטוח הוא, למי שמבין את המטריה, מי שקרה מה שהסברנו במאמר והבינו כהלכה, וזה לא טריויאלי למי שאינו

מגיע מרקע מתאים, לכן ניסיתי הכי טוב שאני מסוגל להסביר לאדם הפשוט ומקווה שהצלחתי, זה ש- הביאה פה

שיחוק אלגוריתמי מארץ האסים בשרוול, וזה מדהים שהם חשבו על ליישם זאת ראשונים בתעשיה. זה game

changer.  יש חכמי מתמטיקה ולאגוריתמיקה ב- AMD היום, ללא ספק. ברמה הגבוה ביותר.  ולכן המגרש פתוח היום

לתחרות, וזה בואו נקווה, מה שיהיה מעתה ואליך לשנים הבאות. אילו רק יכלו להגן על הפטנט ל- 7 שנים זה היה

מאפשר בידם לפתוח פער יפה על נוידיאה, שהיתה נחנקת בלי רוחב זכרון מספק, או שהיה יוצא לה מאד יקר ליישם זכרון

מהיר אבל בשיטת brute force.

 

תבינו חברים, הטמעת cache במעבד גראפי היא אחת הרבולוציות הדרמטיות ביותר שנולדו אי פעם בעולם ההאצה

הגראפית. יתכן שהוא יכול להחשב, כגדול ההמצאות אי פעם בתחום, או לפחות אחד מהשלושה הגדולים ביותר. 
 

לא מפליא איך הם במכה אחת סגרו פער של עשור מול נוידיאה ולו רק בגלל הפטנט הזה, שכמה שהוא פשוט, ככה הוא

גאוני. אני מת לפגוש את המדען/מהנדס שהגה אותו. מת לשוחח עימו. הוא ראוי לדעתי לפרס מדעי כלשהו. תרומתו

לאבולוציית המדע בתחום מרשימה.

 

 

נערך על-ידי nec_000
קישור לתוכן
שתף באתרים אחרים

ווואו...מאמר מדהים! יישר כוח! 

הלוואי והיו ויהיו עוד מאמרים מאירי הבנה בשאר תחומי החומרה באתר כאן.

 

כמה שאלות ברשותך:

 

1.אם הבנתי נכון הרעיון הוא שעל הקאש ישבו 2 , אחת שעוברת בניה\עיבוד עם כל נושא הפוליגונים, ועוד תמונה שלמה.

אם תמונה ברזולוציית צורכת נפח של 32MB אז 2 תמונות צורכות 64MB, לא הבנתי למה הוצרכנו להמתין לליטוגרפיה שתאפשר 128MB של קאש, שהרי ע"פ ההסבר הנ"ל דיי ב64MB, לאן התפספסו לי בהסבר עוד 64?

 

2.ידוע באופן כללי שקצב תעבורת הנתונים  של רכיבי חומרה שמאחסנים נתונים מדורג באופן שהנמוך ברשימה מהיר ביותר :

    דיסק קשיח\SSD 

    RAM

    ואז רמות הקאש השונות במעבד L1\L2\L3 ובין כל רמה לרמה, הנפח קטן, הזיכרון קרוב יותר למעבד ומהיר יותר.

 

   מסיבות שעדיין לא נתקלתי בביאור להן, CPU (בסגמט הגבוה) עובדים בסדר גודל של 5GHZ, בעוד שGPU עובדים בסדר גודל של 2GHZ (אני מודע     לכך שהם שונים באופנים רבים ביעודם\מבניהם) ומכאן מגיעות שתי תתי שאלות:

 

א.מדוע רוחב פס לזיכרון (בכלליות בשלל הכרטיסים הקיימים, ובפרט בחידוש של שעכשיו הזיכרון גם ברמת הקאש) היא בסדר גודל נמוך מאוד יחסית, MBPS1612 ע"פ השקף הנ"ל, לקצב תעבורת נתונים של כונן ממוצע, בעוד שזה האחרון אמור להיות איטי יותר מאחר והוא לא נמצא ברמת הקאש של המעבד. מה כאן התפספס לי?

 

ב.אם מה שחונק את קצב עבודת ה GPU הוא מהירות הזיכרון (שבכל מקרה מהירה הרבה יותר מRAM רגיל) בעוד שהוא עצמו עובד בחצי מהמהירות של הCPU, למה בCPU רגיל מהירות הזיכרון לא מגבילה יחסית את עבודת הCPU, והיא שלעצמה דיי זניחה בתוספת הביצועים (לצורך המחשה ההבדל בין MHZ3000 ל MHZ4000) בעוד שבGPU היא צוואר הבקבוק. לא ראינו שבמעבדים אצים לסגל כדי לזנק בביצועים, אלא רק מנסים להגביר את תדר העבודה (כמובן גם הוספת ליבות ושיפור ומזעור הארכיטקטורה וכו'). איפה מונח ההבדל היסודי שגורם למהירות הזיכרון (שגם ככה מהיר) בGPU לבקבק את העסק, בעוד שהליבה איטית מאוד יחסית לCPU?

קיבלתי רושם דיי פרדוקסאלי בגורם המאט בין הCPU לGPU

    

תודה

קישור לתוכן
שתף באתרים אחרים

@NoOne ברשותך, אנסה לענות על השאלה השנייה:

ציטוט של No-One

ם מה שחונק את קצב עבודת ה GPU הוא מהירות הזיכרון (שבכל מקרה מהירה הרבה יותר מRAM רגיל) בעוד שהוא עצמו עובד בחצי מהמהירות של הCPU, למה בCPU רגיל מהירות הזיכרון לא מגבילה יחסית את עבודת הCPU, והיא שלעצמה דיי זניחה בתוספת הביצועים (לצורך המחשה ההבדל בין MHZ3000 ל MHZ4000) בעוד שבGPU היא צוואר הבקבוק. לא ראינו שבמעבדים אצים לסגל DDR5 כדי לזנק בביצועים, אלא רק מנסים להגביר את תדר העבודה (כמובן גם הוספת ליבות ושיפור ומזעור הארכיטקטורה וכו'). איפה מונח ההבדל היסודי שגורם למהירות הזיכרון (שגם ככה מהיר) בGPU לבקבק את העסק, בעוד שהליבה איטית מאוד יחסית לCPU?

קיבלתי רושם דיי פרדוקסאלי בגורם המאט בין הCPU לGPU

CPU מודרניים מבצעים out-of-order execution. המעבד טריקים מאוד מתוחכמים כדי לא להיות מוגבל ע"י הRAM. לדוגמה, אם יש הוראה שדורשת מידע מהזיכרון, המעבד פשוט ידלג עליה ויבצע הוראות אחרות בזמן שהיא מתבצעת.

 

אני לא מומחה לGPU, אבל מההבנה הפשוטה שלי זה לא אפשרי. GPUs פועלים רק על הזיכרון - בניגוד לCPU שפועל בעיקר על רגיסטרים. אם אני צריך לעבד את התמונה, אני צריך גישה לזיכרון. כל שבלי שום ספק הזיכרון מגביל את המהירות. בנוסף, בגלל ריבוי הליבות, pipelines של GPUs פשוטים בהרבה ממקביליהם בCPU.

קישור לתוכן
שתף באתרים אחרים

ציטוט של af db creid

CPU מודרניים מבצעים out-of-order execution. המעבד מבצע טריקים מאוד מתוחכמים כדי לא להיות מוגבל ע"י הRAM. לדוגמה, אם יש הוראה שדורשת מידע מהזיכרון, המעבד פשוט ידלג עליה ויבצע הוראות אחרות בזמן שהיא מתבצעת.

תודה לך.

אני מבין שקשה לתת תשובה מאוד ברורה וקולעת מבלי להכנס בעובי הקורה למיקרו-אלקטרוניקה\מדעי המחשב\הנסדת חשמל או שאר התחומים מהם מגיעים לעסק המעבדים, וגם בהינתן תשובות כאלה סביר להניח שמי שלא בא מרקע שכזה יראה ג'יבריש לפניו.

 

אני מבין שהשאלה שלי נובעת ככל הנראה מחוסר הבנה בהבדל ההנדסי והפרקטי בו 2 סוגי המעבדים פועלים.

ובכל זאת התהייה הזו עולה לי ביתר שאת דווקא מהכיוון של , שהם נכון להיות החברה היחידה מבין השלוש (כחול אדום ירוק) שמייצרת CPU ו -GPU.

(אני מקווה שהניחוס כאן נכון ומובן -- ) את אותם "מאפיינים" שנמצאים בCPU בכדי שלא יוגבל ע"י הראם, (באופן היפוטתי כמובן) יכלו להטמיע בליבת העיבוד של הGPU, ובכך לפתור את בעיית מהירות הזיכרון, לפחות מצד שלהם יש הידיעה ליצר את שתי סוגי המעבדים.

וברור שהפתרון שלי הוא שגוי ובלתי אפשרי, כי אחרת לא היו ממתנים לליטוגרפיית 7NM בכדי להשתמש בקאש כמו שהוסבר למעלה.

 

רק שאשמח לרעיון\קו מחשבה כללי בהבדל בין סוגי המעבדים מדוע הדבר שלול מהמציאות.

 

קישור לתוכן
שתף באתרים אחרים

מענה ל- no one.

 

מעתיק את הטקסט שלך בשחור ומתייחס בטקסט כחול:

 

 

1.אם הבנתי נכון הרעיון הוא שעל הקאש ישבו 2 תמונות, אחת שעוברת בניה\עיבוד עם כל נושא הפוליגונים, ועוד תמונה שלמה.

אם תמונה ברזולוציית 4k צורכת נפח זיכרון של 32MB אז 2 תמונות צורכות 64MB, לא הבנתי למה הוצרכנו להמתין לליטוגרפיה שתאפשר 128MB של קאש, שהרי ע"פ ההסבר הנ"ל דיי ב64MB, לאן התפספסו לי בהסבר עוד 64?

ההסבר שהבאתי הוא מאד מתומצת (בכוונה) יש כמה וכמה מרכיבים שצריכים לשבת ב- cache בו זמנית. בכללם כל

הוקטורים, הקודקודים, הפוליגונים המחושבים, הטקסטורה (אחת לפחות כמובן), נתוני z buffering לחסכון בשכבות

הרנדור, נתוני mip mapping, רכיבי הארה, ועוד. יש היום גם  דחיסות מידע שיתכן, וצריכות כלי עזר בצד לסייע

לפרוש ולדחוס וכדומה. עם השנים נוספו גם עוד טכנולוגיות שזקן כמותי צריך לקרוא ולהשלים אותם.

ובנוסף לשמור מקום לחישובי ביניים כשטח עבודה... בקיצור ערב רב של נושאים.   זה מורכב מאד העסק הזה. ולכן, אם

פריים בודד בגודל שותה כבר לבדו רבע מכל ה- cache, זה כבר כבד מאד במה שזה מותיר ליתר הצרכים. חסר לנו

ה- stack המלא של , איך בדיוק אלגוריתמית היא מבצעת מה, מה שומרת ב cache, כמה נפח צורך כל דבר, ומה

סדר הפעולות וזריקת החומר החוצה מה- cache כדי לפנות מקום למשהו אחר.

וזה משהו שאינו נגיש לנו כי הוא סוד שלא יגלו אותו. אז לא ניתן לבצע חישוב משלנו, איך בדיוק הם עושים את זה. ככל

המסתמן, הם מסתדרים עם cache של 128MB וזה עושה את העבודה היטב. האם 64MB יכול להספיק איכשהו? יתכן.

נהיה הרבה יותר חכמים אחרי השקת Navi22 שהוא חצי גודל עם רק 40cu. אנו נראה באמצעותו, האם הסתפקו

ב- 64MB cache, או שנאלצו לשים גם 128MB ואז נלמד מזה משהו.

 

2.ידוע באופן כללי שקצב תעבורת הנתונים  של רכיבי חומרה שמאחסנים נתונים מדורג באופן שהנמוך ברשימה מהיר ביותר :

    דיסק קשיח\SSD 

    RAM

    ואז רמות הקאש השונות במעבד L1\L2\L3 ובין כל רמה לרמה, הנפח קטן, הזיכרון קרוב יותר למעבד ומהיר יותר.

 

   מסיבות שעדיין לא נתקלתי בביאור להן, CPU (בסגמט הגבוה) עובדים בסדר גודל של 5GHZ, בעוד שGPU עובדים בסדר גודל של 2GHZ (אני מודע     לכך שהם שונים באופנים רבים ביעודם\מבניהם) ומכאן מגיעות שתי תתי שאלות:

ההבדל בתדרי העבודה נובע מהצפיפות הטרנזיטורית ואורך מסלול האות.

ה- pipe line במעבד גראפי הוא פיסית מאד ארוך בגלל שהוא מחזיק אלפי ליבות, שאין ברירה, אלא לפרוס אותן על

שטח נרחב כדי שכולן יכנסו, וכתוצאה מכך, מסלול האות לכל אחת מהם יוצא מקצה לקצה לא קצר. בגלל הריחוק

הגאוגראפי. הגדלת מסלול אות מקטינה את פוטנציאל תדר הריצה.

הסיבה השניה היא אופי העבודה, במעבד גראפי אלפי ליבות שיורות במקביל יחדיו, הצריכה האנרטית חלקי שטח גדולה

יותר משמעותית ממעבד CPU ומשכך כמות החום הנדרשת לפליטה ליחידה שטח, היא כזו, שמגבילה את הנידוף, ולכן את התדר שניתן להגיע אליו מבלי לשרוף את המעבד.

עוד כוון שמרמז לנו, היום זה בהכי חדשים, ריזן, כ- 4 מיליארד טרנזיסטורים למעבד. מצד שני מעבד גראפי כמו 

שני החדשים שהושקו GA102 ו- NAVI21, הם 28 ו- 26 מיליארד טרניזטורים. די מהר מבינים פה את יחסי הכוחות

ועד כמה GPU זו מפלצת, שגדולה משמעותית בעומס שלה מאשר CPU וזה משפיע על התדר גם.

 

שלוב הסיבות לעיל, מאלץ מעבד גראפי לעבוד בתדרים נמוכים יותר משל CPU

 

א.מדוע רוחב פס לזיכרון (בכלליות בשלל הכרטיסים הקיימים, ובפרט בחידוש של AMD שעכשיו הזיכרון גם ברמת הקאש) היא בסדר גודל נמוך מאוד יחסית, MBPS1612 ע"פ השקף הנ"ל, לקצב תעבורת נתונים של כונן NVMe ממוצע, בעוד שזה האחרון אמור להיות איטי יותר מאחר והוא לא נמצא ברמת הקאש של המעבד. מה כאן התפספס לי?

שאני טעיתי במאמר,

כתבתי בכל המקומות בטעות סופר את הערך Mbyte כשהיה צריך להיות Gbyte. ובזכות שאלתך, נכנסתי ותקנתי

במאמר (תודה לך על כך).  ולכן אחדד כאן, שמהירות רוחב הפס איפה של 256bit באמצעות GDDR 6 היא

512Gbyte לשניה.  הרוחב  פס המשולב של ה cache וה- VRAM יוצא כ- 1600Gbyte לשניה.

ובהשוואה אליהן:

רוחב פס זכרון Ram במחשב מודרני המשתמש בזכרון הוא סביבות 30-50Gbyte. ורוחב פס של כונן מסוג

NVme הוא מסדר גודל של 1.5-3Gbyte בלבד.

 

ב.אם מה שחונק את קצב עבודת ה GPU הוא מהירות הזיכרון (שבכל מקרה מהירה הרבה יותר מRAM רגיל) בעוד שהוא עצמו עובד בחצי מהמהירות של הCPU, למה בCPU רגיל מהירות הזיכרון לא מגבילה יחסית את עבודת הCPU, והיא שלעצמה דיי זניחה בתוספת הביצועים (לצורך המחשה ההבדל בין MHZ3000 ל MHZ4000) בעוד שבGPU היא צוואר הבקבוק. לא ראינו שבמעבדים אצים לסגל DDR5 כדי לזנק בביצועים, אלא רק מנסים להגביר את תדר העבודה (כמובן גם הוספת ליבות ושיפור ומזעור הארכיטקטורה וכו'). איפה מונח ההבדל היסודי שגורם למהירות הזיכרון (שגם ככה מהיר) בGPU לבקבק את העסק, בעוד שהליבה איטית מאוד יחסית לCPU?

קיבלתי רושם דיי פרדוקסאלי בגורם המאט בין הCPU לGPU

מעבד מסתפק בכמות מטמון קטנה על מנת להגיע למצב, שרוב הדרישות שלו לקריאה כתיבה בקוד שכתוב

מתאים, מוצאות hit מול הזכרון מטמון  שלו ולא miss (אירוע שיאלצו לרדת ל- RAM). מנגד מעבד גראפי (ואנחנו

מדברים עדיין על העידן שהוא טרום cache) צריך לכל פעולה שלו לרדת על עד ל- VRAM ולמעשה כל קריאה וכתיבה

שלו נעשית ישירות מול VRAM.

 

נמצא שאם מגדילים את מהירות ה- ביצועי מעבדי CPU משתפרים בישומים מאד ספציים, אך לא משתפרים בכל

אותם מקרים שהוא ממילא עובד מול ה- cache שלו, ואלו מקרים רבים. לכן שמים את הדגש על מהירות שעון גבוה, IPC

גבוה, ו- cache גדול ומהיר, שתרומתם לביצוע CPU היא גדולה יותר בחשיבותה מבחינה סטטיסטית. אם מנגד

(לדוגמא) מדובר בשרת SQL,  שיש לו נפח גדול, ומסוגל לאכסן (למשל) את ה- DB כל כולו ב-  , או אז

למהירות הזכרון תהיה השפעה גדולה על ביצועי השרת, היות וכמעט כל פעולה מול ה- DB היא מטבע הדברים נעשית

מול ה- , לא מול הדיסק, (ולא מול ה cache שאינו מסוגל לאכסן אפילו גרגר מגודלו של ה DB כולו).

 

האם הצלחתי להשיב בצורה טובה ? 🙏

נערך על-ידי nec_000
קישור לתוכן
שתף באתרים אחרים

ציטוט של nec_000

תודה לי על כך

אני משער שאמור להיות "לך" :)

ציטוט של nec_000

אם מנגד מדובר

בשרת SQL,  שיש לו נפח RAM גדול, ומסוגל לאכסן למשל את ה- DB כל כולו ב-  RAM, או אז למהירות הזכרון תהיה

השפעה גדולה על ביצועי השרת, היות וכמעט כל פעולה מול ה- DB היא מטבע הדברים נעשית מול ה- RAM, לא  מול

הדיסק, (ולא מול ה cache שאינו מסוגל לאכסן אפילו גרגר מגודלו של ה DB כולו).

DB שלם שנכנס בRAM? לא נראה לי :)

 

בנוסף, הרבה פעמים עובדים על הDB דרך הרשת, כך שבכל מקרה צוואר הבקבוק הוא אינו הRAM ואפילו לא הדיסק.

קישור לתוכן
שתף באתרים אחרים

מצטער,  אין תלמיד גרוע, יש רק מורה גרוע .....

אף פעם לא התחברתי למגילות שלך, זה לא חדש.

 

גם מעולם לא היו בהן  חידושים, שלא לדבר על מהפכות.

כלומר, היו היפוכי גרסאות ושכתובים, אבל לא מהפכות .....

 

בהצלחה לכל מי שמוצא בזה ערך, כי אני לא.

קישור לתוכן
שתף באתרים אחרים

זה שכתבת שיש 16 ביטים בטיק של שעון כנראה מסביר מדוע הרכיב כל כך רגיש לרעש, לא ידעתי שהם משתמשים בתקשורת כלכך מחורבנת על מנת להעביר מידע, מהצד השני אני רחוק מלהיות מומחה לGPUS, יצא לי לגעת מעט מאוד בקוד שמיועד אליהם אבל מעולם לא יצא לי להתעמק. זו כנראה הסיבה שאוברקלוקרים בדורות האחרונים ממסכים את כרטיסי המסך מרעש עם מוליכים.

לגבי הטכניקה, זה קצת יהיר לכתוב שהשיטה חדשנית מבחינה טכנולוגית, המימוש שלה כן כי זה רכיב חדש אבל מטמון הוא בערך הטריק הישן בספר. בטח עוד כמה שנים יתחילו לממש עוד רמות שלו כמו ברכיבים אחרים...

יש שני דברים שמעניינים אותי כאן, ראשית, מה קורה במצבים שבהם כל המסך או חלקים גדולים ממנו משתנים מאוד מהר ואז המטמון לא עוזר, אולי יש מצב שהביצועים ירדו מאוד, אפילו ליותר משהייתי מצפה כי במצב הזה אתה סתם מבזבז את הזמן שלוקח לבאס להיכנס ולצאת מהcache. השאלה אם זה נכון כי אז FPS ממוצע כבר לא אמור לעניין כמו המינימלי כי יכולים להיות דרופים נוראיים בסצינות מסוימות במשחקים בעיקר ב4K. השאלה אם פרקי הזמן הללו רלוונטיים מבחינת מהירות התפיסה האנושית.

 

ושנית, מעניין איך העיניין ממומש חומרתית כי הרעיון בזכרונות מטמון הוא שבאסים הם סופר איטיים, אז אם הזכרון יושב על המעבד אתה חוסך את הזמן שלוקח לאות לעבור מהזכרון למעבד. אבל בGPU יש הרבה ליבות\הרבה שמעבדים את המידע במקביל מה שאומר שזכרון המטמון צריך להיות מחולק בין הליבות? מעניין אותי איך הם פתרו זאת מבחינת החומרה זה נשמע סיפור מהגיהנום.

נערך על-ידי Buck
קישור לתוכן
שתף באתרים אחרים

ציטוט של nec_000

האם הצלחתי להשיב בצורה טובה ? 🙏

ממש נפלא, נפתרו לי כמה תעלומות שסחבתי כמה שנים, ממש תודה!

מקווה שתצלח עליך רוח מעין זו ותכתוב לנו עוד מאמרים.

 

יש סדרת מאמרים באתרים כמו טק-ספוט של איך עובד RAM/CPU/GPU ושאר רכיבי המחשב, אלא שלא מצאתי בהם מידע מחכים, אלא רק מעין מפה גיאוגרפית כללית של הרכיב, עם שמות ויעודי תתי הרכיבים שהוא בנוי מהם, ללא ירידה לשום רזולוציה שמרחיבה הבנה אמיתית בנושא, בקיצור שעממת... 

 

עושה רושם שאיפשהו ב2004 היה כאן סוג שך הייפ בכתיבת מאמרים בנושאים שונים, ומאז הפוסטים נעוצים בראש כל פורום כמו מוצג היסטורי במוזאון, שחלקו רלוונטי וחלקו כבר לא.

מקווה שעוד יקבלו השראה ויתניעו את העסק שוב לחיים. 

קישור לתוכן
שתף באתרים אחרים

 

התיחסות ל- buck, דבריך בשחור המענה שלי בכחול:

 

זה שכתבת שיש 16 ביטים בטיק של שעון כנראה מסביר מדוע הרכיב כל כך רגיש לרעש, לא ידעתי שהם משתמשים

בתקשורת כלכך מחורבנת על מנת להעביר מידע, מהצד השני אני רחוק מלהיות מומחה לGPUS, יצא לי לגעת מעט

מאוד בקוד שמיועד אליהם אבל מעולם לא יצא לי להתעמק. זו כנראה הסיבה שאוברקלוקרים בדורות האחרונים ממסכים

את כרטיסי המסך מרעש עם מוליכים.

ב- GDDR6X זה לא 16 ביטים, אלא 4 ביטים שמייצרים 16 רמות סיגנל שונות. 2 בחזקת 4 שווה 16.

להשוואה, זה שני ביטים, שמייצרים איפה 4 רמות סיגנל שונות, ואפילו על זה בשעתו כל כך נלחצו שיגרום

לשגיאות, עד שהגדילו והטמיעו מנגנון ECC לתיקון השגיאות. שאחרי כמה שנים ומשעברו ל- , בטלו אותו.

פשוט הבינו שזה מספיק אמין גם בלי התיקון השגיאות,  בעיקר משום שבעבוד גראפי אפשר בקלות לספוג שגיאה פה

ושגיאה שם, הרי מדובר כולה בפיקסל פגום בתמונה של מליוני פקסלים. אף אחד לא ימות מזה וכנראה גם לא יראה את

זה בעין.
**התיקון שגיאות הוכנס ב- מתוך פאניקה של פעם, בגלל שחששו משגיאות בשעתו, פעלו מתוך דפוס

מחשבתי  אינהרנטי של מחשב/שרת.  אך פספסו את הפואנטה, שלגראפיקה זה לא משנה אם יהיו כמה שגיאות.

ב- נזכרו ותקנו (ביטלו את התיקון שגיאות).


לגבי הטכניקה, זה קצת יהיר לכתוב שהשיטה חדשנית מבחינה טכנולוגית, המימוש שלה כן כי זה רכיב חדש אבל זכרון מטמון הוא בערך הטריק הישן בספר. בטח עוד כמה שנים יתחילו לממש עוד רמות שלו כמו ברכיבים אחרים...

וזה מה שכתבתי, שזה אחד הדברים הכי עתיקים בהסטוריה, הכי פשוטים להבנה והטמעה, אלא, שזה גאוני שלראשונה

מישהו נזכר שאפשר בכלל להטמיע את זה בכרטיס מסך. מדוע כי כל משך עשרות השנים, הנושא לא בוצע - בשל

חוסר יכולת לבצע. לא היו מספיק טרנזיסטורים בליטוגרפיה על מנת לאפשר זאת. אז שכחו את זה איפה שהוא בבוידעם

והנושא העלה קורי עכביש. כולם בדיספילינה ידעו דיפולטית, ש- cache אינו מעשי במעבדים גראפיים וזה מה שהנחה

את המחשבה האינהרנטית שלנו. לכן אף אחד לא חשב על זה בכלל.

זה שאחרי 30-40 שנה פתאום כבר כן יש אפשרות לממש, יפה מאד שמישהו טרח להזכר ולומר:

 "היי חברים, נראה לי שהגעו לעת שבה יש מספיק real estate בשלב הזה, ליישם את מה שטמנו בבוידעם בשנת

1980. מישהו זוכר בכלל ? "


יש שני דברים שמעניינים אותי כאן, ראשית, מה קורה במצבים שבהם כל המסך או חלקים גדולים ממנו משתנים מאוד מהר ואז המטמון לא עוזר,

אולי יש מצב שהביצועים ירדו מאוד, אפילו ליותר משהייתי מצפה כי במצב הזה אתה סתם מבזבז את הזמן שלוקח לבאס להיכנס ולצאת מהcache. השאלה אם זה נכון כי אז FPS ממוצע כבר לא אמור לעניין כמו המינימלי כי יכולים להיות דרופים נוראיים בסצינות מסוימות במשחקים בעיקר ב4K. השאלה אם פרקי הזמן הללו רלוונטיים מבחינת מהירות התפיסה האנושית.

אין קשר בין שינויים בין פריים לפריים לזכרון מטמון. זה לא קשור. כל מחזור לציורה של תמונה בדידה, מקבל flash מלא

של כל הזכרון מטמון כולו.  והפלאש המלא נועד לאכסן את מה שהמעבד הגראפי צריך, לטובת השלמת ציורה של

התמונה העדכנית. לא משנה בעצם מה משתנה בה לעומת התמונה הקודמת. יתכן שהתבלבלת עם אלגוריתמים

לדחיסת תמונה מתחום הוידאו, שגרמו לך לחשוב בשגגה, שיש קשר בין פריים לקודמו בהיבט הזה - שמודדים רק את

הדלתאות בוידאו. אך הנושא הזה קשור לדחיסת תמונה בוידאו, ולא קשור לרנדור CGI. שתי חיות שונות.

 

ושנית, מעניין איך העיניין ממומש חומרתית כי הרעיון בזכרונות מטמון הוא שבאסים הם סופר איטיים, אז אם הזכרון יושב על המעבד אתה חוסך את הזמן שלוקח לאות לעבור מהזכרון למעבד. אבל בGPU יש הרבה ליבות\הרבה מעבדים שמעבדים את המידע במקביל מה שאומר שזכרון המטמון צריך להיות מחולק בין הליבות? מעניין אותי איך הם פתרו זאת מבחינת החומרה זה נשמע סיפור מהגיהנום.
משהו מאד יפה שניתן היה לראות מהצילום של ליבת השבב, הוא שהזכרון מטמון עוטף את הליבות עיבוד מבחוצה

כטבעת חנק. הנה אני שם שוב את הצילום כדי שנוכל להבין למה אני מתייחס. העיטוף הזה כנראה נועד על מנת

לאפשר hi bandwidth באמצעות קו השקה מאד ארוך, שמאפשר  בתורו הרבה מאד interconnects מסביב לכל ה-

real estate של השבב. להערכתי נועד לאפשר בדומה לאוטוסטרדה של מכוניות,  קישוריות גבוהה מהירה וזמינה לכל

צרכן שצריך כרגע מידע איפה שהוא בשבב. לקצר מרחקי גישה ותעבורת סיגנלים.

 

אחת הארכיטקטורות היותר מעניינות ואינטיליגנטיות שראיתי בקריירה:

 

923-block-diagram.jpg

נערך על-ידי nec_000
קישור לתוכן
שתף באתרים אחרים

הצטרפ/י לדיון

בשלב זה תוכל/י להצטרף לדיון, ולאחר מכן להצטרף לקהילה שלנו. אם כבר יש לך חשבון אצלנו, אנא התחבר/י עכשיו על מנת להגיב תחת שם המשתמש שלך.
לתשומת לבך: התגובה תופיע לגולשים לאחר אישור של צוות הנהלת הפורומים.

אורח
הוסף תגובה

×   התוכן שהודבק הוא עם עיצוב.   הסר עיצוב

  Only 75 emoji are allowed.

×   הקישור שלך הוטמע אוטומטית.   הצג כקישור רגיל

×   התוכן הקודם שלך שוחזר אוטומטית.   נקה הכל

×   You cannot paste images directly. Upload or insert images from URL.

 Share


×
  • צור חדש...