Pon: کامپایلر بومی پایتون ۳.۱۴ با هسته زنگار برای حذف کامل مفسر

تصور کنید محیط اجرای پایتون را کاملاً حذف کنید و کدها را مستقیماً به زبان سخت‌افزار بسپارید. این دقیقاً همان هدفی است که pon دنبال می‌کند؛ پروژه‌ای که در ۶ ژوئیه ۲۰۲۶ معماری خود را افشا کرد تا با جایگزینی بایت‌کد استاندارد با یک نمایش میانی (IR) مشترک بر پایه Rust، سرعت اجرا را متحول کند.

ده‌ها سال است که پایتون به مفسر بایت‌کد متکی است؛ سیستمی که انعطاف‌پذیری می‌دهد اما سرعت خام را می‌کشد. اکثر توسعه‌دهندگان این کندی را به بهای راحتی اکوسیستم CPython پذیرفته‌اند. pon تلاش می‌کند پایتون را به مدل «Bun/V8» ببرد؛ یعنی جایی که کد برای دستیابی به حداکثر بازدهی، مستقیماً روی سخت‌افزار (metal) کامپایل می‌شود. هدف نهایی، ساخت محیطی است که تمام مجموعه آزمون‌های CPython را پاس کند، فایل‌های اجرایی تک-باینری (Single-binary) را عرضه کند و ابزارهایی مانند مدیریت بسته و ابزارهای توسعه را به‌صورت پیش‌فرض و داخلی (out of the box) داشته باشد.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی زبان‌های سطح بالا اشاره کردیم، حذف لایه‌های میانی همواره کلید دستیابی به سرعت است. در مورد pon، این مسیر از یک خط لوله کامپایلر پیچیده می‌گذرد.

طبق مستندات گیت‌هاب این پروژه، pon از پارسر ruff (که برای نسخه PythonVersion::PY314 روی نسخه ۰.۱۴.۰ تثبیت شده است) برای پردازش کدهای پایتون ۳.۱۴ استفاده می‌کند. به‌جای تولید بایت‌کد، درخت نحو انتزاعی (AST) را به یک IR تخصصی تبدیل می‌کند (PON IR). این نمایش میانی توسط دو بستر (Backend) مختلف پردازش می‌شود که هر دو از توابع کمکی یکسان pon_* و ABI زمان اجرا استفاده می‌کنند:

• حالت JIT (pon run): کدها را در حین اجرا و از طریق pon-codegen و cranelift-jit به کد بومی تبدیل می‌کند تا فوراً اجرا شوند. این حالت، IR را در داخل خودِ پروسه به کد نیتیو تبدیل می‌کند.
• حالت AoT (pon build): با استفاده از pon-codegen و cranelift-object یک فایل اجرایی بومی و مستقل می‌سازد. در این مسیر، ابتدا یک فایل Object ایجاد شده و سپس لینک (Linked) می‌شود تا یک باینری نهایی حاصل شود.

این محیط اجرا، مدل شمارش مراجع (Reference Counting) در CPython را کنار گذاشته و از یک مدیریت حافظه یا Garbage Collector به نام Green Tea استفاده می‌کند تا حافظه را مدیریت کند. مدل اشیاء در اینجا مشابه چیدمان Heap در CPython است، اما هدر مربوط به شمارش مراجع (refcount header) از آن حذف شده است. همچنین، مدیریت خطا در سطح ABI به‌جای استفاده از Unwinding، از طریق Sentinelهای NULL انجام می‌شود.

اجرا در pon برای تعادل بین سرعت شروع و عملکرد پیک، در دو سطح (Tier) سازمان‌دهی شده است:

• سطح صفر (Baseline): همه چیز را به‌صورت جعبه‌بندی شده (Boxed) و بدون بازخورد نوع کامپایل می‌کند تا صحت کد تضمین شود. این سطح به‌عنوان مبنای درستی عمل می‌کند و می‌توان با متغیر محیطی PON_TIER0_ONLY=1 اجبار به استفاده از آن کرد. برای GC، این سطح از اسکن محافظه‌کارانه پشته (conservative stack scanning) به همراه یک Trampoline برای تخلیه ثبات‌ها در نقاط امن (safepoints) استفاده می‌کند.
• سطح یک (Typed): از پروفایل‌های نوع FeedbackCell که از اولین اجراها به دست آمده است، بهره می‌برد. توابع «داغ» یا پرکاربرد در یک رشته (Thread) پس‌زمینه دوباره کامپایل می‌شوند و حلقه‌های در حال اجرا از طریق جایگزینی در پشته (OSR) وارد کد بهینه‌شده می‌شوند. این سطح از نقشه‌های دقیق پشته کاربر Cranelift برای GC استفاده می‌کند.

اعداد صحیح (Integers) با استفاده از num-bigint در پشت PyLong به‌صورت اعداد با دقت باز (Arbitrary-precision) مدیریت می‌شوند، هرچند در حال حاضر یک مسیر سریع برای اعداد صحیح کوچک علامت‌دار (tagged small-int) در سطح Typed در حال پیاده‌سازی است.

به نقل از تیم توسعه، برای تضمین دقت، از یک سیستم تطبیق بایت‌به-بایت (byte-exact differential harness) استفاده می‌شود. یک ماژول در مجموعه داده (Corpus) تنها زمانی پذیرفته می‌شود که خروجی pon دقیقاً و بایت-به-بایت با خروجی CPython v3.14.0 یکسان باشد (که با تنظیمات TZ=UTC و PYTHONHASHSEED=0 استاندارد شده است). این ویژگی، «دروازه خروجی» مطلق مجموعه تطبیق است.

