עבור לתוכן
  • צור חשבון
  • מי אנחנו?

    שלום אורח/ת!

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

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

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

djelectric

כח אדיר בתושבת של AMD: מעבדי Ryzen 7 3700X ו-Ryzen 9 3900X בביקורת

Recommended Posts

מעניין מתי ניראה את הריענון של כל ניידי הAM4, כעת עם 3700X הם יכולים להיתחרות בהצלחה בניידי 9900K אפילו תוך פליטת חום נמוכה יותר וחיי משמעותיים יותר חח.

 

שתף דיון


קישור ישיר להודעה
שתף באתרים אחרים
ציטוט של About:blank

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

 

לעניין נפח ה- cache ישנה משמעות כזו:

שהוא מקטין את כמות ה- miss ובעטיה את הצורך לרדת עד לרמת הזכרון הכללי של המחשב. בואו נלמד איך זה פועל:

 

כאשר מטמיעים cache Level 3 כפול נפח (כמו שהוטמע אכן בריזן דור 3000) לעומת מה שהיה מקובל עד הלום

בריזנים הקודמים, העלו את נפח הזכרון מטמון Level 3 מ- 16MB ל- 32MB פר cluster (לכל יחידת 8 ליבות),

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

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

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

איטית בסדר גודל לעומת הגישה ל- cache Level 3. למעשה מדובר פה במהירות גישה שהיא פי 20 יותר איטית, כ-

1000GB/sec לעומת רק 50GB/sec (ראו תמונה מטה).

 

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

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

למשל לאלגוריתמים הקשורים לתחום דחיסה, פריסה, הצפנה....

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

בבנצ'ים כך שאין פה הפתעה.

 

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

כמו למשל גישה לקריאה מ- data base של SQL, שם לגודל מרכיב ה- cache ישנה חשיבות מופחתת, שהרי ממילא ברוב

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

(שאילתות), או בכתיבה של תא כל פעם למקום אחר ב- DB (פעולת insert).

 

כלומר צריכים להבין איך עובד cache hierarchy מבחינה מתודולגית-אלגוריתמית, פה טמונה המהות,

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

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

 

כך או אחרת הכפלת נפח ה- cache level 3 שהכניס לראשונה מעבד ריזן 3000, לנפח חדש תקדימי בתעשיית המעבדים

32MB per cluster (היה 16MB עד הלום), תהיה תרומה לא מעטה לביצועי המכונה, וזו אחת הסיבות שמסבירות לנו את

הקפיצה המרשימה בכ- 15% IPC לעומת הדור הקודם. קרי להכפלת נפח ה- cache לבדה כבר ישנה תרומה ישירה לנושא,

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

 

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

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

 

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

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

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

 

RYZEN 3000" data-ratio="96.08" height="518" srcset="https://i1.wp.com/www.xanxogaming.com/wp-content/uploads/2019/07/Ryzen-9-3900X-AIDA64-Benchmark.png?zoom=1.100000023841858&resize=539%2C518&ssl=1" style="height:auto;" width="539" data-src="https://i1.wp.com/www.xanxogaming.com/wp-content/uploads/2019/07/Ryzen-9-3900X-AIDA64-Benchmark.png?resize=539%2C518&ssl=1" src="https://hwzone.co.il/community/applications/core/interface/js/spacer.png" />

נערך על-ידי nec_000

שתף דיון


קישור ישיר להודעה
שתף באתרים אחרים

אי אפשר להשוות ישירות בין זיכרון המטמון של ארכיטקטורת ו-ZEN/ZEN2.

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

אם לא היה לנפח מחיר בדמות עכבה, מדוע לא לתקוע מטמון L1 גדול ייעודי לכל ליבה ולגמור עניין (ובאכיטקטורת ZEN2 המטמון L1-I, זה שאוגר את ערכות הפקודות, דווקא קטן)?

 

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

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

עד כמה שאני יכול להסיק, הגדלת מטמון L3 והשינוי הקטן בזיכרון מטמון L2 (שיפור ה-Associativity) נועדו בעיקר כאופטימיזציה לביצועי משחקים (אבל גם תוכנות אחרות עשויות להרוויח) ולכן המיצוג (הטיפשי לדעתי) של Gamecache.

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

 

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

הנחת העבודה היא שעם עדכון ה-Scheduler (בעדכון הגדול האחרון של אמור היה להיות שיפור נוסף) למצות CCX אחד עד הסוף לפני גישה לאחד אחר וערכת הפקודות WBNOINVD שמטרתה לחזות מדי יהיה צורך לטעון מידע לזיכרון מטמון L1 ולפנות את הנפח הזה מבעוד מועד על ידי העברתו לזיכרון מטמון L3 (דומה לפונקציית הדפדוף בכתיבת תוכן זיכרון לדיסק ושליפתו משם לפי הצורך) לנפח זיכרון מטמון L3 גדול יותר תרומה משמעותית יותר מהמחיר בעכבה.

הביצועים בפועל תואמים להנחת העבודה הזאת.

 

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

 

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

נערך על-ידי About:blank

שתף דיון


