ליבות להמונים.

[sdfzxc]

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

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

[tal_levi1000]

ה X360 היא זו שלא תומכת לאחור לא?

הPS3 היא בעלה הקושי לפתח משחקים בשבילה

[sdfzxc]

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

[lipa]

יש פה בעייה של קצרי-ראייה

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

זה מזכיר לי (סיפור אמיתי) , בלונדון בתחילת המאה הקודמת כלי התחבורה הנפוץ היה סוס

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

גם אתם (בלי להעליב) רואים רק את החרא

[sdfzxc]

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

[bla7]

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

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

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

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

[sdfzxc]

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

האם זה ארטיקטורה טיפוסית של מעבדי אינטל ? (בעוד שאני בהחלט יכול לראות 32 ליבות עוזרות בפועולת של שרתים כמו פניות מרובות נימים לשרת WEB או DATABASTE או מה לא).

[QuAKeR_996]

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

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

[bla7]

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

האם זה ארטיקטורה טיפוסית של מעבדי אינטל ? (בעוד שאני בהחלט יכול לראות 32 ליבות עוזרות בפועולת של שרתים כמו פניות מרובות נימים לשרת WEB או DATABASTE או מה לא).

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

לגבי Cache Coherency, מן הסתם הוא מתחשב בזה - זה בכלל לא מסובך, ובטח לא מה שיפיל את הרעיון. כמובן שהסינכרון הזה יהיה Overhead מסויים על המערכת, אז היא לא תהיה חזקה פי 32 ממערכת היום (למשל, רק פי 8 ). אבל מערכת עם 64 ליבות כן תהיה פי 2 חזקה ממנה בשימוש במנגנון הזה.

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

תוספת: לגבי Cache Coherency, יהיה צורך גם ב-Memory Coherency באופן כללי, כי ה-Cache לא משותף לכל הליבות... אבל זה לא כזה משנה, כמו שאמרתי...

[urib]

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

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

הם זקוקים לכמה דברים:

1. Cache Coherent HyperTransport (ccHT

2. Direct Connect Architecture

בנתיים שיספרו סיפורים לפריירים.

[attachment deleted by admin]

[iib]

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

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

אתה לא פותר פה שום בעיה...

בו נבאר את הדברים שלך

מה זאת אומרת לסנכרון - לבדוק שוב שכל מה שמעבד כותב לזכרון באמת נעשה בסדר הנכון?

32 ליבות - נגיד קונורים קטנים - כל קונורו יכול להכיל ולטפל בו זמנית ב-96 פקודות קטנות (Micro ops) בו זמנית.

כל פקודה כזו יכול לכתוב ולקרוא מהזיכרון. לכן מעבד כזה יכול לטפל ב 3072 פקודות במקביל

3072 פקודות שיכולות לכתוב ולקורא מהזכרון!.

אתה באמת חושב שיש דרך לבדוק שפקודה XX בליבה מספר 12 קוראת משהו מהזיכרון

אבל פקודה YY בליבה מספר 9 היתה אמורה לעדכן את התא זכרון הזה קודם אבל היא טרם התבצעה.

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

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

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

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

זה מה שנקרא באג... באג הוא באג ברמת התוכנה.

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

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

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

[iib]

הסינכרון יכול להיות בתדר של 100Hz

מה לעזזל הקשר בן התדר רענון של המסך לתוכנה?

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

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

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

[sdfzxc]

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

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

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

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

האם זה ארטיקטורה טיפוסית של מעבדי אינטל ? (בעוד שאני בהחלט יכול לראות 32 ליבות עוזרות בפועולת של שרתים כמו פניות מרובות נימים לשרת WEB או DATABASTE או מה לא).

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

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

[Gico]

אתה באמת חושב שיש דרך לבדוק שפקודה XX בליבה מספר 12 קוראת משהו מהזיכרון

אבל פקודה YY בליבה מספר 9 היתה אמורה לעדכן את התא זכרון הזה קודם אבל היא טרם התבצעה.

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

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

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

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

זה מה שנקרא באג... באג הוא באג ברמת התוכנה.

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

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

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

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

את הקוד לתהליכים ולהגדיר את התלות בינהם (תהליך A,B יכולים לרוץ ביחד, C חייב לחכות ש-A יסתיים, D חייב

לחכות ש-C ו-B יסתיימו וכך הלאה). כך תוכל החומרה לשלוט על הסדר. בג של מתכנת בהגדרת התהליכים יהיה כמו כל בג אחר.

בנוסף לכך אני מניח שתוכל להיות אופטימיזציה שהחומרה תוכל לעשות: כאשר ליבה אחת או יותר "ישתעממו" היא

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

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

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

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

[iib]

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

את הקוד לתהליכים ולהגדיר את התלות בינהם (תהליך A,B יכולים לרוץ ביחד, C חייב לחכות ש-A יסתיים, D חייב

לחכות ש-C ו-B יסתיימו וכך הלאה). כך תוכל החומרה לשלוט על הסדר. בג של מתכנת בהגדרת התהליכים יהיה כמו כל בג אחר.

בנוסף לכך אני מניח שתוכל להיות אופטימיזציה שהחומרה תוכל לעשות: כאשר ליבה אחת או יותר "ישתעממו" היא

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

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

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

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

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

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

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

ככה היא יכולה לבצע פקודות תוך שהיא בודקת תלות בכתיבה לזכרון:

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2748&p=5

וזו ליבת ה x86 הכי מתקדמת בעולם...

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

בגלל שהקוד פשוט לא מאפשר את זה...

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

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

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

if ביטוי נכון

אז:

{

}

else

אחרת:

{

}

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

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

במה שחושב כבר בליבה 2 וככה לחסוך זמן.

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

רק ליבה 1 יכולה לכתוב לזכרון בצורה בטוחה.

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

זה הרעיון מאחורי "Reveresed Hyperthreding" שזה שם טיפשי...

הייתי פשוט קורה לזה Hardware multi-threading....

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

אבל בצורה מוגבלת ותוך פיתוח מנגנונים של תקשורת בין ליבות שלא קיימים

ולוגיקה נוספת שלא קיימת.

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

אולי 2 ליבות לנים - וגם זה לא באופן אופטימלי - ותוך תוספת מורכבות לא מבוטלת לכל מעבד

שזה בכלל מה שכל ריבוי הליבות קיווה לפתור...