سی‌پایتون

سی‌پایتون (به انگلیسی: CPython) رویه پیش‌فرض و پر کاربردترین رویه در زبان برنامه‌نویسی پایتون است که به زبان سی (زبان برنامه‌نویسی) نوشته شده‌است.

CPython
توسعه‌دهنده(ها)توسعه‌دهندگان مرکزی پایتون و جامعه پایتون؛ پشتیبانی شده توسط بنیاد برنامه‌نویسی پایتون
انتشار پایدار
3.4.1 /
۱۸ مه ۲۰۱۴ (۲۰۱۴-05-۱۸)
2.7.6 /
۱۰ نوامبر ۲۰۱۳ (۲۰۱۳-11-۱۰)
مخزن
نوشته‌شده باسی
بن‌سازه رایانشچندسکویی
پروانهمجوز بنیاد نرم‌افزاری پایتون
وبگاه

سی‌پایتون مفسر کدهای پایتون است.

سی‌پایتون کد پایتون را قبل از تفسیر کردن آن، به بایت‌کد کامپایل می‌کند و از این رو می‌تواند هم به عنوان مفسر و هم کامپایلر (همگردان)، تعریف شود. سی‌پایتون یک رابط عملکرد خارجی (foreign function interface)، با چند زبان از جمله زبان سی دارد که در آن باید صریحاً قیدها را در زبانی غیر از پایتون نوشت.

طراحی

ویژگی خاص سی‌پایتون این است که از قفل مفسر سراسری (به اختصار GIL)، در هر فرایند مفسر سی‌پایتون بهره می‌برد که به این معناست که در ظرف یک فرایند هربار فقط یک ریسه (زیربرنامه) می‌تواند بایت‌کد پایتون را پردازش کند.

این به این معنا نیست که چند ریسمانی فایده‌ای ندارد. متداول‌ترین سناریوی چند ریسمانی وقتی است که ریسه‌ها بیشتر منتظر تکمیل شدن فرایند خارجی هستند.

برای مثال تصور کنید که 3 ریسه در حال سرویس‌دهی به مشتری‌های جداگانه هستند. یک ریسه ممکن است منتظر پاسخ مشتری و دیگری منتظر اجرا شدن جستار پایگاه داده ها باشد در حالی که سومی عملاً در حال پردازش کد پایتون است.

با این حال، وجود GIL به این معناست که سی‌پایتون برای پردازش‌هایی که الگوریتم‌های فشرده CPU را در کد پایتون پیاده‌سازی می‌کنند و به طور بالقوه می‌توانند در چندین هسته توزیع شوند، مناسب نیست.

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

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

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

وجود GIL، پیاده سازی سی‌پایتون را ساده‌تر کرده و پیاده کردن برنامه‌های چند ریسمانی که از انجام همزمان کد پایتون بهره نمی‌برند را آسان‌تر می‌کند. با این حال بدون GIL، در اپلیکیشن‌های چند پردازشی باید از Thread safe بودن کدهای مشترک اطمینان حاصل کرد.

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

تاریخچه

Unladen Swallow

Unladen Swallow بخش بهینه‌سازی سی‌پایتون بود، با این قصد که کاملاً سازگار و به طور قابل توجهی سریع باشد. این پروژه دست یافتن به هدف‌هایش را با تکمیل ماشین مجازی سفارشی سی‌پایتون با یک کامپایلر درجای ساخته شده با استفاده از ال ال وی ام (LLVM)، پیش گرفت.

هدف این پروژه بهبود سرعت 5 برابری نسبت به پایتون بود که این هدف محقق نشد.

اسپانسر این پروژه گوگل بود و صاحبین پروژه، Jeffrey Yasskin، Collin Winter و Thomas Wouter، برخلاف اکثر همکاران این پروژه، کارمندان تمام وقت گوگل بودند. Unladen Swallow روی کد گوگل میزبانی می‌شد.

اگرچه درمیان اهداف منتشر شده کوچک به نظر می‌رسید، اما Unladen Swallow کدهایی را تولید کرد که به پیاده‌سازی اصلی پایتون از جمله بهبود ماژول cPickle، اضافه شد.

در جولای 2010 از آنجا که Q4 Milestone سال 2009 هنوز منتشر نشده بود، برخی ناظران به این فکر افتادند که عمر این پروژه به پایان رسیده یا در حال اتمام است. تعداد پیام‌های mailing list متعلق به Unladen از 500 پیام در ژانویه‌ی 2010، به کمتر از 10 پیام در سپتامبر 2010 رسید. همچنین گزارش شده بود که Unladen بودجه‌ی مالی گوگل را از دست داده است. در نوامبر 2010 یکی از توسعه دهندگان اصلی پروژه اعلام کرد که :"من و جفری وارد پروژه‌هایی با اهمیت بالاتری برای گوگل شده‌ایم."

بخش توسعه‌ی Q4 2009 در 24 ژانویه‌ی 2010 تشکیل شد. اما هیچ تبلیغاتی در وبسایت انجام نشد. همچنین از آنجایی که این پروژه انتشار نسخه‌ی 2.7 پایتون را از دست داد، Python Enhancement Proposal (به اختصار PEP)، برای برنامه‌های بلند مدت پذیرفته شد، که این موضوع، خواستار ادغام Unladen Swallow با یک شاخه Py3k-jit ویژه از repository رسمی پایتون بود. تا جولای 2010 این کار درحال انجام بود.

این ادغام زمان زیادی می‌خواست زیرا Unladen swallow دراصل براساس پایتون 2.6 ساخته شده بود که پایتون 3 با آن مطابقت نداشت. (برای اطلاعات بیشتر پایتون 3000 را ببینید). اگرچه از PEP متعاقباً صرف نظر شد.

اوایل 2011، مشخص شد که پروژه متوقف شده است.

پلت‌فرم‌های مورد پشتیبانی

منابع
  1. "Irix still supported?".
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.