הדיון הראשי וריכוז מידע בנושא מעבדי FX (מעבדי Bulldozer) של AMD - עמוד 8 - מעבדים, לוחות-אם וזכרונות - HWzone פורומים
עבור לתוכן
  • צור חשבון

הדיון הראשי וריכוז מידע בנושא מעבדי FX (מעבדי Bulldozer) של AMD


NI4NI

Recommended Posts

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

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

לבור ועם הספר, נכון מה שציינת.

אם כי לי מפריע הבלבול הטרמינולוגי בו הצליחה להדביק את הצרכן/החובב בתחום:

בבולדוזר מבחינה הגדרתית אין 8 "ליבות", יש 4 ליבות.

מה שAMD קוראת לו "מודול" הוא למעשה "ליבה".

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

עד רמת ה cache level 2 (כולל) חייבת להיות עצמאות מוחלטת למעבד/ליבה.

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

אותן היא מעריכה/חישבה כפונקציות בעלות השימוש התדיר/התכוף ביותר (למשל 2 יחידות חישוב integer).

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

מבחינה הגדרתית בבולדוזר יש 8 ליבות, לא 4. אלו ליבות אמיתיות לחלוטין.

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

זה ששני הליבות חולקות את ה-L2 cache ו-FPU לא הופך אותם לליבה אחת. לשניהם עדיין יש מתזמן משלהם, ושני יחידות חישוב.

amd_bulldozer_scheme.jpg

שני נימים בכל מודול אחד מפיקים 180% לעומת נים בודד. זה אומר ששניהם מקבלים פגיעה של 10% כל אחד משיתוף משאבים.

אולי אין עצמאות "מוחלטת", אבל עדיין יש לך תוספת של 80% (תאורטית) לעומת בודדת.

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

^ בכל מקרה, לא בכל הקשור לחישובי נקודה צפה. שבהם, 8 חד משמעית זה לא 8, אלא 4.

בכל מקרה, לאחר שקראתי סקירות שונות, הגעתי ל 3 מסקנות: (בתמצות)

1. מדובר בשיפור יחסית לדור הקודם של ברוב הישומים. ובחלקם היותר קטן, מדובר אפילו בצעד אחורה. (ל 1100T יש יתרון של 2 ליבות FP לעומת הבולדוזר. ואפילו ב integer עדיף עליו בחלק מהמקרים)

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

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

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

^ בכל מקרה, לא בכל הקשור לחישובי נקודה צפה. שבהם, 8 חד משמעית זה לא 8, אלא 4.

בכל מקרה, לאחר שקראתי סקירות שונות, הגעתי ל 3 מסקנות: (בתמצות)

1. מדובר בשיפור יחסית לדור הקודם של ברוב הישומים. ובחלקם היותר קטן, מדובר אפילו בצעד אחורה. (ל 1100T יש יתרון של 2 ליבות FP לעומת הבולדוזר. ואפילו ב integer עדיף עליו בחלק מהמקרים)

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

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

לא בדיוק.

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

שניהם יכולים לחשב בו זמנית שני סט הוראות של 128bit כל אחד (בניגוד ל-SB שלא יכול לחשב שני סט הוראות של 128bit בו זמנית), או סט הוראות של 256bit יחדיו.

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

על הנייר.

בבדיקות הוכח שאין לא יתרון על פני ה 1100T בכל הנוגע לנקודה צפה. (וזאת למרות 25% יותר יכולת חישוב לפי דבריך, ובנוסף, 9% יתרון בתדר)

ציטוט מ anandtech:

Despite a 9% higher base clock speed (more if you include turbo core), a 3.6GHz 8-core is only able to outperform a 3.3GHz 6-core Phenom II by less than 2%. Heavily threaded floating point workloads may not see huge gains on compared to their 6- predecessors.
קישור לתוכן
שתף באתרים אחרים

מבחינה הגדרתית בבולדוזר יש 8 ליבות, לא 4. אלו ליבות אמיתיות לחלוטין.

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

זה ששני הליבות חולקות את ה-L2 cache ו-FPU לא הופך אותם לליבה אחת. לשניהם עדיין יש מתזמן משלהם, ושני יחידות חישוב.

שני נימים בכל מודול אחד מפיקים 180% לעומת נים בודד. זה אומר ששניהם מקבלים פגיעה של 10% כל אחד משיתוף משאבים.

