تحليل أداء التعددية الثابتة في C++ باستخدام Boost Variant وطرق التصفية المختلفة

في هذا المقال، سنقوم بفحص ومقارنة أداء ثلاثة أساليب لتحقيق التعددية في لغة البرمجة C++، وذلك باستخدام boost variants وزيارات متعددة. الأساليب المدروسة هي:

1. Static Polymorphism باستخدام boost variants مع زائر منفصل لكل طريقة:
   في هذه الطريقة، تم استخدام boost variants لتمثيل مجموعة متنوعة من الأشكال، وتم إنشاء زائر (visitor) منفصل لكل طريقة معينة (rotate و spin).

2. Static Polymorphism باستخدام boost variants مع زائر واحد يستخدم تحميل الطريقة المختلفة:
   في هذه الطريقة، تم استخدام boost variants أيضًا، ولكن تم إنشاء زائر واحد يستخدم تقنية تحميل الطريقة المختلفة (method overloading) لاستدعاء الطريقة المناسبة.

3. Dynamic Polymorphism الكلاسي:
   تم استخدام التعددية الديناميكية الكلاسيكية باستخدام وظائف افتراضية في الواجهة الخاصة بالأشكال.

المنصة والأدوات المستخدمة:

• المنصة: Intel x86 64 بت، Red Hat، معالج متعدد النوى، 32 غيغابايت من الذاكرة العشوائية.
• المترجم: GCC 4.8.1 مع تحسين -O2.
• Boost: الإصدار 1.6.0.

النتائج الأولية:

• أظهرت النتائج أن الطريقة الأولى (Static Polymorphism مع زائر منفصل لكل طريقة) كان لديها أداءًا أفضل بشكل ملحوظ من الطريقتين الأخريين.
• كما لوحظ أن الطريقة الديناميكية (Dynamic Polymorphism) كانت تفوق غالبًا على الطريقة الثانية (Static Polymorphism مع زائر واحد يستخدم تحميل الطريقة المختلفة).

تحليل الأداء:

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

السؤال:

• يتساءل الكاتب عن سبب أداء الطريقة الثانية (Static Polymorphism مع زائر واحد يستخدم تحميل الطريقة المختلفة) الذي كان أداءه أسوأ من الطريقة الديناميكية، حيث كان من المتوقع أن يكون التعددية الثابتة تفوق التعددية الديناميكية.

تحليل السؤال:

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

الختام:

• يجب مواصلة التجارب وفحص الكود بمزيد من التفصيل لفهم تفاصيل الأداء والتأثيرات الدقيقة.
• يمكن استكشاف تحسينات إضافية في الكود لتحسين أداء الطرق المختلفة.
• قد يكون من المفيد استخدام أدوات تحليل الأداء لتحديد النقاط الساخنة وتحسينها.

في هذا السياق، يتم استعراض أداء ثلاثة أساليب لتحقيق التعددية في لغة C++، حيث يتم التركيز على استخدام مكتبة Boost variant لتحقيق التعددية الثابتة (Static Polymorphism) والتعددية الديناميكية (Dynamic Polymorphism). تُظهر الطرق الثلاثة كالآتي:

1. Static Polymorphism using Boost Variants with Separate Visitor for Each Method (Method [1]):
   يتم استخدام مكتبة Boost variant مع إنشاء مستندات فرعية (visitors) منفصلة لكل طريقة (rotate و spin).

2. Static Polymorphism using Boost Variants with Single Visitor using Method Overloading (Method [2]):
   يتم استخدام مكتبة Boost variant أيضًا، ولكن هنا يتم استخدام مستند (visitor) واحد يستخدم تقنية التحميل الزائد (method overloading) لاستدعاء الوظائف المختلفة (rotate و spin).

3. Dynamic Polymorphism (Method [3]):
   تُستخدم وظائف افتراضية في واجهة IShape لتحقيق التعددية الديناميكية.

تمت ملاحظة بعض النتائج الهامة من هذه المقارنة:

• يظهر أن Method [1] يتفوق بشكل كبير على Methods [2] و [3].
• Method [3] يتفوق على Method [2] في معظم الحالات.

المبرر الذي قدمه السائل يتعلق بأداء Method [2]، حيث يتوقع أن يكون التعدد الثابت أفضل أداءًا من التعدد الدينامي. ومع ذلك، يشير إلى أن Method [2] يظهر أداءً أقل من التعدد الدينامي. يعزى هذا إلى تكلفة البارامتر الإضافي الذي يتم تمريره في Method [2] لتحديد أي visit() يجب استدعاؤه، وربما بعض التفرعات الإضافية نتيجة لتقنية التحميل الزائد.

يُرفق مع المقالة كود برمجي يحتوي على تعريفات للكلاسات والمستندات المستخدمة في التجربة، بالإضافة إلى دوال رئيسية (make_virtual_shapes, make_template_shapes, make_template_shapes_single) التي تقوم بتنفيذ التعددية بأساليب مختلفة، ويتم قياس وقت تنفيذ كل طريقة باستخدام Boost chrono.

السائل يطرح سؤالًا حول سبب أداء Method [2] الذي يستخدم زائر واحد ولكن يعتمد على تقنية التحميل الزائد لاستدعاء الوظائف، ويتساءل عما إذا كان يجب ألا يكون هذا الأداء أفضل من وظائف الفيرتشوال.