כה ציטט Donald Knuth:

 

... Premature optimization is the root of all evil...

 

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

 

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

 

ראשית יש להפריד בין כמה סוגי יעולים - יעול אלגוריתמי (כמו שימוש ב-quicksort מול bubble sort) ויעול "טקטי". יעול אלגוריתמי תמיד היה ויהיה חשוב, ובעולם שבו כמויות המידע המעובד רק גדלות, שיפור אלגוריתמי אף הופך למשמעותי יותר.

 

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

Option1:

switch (digit) {

case 0: return '0'

case 1: return '1'

....

case 10: return 'A'

....

}

 

Option 2:

return digitToHex[digit];

 

התשובה שגיליתי, היא שתלוי. מאוד תלוי. תלוי בשפת התכנות, באופטימיזציות של הקומפיילר, ו/או של ה-runtime (בשפות כמו java/c#). במקרה שלי, גיליתי למשל שדווקא האפשרות השניה, שנראית על פניו מהירה יותר, היא דווקא האיטית (בכ-50%), כי ב-java בודקים את גבולות המערך בכל גישה (היום כבר יש אופטימיזציות של ה-runtime שמבטלות אותן) ואילו ה-switch מתורגם על ידי ה-runtime לגישה יחידה למערך, בלי שום בדיקות.

 

אבל לא צריך להרחיק עד לשפות שהן interpreted. כבר ב-c++ אין להרבה אנשים מושג איך הקוד באמת מתנהג. כמות ה-features שמציע המעבד, וסוגי האופטימיזציות שמציע ה-compiler (למשל סידור מחדש של הפקודות כדי לנצל את מלא כוח החישוב של המעבד). נסיון לבצע אופטימיזציה לקוד שטופל היטב על ידי ה-compiler דורש הכרות טובה עם ה-assembly ויכולות מעקב טובה אחרי הקוד הנוצר. או האם, למשל, כדאי לשלב ב-c++ קטעי קוד ב-assembly? הכנסה של קוד כזה יכולה לשבור את האופטימיזציות שה-compiler היה עושה בקוד ה-c++  ובסופו של דבר לגרום לאפקט הפוך. איך אפשר לדעת? אי אפשר, צריך להבין היטב מה עושים ו/או לנסות.

 

דוגמא אחרת היא ההתייחסות ל-cache של המעבד והמחשב. כמה אנשים יודעים כמה cache מסוג L1 או L2 יש להם במחשב? ואת הפרמטרים הפנימיים שלו? עבודה נכונה של ה-cache יכולה לתת שיפורים מדהימים (במקרה אחד ראיתי שיפור של 90% בביצועים של קוד שהיה צוואר בקבוק באפליקציה) ועבודה שגויה יכולה לגרום להאטה משמעותית ביותר.

 

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

 

ומה קורה כאשר אנחנו מגיעים לנקדה שאין ברירה וצריך לייעל? מה ה-skills set שדרוש כדי ליעל קוד? האם מתכנת java יכול/צריך להכיר את c/c++/שפת aseembly/את מבנה המחשב ומערכת ההפעלה/תורת הקומפילציה? בעולם שבו אנחנו הולכים וכותבים יותר ויותר קוד בשפות כמו python/ruby/groove וכד' האם אפשר למצוא בכלל אנשים שמכירים את המחשב ב-low level? והאם לימוד java כשפת לימוד ראשונה לא פוגע בהבנה כזו? והאם הידע שלומדים באוניברסיטה לא הופך ל-obsolete לאחר כמה שנים? כמי שלמד את ה-assembly של pdp11 (אני חושב שבטכניון כבר עברו ל-80x86) ואת המבנה של הפנטיום, ראיתי שאני צריך לקרוא לא מעט חומר בעצמי כדי לעמוד בקצב הטכנולוגי.

 

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

יש כמה רמות לאופטימיזציה ולמודעות לביצועים באופן כללי.

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

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

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

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

גנאדי,

 

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

 

- שפת תכנות - לבחירת שפת תכנות יש סיבות שונות כמו למשל זמן פיתוח, קלות תחזוקה וכו'. השימוש בשפות כמו ruby,python לא נפוץ במערכות high performance (למעט אולי ה-script-ים מסביב) ומצד שני לא סביר לכתוב טופס אלקטרוני באמצעות אסמבלר.

 

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

 

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

 

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

 

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

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

 

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

 

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

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

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

 

ארנון  

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

 

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

 

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

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

 

or_os - זה סוג של אומנות (או טירוף, או שניהם). :)  זאת הסיבה שאני חושב שלרובנו אין באמת מושג באופטימיזציה "עד הסוף"....

 

ארנון (ברוך שובך!): האם ואיך אתה מכניס שיקולי ביצועים בשבל התכנון?

 

 

מימד נוסף להסתכל על זה: 

 

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

 

 ישנם כאלה שמנסים למנוע בלאגן בקוד גם מבחינת מבנה וגם מבחינה אלגוריתמית באמצעות Review של הקוד על ידי "מומחה" לפני השחרור. מהניסיון שלי, הבחור בדרך כלל לא יבין בין ימינו לבין שמאלו בקוד שנכתב עם מינימום תיעוד (הרי אנחנו כותבים Self Documented Code כאילו דאאא), ממלא טופס של Review ויאללא אודרוב.

 

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

 

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

 

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

 

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

 

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

 

 

ארנון (ברוך שובך!): האם ואיך אתה מכניס שיקולי ביצועים בשבל התכנון?

 

 

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

אפשר לקרוא על זה באתר שלי: http://www.rgoarchitects.com/Files/SPAMMED.pdf  

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

 

ארנון 

כמה שאלות מעניינות בפוסט אחד!

 

> בעולם שבו אנחנו הולכים וכותבים יותר ויותר קוד בשפות כמו python/ruby/groove וכד'

> האם אפשר למצוא בכלל אנשים שמכירים את המחשב ב-low level?

 

 תתפלא, זה לא פשוט אבל בהחלט אפשרי. בד"כ אלה האנשים שכותבים דרייברים ו-BSP למערכות Embedded.

 

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

 

השאלה היא לא אם לומדים java, אלא האם ממשיכים ללמוד מעבר לשפה.

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

 

> באופן כללי לטעמי כמעט כל שיפור שאינו אלגוריתמי ניתן להשיג ע"י הוספת יותר כח מחשוב,

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

 

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

 

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

 

לא כל העולם הוא פנטיום!

הנה שני מאמרים שמתארים בצורה טובה מתי ואיך צריך לחשוב על אופטימיזציות:

 

http://www.acm.org/ubiquity/views/v7i24_fallacy.html

http://weblogs.java.net/blog/sdo/archive/2008/02/oh_go_ahead_pre.html

 

(והקרדיט על הביטוי המקורי הוא של Tony Hoare)

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