ציטוט של nec_000

 

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

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

ערוץ עלום שם ללא מוניטין, ללא אישיות, ללא פרטים טכניים רבים, שמפיק 2-3 סרטוני השוואה משונים ביום, על חומרה סופר חדשה שלא תמיד זמינה לצרכנים, עם מהירות זיכרון שלא קיימת לרייזן 2 בשום רמה, ובהפרש ענק עם הזיכרונות מהירים ביותר שיש לרייזן (3466).

 

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

ציטוט של nec_000

אזי עד שנמצא כזה בואו נתמקד במהות הטכנית:

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

ועד כמה הוא נהנה מזכרון שהומהר עד ל- 3000 פלוס Mhz לעומת תדר הבסיס 2133.

 

 

 

בוקר טוב

 

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

עם הרייזנים שבדקו אותם עם 2133\2400 לעומת 3200 וצפונה מעט. 

 

השאלה שלי בנושא היא כזו - האם AMD יכולים מבחינה טכנית לשפר את הביצועים בדור הבא בזכרונות בתדר ממוצע ולא להיות

מאוד תלויים בתדר עבודה גבוה כזה של זיכרון ? או שזה משהו שילווה את הדורות האלה קדימה ? 

לא נראה לי.

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

עיבוד והממשקים ביניהם.

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

אבל סובל מדברים אחרים ( כמו התלות הגדולה במהירות הזיכרון )

יחסית לאינטל.

היות ו"הגיבנת" נמצאת כבר בשני דורות של הרייזנים לפחות, לא

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

 

ציטוט של NiMo1771

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

בעיקרון כל מעבדי ה Ryzen הם זהים, כלומר בנויים מ-2 יחידות CCX כשבכל יחידת CCX יש 4 ליבות עיבוד. אם כל הליבות תקינות המעבד משווק כמעבד Ryzen 7 בעל 8 ליבות עיבוד. אם יש בעיה באחת או יותר מליבות העיבוד, חלק מהליבות מנוטרלות וכך מקבלים מעבדי Ryzen 5 ו Ryzen 3. לפי הפרסום הזה מלפני כשנה, ב AMD הודו שהם מכבים ליבות במעבדים אך ורק בצורה סימטרית. כלומר במעבד בעל 6 ליבות מכבים ליבה אחת בדיוק בכל CCX (זאת אומרת שבכל CCX יש בדיוק 3 ליבות פעילות) ובמעבד בעל 4 ליבות עיבוד מכבים 2 ליבות עיבוד בכל CCX. (בכל CCX יש בדיוק 2 ליבות פעילות). אני מניח שהדבר נעשה בכדי להבטיח שכל המעבדים מאותו הדגם ייתנו בדיוק את אותם הביצועים. לפיכך המצב שתיארת לא ייתכן.

 

ציטוט של nec_000

רק ריזן מסדרת G מכיל יחידה אחת של CCX ובו ארבעת הליבות. יתר מעבדי ריזן מורכבים תמיד משתי יחידות CCX.

אכן כך - במעבד Ryzen עם סיומת G יש יחידת CCX אחת בעלת 4 ליבות עיבוד (כמו בכל יחידת CCX) ועוד יחידת עיבוד גרפית.

ציטוט של coch

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

מאוד תלויים בתדר עבודה גבוה כזה של זיכרון ? או שזה משהו שילווה את הדורות האלה קדימה ?

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

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

הבעיה של AMD זה שבאריטקטורה הנוכחית הם לא יודעים לחבר יותר מארבע ליבות ל- cache מרכזי אחד שהוא level 3.

זו הסיבה שהם נאלצו לחלק את הליבות (8 במספר) לשתי יחידות CCX נפרדות, ולכל יחידת CCX לתת level 3 cache משלה.

 

קרי ליבות 1-4 מדברות בינן לבין עצמן מהר, וליבות 5-8 אותו הדבר.

רק ליבות שנמצאות ב- CCX נפרדים ה- latency בינהן גבוה.

 

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

הפרוססים חכם: 

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

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

 

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

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

נדפקים ממנו.

 

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

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

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

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

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

