مهندس NVIDIA يقترح تعديلاً يخفض وقت بناء GCC بنسبة 15% عبر تخزين نتائج Configure مؤقتاً

مشكلة بطء بناء مترجم GCC

بناء (Compilation) مترجم GCC من المصدر هو عملية شاقة ومعروفة بصعوبتها. لكن القليل من المطورين يتعمق في أسباب هذا البطء. مهندس NVIDIA، Kyrylo Tkachov، قام بتحليل دقيق لعملية البناء على جهاز ضخم متعدد الأنوية بمعمارية AArch64 (يُعتقد أنه يعمل بمعالج NVIDIA Vera)، واكتشف شيئاً مدهشاً: حوالي 30% من الوقت الفعلي (Wall Time) المستغرق في بناء المترجم يضيع في تشغيل نصوص Configure، وهي نصوص تنفذ بشكل تسلسلي (Serial) ولا تستغل المعالجات المتعددة إطلاقاً. والأسوأ من ذلك، أن النظام كان يستغل أقل من 15% من قدراته الحسابية لنصف مدة البناء تقريباً [citation:1][citation:8].

🔗 المناقشة على قائمة GCC البريدية: gcc.gnu.org/pipermail/gcc-patches/2026-June/719831.html

ما هي عملية Bootstrap في GCC؟

لفهم المشكلة، يجب شرح عملية التمهيد (Bootstrap) في GCC. هي عملية بناء المترجم في ثلاث مراحل متتالية لضمان سلامته وخلوه من الأخطاء [citation:5][citation:8]:

المرحلة الأولى (Stage 1): بناء نسخة أولية من GCC باستخدام مترجم النظام (System Compiler) المثبت مسبقاً (مثل GCC قديم أو Clang). يتم بناء هذه النسخة بدون تحسينات (-O0) لتكون بسيطة ومستقرة [citation:2].
المرحلة الثانية (Stage 2): إعادة بناء المترجم من الصفر، ولكن هذه المرة باستخدام المترجم الذي تم بناؤه في المرحلة الأولى. يتم تمكين التحسينات (-O2) للحصول على أداء أفضل [citation:2].
المرحلة الثالثة (Stage 3): بناء ثالث للمترجم باستخدام ناتج المرحلة الثانية. بعد الانتهاء، تتم مقارنة ناتج المرحلتين الثانية والثالثة بايت ببايت للتأكد من أن المترجم ينتج نفس الكود عند ترجمة نفسه، مما يثبت أنه موثوق وخالٍ من الأخطاء [citation:8].

المشكلة هي أن كل مرحلة من هذه المراحل الثلاث تقوم بتشغيل نصوص configure من الصفر. هذه النصوص تقوم بمئات أو آلاف الفحوصات: تبحث عن ملفات الرأس (Header Files)، أحجام الأنواع (Type Sizes)، سلوك المكتبات، إمكانيات الرابط (Linker)، والمزيد [citation:8]. في حالة البناء المحلي (Native Bootstrap) وليس البناء المتقاطع (Cross-Compilation)، فإن نتائج هذه الفحوصات لا تتغير بين المراحل الثلاث. معنى هذا أنك تقوم بنفس العمل المكلف ثلاث مرات متتالية دون داعٍ، وهذا ما أشار إليه البعض سابقاً كمشكلة معروفة في نظام بناء GCC [citation:7][citation:10].

الحل المقترح: تخزين نتائج Configure مؤقتاً

الحل الذي قدمه Kyrylo Tkachov هو في غاية الذكاء والبساطة: تخزين نتائج فحوصات configure مؤقتاً في كل مرحلة، وإعادة استخدامها تلقائياً في المراحل التالية [citation:1][citation:8]. الفكرة تعتمد على آلية “Site Cache” الموجودة أصلاً في Autoconf، والتي تُستخدم لتخزين نتائج الفحوصات الخاصة ببيئة معينة.

نتائج المقترح: بعد تطبيق التعديل، أظهرت الاختبارات الأولية نتائج واعدة جداً على معمارية AArch64 و x86_64 [citation:1]:

انخفاض الوقت المستغرق في configure بنسبة 43%.
انخفاض الوقت الإجمالي لعملية Bootstrap بنسبة 15%.
ضمان صحة الناتج: أكد المطور أن ملفات الإعداد (config headers) الناتجة متطابقة تماماً مع النسخة غير المخزنة، وأن مقارنة المرحلتين الثانية والثالثة تنجح دون مشاكل [citation:1].

هذا يعني أنه إذا كان بناء GCC يستغرق 30 دقيقة، فإن هذا التعديل سيختصر حوالي 4-5 دقائق من وقت الانتظار، وهو تحسن كبير للمطورين وخاصة في أنظمة التكامل المستمر (CI) [citation:8].

انتقادات أولية: هل هو “Hack” أم حل حقيقي؟

لم يمر الاقتراح دون نقاش. أحد المعلقين على قائمة البريد اعتبر التعديل “Hack” (حل مؤقت أو غير أنيق) واقترح بدلاً من ذلك تنظيف نصوص configure نفسها، وإزالة الفحوصات القديمة غير المجدية، ودعم Linker القديم GNU Gold، وبقايا أخرى تراكمت على مر السنين [citation:1][citation:8]. تنظيف النصوص سيفيد أيضاً حالات البناء المتقاطع (Cross-Compilation) وليس البناء المحلي فقط، بينما يقتصر حل التخزين المؤقت على البناء المحلي.

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

خلاصة

اقتراح Kyrylo Tkachov لتخزين نتائج configure مؤقتاً هو خبر ممتاز لكل من يضطر إلى بناء GCC من المصدر، سواء كان مطور أنظمة مدمجة، أو مسؤول حزمة في توزيعة لينكس، أو باحث في أمان المعلومات يحتاج إلى مترجم معدّل. مع تزايد عدد النوى في المعالجات الحديثة (64، 128، 256 نواة)، تصبح المهام التسلسلية مثل هذه هي العائق الرئيسي أمام الاستفادة من قوة العتاد. هذا التعديل يزيل هذا العائق لمرحلة configure ويجعل عملية الـ Bootstrap أكثر كفاءة.