קרנל ו-++C...

[אלדד28]

חבל שאנשים פה לא מדייקים.

++C מעניקה כלים מסוימים לתוכניתן. לשם הדוגמה, ניקח את VTBL. אם היה בא תוכניתן ומפתח את הכלי הזה בכוחות עצמו, זה ככל הנראה היה יוצא פחות יעיל מאשר שימוש ב-VTBL ב-++C. למה? כי הקומפיילר יודע שזה VTBL וזה משהו מיוחד ואפשר לעשות כך וכך אופטימיזציות, וכו'. כל זה נכון וטוב ויפה. אבל אם לא משתמשים ב-FEATURE-ים האלו ספציפית, אבל כן משתמשים ב-FEATURE-ים אחרים (כמו שהדגמתי עם string), אז התוכנית תהיה יותר איטית. משהו גנרי (שכתוב בצורה מושלמת) תמיד יהיה פחות מהיר ממשהו ספציפי (שכתוב בצורה מושלמת). השאלה היא, מה הגנריות הזו נותנת, וכמה המהירות יורדת. זה הכל.

 

[זהיר]

נכון - חבל שאתה לא מדייק

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

 

[אלדד28]

אתה צריך להיות יותר זהיר,

כי להיות מדויק אתה בטוח לא. אני הוכחתי את טענתי בדוגמה המספרית שנתתי לאייל. המאמר של S מדויק לחלוטין לטעמי, וארז כבר שלושה ימים במחזור וטוען על כל דבר שהוא שטויות. העניין הוא שהמאמר הנ"ל מתמקד ב-STL. ואכן, אין הרבה סיכוי לנצח את STL. אבל אני לא מדבר על STL, אלא על השפה כמכלול. בעקרון, ++C יותר איטית מ-C. אלא שככל שהתוכנה משתמשת ביותר FEATURE-ים, כך הולך וקטן הפרש הביצועים ביניהן, כי כל FEATURE של ++C שלא קיים ב-C צריך להיות מפותח על ידי התוכניתן, ובהכרח יהיה נחות ל-FEATURE שמוכר ומאופטמז על ידי ה-COMPILER.

 

[זהיר]

נדמה לי שהחמצת נקודה חשובה

במאמר של STROUSTRUP. אמנם הוא מדבר על STL אבל הייתרון של ++C בדוגמות שלו הוא INLINE מסוג ש C לא תוכל לעשות אף פעם (גם עם מנגנון ה INLINE שהוא רשמי החל מ C99): הדרך היחידה לממש קוד גנרי ב C היא ע"י מצביעים לפונקציות. אבל הסיכוי שהפונקציה הכללית תהפוך ל INLINE יחד עם הפונקציה המוצבעת הוא בעצם 0. לעומת זאת, ב ++C שמאפשרת FUNCTIONAL OBJECTS זה דבר טריוויאלי. תכנתו בזהירות

 

[אלדד28]

על זה אני מסכים, כמובן -

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

 

[eyalbd]

אתה מתכוון ל abstraction penalty

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

 

[אלדד28]

אני אומר דבר מאוד פשוט,

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

 

[MotiAd]

תודה רבה רבה חברה.!!!!...

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