פשוט מדהים מה שקורה ל- ryzen עם זכרון סופר מהיר

- Share

ציטוט של nec_000

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

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

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

בוקר טוב

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

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

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

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

קישור לתוכן

שתף באתרים אחרים

askme

- Share

לא נראה לי.

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

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

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

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

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

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

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

קישור לתוכן

שתף באתרים אחרים

smalul

- Share

ציטוט של 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) ועוד יחידת עיבוד גרפית.

קישור לתוכן

שתף באתרים אחרים

StavBN

- Share

ציטוט של coch

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

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

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

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

קישור לתוכן

שתף באתרים אחרים

nec_000

מחבר

- Share

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

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

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

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

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

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

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

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

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

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

נדפקים ממנו.

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

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

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

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

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

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

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

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

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

קישור לתוכן

שתף באתרים אחרים

djelectric

- Share

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

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

קישור לתוכן

שתף באתרים אחרים

captaincaveman

- Share

ציטוט של nec_000

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

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

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

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

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

קישור לתוכן

שתף באתרים אחרים

Jabberwock

- Share

ציטוט של smalul

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

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

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

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

ציטוט של nec_000

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

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

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

קישור לתוכן

שתף באתרים אחרים

nec_000

מחבר

- Share

ציטוט של captaincaveman

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

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

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

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

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

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

קישור לתוכן

שתף באתרים אחרים

coch

- Share

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

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

קישור לתוכן

שתף באתרים אחרים

smalul

- Share

ציטוט של Jabberwock

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

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

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

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

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

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

ציטוט של nec_000

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

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

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

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

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

קישור לתוכן

שתף באתרים אחרים

captaincaveman

- Share

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

קישור לתוכן

שתף באתרים אחרים

nec_000

מחבר

- Share

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קישור לתוכן

שתף באתרים אחרים

smalul

- Share