אולי אין עצמאות "מוחלטת", אבל עדיין יש לך תוספת של 80% (תאורטית) לעומת ליבה בודדת.

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

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

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

לענייננו:

ליבה בהגדרתה היא מעבד עצמאי. את ההגדרות לא קובעת, אלא הרגולציה קובעת. במקרה דנן הרגולציה זו האקדמיה.

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

1. איננה תלויה באף אחת מהיחידות האחרות. קרי: מסוגלת להריץ פרוסס עצמאית לחלוטין.

2. איננה משתפת אף רכיב עד לרמת ה- L2 cache (כולל).

מודול במעבד הבולדוזר מכיל לא רק L2 משותף, אלא גם L1 משותף, יחידות רבות נוספות כמו fetcher, כמו FP unit, ועוד...

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

כל אחת מהן עד כדי מחצית.

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

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

אם לסכם, שכפול יחידות עיבוד Integer בתוספת 16kb זכרון עיבוד, עדיין לא הופך את הרכיב לליבה נוספת עם הכבוד לכך.

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

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

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

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

מה ש הטמיעו בבולדוזר, דומה "ברעיונו הבסיסי" ל- hyper threading של , רק שאלו ממשו את זה באופן שונה.

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

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

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

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

*אם מצליחים לספק יותר הספק (יותר כח חישובי), למה שזה יהיה איכפת למשתמש אם הוא מושג ע"י אחת, או על ידי מיליון ליבות ?

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

למעשה "ריבוי הליבות" איננה מטרה בפני עצמה, אלא פתרון טכני שנובע מאילוץ והכל במטרה להמשיך ולהכפיל את יכולות החישוב מדי 24 חודש,

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

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

מאשר מספר רב של ליבות - כאשר ההספק המצרפי שלהם זהה.

ומהיא הסיבה לכך: "שהניצולת" של יחידת העיבוד הבודדת עולה על הניצולת של מספר יחידות העיבוד - שצירוף הספקם שווה ערך לה,

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

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

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

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

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

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

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

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

על הנייר.

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

nec_000;

אין מעבד עצמאי.

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

לכל יש נים משלה, וזכרון L1 משלה.

ה-fetch יכול לשלוף ארבעה סט של הוראות לכל נים בצורה מקבילית, בדומה ל-SB (פנום II לצורך ההשוואה יכול לשלוף רק עד 3). ככה שה-fetch לא ממש מהווה בעייה, ושטח הקידוד הוכפל אאל"ט.

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

hyper threading ו-CMT אולי נשמע דומה, אבל הם לא, ובטח שלא מניבים את אותם תוצאות.

תאורטית (וידוע לי שהמצב במציאות שונה לגמריי), בעזרת CMT, הליבה השנייה תפיק 80% ביצועים (ב12% תוספת שטח, לעומת 5% של אינטל), ובגלל ש-hyperthreading חולק את כל המשאבים בין שני הנימים, ולא רק את ה-FP, התפוקה בעזרת HT תהיה עד 20% לכל נים נוסף.

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

nec_000;

אין מעבד עצמאי.

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

לכל ליבה יש נים משלה, וזכרון L1 משלה.

ה-fetch יכול לשלוף ארבעה סט של הוראות לכל נים בצורה מקבילית, בדומה ל-SB (פנום II לצורך ההשוואה יכול לשלוף רק עד 3). ככה שה-fetch לא ממש מהווה בעייה, ושטח הקידוד הוכפל אאל"ט.

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

hyper threading ו-CMT אולי נשמע דומה, אבל הם לא, ובטח שלא מניבים את אותם תוצאות.

תאורטית (וידוע לי שהמצב במציאות שונה לגמריי), בעזרת CMT, הליבה השנייה תפיק 80% ביצועים (ב12% תוספת שטח, לעומת 5% של אינטל), ובגלל ש-hyperthreading חולק את כל המשאבים בין שני הנימים, ולא רק את ה-FP, התפוקה בעזרת HT תהיה עד 20% לכל נים נוסף.

אענה לכל אחת מטענותיך על פי סדר הופעתן:

1. יש "לי" טעות ?! הנני עובד לפי הגדרות המקצוע בתחום. אם יש טעות היא וודאי שלא אצלי שכן לא "אני" הגדרתי את הנושא.

