Python 3.12: سریعتر، لاغرتر، مقاوم تر در آینده

بهبود نسخه‌های بعدی (و آینده) پایتون برای سرعت بخشیدن به آن، کاهش آن و هموار کردن راه به سوی چیزهای بهتر تنظیم شده است.

• GIL هر مترجم و مترجمان فرعی
• مفسر سریعتر پایتون
• کاهش شی بزرگ پایتون
• موارد داخلی پایتون مقاوم در برابر آینده

از آنجایی که Python یک زبان پویا است، سریعتر کردن آن یک چالش بوده است. اما در طی چند سال گذشته، توسعه دهندگان تیم اصلی پایتون روی راه های مختلفی برای انجام آن تمرکز کرده اند.

در PyCon 2023 که در سالت لیک سیتی، یوتا برگزار شد، چندین گفتگو آینده پایتون را به عنوان یک زبان سریعتر و کارآمدتر برجسته کردند. Python 3.12 بسیاری از این پیشرفت‌ها را به نمایش می‌گذارد. برخی از آنها در آخرین نسخه جدید هستند، برخی دیگر در حال حاضر در پایتون هستند اما بیشتر بوده اند. تصفیه شده.

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

پروژه‌های دیگر، هنوز در دست بررسی هستند، اما در حال حاضر نویدبخش هستند، راه‌هایی برای گسترش مدل همزمانی پایتون ارائه می‌دهند. این به Python اجازه می‌دهد تا از چندین هسته با تغییرات کمتری که توسط threads، async یا multiprocessing اعمال می‌شود، بهتر استفاده کند.

GIL هر مترجم و مفسر فرعی

چه چیزی باعث می‌شود پایتون واقعا سریع نباشد؟ یکی از رایج‌ترین پاسخ‌ها «عدم وجود راه بهتر برای اجرای کد در چند هسته» است. پایتون دارای multithreading است، اما thread ها به طور مشترک اجرا می شوند و برای کار با CPU به یکدیگر تسلیم می شوند. و پشتیبانی پایتون از چند پردازش بسیار سنگین است: شما باید چندین نسخه از زمان اجرا پایتون را برای هر هسته بچرخانید و کار خود را بین آنها توزیع کنید.

یکی از راه‌هایی که مدت‌ها برای حل این مشکل آرزو داشتیم، حذف GIL پایتون یا قفل مترجم جهانی است. GIL عملیات بین رشته‌ها را همگام‌سازی می‌کند تا اطمینان حاصل کند که اشیاء فقط توسط یک رشته در یک زمان قابل دسترسی هستند. در تئوری، حذف GIL امکان چند رشته ای واقعی را فراهم می کند. در عمل – و بارها امتحان شده است – موارد استفاده غیر رشته ای را کند می کند، بنابراین یک برد خالص نیست.

اریک اسنو، توسعه‌دهنده هسته پایتون، در سخنرانی خود، از راه‌حل احتمالی آینده برای همه این موارد پرده برداری کرد: مفسرهای فرعی، و یک GIL برای هر مترجم. به طور خلاصه: GIL حذف نمی شود، فقط کنار گذاشته می شود.

مفسرهای فرعی مکانیزمی است که در آن زمان اجرای پایتون می‌تواند چندین مفسر با هم در یک فرآیند واحد داشته باشد، برخلاف اینکه هر مفسر در فرآیند خودش جدا شده باشد (مکانیسم چند پردازشی فعلی). هر مترجم فرعی GIL خود را دریافت می کند، اما همه مترجمان فرعی می توانند حالت را با سهولت بیشتری به اشتراک بگذارند.

در حالی که مدتی است که مترجم فرعی در زمان اجرای پایتون در دسترس بوده است، آنها رابطی برای کاربر نهایی ندارند. همچنین، وضعیت نامرتب داخلی پایتون اجازه استفاده موثر از subinterperters را نمی دهد.

با پایتون ۳.۱۲، اسنو و گروهش به اندازه کافی داخلی پایتون را پاکسازی کردند تا مترجمان فرعی مفید باشند، و آنها در حال افزودن یک ماژول حداقلی به کتابخانه استاندارد پایتون به نام مفسران هستند. این به برنامه نویسان یک روش ابتدایی برای راه اندازی زیرمفسرها و اجرای کد روی آنها می دهد.

آزمایش‌های اولیه خود اسنو با مترجم‌های فرعی به‌طور قابل‌توجهی بهتر از رشته‌بندی و پردازش چندگانه بود. یک مثال، یک وب سرویس ساده که برخی از کارهای محدود به CPU را انجام می‌دهد، حداکثر ۱۰۰ درخواست در ثانیه با رشته‌ها و ۶۰۰ درخواست با چند پردازش. اما با استفاده از مترجمان فرعی، ۱۱۵۰۰ درخواست ارائه داد، و وقتی از یک کلاینت بزرگ‌تر شد، افت کمی داشت.

ماژول مفسران در حال حاضر عملکرد بسیار محدودی دارد و فاقد مکانیسم‌های قوی برای اشتراک‌گذاری حالت بین مفسرهای فرعی است. اما Snow معتقد است که توسط Python 3.13 عملکردهای بیشتری ظاهر می شود و در مرحله موقت توسعه دهندگان تشویق به آزمایش می شوند.

مفسر سریعتر پایتون

مجموعه عمده دیگری از بهبودهای عملکردی که شانون به آن اشاره کرد، مفسر تخصصی تطبیقی ​​جدید پایتون است که در یک جلسه جداگانه توسط توسعه‌دهنده اصلی پایتون، برندت بوچر، به تفصیل مورد بحث قرار گرفت.

