עבור לתוכן

Q6600 מול E6600

Featured Replies

פורסם

multi tasking זה לעבוד עם כמה תוכנות בו זמנית.

זה יותר קל עם יותר ליבות

  • תגובות 36
  • צפיות 5k
  • נוצר
  • תגובה אחרונה
פורסם

המחשב הבא שלי יהיה מרובע ליבה

פורסם

כל ליבה (core) יכולה להריץ תהליך (process) או חוט (thread) אחד בכל רגע נתון. כאשר תהליך אחד יכול להכיל כמה חוטים.

תפקיד מערכת ההפעלה היא לקחת את כל התהליכים ואת כל הליבות ולמפות את התהליכים לליבות השונות. לרוב היא עושה את זה ע"י מדידת כמה זמן כל ליבה נמצאת בשימוש ולפי זה היא מנסה לחלק את התהליכים שירוצו באופן שווה בחלוקת עומס על הליבות השונות (זאת אם לא מחריכים תהליך מסוים לעבוד על ליבה מסוימת ע"י קביעת שייכות (affiniy) ב task manager למשל).

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

פורסם
  • מחבר

OK

תודה על ההסברים

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

יעבוד טוב יותר עם Q6600 או X6800 י?

פורסם

^^^^^

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

פורסם
  • מחבר

^^^

רגע, משחק שתומך ב 2 ליבות לא אמור לתמוך גם ב 4 (כמו שאמרתם פה) ??

פורסם

זה כלל וכלל לא נכון שמשחקים/תוכנות אשר יתוכנתו להעמיס 2 ליבות יעמיסו/ינצלו באותה מידה גם 4 ליבות.

אם חלוקת העומס מתוכננת ל-2 ליבות, 4 ליבות לא יתרמו כמעט כלום.

פורסם
  • מחבר

מי שמנצל 2 ליבות ינצל גם 4

לא נראה לי שצריך ללמד ישומים שעובדים עם 2 ליבות לעבוד עם 4 ליבות.

זה כלל וכלל לא נכון שמשחקים/תוכנות אשר יתוכנתו להעמיס 2 ליבות יעמיסו/ינצלו באותה מידה גם 4 ליבות.

אם חלוקת העומס מתוכננת ל-2 ליבות, 4 ליבות לא יתרמו כמעט כלום.

תחליט בקשה..

כמה אמרו שיישומים שתומכים ב 2 ליבות ישתמשו גם ב 4 ליבות

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

פורסם

התשובה היא כפי שאמרתי חד משמעית.

יישום שחלוקת העבודה שלו מיועדת ל-2 ליבות בלבד, לא ירוויח מיותר ליבות.

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

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

פורסם

OK, תנסה לעקוב שוב. אני רק מסביר בשפה פשוטה מה שהסבירו פה הרבה יותר מקצועי לפני.

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

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

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

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

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

אם יש יותר סטים שרצים במקביל אז הם יכולים לרוץ על יותר מעבדים בצורה שתורגש יותר.

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

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

פורסם

זה כלל וכלל לא נכון שמשחקים/תוכנות אשר יתוכנתו להעמיס 2 ליבות יעמיסו/ינצלו באותה מידה גם 4 ליבות.

אם חלוקת העומס מתוכננת ל-2 ליבות, 4 ליבות לא יתרמו כמעט כלום.

זה לא כזה מדוייק.

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

פורסם

זה לא כזה מסובך ולא הפיסי המציא את ריבוי הליבות

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

פורסם

כל ליבה (core) יכולה להריץ תהליך (process) או חוט (thread) אחד בכל רגע נתון. כאשר תהליך אחד יכול להכיל כמה חוטים.

רק יצויין שתהליך חייב להכיל לפחות חוט אחד

פורסם
  • מחבר

OK, תנסה לעקוב שוב. אני רק מסביר בשפה פשוטה מה שהסבירו פה הרבה יותר מקצועי לפני.

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

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

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

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

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

אם יש יותר סטים שרצים במקביל אז הם יכולים לרוץ על יותר מעבדים בצורה שתורגש יותר.

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

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

אז למי שיש Q6600 יש לו לפעמים כמה באגים?

כלומר התוכנות נתקעות וכדומה?

פורסם

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

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

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

ארכיון

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

דיונים חדשים