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

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

הבדיקות שהרצתי התבצעו באמצעות lame 39.6.1 וסופר פי

הרצתי בהתחלה מגה של סופר פי - לקח 47 שניות

אח"כ הרצתי במקביל שני תרדים של סופר פי ולקח דקה וקצת יותר מחצי - כלומר ל היה איבוד ביצועים(90 שניות בערך שהם קרובות ל47 שניות כפול 2)

אח"כ הרצתי במקביל 3 תרדים של סופר פי ולקח 2 דקות ו22 שניות (162 שניות שהם כמעט 47 כפול שלוש)

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

קידוד ל128 ביט של MP3 לקח 15 שניות

קידוד מקבילי של שני תרדים לקח 31 שניות - כלומר לא היה איבוד ביצועים (או מה שהיה היה זניח מאוד)

אח"כ ניסיתי לבדוק מה קורה ב2 ישומים שונים - כדי להקשות יותר על הסקדואלר :

עבדתי בסופר פי על 256K ביחד עם עידן רייכל בליים

סופר פי ל256K לקח 8 שניות , עידן רייכל כזכור לוקח 15 שניות(סה"כ 23 שניות)

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

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

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

בבקשה מישהוא עם מערכת HT (אולי SMP מישהוא ? ) ינסה את הבדיקות האלו , וכדי להריץ את הישומים במקביל צריך ליצור עותק שלהם בתיקייה אחרת.

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

תרגע, ילד, לא טעית.

העניין הוא שעוד אפליקציה תמיד תוסיף עומס לscheduler - זה עוד משהו לדאוג לו. זה תמיד כך.

נכון שאפליקציה שהינה blocked (כלומר מחכה לאירוע כלשהו) לרוב לא תורגש כלל על ידי הscheduler (פשוט לא תכנס לready list, רשימת הprocess-ים שמסוגלים לרוץ באותו רגע), אך בכל מצב אחר היא תגרום לעוד context switch. עובדות החיים המצערות.

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

שלו תעלה באופן לינארי יותר עם הוספת process-ים.

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

אז נוספת לו קצת עבודה, אז מה.. הוא מסתדר.

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

אוקי, אם כבר - הפגיעה הינה זניחה במקרים מסויימים. במקרים אחרים, לא כלכך. אבל זה לא קשור לscheduler. מבחינתו, הפגיעה היא פחות-או-יותר קבועה (לפחות כשמדובר בתוכנות cpu intensive), וקטנה למדי.

עד כמה שאני מכיר את האפליקציות אותן הרצת, כולן מאופיינות בדבר אחד - הן cpu intensive ומבצעות מעט מאוד i/o.

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

שתי הסיבות העיקריות הן:

1. כמובן, חברנו הcache. במצב בו אנו מריצים שתי אפליקציות אינטנסיביות מבחינת זכרון, ברור שהcache miss עף לשמיים - כל המידע הcached של אפליקציה א' לא יתאים לאפליקציה ב'. עד שאחת כבר תכניס לcache את מה שמעניין אותה, יתרחש context switch, והמידע יהיה שוב לא רלבנטי.

2. page faults, אפליקציות שניגשות לכמות גדולה של זכרון (להבדיל מאפליקציות שניגשות הרבה פעמים למעט זכרון, כמו Super PI) שותות מהר מאוד את טבלאות דפי הזכרון החומרתיות (ITLB/DTLB) של הMMU ומשם כבר מערכת ההפעלה צריכה לעדכן את הדפים מהזכרון שלה. תהליך יקר מאוד (exception על כל דף כזה, גישות לזכרון המערכת, עדכון מבני נתונים ומה לא). כאן מופיעה אותה בעיה של הcache - מה שנכון לאפליקציה א' לא יהיה נכון לאפליקציה ב'.

בניגוד לcache, כאן המצב אפילו גרוע יותר - הcache הוא set associative, כלומר עובד בצורה אופטימלית עם מספר איזורי זכרון, והTLB הוא fully associative, כלומר עובד בצורה גמישה לחלוטין - ללא הבחנה בין איזורי זכרון שונים (ועזבו כרגע את ההסבר, אלא אם אתם באמת רוצים... : )

בהצעה לSchdeuler אלטרנטיבי עבור לינוקס אני מניח שאתה מתכוון לסקדולר (סלח לי על העברות של המילה) ה (1)O.

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

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

XOD - מאיפה אתה באת? (אגב, מדברים פה על ווינדוז, לא לינוקס)

בכל מקרה, הדוגמאות שהבאת אינן מנוגדות לטענה שIB העלה ...

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

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

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

from the depths I come... ;D

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

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

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

דבר שני, גם ללא swapping, עדיין יש פגיעה בביצועים עקב page faults בשעת context switch בין אפליקציות (ולא בין thread-ים, שחולקים את אותו מרחב זכרון). הרי בכל אפליקציה מיפוי הכתובות הוירטואליות לכתובות הפיסיות הינו שונה, ולכן טבלאות המיפוי החומרתיות (הTLB, שהינו חלק מהMMU) צריכות להתעדכן בשעת המעבר.

זה overhead.

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

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

אגב, שים לב שהמבחן מתייחס לאפליקציות, ולא thread-ים (שגם בהם נעשה context switch, אך חלקי, ללא שינוי במשחקי הדפים שבMMU - שהרי מספר thread-ים חולקים את אותו הזכרון). חוסר היעילות שבתוכנה multi threaded קטן בהרבה מחוסר היעילות שבשתי אפליקציות נפרדות לגמרי - כאן כבר אין ממש בעיות cache או מיפוי TLB, הפגיעה היחידה בביצועים באה מכיוון תוכנתי טהור של נעילות משאבים וסנכרון thread-ים (וכמובן מעט מאוד scheduling, אבל זה זניח, לא? )

3. ישנו overhead, לפעמים לינארי ולפעמים לא - תלוי במערכת ההפעלה, ראה את מה שצויין לגבי הO(1) scheduler של לינוקס ממקודם - שמתחייב מעצם הרצת תהליך נוסף. הוא קיים, כך שפותח השרשור המקורי אינו טועה. הוא עומס קטן מהמצופה, בגלל שהscheduler-ים יעילים כלכך.

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

ע"ע benchmarks בהם מעבדי P4 עם HT איטי ממעבד זהה עם HT מבוטל - כולנו ראינו כאלו, לא? מערכת ההפעלה צריכה לעבוד קשה בשביל לאפשר פעולה של מספר מעבדים במקביל.

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