Python 3.14 no-GIL في production: متى تبدّل ومتى تفضل في 3.12

لو شغلك Python فيه عمليات CPU-bound متوازية (معالجة صور، تشفير، parsing لـ payloads ضخمة)، الـ free-threaded build في Python 3.14 بيديك تسريع 3×–5× على جهاز بـ 8 cores. لو شغلك غالبه I/O (API calls، DB queries)، التغيير هيفرق معاك أقل من 5%، والـ single-thread هيبقى أبطأ 5–8%.

المشكلة باختصار

الـ GIL (Global Interpreter Lock) كان بيمنع threads متعددين من تنفيذ bytecode Python في نفس اللحظة. بقالنا سنين بنحايل المشكلة دي بـ multiprocessing، لكن الـ overhead بتاع الـ IPC وتكلفة الذاكرة عاليين جدًا لمهام قصيرة. في أكتوبر 2025، Python 3.14 عملت الـ free-threaded build (المعروف بـ python3.14t) خيار رسمي supported، مش experimental. وبحلول أبريل 2026، الـ ecosystem وصل لنقطة إن القرار بقى عملي، لكنه مش بديهي.

ليه القرار مش "بدّل على طول"

فيه تلات أسباب واقعية تخلّيك تفكر مرتين قبل ترحيل production workload كامل:

• single-thread أبطأ: الـ free-threaded build بيشيل optimizations معتمدة على الـ GIL، فالكود اللي مش parallel بيركض أبطأ 5–8% مقارنة بـ 3.13 الـ GIL'd.
• C extensions ناقصة دعم: numpy ≥ 2.2 و lxml ≥ 5.3 مدعومين، لكن الـ long tail من مكتبات صغيرة لسه بتطلّع warnings أو بتقع لما تشتغل threaded.
• debugging أصعب: race conditions في Python code بقت حقيقية. الكود اللي كان شغال صح لسنين بسبب الـ GIL ممكن يظهر bugs غريبة تحت load عالي.

متى الـ no-GIL يفرق فعلاً

التسريع الحقيقي بيظهر في الحالات دي بس:

1. عمليات CPU-bound قصيرة (أقل من 100ms لكل task) — هنا multiprocessing overhead بيأكل المكسب.
2. تطبيقات بتعالج آلاف payloads متوازية في الذاكرة (JSON parsing، regex، hashing، compression).
3. Data pipelines بتستخدم pandas/polars على DataFrames تدخل memory بالكامل.
4. Web scrapers بيعملوا parsing محلي لـ HTML بعد ما يجيبوا البيانات.

السكربت: قياس فعلي على جهازك

قبل ما تقرر، قيس. السكربت ده بيشغّل hashing في threads متعددين ويطبع الزمن. شغّله مرة بـ python3.12 ومرة بـ python3.14t وقارن.

# bench_threads.py
import threading
import time
import hashlib

def hash_loop(iterations: int) -> None:
    data = b"x" * 2048
    for _ in range(iterations):
        hashlib.sha256(data).hexdigest()

def run(threads_count: int, iterations_per_thread: int) -> float:
    threads = [
        threading.Thread(target=hash_loop, args=(iterations_per_thread,))
        for _ in range(threads_count)
    ]
    start = time.perf_counter()
    for t in threads:
        t.start()
    for t in threads:
        t.join()
    return time.perf_counter() - start

if __name__ == "__main__":
    total_work = 2_000_000
    for n in (1, 2, 4, 8):
        per_thread = total_work // n
        elapsed = run(n, per_thread)
        print(f"threads={n} elapsed={elapsed:.2f}s")

النتيجة المتوقّعة على جهاز 8 cores:

• 3.12 (مع GIL): الزمن تقريبًا ثابت عند كل عدد threads (حوالي 6–7 ثواني). الـ GIL بيسلسل العمل.
• 3.14t (بدون GIL): threads=1 يعطي ~7s، threads=4 يعطي ~1.9s، threads=8 يعطي ~1.1s. تسريع يقرب من خطي.

لو الفرق على 4 threads عندك أقل من 30%، شغلك غالبًا مش CPU-bound أصلًا. خلّيك على 3.12.

Trade-offs: بتكسب إيه، بتخسر إيه

بالظبط علشان القرار يبقى واضح:

• بتكسب: parallelism حقيقي على threads في نفس الـ process، توفير ذاكرة مقارنة بـ multiprocessing (مش بتضرب حجم الذاكرة × عدد الـ workers)، ولا تحتاج IPC serialization.
• بتخسر: ~7% من أداء الـ single-thread، استقرار بعض C extensions القديمة، وسهولة الـ debugging. كمان memory usage لكل thread أعلى شوية بسبب per-thread GC state.

متى لا تستخدم no-GIL

فضّل تبقى في 3.12 أو 3.13 لو:

• شغلك web API بيستخدم async/await (الـ asyncio بيحل المشكلة فعلاً لـ I/O).
• بتعتمد على مكتبات C extensions مش مذكورة في قائمة الدعم الرسمية لـ 3.14t.
• فريقك مش معتاد debug race conditions — هتقضي وقت أكتر من اللي هتكسبه.
• شغلك batch jobs قصيرة تشغّلها مرة في اليوم — الـ multiprocessing كفاية.

الافتراض هنا

الكلام ده مبني على فرضية إن عندك خوادم بـ ≥ 4 physical cores ومهام CPU-bound مستمرة. لو سيرفرك core واحد أو اتنين، الـ no-GIL مش هيعمل فرق يستاهل المخاطرة.

الخطوة التالية

نزّل python3.14t على بيئة dev فقط عبر uv python install 3.14t أو من pyenv. شغّل السكربت فوق على أثقل workload عندك، قارن النتائج. لو التسريع أقل من 2× على 4 threads، استمر في 3.12 بدون ندم. لو أعلى من 2.5×، ابدأ قائمة بمكتبات C extensions اللي شغلك بيعتمد عليها وتحقّق من دعمها قبل أي ترحيل لـ production.