ميزات برامج ملفات التعريف في C ++

في بعض الأحيان ، قد يكون من الضروري تحديد أداء البرنامج أو استهلاك الذاكرة في برنامج C ++. لسوء الحظ ، في كثير من الأحيان هذا ليس سهلا كما قد يبدو.

سننظر هنا في ميزات برامج ملفات التعريف باستخدام أدوات valgrind و google perftools . تحولت المادة إلى أنها ليست منظمة للغاية ، بل هي محاولة لتجميع قاعدة معرفية "للأغراض الشخصية" بحيث لا يتعين عليك في المستقبل أن تتذكر "لماذا لا ينجح هذا" أو "كيفية القيام بذلك". على الأرجح ، لن تتأثر جميع الحالات غير الواضحة هنا ، إذا كان لديك شيء تضيفه ، فالرجاء كتابة التعليقات.

جميع الأمثلة سوف تعمل على نظام لينكس.

وقت التشغيل التنميط

تدريب

لتحليل ميزات التوصيف ، سأقوم بتشغيل برامج صغيرة ، تتكون عادةً من ملف main.cpp وملف func.cpp واحد مع التضمين.
سوف أجمعها مع برنامج التحويل البرمجي g ++ 8.3.0 .

نظرًا لأن إنشاء ملفات غير محسّنة مهمة غريبة إلى حد ما ، فسنقوم بتجميع خيار -Ofast ، ومن أجل الحصول على أحرف تصحيح الأخطاء في الإخراج ، لن ننسى إضافة خيار -g . ومع ذلك ، في بعض الأحيان بدلاً من أسماء الوظائف العادية ، يمكنك رؤية عناوين المكالمات غير المسموعة فقط. هذا يعني أنه كان هناك "توزيع عشوائي لتخصيص مساحة العنوان". يمكن تحديد ذلك عن طريق استدعاء الأمر nm على ثنائي. إذا كانت معظم العناوين تبدو مثل هذا 00000000000030e0 (عدد كبير من الأصفار في البداية) ، فمن المرجح أن هذا هو. في البرنامج العادي ، تبدو العناوين مثل 0000000000402fa0. لذلك ، تحتاج إلى إضافة الخيار -no-pie . نتيجة لذلك ، ستبدو المجموعة الكاملة للخيارات كما يلي:
-Ofast -g -no-pie

لعرض النتائج ، سوف نستخدم برنامج KCachegrind ، والذي يمكنه العمل مع تنسيق تقرير callgrind

Callgrind

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

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




نقوم بتجميع البرنامج ، وتشغيل valgrind على النحو التالي:

 valgrind --tool=callgrind ./test_profiler 100000000 

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

لإصلاح ذلك ، عند بدء تشغيل البرنامج ، تحتاج إلى تعيين متغير LD_BIND_NOW على 1 ، مثل هذا:

 LD_BIND_NOW=1 valgrind --tool=callgrind ./test_profiler 100000000 

والآن ، كما ترون ، كل شيء على ما يرام

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

لنلقِ نظرة على هذا الكود:

 int func(int arg) { int fst = 1; int snd = 1; std::ofstream file("tmp.txt"); for (int i = 0; i < arg; i++) { int res = (fst + snd + 1) % 19845689; std::string r = std::to_string(res); file << res; file.flush(); fst = snd; snd = res + r.size(); } return fst; } 

أضفت هنا كمية صغيرة من البيانات إلى ملف لكل تكرار للحلقة. بما أن الكتابة إلى ملف هي عملية طويلة إلى حد ما ، كوزن موازن ، أضفت خطًا من رقم إلى كل تكرار للحلقة. من الواضح ، في هذه الحالة ، تستغرق عملية الكتابة إلى الملف وقتًا أطول من باقي منطق الوظيفة. لكن callgrind يفكر بطريقة مختلفة:


يجدر أيضًا مراعاة أن callgrind يمكنه فقط قياس تكلفة وظيفة عندما تعمل. لا تعمل الوظيفة - وبالتالي ، لا تزيد التكلفة. يؤدي هذا إلى تعقيد تصحيح البرامج التي تدخل القفل من وقت لآخر أو تعمل مع نظام / شبكة لحظر الملفات. لنفحص:

 #include "func.h" #include <mutex> static std::mutex mutex; int funcImpl(int arg) { std::lock_guard<std::mutex> lock(mutex); int fst = 1; int snd = 1; for (int i = 0; i < arg; i++) { int res = (fst + snd + 1) % 19845689; fst = snd; snd = res; } return fst; } int func2(int arg){ return funcImpl(arg); } int func(int arg) { return funcImpl(arg); } int main(int argc, char **argv) { if (argc != 2) { std::cout << "Incorrect args"; return -1; } const int arg = std::atoi(argv[1]); auto future = std::async(std::launch::async, &func2, arg); std::cout << "result: " << func(arg) << std::endl; std::cout << "second result " << future.get() << std::endl; return 0; } 