2. אם כלשונך היכולת בבולדוזר הינה לשלוף (בכל מחזור) כמות זהה של הוראות/דטה כמו זו של

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

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

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

*אם יחידת fetch אחת משרתת יותר סיליקון, היא "תרעיב" את הסיליקון העודף ותקטין את יעילות המעבד.

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

להזין אותן.

3. שני נימים בו זמנית איננו אומר שתי ליבות. עושה הרושם שאינך בקיא בהבדל בין thread (נים) ל-

process (תהליך) זהו הבדל אקוטי. עד שלא תרד לסוף הדעת בעניין זה, יקשה עליה להבין את המשמעות.

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

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

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

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

הסבר על קצה הלשון:

דמיין לעצמך מעבד בעל n יחידות עיבוד מקביליות, ששווה בהספקו המצרפי למעבד אחד בעל ליבה בודדת.

הרץ במעבד זה תהליך בודד, הרץ שני תהליכים... עד שתריץ n תהליכים. במעבד בעל n הליבות מתקבלת

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

אחת מליבותיו בעומס זהה.

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

8 ליבות שמקבל תהליך בודד, נצילותו יורדת כדי רק 12.5% - זוהי נצילות גרוע.

דהיינו: בנושא ליבות (עיבוד מקבילי) כל המוסיף גורע. עיבוד מקבילי לא רק שפוגם בביצועי המערכת כאשר

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

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

מאלץ את מערכת ההפעלה כמו גם את המתכנת, לשבור את הראש ולחשוב על פתרונות אלגורתימיים יצירתיים

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

שזרקנו לעברו.

ברדוקציה מהירה לסוגית מעבד 8 ליבות אל מול מעבד 4 ליבות כאשר שניהם בעלי הספקים (מצרפיים) זהים:

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

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

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

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

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

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

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

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

4. אני לא מסכים איתך;

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

AMD בחרו לקטרג את המעבדים הללו כמתומני ליבות בגלל ש-95% מהתוכנות כיום שרצות על בנויות ע"ג interger.

ז"א שב-95% מהמקרים, הליבות יעבדו בצורה עצמאית, fetcher ישלוף הוראות לכל נים מכל יחידת מבצעת, והנקודה הצפה תעבוד עם שני הנימים במקביל, כאשר כל אחד מקבל 128bit, ושניהם עובדים בצורה עצמאית.

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

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

bulldozer-front-end.jpg

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

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

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

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

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

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

4. אני לא מסכים איתך;

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

AMD בחרו לקטרג את המעבדים הללו כמתומני ליבות בגלל ש-95% מהתוכנות כיום שרצות על x86 בנויות ע"ג interger.

ז"א שב-95% מהמקרים, הליבות יעבדו בצורה עצמאית, fetcher ישלוף הוראות לכל נים מכל יחידת מבצעת, והנקודה הצפה תעבוד עם שני הנימים במקביל, כאשר כל אחד מקבל 128bit, ושניהם עובדים בצורה עצמאית.

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

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

יוסי נכבדי,

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

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

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

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

ב. כמו כן אמליץ שבנוגע לדוגמא שהנך מנסה להביא מתחום העיבוד הגראפי - לא נכנס. ולו מפאת העניין, כי מעבד תמונה (GPU) הינו

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

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

2. חד משמעית לא: בכל מודול בבולדוזר קיים מנגנון fetcher בודד, שמסוגל לשלוף את הדרוש לכל המודול יחדיו

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

מנגנון ה- fetching נאלץ לשרת: בפעימה אחת את אחת מיחידות האינטג'ר, ובפעימה השניה את היחידה השניה. כלומר:

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

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

צוואר בקבוק ואותה יחידת fetch בודדה אמורה להספיק ולשרת את שתי יחידות ה- Int בשוטף.

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

3. מה ש- מכנים אותו בטעות טרמינולוגית "ליבה", הוא למעשה לא אחר מאשר "יחידת עיבוד אינטרג'רית" - הא ותו לא.

בנגוד לכך, ההגדרה הטרמינולוגית התקינה היא: ליבה = מעבד.

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

לרבות זכרון מטמון שמשרת אותן.

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

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

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

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

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

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

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

4. הסברך בסעיף זה (לצערי הרב כמובן) אינו נכון. טענותיה של היצרנית לדבר כך, שב- 95% מהמקרים הפעולות הנדרשות מהמעבד הן