קישור ישיר להודעה
שתף באתרים אחרים

 

כבר לא,

 

העכבה = latency של ריזן 3000 טובה יותר מזו של (קרי נמוכה יותר) וגם הרוחב פס רחב יותר (ולא במעט).

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

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

כמו גם היכולת לחבר ממשק רחב יותר לוגי (יותר סיביות) כי יש יותר מקום כשהמוליכים קטנים יותר ומצופפים יותר.

 

נוכל לשים לב שלא רק שה- cache level 3 בריזן 3000 מהיר ב- latency בכ- 10% (9.4ns לעומת 10.5)

אלא שהרוחב פס הוא דרמטית גדול יותר - 1044GB לשניה לעומת רק 397GB באינטל.

 

ההבדל ברוחב פס נובע בעיקר משום גישה רחבה יותר סיבייתית:

בריזן 3000 הוא ברוחב פס 2048 סיביות, בעוד שבאינטל הוא רק 512 סיביות (level cache 3)

 

למעשה לריזן 3 ברובד cache level 3 - גם פי 2 נפח , גם 10% עכבה נמוכה יותר, וגם רוחב פס גדול פי 4

(בסיביות), שמתורגם לבערך פי 2.5 עד פי 3 בביצועים (של הבנץ הספציפי של Aida64 - נובע מהפרש תדר

עבודה של המעבד).

 

להלן להתרשמותנו השוואת 9900k בצד שמאל מול ריזן 3000 בצד ימין:

image.thumb.png.ba6daa948d3625f7bd5c9ec5413b03c7.png

 

אם לשיטתנו נבחן מה קורה ב- level 2 cache אז נוכל להתרשם כי:

בריזן 3000 ישנו נפח (שוב) כפול מזה שבאינטל, 512MB לכל כשבאינטל 256MB,

זמן התגובה (עכבה) די דומה 2.6 לעומת 2.4 ,

אבל רוחב פס של 2048 סיביות לעומת רק 1024 באינטל, שמוביל לכמעט פי 2 בביצועים בבנץ של Aida

(בגלל הפרשי תדר מעבד אגב) לכדי 1624GB לעומת 945GB.

 

ואם נרד לרמה של cache level 1 נוכל להתרשם:

בריזן 3000 ישנו נפח כמו זה שבאינטל, 64MB לכל ,

זמן תגובה 0.9ns לעומת 0.8ns ,

אבל רוחב פס של 4096 סיביות לעומת רק 2048 באינטל, שמוביל לבערך 1.5 בביצועים בבנץ של Aida

(בגלל הפרשי תדר מעבד - ומגבלת הספק העיבוד ברובד זה) לכדי 3,292GB לעומת 2,471GB .

**הביצועים של ה- cache ברובד L1 חסומים מלעיל "בקצב הבליעה" של ליבת המעבד - למרות שתאורטית הם גבוהים

הרבה יותר, ואילו היה מעבד "שיכול לאכול" יותר פר clock אז הוא היה אוכל יותר מהרמה הזו של .

 

לשאלה התאורטית שהעלת מדוע לא לתקוע יותר level 1 cache במקום לחלקו לרמות L2 ו- L3 - שזו שאלה טובה

כי היא מאפשרת להסביר את הסגמנטציה ותודה לי על ההזדמנות (שאלה חכמה):

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

(בשביל רוחב פס), אל ליבת המעבד. הבעיה היא שאי אפשר להשיג את שלושת הפרמטרים בו זמנית:

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

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

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

 

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

או אם נרצה אפיק התקשורת הבין ליבתי.

 

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

L1, L2, L3 ואחריו ה- שנחשב כ- L4.

L1 ו- L2 יעודיים לליבה, בשעה ש- L3 ו- L4 משותפות לכל המעבד ומאפשרות בין מערכתית בין רכיביו השונים

של המעבד.

נערך על-ידי nec_000

שתף דיון


קישור ישיר להודעה
שתף באתרים אחרים

בדיקות אחרות מראות תוצאות הפוכות. על פי הבדיקה הזאת ZEN2 עם עכבה נמוכה יותר משמעותית ברמה L3 גם לנומת ZEN/ZEN+. משהו פה לא מסתדר.

 

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

 

נערך על-ידי About:blank

שתף דיון


קישור ישיר להודעה
שתף באתרים אחרים

תקרא עשיתי עוד עריכה לפוסט.

כמו כן קשה לי להעלות הכל על כתב - זה לוקח זמן שאין לי תמיד.

אשתדל להשלים את המענה תוך כדי...אז יהיו עוד עדכונים בנושא ממני.

מנסה להתייחס לכל נושא שהעלאת - השאר בהאזנה.

שתף דיון


קישור ישיר להודעה
שתף באתרים אחרים

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

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

 

נ.ב. יכול להיות שהבדיקה של AIDA מודדת רק ביצועי בודדת?

שתף דיון


קישור ישיר להודעה
שתף באתרים אחרים

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

 

עכשיו לנושא השני שכתבת,

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

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

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

 

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

מקצועיות, או תחנות עיבוד workstations שעוסקים באותם יישומים מתמטיים.

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

 

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

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