هنا قمنا بتضمين تنفيذ الوظيفة بالكامل في قفل mutex ، وسميت هذه الوظيفة من خيطين مختلفين. يمكن التنبؤ بنتيجة callgrind تمامًا - فهو لا يرى مشكلة في التقاط كائن مزامنة:


لذلك ، درسنا بعض مشاكل استخدام منشئ ملفات التعريف callgrind. دعنا ننتقل إلى موضوع الاختبار التالي - ملف تعريف google perftools

جوجل perftools

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

لنبدأ بالتوصيف على البرنامج الأول مع مكتبتين.

كقاعدة عامة ، للبدء في إنشاء ملفات تعريف باستخدام هذه الأداة ، يجب عليك تحميل مكتبة libprofiler.so مسبقًا وتعيين تردد أخذ العينات وتحديد ملف لحفظ التفريغ. لسوء الحظ ، يتطلب الملف التعريفي إنهاء البرنامج "من تلقاء نفسه". سيتسبب الإنهاء القسري للبرنامج في عدم إلقاء التقرير. هذا غير مريح عند تحديد برامج طويلة العمر لا تتوقف في حد ذاتها ، مثل الشياطين. للتغلب على هذه العقبة ، قمت بإنشاء هذا البرنامج النصي:


يجب تشغيل هذه الأداة المساعدة ، لتمرير اسم الملف القابل للتنفيذ وقائمة المعلمات الخاصة به كمعلمات. أيضًا ، من المفترض أن بجانب الملفات النصية الملفات التي يحتاجها libprofiler.so و pprof. إذا كان البرنامج طويل العمر وتوقف عن طريق مقاطعة التنفيذ ، يجب عليك تعيين المتغير N_STOP إلى صواب ، على سبيل المثال ، مثل هذا:

 N_STOP=true ./gprof.sh ./test_profiler 10000000000 

في نهاية العمل ، سينشئ النص تقريرًا بتنسيق callgrind المفضل لدي.

لذلك ، دعونا ندير برنامجنا تحت هذا التعريف.

 ./gprof.sh ./test_profiler 1000000000 

من حيث المبدأ ، كل شيء واضح جدا.

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

 int runExcept(int res) { if (res % 13 == 0) { throw std::string("Exception"); } return res; } int func(int arg) { int fst = 1; int snd = 1; for (int i = 0; i < arg; i++) { int res = (fst + snd + 1) % 19845689; try { res = runExcept(res); } catch (const std::string &e) { res = res - 1; } fst = snd; snd = res; } return fst; } 

وتشغيل التنميط. البرنامج يتجمد بسرعة كبيرة.

هناك مشكلة أخرى تتعلق بخصوصية عملية المحلل. لنفترض أننا نجحنا في فك المكدس ، والآن نحن بحاجة إلى مطابقة العناوين مع الوظائف المحددة للبرنامج. يمكن أن يكون هذا غير تافه للغاية ، لأنه في C ++ هناك عدد كبير إلى حد ما من الوظائف مضمنة. دعونا نلقي نظرة على مثال مثل هذا:

 #include "func.h" static int func1(int arg) { std::cout << 1 << std::endl; return func(arg); } static int func2(int arg) { std::cout << 2 << std::endl; return func(arg); } static int func3(int arg) { std::cout << 3 << std::endl; if (arg % 2 == 0) { return func2(arg); } else { return func1(arg); } } int main(int argc, char **argv) { if (argc != 2) { std::cout << "Incorrect args"; return -1; } const int arg = std::atoi(argv[1]); int arg2 = func3(arg); int arg3 = func(arg); std::cout << "result: " << arg2 + arg3; return 0; } 

من الواضح ، إذا قمت بتشغيل البرنامج على سبيل المثال مثل هذا:

 ./gprof.sh ./test_profiler 1000000000 

ثم لن يتم استدعاء الدالة func1. لكن المحلل يفكر بطريقة مختلفة:

(بالمناسبة ، قرر valgrind هنا التزام الصمت بشكل متواضع وعدم تحديد الوظيفة المحددة التي جاءت منها المكالمة).

التنميط الذاكرة

غالبًا ما تكون هناك مواقف عندما تتدفق الذاكرة من التطبيق في مكان ما. إذا كان هذا بسبب نقص تنظيف الموارد ، فيجب أن تساعد Memcheck في تحديد المشكلة. لكن في C ++ الحديثة ، ليس من الصعب الاستغناء عن الإدارة اليدوية للموارد. unique_ptr، shared_ptr، vector، map تجعل التلاعب بالنقاط المجردة بلا فائدة.

