مطور Wild يفسّر تناقض نتائج مقارنة الأداء مع Mold: الفرق في طريقة القياس

نشر David Lattimore، مطور الـ linker المسمى Wild، في 18 سبتمبر 2026 مقالًا بعنوان Benchmarking Wild vs Mold. والـ linker هو الأداة التي تجمع ملفات الكود المترجمة في برنامج تنفيذي واحد، وسرعته تؤثر مباشرة في زمن كل عملية build.

السياق أن فريق Mold حدّث اختبارات الأداء لديه وضم إليها Wild لأول مرة، فظهر Wild أبطأ بوضوح. وهذا عكس ما أظهرته اختبارات Wild المنشورة في 4 أغسطس.

أين كان الفرق

بحث Lattimore عن السبب، ووجد أنه لا يكمن في الكود بل في إعداد القياس. فاختبارات Wild كانت تعمل والملف الناتج موجود من تشغيل سابق، بينما تحذف اختبارات Mold الملف الناتج بين كل تشغيل وآخر. وحين لا يكون الملف موجودًا، يضطر الـ linker إلى إنشائه من البداية.

وكان هناك فرق ثانٍ: Wild يقيس على tmpfs، أي نظام ملفات في الذاكرة، بينما يقيس Mold على ext4. ويكتب Lattimore: “بالنظر إلى الوراء، كان هذا خطأً على الأرجح، لأن أغلب المستخدمين لا يبنون مشاريعهم على tmpfs”. كما يمرر Mold الخيار –no-fork الذي يلغي السلوك الافتراضي. واختلفت الأجهزة أيضًا: Threadripper بـ 64 نواة وApple M1 Ultra لدى Mold، وRyzen 9955hx بـ 16 نواة لدى Wild.

وحين أعاد القياس بإعداد Mold نفسه، اقتربت النسب كثيرًا من نتائج Mold: blender-debug بنسبة 1.2x لدى الطرفين، وgodot-debug بنسبة 1.3x لدى Mold و1.2x لديه، وblender-release بنسبة 0.8x و0.9x، وclang-release بنسبة 1.0x لدى الطرفين.

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