על איזה מספר ליבה במעבד ריזן. זה ממש פשוט לביצוע.

 

הבעיה ש- AMD אינה חברת היי-טק ישראלית עם חוצפה ויוזמה, למצוא בשטח פתרון קונץ פטנט בזמן מהיר.

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

ואני ממש לא צוחק אלא רציני מאד.

 

 

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

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

ציטוט של nec_000

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

הפרוססים חכם: 

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

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

 

 

קצת פשטני. ואם יש לי משהו שצריך יותר מ-4 פרוססים?

ציטוט של smalul

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

עדיין, יש בעיה. נניח מדברים על מעבד 2600X, זאת אומרת שאם יש לנו 12 ת'רדים. מ-0 עד 5, המטמון מנהל את ההעברה של המידע בין הת'רדים. ומ-6 עד 11 אותו דבר.

אבל איך הוינדוס מחלק את העבודה? בכך שהוא רואה איזה ליבה פנויה ומשנה את הת'רד בהתאם לעומס העבודה. אז יכול לקרות מצב שהשינוי בת'רד יהיה פעם עם שהות גבוהה ופעם עם שהות נמוכה. למה? כי הוא יכול להעביר את החלוקה לליבה שלא מאותו ה-CCX. לא כך?

אני הייתי פותר את זה עם פאטץ' לוינדוס. שת'רדים לא יקפצו בין CCX למשנהו.

 

ציטוט של nec_000

קרי ליבות 1-4 מדברות בינן לבין עצמן מהר, וליבות 5-8 אותו הדבר.

רק ליבות שנמצאות ב- CCX נפרדים ה- latency בינהן גבוה.

 

נשמע הגיוני למעבד 2700X.

ציטוט של captaincaveman

 

 

קצת פשטני. ואם יש לי משהו שצריך יותר מ-4 פרוססים?

 

לא בהכרח יותר מ- 4 תלויים זה בזה.

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

זה תלוי אלגוריתמיקה כמובן ואין דין מקרה אחד מכליל על כולם.

 

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

2 פרוססים תלוים זה בזה וכל שצריך זה לדאוג שהם ישבו על אותו מודול CCX בכדי לזרז את מהירות עבודתם.

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

 

2019-2020 אמורות להיות שנים מעניינות. גיימינג, חומרה וכדומה.

ציטוט של Jabberwock

אבל איך הוינדוס מחלק את העבודה? בכך שהוא רואה איזה ליבה פנויה ומשנה את הת'רד בהתאם לעומס העבודה. אז יכול לקרות מצב שהשינוי בת'רד יהיה פעם עם שהות גבוהה ופעם עם שהות נמוכה. למה? כי הוא יכול להעביר את החלוקה לליבה שלא מאותו ה-CCX. לא כך?

אני הייתי פותר את זה עם פאטץ' לוינדוס. שת'רדים לא יקפצו בין CCX למשנהו.

השאלה היא האם זה באמת כזה פשוט - האם patch או מנהל התקן (דרייבר) ייעודי למעבדים של AMD באמת מסוגל לעשות את זה?

 

לדעתי, ואני לא מומחה בתחום של תכנות מקבילי, יש פה 2 חלקים עיקריים:

א. החלק הראשון ב"משוואה" הזו הוא בכלל לזהות את הליבות השייכות לכל CCX.  אני לא יודע אם ניתן לעשות את זה ברמת מערכת ההפעלה . האם הקצאת המספרים לכל ליבה נעשית ברמת מערכת ההפעלה בכלל או ברמת החומרה (כלומר המעבד מדווח שיש לו ליבה 0, ליבה 1 וכו')? האם ההקצאה המספרית הזו תמיד זהה בכל איתחול או שהיא נעשית בצורה אקראית (כלומר האם ליבות 0 ו-1 תמיד שייכות לאותו CCX או שיכול להיווצר מצב שבו ליבות אלו שייכות לשני CCX נפרדים)? סביר להניח, אבל אני לא יודע את זה בוודאות, שקיימת דרך לדעת לאיזה CCX כל ליבה שייכת, אז זה החלק הקל.

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

 

ציטוט של nec_000

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

זה תלוי אלגוריתמיקה כמובן ואין דין מקרה אחד מכליל על כולם.

 

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

2 פרוססים תלוים זה בזה וכל שצריך זה לדאוג שהם ישבו על אותו מודול CCX בכדי לזרז את מהירות עבודתם.

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

אני מניח שאתה מתכוון לתהליכים (processes) ולא לנימים (threads). כמעט כל תוכנה היום מעלה המוני נימים לאוויר בזמן הפעולה שלה.

נים = thread הוא תת-פרוסס.

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

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

אלו חייבים ממש לשבת באותו CCX - זה מתבקש, כי המידע שהם עובדים עליו (ביחד) הוא אותו מידע.

 

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

וישויכו כקבוצה אל ארבעת הליבות שיושבות ביחד באותה יחידת מודול CCX.

 

הדבר אינו תורה מסיני ולא מורכב לישום. דרושים לשם כך שני מרכיבים:

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

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

 

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

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

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

 

האמור יניב שפור משמעותי בלא מעט אפליקציות.

זה מה שה- latency גוזל כשתהליך ביחידה CCX אחת - נאלץ להמתין עד לתקשורת מול תהליך שיושב ב- CCX השני:

הם עוברים דרך ה bus של ה- ram , שהוא איטי בסדר גודל מה- bus של cache level 3.

 

 

ציטוט של captaincaveman

אני מניח שאתה מתכוון לתהליכים (processes) ולא לנימים (threads). כמעט כל תוכנה היום מעלה המוני נימים לאוויר בזמן הפעולה שלה.

לא. אכן התכוונתי לנימים ולא לתהליכים.

 

ציטוט של nec_000

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

אלו חייבים ממש לשבת באותו CCX - זה מתבקש, כי המידע שהם עובדים עליו (ביחד) הוא אותו מידע.

לזה בדיוק התכוונתי.

 

באופן כללי:

נימים (threads) שנוצרים מאותו תהליך יכולים לחלוק ביניהם מידע, כפי ש @nec_000 הסביר. מכאן ברור מדוע עדיף שכולם יחלקו את אותו ה CCX.

תהליכים (processes), לעומת זאת, הם שונים - כל אחד מהם רץ בשטח זיכרון משלו והם לא אמורים להיות מסוגלים לגשת לשטחי זיכרון של תהליכים אחרים. נכון, יכול להיות ששני תהליכים או יותר יחלקו את אותו הקוד (סביר להניח שעם פרמטרים שונים), אבל מדובר בשתי יישויות נפרדות לחלוטין (תאר לך מה יקרה אם תהליך אחד יוכל לקרוא זיכרון של תהליך אחר או חלילה - לשנות בו ערכים*). תקשורת בין תהליכים היא אפשרית כמובן והיא נעשית ע"י שימוש במשאבים משותפים כמו שטחי זיכרון משותפים, מנגנון הודעות, סמפורים וגישה לקבצים בהתקן האחסון (עם מנגנון נעילה מתאים כמובן). העניין הוא שכל הפניות בסופו של דבר, למיטב הבנתי, הן לכתובות בזיכרון. למשתמש וגם למערכת ההפעלה אין גישה ישירה לזיכרון המטמון (L2, L1 ו L3) - הדבר מנוהל, שוב - למיטב הבנתי, ע"י חומרת המעבד בלבד, שכן לא נרצה שתהיה אפשרות לקרוא את המידע שבזיכרון המטמון (או לשנותו)* מפני שיכול להיות שהמידע שם שייך לתהליכים אחרים. לכן ה"הימור" הכי טוב ליצירת גישה לזיכרון משותף מסוג כלשהו הוא לדאוג שכל התהליכים שניגשים לאותם משאבים משותפים יהיו באותו CCX, שכן הדבר יגדיל את הסיכוי שהמשאב המשותף (למעשה עותק שלו) יהיה בזיכרון המטמון ואז לא יהיה צורך לגשת לזיכרון הפיזי (ה RAM) בכדי להביא את הערך הנדרש.

 

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

 

אני מקווה שהבהרתי את הנקודה שלי.