זכרון מטמון גדול. ראינו מה קורה בכווץ /פריסה שהודגמו בסקירה האחרונה של ריזן 3000 לעומת .

הקפיצה שהדבר הביא לריזן לעומת קודמו ריזן 2000 היא דרמטית לא פחות.

 

עכשיו,

אחד הרעיונות שהיו לי ואני משתף כאן את הפורום, הוא להטמיע עמודת HBM בצמוד ל- PCB של ה- CPU,

בכדי לתת לו עוד שכבת cache level 4. בעמודת אחת (אם נשאיל מעולם ההאצה הגראפי GPU) בת 1024 סיביות,

אפשר לספק רוחב פס עד כדי 256GB/sec (בקצבי תדר של היום), שזה המון, אבל עם נפחים אדירים של 1-4GB בקלות.

נשים לב שקצב זכרון שכזה מהיר מ- רגיל פי 5-10 סדר גודל (תלוי מול איזה מעבד מודדים).

אפשר גם להטמיע 2 עמודות לכדי 512GB/sec אם רוצים עוד מהירות (נפח נוסף כבר לא צריך - אנחנו באזור של ג'יגות בשלב הזה).
 

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

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

בין 50-100$ בלבד (סדר גודל עקרוני) לעמודה אחד. כפול מזה לשני עמודים.

 

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

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

 

אני רואה לנגד עייני מעבדי ענק 32-64 ליבות לסגמנט שרתים xeon/epyc שמחזיקים 4 מגדלים שכאלו, רוחב פס 1024GB/sec,

ונפח כולל של 32GB. אלו של 1000-5000$ הרי ממילא כבר, עבורם התוספת מחיר הנדרשת להטמעת HBM בטלה בשישים.

ה- performance יהיה מטורף ולא משהו שראינו במחוזותינו.

 

היתרון של cache level 4 ענק שכזה ילך ויגדל ככל שהמעבד יחזיק יותר ליבות - קרי יוכל לאכול יותר אוכל פר קלוק. 

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

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

 

 

נערך על-ידי nec_000

שתף דיון


קישור ישיר להודעה
שתף באתרים אחרים
ציטוט של Jabberwock

דווקא העכבה לזיכרון DRAM גדלה.

חשבתי שוינדוס פועל בשיטת Round-robin scheduling עם אינטרפטים של המעבד מדי פעם לאמוד זמן

 

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

מה שמעלה את מסלול האות (משמעותית) צריך לצאת מה- die להגיע ל- IO chip, והוא זה שבתורו פונה לזכרון.

הדבר מעלה latency ולא במעט.

 

העניין הוא שה- latency ל- פחות רלוונטי ברגע ש- inter chip communications כבר לא עובר דרכו עוד,

אלא דרך - IO chip עצמו (מבלי לצאת החוצה משם).

 

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

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

שתף דיון


קישור ישיר להודעה
שתף באתרים אחרים
ציטוט של About:blank

Windows מאוד אוהבת להקפיץ תהליכונים גם בלי סיבה

 

אגב הנושא הזה שכתבת מאד מעניין, אבל יש לו סיבה - הוא לא נעשה סתם:

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

שאיפה להביא למצב שכל הליבות יהיו מועמסות באופן זהה ושווה זה לזה (עד כמה שניתן כמובן).

 

קרי שלא יהיה מצב בו אחת נחנקת למשל ב- 100% עומס (כי למשל היא תקוע עם פרוססים כבדים שהתישבו

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

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

 

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

על פני כלל הליבות. להגיע ל- 25% נגיד בכל אחת מ- 4 הליבות למשל, ולא הכל בליבה אחת.

תראו task manager איך המערכת מנסה להגיע למצב שכל הליבות יועמסו בהומוגניות ולא רק אחת מהן

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

 

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

סיבה משנית אבל גם היא טובה.

 

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

של המעבד ישנה משמעות, כמו שזה למשל קורה בריזן - בגלל החלוקה המוכרת למודולים נפרדים (CCX-ים),

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

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

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

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

ביצועי של המעבד הזה בעת היותר אחרונה. המעבד מה שנקרא aged well בגלל שהתחילו להתייחס אליו

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

 

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

נערך על-ידי nec_000

שתף דיון


קישור ישיר להודעה
שתף באתרים אחרים
ציטוט של TheHwGeek

מעניין מתי ניראה את הריענון של כל ניידי הAM4, כעת עם 3700X הם יכולים להיתחרות בהצלחה בניידי 9900K אפילו תוך פליטת חום נמוכה יותר וחיי סוללה משמעותיים יותר חח.

 

 

סביר להניח בתוך רבעון גג 2.

דווקא בלפטופים יתרון ה- 7nm של משחק לטובתם באופן משמעותי יותר מאשר ב desktop.

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

מדובר במשך זמן עבודה עד צורך בטעינה חוזרת.

שתף דיון


קישור ישיר להודעה
שתף באתרים אחרים

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

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

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

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

  Only 75 emoji are allowed.

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

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

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


×
  • צור חדש...
Back to top button
Close
Close