سؤال

بالنظر إلى أنك تحاول فقط التحسين للسرعة ، ما هي الاستدلال الجيد لتحديد ما إذا كنت ستحدد وظيفة أم لا؟ من الواضح أن حجم الكود يجب أن يكون مهمًا ، ولكن هل هناك أي عوامل أخرى تستخدم عادةً عندما تحدد (SAIN) GCC أو ICC ما إذا كنت تريد وضع مكالمة وظيفية؟ هل كان هناك أي عمل أكاديمي كبير في المنطقة؟

هل كانت مفيدة؟

المحلول

ويكيبيديا أ قليل فقرات حول هذا الموضوع ، مع بعض الروابط في الأسفل:

  • بالإضافة إلى حجم الذاكرة وذاكرة التخزين المؤقت ، اعتبار آخر هو تسجيل الضغط. من وجهة نظر المترجم "قد تستهلك المتغيرات المضافة من الإجراء المضمّن سجلات إضافية ، وفي منطقة يكون فيها ضغط التسجيل مرتفعًا بالفعل ، قد يفرض هذا الانسكاب ، مما يسبب وصولًا إضافيًا ذاكرة الوصول العشوائي."

تحتوي اللغات التي تحتوي على مجمعين JIT وتحميل فئة وقت التشغيل إلى مقايضات أخرى لأن الأساليب الافتراضية غير معروفة بشكل ثابت ، ومع ذلك يمكن لـ JIT جمع معلومات التنميط في وقت التشغيل ، مثل تردد استدعاء الطريقة:

  • تصميم وتنفيذ وتقييم التحسينات في برنامج التحويل البرمجي في الوقت المناسب (بالنسبة لـ Java) يتحدث عن طريقة تضم الأساليب الثابتة والفئات المحملة ديناميكيًا وتحسيناتها على الأداء.

  • ممارسة الجودو: جافا تحت تحسينات ديناميكية يدعي أن "سياسة التحديد الخاصة بهم تعتمد على حجم الكود ومعلومات التنميط. إذا كان تردد تنفيذ إدخال الطريقة أقل نحن لا ندخل طريقة بحجم بايت من أكثر من 25 بايت ... لتجنب الإطار على طول سلسلة مكالمات عميقة ، يتوقف عند التوقف عندما يتجاوز حجم البايت المتراكم على طول سلسلة المكالمات 40 بايت. " على الرغم من أن لديهم معلومات التنميط في وقت التشغيل (تردد استدعاء الطريقة) ، إلا أنها لا تزال حريصة على تجنب ضم وظائف أو سلاسل وظائف كبيرة لمنع الانتفاخ.

بحث على الباحث العلمي من Google يكشف عن عدد من الأوراق ، مثل

بحث على كتب Google يكشف عن عدد لا بأس به من الكتب التي تحتوي على أوراق أو فصول حول الوظيفة التي تضم في سياقات مختلفة.

  • دليل تصميم المترجم: التحسينات وتوليد رمز الجهاز لديه فصل حول تقنيات التعلم الإحصائي والآلي في تصميم التحويل البرمجي ، مع الاستدلال لوضع معلمات مختلفة ، والتوصيف النتائج. يشير هذا الفصل إلى ورقة فاسواني وآخرون النماذج التجريبية الحساسة للهندسة المعمارية الدقيقة لتحسين البرمجيات حيث يقترحون "استخدام تقنيات النمذجة التجريبية لبناء النماذج الحساسة للهندسة المعمارية الدقيقة لتحسينات البرمجيات".

  • (تتحدث بعض الكتب الأخرى عن Inling من وجهة نظر المبرمج ، مثل C ++ لمبرمجي اللعبة, ، الذي يتحدث عن مخاطر وظائف التحديد في كثير من الأحيان والاختلافات بين الإضفاء غالبًا ما يتجاهل المجمعون طلبات المبرمج المضمّنة إذا تمكنوا من تحديد أنهم سيؤذيون أكثر مما ينفع ؛ يمكن التغلب على هذا مع وحدات الماكرو كملاذ أخير.)

نصائح أخرى

تتضمن استدعاء الوظيفة بعض التعليمات البرمجية الإضافية (مقدمة الوظيفة ، حيث يتم إعداد إطار المكدس الجديد ، و epilogue الوظيفة ، حيث يتم تنظيفه). إذا رأى المترجم الخاص بك أن رمز الوظيفة صغير بالمقارنة مع المقدمة والخاتبة ، فيمكنه أن يقرر أنه لا يستحق إجراء مكالمة فعلية ، وسيقوم بتضمين الوظيفة.

الفائدة الوحيدة التي أراها هي استدعاء وظيفة بدلاً من إطارها مرتبطة بالحجم. أعتقد أن ضم وظيفة ما ، ثم يمكن أن يؤدي إلغاء حلقة إلى زيادة كبيرة في الحجم.

بقدر ما رأيت ، حجم الوظيفة هو العامل الوحيد المجمعين المستخدمة لتحديد مضمّنة. ومع ذلك ، إذا قمت بإجراء تحسين موجه ملف تعريف ملف تعريف (PGO) ، أعتقد أن برنامج التحويل البرمجي قادر على استخدام متغيرات أخرى ، مثل عدد المكالمات/وقت إعداد المكالمات.

في .NET يعتمد في الغالب على الحجم. قياس حجم وظيفة الوالد ووظيفة الطفل في بايت المترجمة. ثم قياس حجم الوظيفة المشتركة. إذا كانت الوظيفة المشتركة أصغر ، فإن الإطار هو فكرة جيدة.

والسبب في ذلك هو جعل من الممكن دفع أكبر قدر ممكن من التعليمات البرمجية في ذاكرة التخزين المؤقت لوحدة المعالجة المركزية. تخطئ ذاكرة التخزين المؤقت هي أغلى بكثير من مكالمات الوظائف في وحدات المعالجة المركزية الحديثة.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top