שלום.

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

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

מה שאומר שהאלגוריתם צריך להיות יותר מורכב.

הוא אמר שזה שטויות וזה בכלל לא קשה לכתוב קוד כזה, והביא לי כדוגמא את ה hyper threading.

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

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

תודה.

שלום.

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

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

מה שאומר שהאלגוריתם צריך להיות יותר מורכב.

הוא אמר שזה שטויות וזה בכלל לא קשה לכתוב קוד כזה, והביא לי כדוגמא את ה hyper threading.

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

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

תודה.

תיראה אני לא מפתח אז אני לא יכול לתת לך תשובה מוחצת

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

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

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

טוב זה בקשר למרובי ליבות רגילים ולא לCELL שהוא ביכלל עוף מוזר

Hyper Threading לא קשור בכלל כי זאת טכנולוגיה שגורמת למעבד P4 אחד של אינטל להופיע כשתי ליבות וירטואליות למערכת הפעלה.

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

בגדול, כן, תכנות של ריבוי נימים מביא איתו סיבוכים מכל מני סיבות, כשעיקרם הם:

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

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

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

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

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

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

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

דבר רביעי והכי חשוב, שפות התכנות ה"חדשות" כדוגמת java ו c# ועוד כמה, מכילים בבסיס השפות, כל מני אוביקטים ופרימיטיבים שכבר יודעים מראש להתמודד עם הכאב ראש של תכנות מרובה נימים, ומאפשרים למתכנת שליטה יותר שפוייה על איך לכתוב את הקוד שלו בצורה מקבילית בלי להילחם עם כל מני בעיות שיכולות להתעורר כשאתה כותב בשפה פחות נוחה, או פחות מפותחת (כמו C למשל).

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

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

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

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

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

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

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

כי משחקים זה לא התחום שלו.

תודה רבה.

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

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

ככה נראה לי, אני צודק?

שטויות, בסופו של דבר הכל יהיה בסדר - מן הסתם.

ברור

אחרת לא היו ממשיכים להוסיף כל כך הרבה ליבות

שהמתכנתים ידפקו תראש

בשביל מה משלמים להם??? =-)

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

מה טוב...

הבעיה אינה במערכת ההפעלה.

שהמתכנתים ידפקו תראש

בשביל מה משלמים להם??? =-)

לא ממש חכם

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

אז זה חוזר אלינו כמו בומרנג

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

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

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

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

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

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