أداء ARM مقابل Thumb على iPhone 3GS، رمز النقطة غير العائمة

Question

كنت أتساءل عما إذا كان لدى أي شخص أي أرقام ثابتة على أداء رمز ARM مقابل Thumb على iPhone 3GS.خصيصًا لرمز النقطة غير العائمة (VFP أو NEON) - أنا على دراية بالمشكلات المتعلقة بأداء الفاصلة العائمة في وضع الإبهام.

هل هناك نقطة يصبح فيها حجم الكود الإضافي لتعليمات ARM الأكبر خطراً على الأداء؟بمعنى آخر، إذا كانت التعليمات البرمجية القابلة للتنفيذ صغيرة نسبيًا مقارنة بالذاكرة المتوفرة، فهل هناك أي منها؟ قياس فرق الأداء لتشغيل وضع الإبهام؟

سبب سؤالي هو أنه على الرغم من أنه يمكنني تمكين ARM لملفات المصدر المحددة لـ NEON في Xcode باستخدام خيار "-marm"، فإن هذا يكسر بنية Simulator لأن مجلس التعاون الخليجي يبني x86.كنت أتساءل ما إذا كان ينبغي عليّ إيقاف تشغيل "التجميع كإبهام" والانتهاء منه.

Answer 1

لا أعرف شيئًا عن iPhone ولكن التصريح الشامل بأن الإبهام أبطأ من ARM ليس صحيحًا على الإطلاق.نظرًا لذاكرة حالة الانتظار الصفرية بعرض 32 بت، سيكون الإبهام أبطأ قليلاً، مثل 5% أو 10%.الآن، إذا كانت قصة الإبهام 2 مختلفة، يُقال أن الإبهام 2 يمكن أن يعمل بشكل أسرع، ولا أعرف ما الذي يعتقده iPhone، أعتقد أنه ليس الإبهام 2.
إذا لم تكن ذاكرة 32 بت في حالة الانتظار الصفري على وشك النفاد، فستختلف النتائج.شيء واحد كبير هو ذاكرة واسعة 32 بت.إذا كنت تعمل على ناقل بعرض 16 بت مثل عائلة GameBoy Advance، وكانت هناك بعض حالات الانتظار على تلك الذاكرة أو ذاكرة القراءة فقط (ROM)، فيمكن بسهولة أن يتفوق الإبهام على تشغيل ARM للأداء على الرغم من أن الأمر يتطلب المزيد من تعليمات الإبهام لأداء نفس المهمة.

اختبار التعليمات البرمجية الخاصة بك!ليس من الصعب اختراع اختبار يقدم النتائج التي تهمك أم لا.من السهل إظهار أن الذراع تضرب الإبهام كما هو الحال مع الإبهام الذي يحرك الذراع بعيدًا.من يهتم بماهية أحجار الدريستون، ما يهم هو مدى سرعة تشغيل الكود الخاص بك اليوم.

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

إذا كنت تستخدم iPhone، سمعت أن هؤلاء الأشخاص يستخدمون LLVM؟أحب مفهوم llvm بعدة طرق وأتوق لاستخدامه كبرنامج تشغيل يومي عندما ينضج، لكنني وجدته ينتج كودًا أبطأ بنسبة 10-20% (أو أكثر بكثير) للمهمة المحددة التي كنت أقوم بها.كنت في وضع الذراع، ولم أحاول وضع الإبهام، وكان لدي ذاكرة تخزين مؤقت l1 وl2.لو قمت بالاختبار بدون ذاكرة التخزين المؤقت لمقارنة الإبهام بالذراع، فمن المحتمل أن أرى الإبهام أبطأ بنسبة قليلة في المائة، ولكن إذا فكرت في الأمر (وهو ما لم أكن مهتمًا به في ذلك الوقت) يمكنك تخزين رمز الإبهام مرتين أكثر من رمز الذراع الذي قد يشير ضمنًا إلى أنه على الرغم من وجود نسبة مئوية قليلة من التعليمات البرمجية بشكل عام للمهمة، فمن خلال تخزين المزيد منها مؤقتًا وتقليل متوسط ​​وقت الجلب، يمكن أن يكون أسرع بشكل ملحوظ.قد أضطر إلى الذهاب لمحاولة ذلك.

