http://www.fronic.com/?p=66

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

אם הם באמת הולכים לעשות את זה, אז מעניין איך זה יעבוד? המערכת הפעלה תראה רק מעבד לוגי אחד? בדיוק כמו שעם מעבד HT ה-OS רואה 2?

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

בכל מקרה, לדעתי עדיף כבר שיצאו יותר ישומים שתומכים בעבודה עם 2(או 4 בעתיד) ליבות. יותר מעניין.

נשמע לי קצת מגוחך.

למה לעזזל הם עושים את זה?

כאילו מי ירוויח מזה? הרי זה ידוע שכל התוכנות הולכות ועוברות לשימוש ב2 ליבות...

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

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

אפשר לדעת למה זה יהיה נהדר?

כי ת'רד אחד יתחלק למספר ליבות

כנראה הוא יידע לזהות חישובים בלתי תלויים ויתן כל חישוב לליבה אחרת

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

כי ת'רד אחד יתחלק למספר ליבות

כנראה הוא יידע לזהות חישובים בלתי תלויים ויתן כל חישוב לליבה אחרת

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

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

בהרבה מקרים כמו ב-3DMARK במבחני CPU היא מורידה ביצועים משמעותית.

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

בעתיד הריבוי ליבות זה "כל הקטע".

זה נשמע לי חרטוט.

זה יהיה בלתי יעיל לחלוטין לביצוע על קטע קוד קצר.

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

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

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

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

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

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

זה נשמע לי חרטוט.

זה יהיה בלתי יעיל לחלוטין לביצוע על קטע קוד קצר.

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

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

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

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

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

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

זה גם למה לדעתי זה יהיה סתם ביזבוז...

זה נשמע לי חרטוט.

זה יהיה בלתי יעיל לחלוטין לביצוע על קטע קוד קצר.

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

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

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

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

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

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

עם branching unit "משותף" זה יעבוד לא רע, אבל במילא כל מי שמתכנת כיום עובד עם managed לא צריך כבר ליצור את התראדים לבד, סביבת העבודה עושה זאת בשבילך. dotnet יהיה חלק אינטגרלי מvista לתכנת לריבוי ליבות לא היה קל יותר מעולם.

איך לדעתך יעזור Branch Prediction Unit משותף?

איך לדעתך יעזור Branch Prediction Unit משותף?

well it depends on how this feature will be implemented.

i.e. lets simplify a proccessor into to a single pipeline. if infact the way they implement this technology will result in a longer "virtual" pipeline which will consist of CPU1=>CPU2(similar to the way most "supercomputers" are built) then they have to implement some form of global branch prediction for the entire proccess. because if they dont then they will end up with much much poorer preformance then using a single CPU since every time a program branches they whole pipeline has to be flushed. and unlike programs for "supercomupting" which are designed to branch very rarely, most of the commom programs tend to branch alot. which results in a pretty big preformance hit when dealing with longer pipelines.

but untill we get atleast some technical details there is very little point in discussing this. if they do go with the "supercomputer" apporach the only major issues i can think off are branching and registers related.

What is the point of placing one pipeline after the other?

It does not logically make sense, atleast not to me. Suppose you create this logical long pipeline assuming a simple in order execution, you fetch an instruction, decode it/break to uops, fetch data, allocate registers, load registers, execute and write back.

And then there is another fetch instruction. Fetch what

?

aye you dont need more then a 5 stage pipe line, but thats if you have an ideal excution, longer pipelines do have their .advantages