ومع ذلك ، في مثل هذه التطبيقات ، يحدث تسرب للذاكرة. كيف الحال؟ بكل بساطة ، كقاعدة عامة ، هو شيء مثل "ضع القيمة في خريطة طويلة العمر ، ولكن نسيت حذفها". دعونا نحاول تتبع هذا الموقف.

للقيام بذلك ، نعيد كتابة وظيفة الاختبار الخاصة بنا بهذه الطريقة

 #include "func.h" #include <deque> #include <string> #include <map> static std::deque<std::string> deque; static std::map<int, std::string> map; int func(int arg) { int fst = 1; int snd = 1; for (int i = 0; i < arg; i++) { int res = (fst + snd + 1) % 19845689; fst = snd; snd = res; deque.emplace_back(std::to_string(res) + " integer"); map[i] = "integer " + std::to_string(res); deque.pop_front(); if (res % 200 != 0) { map.erase(i - 1); } } return fst; } 

هنا ، في كل تكرار ، نضيف بعض العناصر إلى الخريطة ، وننسى أنه في بعض الأحيان يتم حذفها من هناك عن طريق الصدفة (صحيح ، صحيح). أيضا ، لتجنب عيوننا ، نحن التعذيب الأمراض المنقولة جنسيا :: deque قليلا.

سنلتقط تسريبات الذاكرة باستخدام أداتين - valgrind massif و google heapdump .

المسيف الجزء الرئيسي من جبل

قم بتشغيل البرنامج باستخدام هذا الأمر

 valgrind --tool=massif ./test_profiler 1000000 

ونحن نرى شيئا مثل


يمكن أن نرى أن كتلة صخرية كانت قادرة على اكتشاف تسرب في الوظيفة ، لكن حتى الآن لم يتضح أين. دعنا نعيد بناء البرنامج مع العلم -fno-inline وتشغيل التحليل مرة أخرى


أصبح من الواضح الآن مكان التسرب في إضافة عنصر الخريطة. يمكن لـ Massif اكتشاف أشياء قصيرة العمر ، لذا فإن التلاعب بالأمراض المنقولة جنسياً :: deque غير مرئي في هذا التفريغ.

Heapdump

لكي يعمل google heapdump ، يلزمك ربط مكتبة tcmalloc أو تحميلها مسبقًا . تحل هذه المكتبة محل الوظائف المعيارية لتخصيص الذاكرة malloc ، مجانًا ، ... كما يمكنها جمع معلومات حول استخدام هذه الوظائف ، والتي سنستخدمها عند تحليل البرنامج.

نظرًا لأن هذه الطريقة تعمل ببطء شديد (حتى بالمقارنة مع الكتلة) ، فإنني أوصيك بتعطيل تجميع الوظائف على الفور باستخدام الخيار -fno -line عند التحويل البرمجي. لذلك ، نحن نعيد بناء طلبنا ونعمل مع الفريق

 HEAPPROFILESIGNAL=23 HEAPPROFILE=./heap ./test_profiler 100000000 

هنا يفترض أن مكتبة tcmalloc مرتبطة بطلبنا.

الآن ، ننتظر بعض الوقت اللازم لتشكيل تسرب ملحوظ ، ونرسل إلى العملية إشارة 23

 kill -23 <pid> 

نتيجة لذلك ، يظهر ملف يسمى heap.0001.heap ، نقوم بتحويله إلى تنسيق callgrind باستخدام الأمر

 pprof ./test_profiler "./heap.0001.heap" --inuse_space --callgrind > callgrind.out.4 

أيضا الانتباه إلى خيارات pprof. يمكنك الاختيار من بين الخيارات inuse_space أو inuse_objects أو custom_space أو custom_objects ، والتي تعرض المساحة أو الكائنات المستخدمة ، أو المساحة والكائنات المخصصة لكامل مدة البرنامج ، على التوالي. نحن مهتمون بخيار inuse_space ، والذي يعرض مساحة الذاكرة المستخدمة حاليًا.

فتح kCacheGrind المفضلة لدينا ونرى

الأمراض المنقولة جنسيا :: خريطة قد أكلت الكثير من الذاكرة. ربما تسرب فيه.

النتائج

التوصيف في C ++ مهمة صعبة للغاية. هنا يتعين علينا التعامل مع الدوال المضمنة ، والتعليمات غير المدعومة ، والنتائج غير الصحيحة ، إلخ. ليس من الممكن دائمًا الوثوق بنتائج ملف التعريف.

بالإضافة إلى الوظائف المقترحة أعلاه ، هناك أدوات أخرى مصممة للتنميط - perf و intel VTune وغيرها. لكنها تظهر أيضا بعض هذه العيوب. لذلك ، لا تنسى طريقة "الجد" الخاصة بالتوصيف عن طريق قياس وقت تنفيذ الوظائف وعرضها في السجل.

أيضا ، إذا كان لديك تقنيات مثيرة للاهتمام لتعريف رمز الخاص بك ، يرجى نشرها في التعليقات