AMD הולכים להשתמש בטכנולוגיה הפוכה ל-HyperThreading של אינטל? - מעבדים, לוחות-אם וזכרונות - HWzone פורומים
עבור לתוכן
  • צור חשבון

AMD הולכים להשתמש בטכנולוגיה הפוכה ל-HyperThreading של אינטל?

The Coolest

נוצר על ידי The Coolest
ב מעבדים, לוחות-אם וזכרונות

Recommended Posts

The Coolest Zone Master

The Coolest

פורסם
פורסם

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

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

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

קישור לתוכן
שתף באתרים אחרים
  • תגובות 31
  • נוצר
  • תגובה אחרונה
kawaii Zone Addict

kawaii

פורסם
פורסם

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

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

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

LiorP23

פורסם
פורסם

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

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

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

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

barak_11

פורסם
פורסם

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

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

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

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

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

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

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

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

Nemesis

פורסם
פורסם

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

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

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

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

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

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

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

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

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

BUNG

פורסם
פורסם

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

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

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

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

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

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

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

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

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

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

DOGMA

פורסם
פורסם

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

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

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

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

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

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

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

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

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

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

DOGMA

פורסם
פורסם

איך לדעתך יעזור 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.

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

Nemesis

פורסם
פורסם

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

?

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

ארכיון

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

עבור לרשימת הדיונים
×
  • צור חדש...