Python 3.11 کدهای بایت جدیدی را به مفسر معرفی کرد که دستورالعمل‌های تطبیقی نامیده می‌شوند. این دستورالعمل‌ها را می‌توان به‌طور خودکار در زمان اجرا با نسخه‌های تخصصی برای یک نوع پایتون جایگزین کرد، فرآیندی که سریع‌سازی نامیده می‌شود. این کار باعث می‌شود که مفسر در مرحله جستجوی انواع اشیاء صرفه‌جویی کند و کل فرآیند را به شدت افزایش می‌دهد. به عنوان مثال، اگر یک عملیات جمع معین به طور منظم دو عدد صحیح داشته باشد، می توان آن دستورالعمل را با دستوری جایگزین کرد که فرض می کند عملوندها هر دو عدد صحیح هستند.

هر چند همه کدها به خوبی تخصصی نیستند. به عنوان مثال، حساب بین اینت و شناور در پایتون مجاز است، اما عملیات بین اینت و اینت، یا شناور و اینت، به خوبی تخصصی نیستند. Bucher ابزاری به نام متخصص را ارائه می‌کند که در PyPI موجود است، تا مشخص کند کد به خوبی یا بد تخصصی خواهد شد و جایی که می‌توان آن را بهبود بخشید، پیشنهاد دهید.

Python 3.12 دارای اپکدهای تخصصی انطباقی بیشتری است، مانند دسترسی به ویژگی های پویا، که عملیات کند هستند. نسخه ۳.۱۲ همچنین فرآیند کلی تخصصی شدن را با مراحل کمتری ساده می کند.

کاهش شی بزرگ پایتون

اشیاء پایتون در طول تاریخ از حافظه زیادی استفاده کرده‌اند. سرآیند شی پایتون ۳، حتی بدون داده‌های مربوط به شی، ۲۰۸ بایت را اشغال کرده است.

در طول چندین نسخه اخیر پایتون، تلاش‌های مختلفی برای ساده‌سازی روش طراحی اشیاء پایتون، یافتن راه‌هایی برای اشتراک‌گذاری حافظه یا نمایش فشرده‌تر چیزها صورت گرفت. شانون توضیح داد که چگونه از پایتون ۳.۱۲، سرآیند شی اکنون فقط ۹۶ بایت است – کمی کمتر از نیمی از آنچه قبلا بود.

این تغییرات نه تنها اجازه می‌دهد که اشیاء پایتون بیشتری در حافظه نگهداری شوند، بلکه محل نگهداری کش برای اشیاء پایتون را نیز بهبود می‌بخشند. اگرچه این به خودی خود ممکن است به اندازه تلاش‌های دیگر سرعت کارها را افزایش ندهد، اما هنوز یک موهبت است.

موارد داخلی پایتون مقاوم در برابر آینده

پیاده‌سازی پیش‌فرض پایتون، CPython، سه دهه توسعه در پشت خود دارد. این همچنین به معنای سه دهه cruft، APIهای قدیمی و تصمیمات طراحی است که فراتر رفتن از آنها دشوار است—همه اینها بهبود پایتون را از راه های کلیدی دشوار می کند.

ویکتور استینر، توسعه‌دهنده هسته پایتون، در ارائه‌ای درباره نحوه منسوخ شدن ویژگی‌های پایتون در طول زمان، به برخی از روش‌هایی که بخش‌های داخلی پایتون پاک می‌شوند و در آینده محافظت می‌شوند، اشاره کرد.

یک مشکل کلیدی، تکثیر C APIهای موجود در CPython، زمان اجرا مرجع برای زبان است. از پایتون ۳.۸، چند مجموعه مختلف از API وجود دارد ، هر کدام با نیازهای نگهداری متفاوت. در طول پنج سال گذشته، استینر روی خصوصی کردن بسیاری از APIهای عمومی کار کرده است، بنابراین برنامه نویسان نیازی ندارند که مستقیماً با داخلی های حساس CPython سروکار داشته باشند. هدف بلندمدت این است که مؤلفه‌هایی که از C API استفاده می‌کنند، مانند ماژول‌های افزونه پایتون، کمتر به چیزهایی وابسته باشند که ممکن است با هر نسخه تغییر کنند.

یک پروژه شخص ثالث به نام HPy با هدف کاهش بار تعمیر و نگهداری بر دوش برنامه‌نویس است. HPy یک API جایگزین C برای Python است که در نسخه‌های مختلف پایدارتر است، کدهای سریع‌تری را در زمان اجرا ارائه می‌کند و از قسمت‌های داخلی اغلب آشفته CPython انتزاع می‌شود. نکته منفی این است که یک پروژه انتخابی است، نه یک الزام، اما پروژه‌های کلیدی مختلفی مانند NumPy در حال آزمایش با استفاده از آن هستند، و برخی (مانند درگاه HPy ultrajson) در نتیجه از پیشرفت‌های عملکردی بزرگی برخوردار هستند.

بزرگترین پیروزی برای پاکسازی C API این است که در را به روی بسیاری از انواع بهبودهایی که قبلاً امکان پذیر نبودند باز می کند. مانند سایر بهبودهایی که در اینجا توضیح داده شد، آنها در مورد هموار کردن راه به سوی نسخه های آینده پایتون هستند که سریعتر و کارآمدتر از همیشه اجرا می شوند.