إذا كنت تستخدم llvm، فلديك مشكلة أخرى وهي وجود أماكن متعددة لإجراء التحسينات.بالانتقال من C إلى الرمز الثانوي، يمكنك التحسين، ويمكنك بعد ذلك تحسين الرمز الثانوي نفسه، ويمكنك بعد ذلك دمج كل الرمز الثانوي الخاص بك وتحسينه ككل، ثم عند الانتقال من رمز البايت إلى المجمّع، يمكنك التحسين.إذا كان لديك 3 ملفات مصدر فقط، وافترضت أن هناك مستويين فقط للتحسين لكل فرصة، هؤلاء لا يقومون بالتحسين أو التحسين، مع gcc سيكون لديك 8 مجموعات للاختبار، مع llvm يكون عدد التجارب أعلى تقريبًا من حيث الحجم .أكثر مما يمكنك تشغيله حقًا، مئات إلى آلاف.بالنسبة للاختبار الوحيد الذي كنت أجريه، لم أقم بتحسين خطوة C إلى كود البايت، ثم لم أقم بتحسين الكود الثانوي أثناء فصله، ولكن التحسين بعد دمج ملفات البايت كود في ملف واحد كبير (ger).أدى وجود شركة ذات مسؤولية محدودة (LLC) إلى التحسين في طريقها إلى تحقيق أفضل النتائج.

خلاصة القول...اختبار، اختبار، اختبار.

يحرر:

لقد كنت أستخدم كلمة bytecode، وأعتقد أن المصطلح الصحيح هو bitcode في عالم LLVM.الكود الموجود في ملفات .bc هو ما أعنيه...

إذا كنت تنتقل من C إلى ARM باستخدام LLVM، فهناك رمز البت (bc) في المنتصف.هناك خيارات سطر الأوامر لتحسين الخطوة من C إلى BC.مرة واحدة قبل الميلاد يمكنك تحسين كل ملف، قبل الميلاد إلى قبل الميلاد.إذا اخترت ذلك، يمكنك دمج ملفين أو أكثر من ملفات BC في ملفات BC أكبر، أو مجرد تحويل جميع الملفات إلى ملف BC واحد كبير.ثم يمكن أيضًا تحسين كل من هذه الملفات المدمجة.

نظريتي، التي تحتوي على حالتين فقط من حالات الاختبار حتى الآن، هي أنه إذا لم تقم بأي تحسين حتى يكون لديك البرنامج/المشروع بأكمله في ملف واحد كبير قبل الميلاد، فإن المحسن لديه الحد الأقصى من المعلومات التي يمكن استخدامها القيام بعملها.وهذا يعني الانتقال من C إلى BC بدون أي تحسين.ثم قم بدمج جميع ملفات BC في ملف BC واحد كبير.بمجرد حصولك على كل شيء كملف BC واحد كبير، دع المحسن يقوم بخطوة التحسين الخاصة به، مما يؤدي إلى تعظيم المعلومات وجودة التحسين.ثم انتقل من ملف BC المُحسّن إلى مُجمّع ARM.الإعداد الافتراضي لشركة llc هو تشغيل التحسين، فأنت تريد السماح بهذا التحسين لأنه الخطوة الوحيدة التي تعرف كيفية التحسين لتحقيق الهدف.تعد التحسينات من bc إلى bc عامة وليست مستهدفة محددة (AFAIK).

لا يزال يتعين عليك الاختبار، الاختبار، الاختبار.يمكنك المضي قدمًا وتجربة التحسينات بين الخطوات، ومعرفة ما إذا كان ذلك يجعل برنامجك يعمل بشكل أسرع أم أبطأ.

Answer 2

شاهد هذا قوات الدفاع الشعبي من الذراع / الإبهام للأداء / إخراج مقايض استهلاك الطاقة / استهلاك الطاقة.

التعشيد بتشكيل الملف الشخصي من الذراع وتعليمات الإبهام
- قسم علوم الكمبيوتر، جامعة أريزونا بقلم راجيف غوبتا

Answer 3

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

من الصعب إعطاء أرقام دقيقة بشأن اختلافات الأداء، لأنه يعتمد بالكامل على ما يفعله رمزك بالفعل.

يمكنك تعيين إشارات مترجم لكل بنية في Xcode، والتي من شأنها تجنب كسر بناء المحاكاة. انظر وثائق إعداد إنشاء XCODE.