VB.NET

Flexibal

New member
VB.NET

עד אתמול עוד החזקתי מ DOTNET, אמרו, "נכון שזה מכונה וירטואלית, אבל זה מתקמפל לקוד מכונה מקומי אחרי ההרצה הראשונה" וכו', ויש גם אופטימייזרים... רק 15% יותר איטי מקוד מקומי... הקיצר, אני כותב את הקוד הבאה:
dim i as integer i=8 for... i/=2 next​
זה טוען מקובץ דברים וכו', לא משנה. השורה i/=2 היא זו החשובה כאן. עקרונית, קומפיילר של C או כל דבר עם אופטימייזר נורמלי, היה עושה:
mov eax, shr eax, 1 mov , eax

אבל כאן, לא ולא. בכוונה תחילה שמתי STOP בלולאה, וביקשתי שיציג לי את ה DISASSEMBLY של הקוד שרץ. עבור השורה הזאת בלבד היו שם 9 שורות, חילוק FLOAT וחזרה ל INTEGER, ואפילו קריאה לפונקציה! על כל חילוק הוא שם קריאה לפונקציה! באמת! הרי i הוא INTEGER, החילוק בכל מקרה יתעגל ל INTEGER, אז למה FLOAT? אז נכון שהקופניג של הפורייקט היה DEBUG, אבל גם כשהעברתי אותו ל RELEASE, ביטלתי את ההגדרה של DEBUG ו TRACE, ביטלתי בדיקת חריגות של INTEGER, ואיפשרתי אופטימיזציות, קיבלתי את אותו הקוד. בסופו של יום - זה מוות קליני. אני מסכים שקוד מכונה וירטואלי לא יכול לעשות שימוש ברגיסטרים של המכונה, בקוד עצמו -- אבל כשה JIT הופך אותו ל NATIVE CODE, למה לא? ובסך הכל, אין פה איזה גאונות, חילוק בשתיים (קבוע) אפשר לעשות עם SHR, וגם עם DIV זה יותר זול מ FDIV, אז למה לעזאזל? סתם כי בא לי לדבר. -תומר
 

MotiAd

New member
קשה לי להבין למה איך וכמה?...

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

Flexibal

New member
טוב

אני עובד עם FRAMEWORK 1.1, VS2002, לא ה 2003 או ה 2004 הממשמש ובא... בקשר לאידיאולוגיה של שפה מסויימת -- תראה, הקוד מתקפמל ל BYTECODE, כלומר, אותו קוד ש VB מייצר, מייצר גם C#, והמנוע שמריץ את זה צריך לקמפל לקוד מכונה אמיתי. בלי קשר -- לינוקס -- הם יכלו לתמוך ב UNICODE מלכתחילה. וכן, אני נשאר אופטימי :) כשאני צריך לבדוק איזה אלגוריתם ולא בא לי להתחיל לנהל זיכרון או להתרקס בגלל ששכחתי איזה פסיק ב MALLOC, אני עובד עם DOTNET. ובגלל שאת ג'אווה אני שונא יותר, אני בוחר באלטרנטיבה היותר טובה. אז כן, אני נשאר אופטימי. -תומר
 

voguemaster

New member
האמת

גם הקוד באמסמבלי שרשמת לא ממש יעיל, אפשר לעשות את זה הרבה יותר טוב
בכל אופן, אני לא בדקתי ולא ראיתי בדיקות של איך ממומש אותו הדבר בג'אווה ואיך ה-JIT של ג'אווה מקמפל ל-native אז אין ממש מקום להשוואה. אני רק אגיד: אם אתה שונא ג'אווה אתה גם שונא $C. נראה לי קצת מוזר לא ?
 

אלדד28

New member
שאלת תם ../images/Emo8.gif

אם הקוד "מתקמפל ל-NATIVE אחרי ההרצה הראשונה", למה הוא צריך להיות יותר איטי מהקוד המקומי?
 

MotiAd

New member
זה עדיין בחיתולים שלו...

וחבל שקח. יש להם הרבה מאוד לטפל בכל מה שקשור לאופטימיזציות של הקוד ובייעול של הקוד שנוצר. ד"א הקוד לא איטי בכלל. ממש לא. וחוץ מזה הוא הרי טוען חלק מהמנועים שלו (system.dll, system.drawing.dll) וכו'. להשוואה אני יכול לתת לך את VB.NET מול VC++ באפליקציה מאוד עצבנית שכתבתי ב- DX לפי בדיקה שלי ושל הקוד ב-DX מספר ה-FPSים שווה לחלוטין. רק ב-$c (אני אשאר נאמן להחלטה שלכם) הביצועים ירדו פלאים בכמה FPSים לא מבוטלים בכלל. (7 או 10 אפילו יותר) שווה לבדוק למה. לא בראש מעיני עכשיו. שלכם, מוטי.
 
למעלה