PEP 836 يضع هدفًا رقميًّا لـ JIT في Python: تحسين 20% قبل أول beta من 3.17
مشروع مفتوح المصدر يربط بقاء ميزة كبيرة برقم مكتوب وموعد محدد، والأرقام الحالية لا تتجاوز نصف الهدف في أحسن الأحوال.
دخل الـ JIT، أي المترجم الذي يحوّل الكود إلى تعليمات آلية أثناء التشغيل، إلى الفرع الرئيسي في CPython دون أن يمر بعملية الـ PEP الكاملة التي يُفترض أن يمر بها أي تغيير كبير في Python. لذلك أوقف الـ Steering Council التطوير الجديد عليه، وطلب خطة مكتوبة.
جاءت الخطة في PEP 836، الذي قدّمه Savannah Ostrowski وKen Jin وBrandt Bucher، وما زال في حالة Draft.
يحدد الـ PEP هدفًا واحدًا: تحسين لا يقل عن 20% بالمتوسط الهندسي على مجموعة اختبارات pyperformance، للـ JIT مع الـ free-threading، مقارنة بمفسّر الـ free-threading وحده. والموعد النهائي هو أول إصدار beta من Python 3.17.
أما الأرقام الحالية فتتراوح بين 4% و12% على المنصات المدعومة. أي أن المطلوب يقارب ضعف ما تحقق إلى ثلاثة أضعافه. وينص الـ PEP على أن هذا الرقم هو “الحد الأدنى لاستمرار التطوير داخل الشجرة”، ما يعني أن عدم بلوغه قد ينتهي بإزالة الـ JIT من CPython.
ويضع الـ PEP كذلك حدًّا أدنى مرحليًّا قدره 5% في السنة الأولى، حتى لا يبقى الحكم معلّقًا إلى اليوم الأخير.
وتشير بعض التغطيات إلى مهلة “6 أشهر”، غير أن نص الـ PEP نفسه يربط الموعد بأول beta من 3.17.
ما يعنيه ذلك للفرق
الجديد هنا هو الصيغة: رقم مكتوب وموعد محدد، بدل وعد مفتوح بتحسين الأداء. وهذا يمنح المستخدمين وضوحًا نادرًا بشأن مستقبل الميزة.
أما الفرق التي تؤجل قرارات الأداء في انتظار أن تصبح Python أسرع من تلقاء نفسها، فالأرقام الحالية تشير إلى أن المفسّر المتاح اليوم هو الأساس الواقعي للتخطيط، لا مفسّر ما زال يثبت جدواه. ويبقى مفتوحًا سؤال ما إذا كانت نسبة 20% عادلة لميزة بهذا الحجم أم مرتفعة.