אינטג'ריות בבסיסן ורק 5% הן אחרות, הינה טענה שגויה. היחס בפועל שונה ומשתנה כתלות בשמוש המחשב ובאפליקציות שרצות עליו.

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

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

בכלל, יש המציירים יחס ממוצע אוניברסלי בין פעולות Int לפעולות FP (למשל), ככזה העומד על 60\40. אז מי פה צודק ? דווקא ?

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

היא הנכונה ?

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

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

- זכרון מטמון משותף (אל תבלבל את משטח העבודה בן 16KB לכל יחידת Int, זה איננו זכרון ה- L1)

- רוחב פס fetching משותף, וכבר הסברתי לעיל שזה נושא כן רלוונטי - היכן שהפעולות נוטלות פחות משני מחזורים

- וחשוב עוד יותר, מנגנון prediction משותף.

על כן, 8 יחידות העיבוד האינטג'ריות של הבולדוזר אינן חזקות "פי שניים" מאשר 4 יחידות עיבוד אינטג'ריות, ולו מפאת שיתוף המשאבים

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

למעשה, אחוז הנצילות בהפעלת 8 יחידות Int בבולדוזר, לעולם לא מצליח להגיע ל 100% הכפלת ביצועים ביחס ל- 4 יחידות Int

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

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

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

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

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

בנקודה הזאת אני רוצה להוסיף משהו.

כשהתחילו לצאת ההדלפות הראשונות בנוגע לביצועי המעבד מתומן הליבות של (שעכשיו אנו יודעים שממותג כ-FX-8xxx) בהשוואה ל-Core i7-2xxx ול-Core i7-9xx, היו לא מעט מאוכזבים או שמחים לאיד (תלוי איך מסתכלים על זה) שאמרו, "תראו, צריכה מעבד מתומן ליבות כדי להתחרות במעבד מרובע ליבות של Intel", בתגובה הסברנו (אני זוכר התייחסות מקיפה למדי של 'בור ועם הספר' לנושא) לא אחת שזאת השוואה שגויה כי לא משווים בין 8 ליבות ל-4 ליבות, אלא יותר בין 8 נימים ל-8 נימים. זאת עקב המבנה של ארכיטקטורת Bulldozer וטכנולוגיית ה-HT שהוטמעה במעבדים הנ"ל של Intel. לכן יש לבצע את ההקבלה הזאת גם במעבדים "משושי הליבה" ו"מרובעי הליבה" מסדרת FX.

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

אני גם חושב שהאכזבה מפלטפורמת FX היא מוקדמת מדי, אם כי אני מבין את חלקה. ראשית היא עדיין בשלבי השקה וכבר נדמה שחרצו את גורלה, וזה סתם לא לעניין מכיוון שבהחלט יש תקציבים, שימושים וקהל יעד שעבורם היא עשויה להתאים מאוד ואף להיות משתלמת בהתאם לתמחורה (כן, כולל לוח-אם שאני לא מבין למה מתעקשים להתעלם ממנו כאילו שהוא לא חלק מהפלטפורמה), ושנית, אם רוצים להיכנס לדיון קצת יותר מעמיק מאשר רק ה"שורה התחתונה", את הפלטפורמה הזאת צריך להציב מול ארכיטקטורת Nehelam של ולא SB, כי זה המועד שבו פחו או יותר היא הייתה אמורה לצאת אילולא מערבולת הבעיות שאליהן נקלעה AMD. אז כן, אני יודע שאת צרכן הקצה כל זה לא מעניין ומבחינתו אם מוצר א' טוב ממוצר ב' לא מעניין אותו למה ומדוע, וזה כמובן לגיטימי לגמרי, אבל אם רוצים לדון בנושא "שוק מעבדי ה-x86 לאן" ולא סתם לזרוק מבחני ביצועים אז צריך להכניס את הדברים קצת יותר לפרופורציה ולהתחשב גם בגורמים עסקיים. ואני אומר זאת בתגובה לטענות שעולות כאילו AMD מפגרת טכנולוגית אחרי מבחינת יכולות הנדסיות, חדשנות ומעוף; זאת להבדיל ובניגוד למשאבים ולניהול יציב וממוקד שני תחומים שבהם היא בהחלט נמצאת בפיגור באופן כללי ובחצי העשור האחרון, בהתאמה).

