لماذا ما زالت البرمجيات بطيئة؟ حجة دان لو حول الاقتصاد الجديد للتحسين

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

الحجة

يبدأ المقال بادعاء واسع الانتشار مفاده أن منتقدي الكود "المنتفخ" الذي تنتجه النماذج اللغوية سيشعرون بالحرج حين يُعاد كتابة كل شيء بـ"لغة تجميع محسّنة للغاية". لا يذهب لو إلى هذا الحد: لن نعود إلى كتابة كل شيء بلغة التجميع يدوياً، لكن التحسينات التي كانت تتطلب شخصاً أو فريقاً بمهارات نادرة صارت في متناول أي شخص قادر على كتابة بضع جمل. ويقدّر أن كلفة وقت الإنسان انخفضت "في كثير من الأحيان 1000 أو 10 آلاف أو مليون مرة"، أما الكلفة بالدولار فقد تراجعت نحو 1000 مرة مقارنة بالمهندس في Bing الذي كتب سابقاً المترجمات ومترجمات JIT داخل فهرس البحث.

أرقام ملموسة: regex وripgrep

يستند المقال إلى تجارب أجراها على محرك regex المسمى FRE، الذي بُني عبر تشغيل وكيل في حلقة لمدة شهر على مجموعة اختبارات rebar. كان الإفراط في التخصيص قوياً لدرجة أن الوكيل احتاج إلى إخباره بوجود مجموعة holdout قبل أن تتعمّم التحسينات. وفي إحدى التجارب، كان ripgrep يترجم الأنماط إلى كود أصلي في خيط خلفي ثم يتحول إليه بعد انتهاء الترجمة: تسريع بمقدار 2 إلى 4 أضعاف في عدد قليل من الاستعلامات الطويلة البسيطة، ونحو 7% في استعلامات holdout التمثيلية التي ينطبق عليها المسار الأصلي — مقابل إبطاء الاستعلامات القصيرة.

برمجيات مخصصة لعبء عمل واحد

شبّه مارك بروكر هذا الاتجاه بمكتبة FFTW وبحيل مشهد الديمو: كود مُشكَّل لمسألة واحدة بدل فئة من المسائل، وتوقع انتشار "برمجيات ديناميكية مخصصة". ويضيف مايكل ماليس، العامل على pgrust، أن الفكرة الشائعة بأن "كتابة الكود لم تكن يوماً الجزء الصعب" صحيحة في مجالات محددة فقط: فمترجمات JIT نادرة لأن كتابتها كانت مكلفة أكثر من أن تستحق، وقواعد البيانات كانت تاريخياً أصعب البرمجيات بناءً. وقد عمل لو نفسه على BitFunnel، فهرس بحث Bing الذي فاز بجائزة أفضل ورقة في SIGIR؛ وتحتوي نسخة Bing على عدة مترجمات JIT — وهو حجم صار "سأنجزه في عطلة نهاية الأسبوع" وصفاً صحيحاً له.

ما لا يتغير

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