Comments on: C יותר מהירה מJava

By: סשה

סשה — Tue, 08 Jul 2008 05:07:05 +0000

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

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

By: עמרי

עמרי — Sun, 06 Jul 2008 13:29:43 +0000

גרשון, נכון. ולכן המכונה עם שתי הליבות המהירות נתנה ביצועים יותר טובים מהמכונה עם ארבע הליבות האיטיות.
מה אתה רוצה להגיד?

By: גרשון בבולה

גרשון בבולה — Sun, 06 Jul 2008 11:42:20 +0000

שתי ליבות, ארבע ליבות, שבע עשרה ליבות - הקוד שלך רץ עם פתיל אחד!

מעניין לנסות על JVM-ים אחרים, שלחלקם מוניטין יותר טובים משל Hotspot.

By: עמרי

עמרי — Thu, 26 Jun 2008 21:14:42 +0000

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

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

By: מרק ק.

מרק ק. — Thu, 26 Jun 2008 11:47:08 +0000

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

By: עמרי

עמרי — Thu, 26 Jun 2008 10:03:30 +0000

מרק, ראה עדכון נוסף בפוסט.

By: מרק ק.

מרק ק. — Thu, 26 Jun 2008 08:41:55 +0000

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

By: עמרי

עמרי — Thu, 26 Jun 2008 08:29:21 +0000

מרק, ראה עדכון בפוסט.

By: עמרי

עמרי — Thu, 26 Jun 2008 08:17:01 +0000

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

By: מרק ק.

מרק ק. — Thu, 26 Jun 2008 08:06:17 +0000

אה, אולי יש מקרים שזה נכון שjava יותר מהירה, אבל זה לא המקרה.

ראשית כתבת קוד C כאילו שזה JAVA, שזו כמובן הדרך הלא נכונה…
1. אין שום סיבה לעשות אלוקציה מהזיכרון בשביל מערך מקומי בפונקציה, אלוקציה כזו עושים על הסטאק.
2. משתני INT שנעשה בהם שימוש כלכך מסיבי צריך לבקש שישבו ברגיסטר
3. לא קימפלת עם אופטימיזציה. אני לא זוכר אם האופציות הבסיסיות של GCC מקמפלות עם אינפורמצית דיבוג או לא, אבל אחרי שנגמר שלב הדיבוג, תוכנות C מקמפלים עם אופטימיצזיה.

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

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