פורסם 2011 בדצמבר 3013 שנים שלום לכולם,אני מתכנת (מאוד) מתחיל ב C#, יש לי טיפה רקע בC ובתיכנות למיקרו בקרים של 8 ביט.לכן יש לי הרגל ו"טיק" לנסות לכתוב קוד יעיל.היום כתבתי את הקוד הבא: private void button1_Click(object sender, EventArgs e) { byte[] data= new byte[256]; for (ushort i = 0; i < 256; i++) { data[i] = (byte)i; } CommHandler.EncodeManchester(data); stopWatch.Start(); for (ushort i = 0; i < 256; i++) { ushort crc=0; crc=crc16_update(crc, data[i]); } stopWatch.Stop(); stopWatch.Reset(); stopWatch.Start(); for (int i = 0; i < 256; i++) { int crc = 0; crc = crc16_update(crc, data[i]); } stopWatch.Stop(); } ushort crc16_update(ushort crc, byte a) { int i; crc ^= a; for (i = 0; i < 8; ++i) { if ((crc & 1)==1) crc = (ushort)((crc >> 1) ^ 0xA001); else crc = (ushort)(crc >> 1); } return crc; } int crc16_update(int crc, byte a) { int i; crc ^= a; for (i = 0; i < 8; ++i) { if ((crc & 1) == 1) crc = ((crc >> 1) ^ 0xA001); else crc = (crc >> 1); } return crc; }הפונקציה בעצם מחשבת CRC16 לבייט.כפי שרואים, כתבתי את הפונקציה ב2 גירסאות, אחת שמתמשת בכמות זכרון מנימלית שמתאימה לנתונים והשניה פשוט משתמשת בINT.מסתבר שחישוב הCRC למערך של 256 איברים לוקח פי 5 יותר זמן עם הפונקציה "החסכונית" (ushort).מה אני אמור להסיק מכך ? מעכשיו לא לחסוך במשאבים ?בנוסף, לא הצלחתי להבין למה הקומפיילר הכריח אותי לעשות casting ברוב המקרים, לדוגמה כאן:crc = (ushort)(crc >> 1); הטיפוס של crc הוא גם ככה ushort מזה אני אמור להסיק שהקבוע 1 הוא בעצם INT ? שערוריה !
פורסם 2011 בדצמבר 3013 שנים מייק, קודם כל אני לא מתכנת C#, ואני יודע בערך 0 על dot net... אז קח את התגובה בזהירות. אני כן אבל יודע ש C# תריץ את הקוד שלך על VM. וזה לרוב אומר שאין לך באמת שליטה על ההתנהגות מתחת למכסה, תמיד קח את זה בחשבון כשאתה כותב קוד רגיש לביצועים\זיכרון. תזכור גם שתמיד יש לך אפשרות לכתוב ב C וקרוא לקוד מתוך C# ( כלומר bindings ), זאת הגישה שעובדת ב python (אפילו לספריה הסטנדרטית) ,גם ב JAVA זה אפשרי. אני בטוח ש C# מאפשרת את זה. לגבי int vs short, אני מנחש שזה קשור למעבד שלך, יותר ספציפית לגודל המילה שלו. מעבדי 32 ביט ניגשים יותר מהר לזיכרון בקפיצות 32 ביט מקפיצות של 8 או 16. אגב בגלל זה הרבה פעמים ב C קומפיילרים דוחפים pad לתוך ה structים שלך... ולגבי צריכת זכרון, ממש לא הייתי דואג במקומך, קודם כל מערך של 256 נחשב קטן מאוד מאוד מאוד קטן. אם המכונה יכולה להריץ את ה VM היא גם תוכל להקצות לך את הגודל הזה על ה stack, מבטיח. ^ בתנאי כמובן שאתה לא עושה רקורסיה משוגעת שתופצץ את ה stack דבר שני, אתה הרי לא שומר את הזכרון, אתה מקצה ומחזיר בסוף הפונקציה. כלומר, אין לך השפעה על צריכת זיכרון לטווח הארוך.
פורסם 2011 בדצמבר 3113 שנים מחבר אני יודע אני לא אבחין בהבדל ביצועים בכל דרך שאני אכתוב את התוכנית שלי (הפרוייקט הנוכחי לפחות), אפילו אם אשתמש בdecimal בשביל לקדם לולאה או כל בזבוז אחר. כפי שכבר ציינתי זה יותר "טיק" או איזה הפרעה נפשית שגורמת לי לרצות לכתוב קוד יעיל ככל האפשר.
פורסם 2011 בדצמבר 3113 שנים אה אוקי, אני יש לי את מחלת ה"ההאקים המאגניבים", עם הזמן אני משתקם ונגמל... ואולי יום אחד אני עוד אכתוב קוד נטול WTFים
פורסם 2011 בדצמבר 3113 שנים C# היא שפה מנוהלת, אם אתה רוצה קוד יעיל ברמה של זכרון תחזור לC או אסמבלי, C# נועדה לחסוך ממך את השטויות האלו של התעסקות בכמה זיכרון כל אובייקט לוקח.מן הסתם אם תאנוס את הזיכרון זה יהיה מורגש, אבל אם תחליף בין intים לushortים לא תרגיש כלום/ תמנע מהקומפילר לעשות את האופטימיציות שלו ותכריח אותו להשתמש בסוג שהוא לאו דווקא היעיל ביותר. (במיוחד אם יש casting שזו אחת הפעולות היקרות בכל שפת תכנות)בכ"מ כדי לסגור את הפינה, חוץ ממתי שעשיתי קריאות לקוד לא מנוהל לא ראיתי צורך להשתמש במשהו אחר מint, תן לוודו של הJIT לעשות את שלו.
פורסם 2011 בדצמבר 3113 שנים (במיוחד אם יש casting שזו אחת הפעולות היקרות בכל שפת תכנות)זה כבר לגמרי תלוי בשפה ואופרנדים ל cast. יש שפות כמו C++ עם מספר סוגי casting, כמו static cast.ובכלל cast של primitives לרוב אמור להיות די זול, במיוחד בין אותם סוגי נתונים.
ארכיון
דיון זה הועבר לארכיון ולא ניתן להוסיף בו תגובות חדשות.