האכזבה היחסית שלי היא בעיקר מכך שאין שיפור ב-IPC, ואני חושב שאם מקלפים את כל שכבות הביקורת הלא עניינית או הענייניות לחמצה, בזה מסתכמת האכזבה באופן כללי כמעט של כל אלה שבאמת ציפו למשהו אחר (להבדיל מהשמחים לאיד). אני באופן אישי ציפיתי ל-15%-30% (כאשר 30% היא יותר משאלת לב מציפייה מעשית) שיפור בהשוואה ל-K10 וזה לא ממש קרה. אם זה היה קורה, לדעתי התגובות לפלפטפורמה היו הרבה יותר נלהבות. אני חושב שמלכתחילה ארכיטקטורת מרובת נימים היא לא הדרך אל ליבו של קהל המשתמשים הביתי מכיוון שבנקודת הזמן הנוכחית התוכנה ממש עדיין לא שם. זה מקביל בדיוק למצב עם טכנולוגיית ה-HT של Intel, מכיוון שלשימושים ביתיים-עסקיים ממוצעים (עבודה משרדית, מדיה, משחקים) לריבוי נימים יש בחלק קטן מהמקרים תועלת נמוכה עד זניחה, בחלק אחר הוא אפילו מפריע ובסך הכל עדיין ל-IPC חשיבות גדולה מאוד. גישה כזאת כלפי ריבוי נימים מבלי לשפר את ה-IPC, ופה אני מסכים לגמרי עם yossi_77, מפסידה ל-AMD מראש את הקרב על ליבו של קהל הגיימרים (אבל לא לפרש בבקשה את המשפט הזה כאילו פלטפורמת FX לא יכולה למצוא את קהל היעד שלה מבין ה"גיימרים"), קרב שאני לא בטוח שבמצב הנוכחי של החברה הם בכלל ציפוי או קיוו לנצח, וזאת אולי בניגוד לנקודת הזמן שבה הוכרזה הפלטפורמה.

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

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

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

ואני אוסיף גם קצת משלי:

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

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

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

הגראפי ולא על המעבד.

בנקודה זו של יכולות עיבוד גראפיות, היות ורוחב הפס של הבולדוזר הוא כפול מרוחב הפס של הסנדי ברידג' (32 PCI LANES לעומת 16)

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

(SLI/CrossFire) או יותר, יתכן שדווקא ידו של הבולדוזר תצא על העליונה (וכמה bench-ים רמזו לכוון זה).

דהיינו רוצה לומר: שבדיקת benchmark על משחק תלת מימדי תוך בידוד פרמטר ה- CPU במשוואה, וזאת באמצעות רזולוציה מינימאלית תוך

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

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

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

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

התחרות.

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

"בטויוטה". רוצה לאמר: אם בולדוזר (רק לשם הדוגמא) מספק בממוצע 80% מביצועי 2500k, אזי תמחורו במחיר של בערך

80% ממחירו של 2500K הינו מחיר סביר בהחלט וכזה שיניב לAMD נתח שוק ראוי. זה כל מה שאנחנו הצרכנים צריכים, שהתחרות תשמר,

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

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

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

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

בולדוזר בכלל לתחום השרתים, זו כמות ה L3 cache (שחוזרת על זו של ה L2 cache) - שניהם ב- 8MB :kopfpatsch:

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

הספק/טרנזיסטור נמוך ל ממוצע.

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

בנגזרת שמתאימה לתחום ה- ובו תבטל אף לחלוטין את ה L3 (באם ה L2 עומד על 8MB בלאו הרי). בכך תחסוך AMD כסף רב:

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

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

מעבדי הזולים יותר I5-2300 ? אולי כפולי הליבה (כמו למשל ה Icore3) ?

במקרה שכזה הבולדוזר יתן value for money עדיף, במיוחד על רקע העובדה שהוא בר בעוד שהמקבילות

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

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

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

ב. מסכים לגמרי.

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

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

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

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

בהחלט נכון. מחשב העל החזק ביותר בעולם (אוטוטו) יהיה היגואר של CRAY ויתבסס על מעבדי Interlagos עם 16 ליבות (8 מודולים של בולדוזר).

סקירה כאן:

http://www.extremetech.com/extreme/99413-titan-supercomputer-38400-processor-20-petaflop-successor-to-jaguar

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

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

ארכיון

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


×
  • צור חדש...