تست‌ها در چندین لایه سخت‌گیرانه (ratcheted floors) اجرا می‌شوند:

• cpython corpus: ردیابی ۲۴۴ ماژول در فایل conformance-floor.json برای تطابق بایت-به-بایت در حالت JIT.
• cpython-aot-subset: ردیابی ۲۰۶ ماژول در aot-parity-floor.json برای برابری در باینری‌های بومی.
• cpython-full: ادغام کامل مجموعه آزمون‌های استاندارد پایتون (Lib/test) از طریق conformance-full-floor.json.
• fuzz & stress: استفاده از Fuzzing تفاضلی برای اطمینان از عدم وجود واگرایی، در حالی که ft-stress پایداری سیستم را در حالت بدون GIL و چندرشته‌ای شدن (threading) آزمایش می‌کند.

توسعه‌دهندگان از اسکریپت scripts/gate.sh برای تأیید این ادعاها استفاده می‌کنند؛ به‌طوری که دستور bash scripts/gate.sh fast لایه‌های پایه را پوشش می‌دهد و bash scripts/gate.sh full شامل بنچمارک‌ها و تست‌های End-to-End مدیریت بسته می‌شود.

فراتر از کامپایلر، pon یک مدیریت بسته داخلی دارد که از uv الهام گرفته است. این ابزار از الگوریتم pubgrub برای حل وابستگی‌ها استفاده می‌کند و از فایل pyproject.toml و ایندکس ساده PyPI پشتیبانی می‌کند. این مدیریت بسته برای کار با Wheels، توزیع‌های سورس (sdists)، نصب‌های قابل ویرایش (editable installs) و نیازمندی‌های VCS طراحی شده است.

مدیریت بسته مجموعه‌ای جامع از دستورات شامل init ،add ،remove ،install ،lock ،run ،list ،freeze ،show ،download ،check ،cache و env را ارائه می‌دهد. دستور run آن از همان مسیر زمان اجرای اجرای مستقیم اسکریپت‌ها عبور می‌کند، اما ریشه‌های واردات (import roots) مدیریتی را به آن اضافه می‌کند.

بر اساس آخرین گزارش‌های جولای ۲۰۲۶، این پروژه در توسعه فعال است و از زنجیره ابزارهای تثبیت‌شده nightly-2026-04-29 و MSRV 1.94.0 استفاده می‌کند. در حال حاضر تأییدات نشان می‌دهد ۲۰۹ ماژول در حالت JIT با CPython ۳.۱۴ تطابق بایت-به-بایت دارند و ۱۷۲ مورد از آن‌ها در حالت AoT نیز پاس شده‌اند.

زیرساخت عملکرد با کامپایل پس‌زمینه و حافظه‌های کش داخلی (inline caches) در حال حاضر آماده است. هدف نهایی عملکردی، دستیابی به میانگین هندسی سرعت (geomean speedup) برابر یا بیشتر از ۵ برابر نسبت به CPython است و در وظایف عددی، این مقدار باید به ۲۰ برابر یا بیشتر برسد. برای دستیابی به این هدف، نقشه راه شامل موارد زیر است:

• تکمیل کتابخانه استاندارد: ایجاد ماژول‌های بومی و ماژول‌های تطبیق برای _io/os ،math ،struct ،random ،collections ،itertools ،json ،datetime و importlib.
• بهینه‌سازهای پلکانی: پیاده‌سازی تخصیص TLAB، مسیرهای سریع برای دیکشنری‌ها، Unboxing برای اعداد اعشاری (float)، تخصصی‌سازی فراخوان/صفت (call/attribute specialization) و لایه‌بندی ژنراتورها.
• سخت‌سازی محیط اجرا: نهایی کردن محیط اجرای بدون GIL و free-threaded در برابر تست‌های فشار رشته‌ها، GC و سیگنال‌ها.

این تغییر، فرض بنیادین مبنی بر اینکه پایتون برای حفظ انعطاف باید مفسر باشد را می‌زند. pon آینده‌ای را ترسیم می‌کند که اپلیکیشن‌های پایتون به‌صورت باینری‌های سریع و مستقل توزیع شوند، بدون اینکه کاربر نیاز به نصب پایتون روی سیستمش داشته باشد.

برای توسعه‌دهنده، این یعنی امکان توزیع ابزارهای پایتونی به‌عنوان اپلیکیشن‌های بومی در حالی که با استاندارد ۳.۱۴ سازگار هستند. اگر تیم بتواند به اهداف عملکردی خود برسد، «مالیات پایتون» (Python tax) در کارهای وابسته به CPU عملاً حذف خواهد شد.

برای مشاهده اینکه آیا pon می‌تواند به برابری کامل با اکوسیستم برسد، منتظر تکمیل مجموعه آزمون cpython-full و گسترش ماژول‌های بومی کتابخانه استاندارد باشید.

گام بعدی شما

• اگر ابزارهایی می‌سازید که توزیع سریع برای کاربر نهایی دارند، چشم به انتشار نسخه پایدار cpython-full بدوزید.
• مستندات pon-codegen را برای درک نحوه تبدیل AST به IR بررسی کنید.
• در صورت دسترسی به نسخه آزمایشی، بنچمارک‌های عددی خود را با حالت AoT مقایسه کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تأثیر تراشه‌های جدید بر زمان استنتاج مراجعه کنید.