member access

[צונאמי]

member access

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

class RetClass { public: int myInt; }; class RetWraper { public: int padding; RetClass myRet; }; RetClass * return_somthing_1(RetWraper * a) { return &a->myRet; } RetClass * return_somthing_2(RetClass * a) { return a; }​

תודה,

 

[® רן]

עקרונית אתה צודק

הפונקציה השניה מקבלת פרמטר ומחזירה אותו. הפונקציה הראשונה מקבלת פרמטר, מוסיפה לו 4 (או כמה ש sizeof int במערכת שלך), ומחזירה אותו. פעולת ה +4 לוקחת לפחות עוד מחזור שעון אחד של ה CPU. מבחינה מעשית, אין לזה חשיבות רבה - לא עושים אופטימיזציה של קוד לרמה של clock-ים בודדים, אלא במקרים ממש קיצוניים.

 

[צונאמי]

אני עושה מקצה שיפורים ל-smart Ptr

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

 

[® רן]

הבנתי, אבל

עדיין לא הייתי עושה אופטימיזציות בשביל לחסוך clock אחד. SmartPtr כזה או אחר מרמז על כך שאתה מתכוון להקצות זיכרון בצורה דינאמית. הקצאה דינאמית (או שחרור) היא תמיד פעולה כבדה, שכרוכים בה בד"כ קריאה לפונקציה של מערכת ההפעלה, לקיחת סמפור אחד או יותר, חיפוש במבנה נתונים (free list או משהו דומה) וכולי וכולי. חיסכון של פעולת חיבור אחת יהיה כל כך שולי שאי אפשר יהיה אפילו למדוד אותו. חיפשת קצת בגוגל על Smart Pointers? יש הרבה דוגמאות: http://www.google.com/search?sourceid=navclient&ie=UTF-8&rls=GGLD,GGLD:2004-32,GGLD:en&q=smart+pointers+c%2B%2B

 

[צונאמי]

לא בהכרח

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

.

 

[DadleFish]

בכל מקרה, לגבי אופטימיזציות -

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

 

[® רן]

הייתי הופך את הסדר

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

 

[צונאמי]

אולי להתיחס להכל בו זמנית ?

 

[vinney]

לא כדאי

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

 

[DadleFish]

אני מנסח את זה לעצמי קצת אחרת

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

 

[DadleFish]

האמת היא שקודם כתבתי את מה..

שאתה אומר, ואח"כ החלפתי את הסדר. אני האחרון שיחלוק עליך שהתוכנה צריכה להיות כתובה יפה. עם זאת, נתקלתי כבר בתוכנות שכתובות פשוט נהדר, ממש אקדמית, BY THE BOOK, ופשוט לא עובדות, או לפחות לא עושות את מה שמצפים מהן. בנוסף יש עוד בעיה, והיא OVERKILL של DESIGN - הרבה אנשים שלמדו DESIGN אבל אין להם את הפרקטיקה נוטים לפוצץ את ה-DESIGN בעשרות ומאות CLASS-ים, מתוך "מחשבה קדימה" כביכול, ובלי להתייחס בכלל לזה שהתוכנה צריכה לזוז. אופטימיזציה ברמת הקוד היא אפשרית, אופטימיזציה ברמת ה-DESIGN זה כבר סיפור יותר מסובך, וגם REFACTORING צריך לדעת איך לעשות.

 

[Zack DA]

../images/Emo45.gif

 

[voguemaster]

צונאמי צודק

בהקשר של הקצאות דינמיות, יש מערכות שכתובות לא רק בצורה של OBJECT POOL אלא גם בצורה של GARBAGE COLLECTOR מסוים שבעצם מה שהוא עושה זה לשמור לו לעצמו את כל האובייקטים שהוקצו עד עכשיו באיזה list. כך מקצים מראש את כל האובייקטים (או את כל ה-OBJECT POOLS) ומשחררים בסוף. כלומר כל ההקצאה מבוצעת בהתחלה ואין לה יותר השפעה על הביצועים של התוכנית בהמשך. ככה כתובים משחקים, אגב.

 

[DadleFish]

../images/Emo13.gif אתה לא מדבר על RDO-ים במקרה,

נכון?

 

[voguemaster]

זרבסט הבהמה הזה

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

 

[DadleFish]

חחחחחח כן אה

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

 

[voguemaster]

אני יודע מה הוא כן המציא

IRenderableDeviceObject איזה פלצנות לשמה

 

[DadleFish]

לא בהכרח.

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

 

[צונאמי]

אפשר פירוט ?

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

 

[DadleFish]

תאר לך,

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