گوگل حرف نمیزند, عمل میکند: بالا بردن سرعت زبان برنامه نویسی پایتون تا حداقل 5 برابر!

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

همونطور که همتون میدونید ( یا شاید هم نمی دونید ) یکی از سه زبان اصلی برنامه نویسی مورد استفاده در گوگل, پایتون هستش. دو تای دیگه,  یکی ++C هست که قسمت زیادی از کدهاش به عنوان توسعه دهنده های پایتون نوشته شدن و اون یکی که نیاز به گفتن نداره. جاوا.

و باز هم همونطور که همتون میدونید (یا شاید اینبار هم نمیدونید) سایت محبوب یوتیوب با پایتون خالص نوشته شده! البته جو گیر نشید یوتیوب هم از ++C استفاده میکنه ولی بر عکس گوگل, یوتیوب تقریبا 99.99% درصد از کدهای ++C رو برای ساخت توسعه دهنده های پایتون نوشته. و احتمالا این رو هم میدونید که گوگل یوتیوب رو خیلی وقت پیش خریده پس با این توضیحات میشه به صورت تئوری اینطور بیان کرد که گوگل بزرگترین منبع سورس های نوشته شده با پایتون رو در اختیار خودش داره و از طرفی هم خیلی از افراد کلیدی پایتون توی گوگل مشغول به کارن که خوب دلیلش هم کاملا واضحه.

یکی از چیزهای دیگه ایی که باید بدونید اینکه من دو تا پاراگراف بالا رو از یه جام در نیاوردم! یه سرچ تو گوگل بزنید یا مطلب رو تا پایین ادامه بدید و فایل PDF ای که براتون می ذارم رو بخونید تا درستی این گفته ها بهتون ثابت بشه.

به هر حال؛ اینطور که پیداست (یا بهتره بگم پیدا بود) گوگل به عنوان شرکتی که ستون های اصلیش روی پایتون ساخته شده, تصمیم گرفت که سرعت این زبان برنامه نویسی رو با توجه به چیزی که خودش از مفهوم “سرعت” انتظار داره, بالاتر ببره. حداقل 5 برابر بالاتر از سرعت فعلی پایتون!

می دونید پایتون یه زبان تفسیری و دینامیک هستش. تو این مدل از زبان های برنامه نویسی سرعت عمل برنامه نویس خیلی بالاست اما لزوما قرار نیست سرعت برنامه هم به همون اندازه بالا باشه! رو همین حساب گوگل چند تا از برنامه نویس های با تجربه در زمینه ی کامپایلرها و مفسر ها رو به صورت تمام وقت یه جا جمع میکنه تا تحت پروژه ایی به اسم “Unladen Swallow” سرعت این زبان برنامه نویسی محبوب رو بهبود ببخشن.

کاری که بروبکس Unladen Swallow (یکی یه ترجمه ی مناسب ارائه بده خواهشا) انجام دادن این بوده که سورس کدهای اصلی منبع پایتون رو گرفتن (با تشکر فراوان از از آزادی و متن باز بودن این زبان برنامه نویسی) و به صورت جداگونه دارن با بر مبنای LLVM روش دستکاری انجام میدن تا بتونن علاوه بر بهبود در ترجمه و تفسیر بهتر پایتون, یه کامپایلر زمان اجرا (JIT Compiler) براش بسازن و از طرفی هم میزان منابع سخت افزاری مورد نیاز مثل حافظه یا پردازنده رو کاهش بدن.

اینجا فکر کنم لازم باشه توضیح بدم این LLVM چی هست کلا:

LLVM عزیزم یه سازه…. اوخ باز من جوگیر شدم…. برو بچه های یکی از دانشگاه های معروف امریکایی (University of Illinois) از مدت های پیش یک سری استراتژی ها و ابزارهایی روتحت اسم LLVM  طراحی کردن که منحصرا برای استفاده در لایه های زیرین یک کامپایلر کاربرد داره و می تونه باعث بهبود در قسمت های مختلف یه کامپایلر بشه. این بهینه سازی بر جنبه های مختلف کار یه کامپایلر مثل عملیات زمان کامپایل, عملیات پیوند دهی!!!!, و عملیات زمان اجرا تاثیر گذاره.

مجموعه ابزارها و کدهای LLVM با ++C نوشته شده و اولش قرار بود برای بهینه سازی کامپایلر ++C/C مجموعه  ی GCC استفاده بشه اما از اونجایی که ساختارش مستقل از یه زبان برنامه نویسی خاص طراحی شده, می تونه برای بهبود کار کامپایلر ها و یا مفسرهای بقیه زبان های برنامه نویسی هم استفاده بشه. برای مثال مجتمع سازی LLVM با جاوا در حال توسعه هستش یا برو بچه های Unladen Swallow قراره کاری کنن که پایتون هم بتونه از LLVM استفاده کنه.

پروژه Unladen Swallow قرار نیست کارها رو با عجله و هول هولکی انجام بده و در عوض با تقسیم بندی پروژه در چند فاز مختلف سعی کرده آروم آروم به پیشرفت کار اضافه کنه.

- فاز یک پروژه به پایان رسیده و سرعت پایتون 35-25 در صد افزایش پیدا کرده.

- فاز دوم پروژه به پایان رسیده و کامپایلر زمان اجرا بر پایه LLVM به پایتون اضافه شده و علاوه بر اون تا 25 درصد نسبت به فاز یک بهبود در سرعت حاصل شده !

- فاز سوم هم جدیدا به پایان رسیده. بهبود سرعت نسبت به فاز دوم پروژه از 70-15 درصد دیده میشه و در ضمن میزان استفاده از حافظه نسبت به فاز دوم پروژه 930 در صد کاهش پیدا کرد. (درست خوندید 930 درصد!)

- پروژه هنوز به اتمام نرسیده و باید منتطر کامل شدن فاز های بعدی باشیم. چرا؟ چون:

• سرعت پایتون میتونه از این هم زیادتر بشه. تیم متوجه شده که کار سخت تر از اونیه که فکر میکردن. در واقع سختی بیشتر کار بابت اینه که تیم نمی خواد خیلی زیاد هسته ی پایتون رو دستکاری کنه. به خاطر همین ممکنه سرعت به حدی که انتظار میرفت نرسه.

• میزان استفاده از منابع سخت افزاری هم باید کاهش بیشتری پیدا کنه چون در حال حاظر این ویرایش پایتون   از 2 تا 3 برابر نسبت به ویرایش معمولی CPython بیشتر حافظه مصرف میکنه.

• در ضمن باید این کدها به پلتفرم های مختلف پورت بشن چون در حال حاظر فکر میکنم بیشتر با سیستم های یونیکس و لینوکس و بقیه رفقاشون سازگاره.
• با تغییرات انجام شده عملیات debug کردن برنامه ها مشکل پیدا کرده و باید فکری براش بشه.
• از همین الآن تعدادی از برنامه نویس های برتر مفسر پایتون خالفت خودشون رو با ترکیب شدن کدهای این پروژه با کدهای اصلی CPython اعلام کردن.

به روزرسانی: چند خط از این نوشته (مواردی که با دایره های سیاه رنگ نوشته شدن) در تاریخ 13 آبان 88  اضافه شده ان.

خوبیه این پروژه اینکه قراره با کدهای معمولی پایتون کاملا سازگار باشه و توسعه دهنده هایی که تا امروز برای پایتون نوشته شدن بدون هیچ تغییری به راحتی اجرا بشن. در آخر هم هدف اصلی پروژه اینکه نمه نمه تغیرات صورت گرفته رو به سورس اصلی پایتون (CPython) اضافه کنه.

این فایل PDF رو هم دانلود کنید بد نیست. فایل یکی از کنفرانس های معرفی پروژه ی Unladen Swallow هستش. البته یکم قدیمی شده چون پروژه خیلی سریع داره پیشرفت میکنه. من نظرم اینه که اگه به سایت پروژه برید و اطلاعات اونجا رو بخونید بهتر کمکتون میکنه.

کیوت 4.5 منتشر شد.

خب بالاخره روزی که خیلی ها منتظر بودن رسید و نوکیا نسخه ی 4.5 کیوت رو حدودا دو روزه پیش منتشر کرد.

به دنبال اون برنامه ی Qt Creator به عنوان IDE مخصوص برنامه نویسی ++C و کیوت که قبلا در نسخه آزمایشی به سر می برد ( و همچنین فقط با مجوز GPL در دسترس بود)  به نسخه ی پایدار تبدیل شد ( و تحت مجوز LGPL) برای دانلود آماده شد. این یعنی اینکه اگه مردم یکم بهتر تصمیم گیری کنن, دیگه چیزایی مثل ویژوال استودیو رو باید به تاریخ بسپرن چون با وجود یک محیط ویژوال کاملا حرفه ایی و آزاد, اون هم برای یکی از پر امکانات ترین فریم ورک های GUI حال حاظر, کار کردن با ویژوال استودیو واقعا مسخرست. بیاین با خودمون صادق باشیم, 90% افرادی که زبان های ماکروسافتی رو انتخاب میکنن فقط به خاطر راحتی کار با ویژوال استودیو هستش و 60% از همین 90% حتی نمی تونن بدون ویژوال استودیو یه برنامه ی ساده رو هم بنویسن.

اما فقط Qt Creator نیست… جدیدا سرعت توسعه IDE معروف محیط KDE یعنی kdevelop هم به شدت بالا رفته و می تونید از همین الان اطمینان داشته باشید که تا چند مدت دیگه صحبت اصلی مردم تو انجمن های اوپن سورس اینه که بین kdevelop و Qt Creator کدوم یکی رو باید انتخاب کنن.

از طرفی بسته ی SDK این پلتفرم که برای برنامه نویس های مشتاق به توسعه و بهبود کیوت آماده شده هم در دسترس قرار گرفت.

از این به بعد تمام برنامه های مبتنی بر کیوت و مخصوصا تمام قسمت های kde می تونه تحت مجوز LGPL منتشر بشه (البته نه کاملا همه ی قسمت ها!). میشه گفت جنگ بین GTK و QT ( و متعاقب اون جنگ بین GNOME و KDE ) تازه از الآن شروع شده چون تا قبل از این هیچکسی جز برنامه نویس های QT نمی تونستن کدها رو توسعه بدن اما از الآن به بعد همه می تونن در توسعه ی اون شریک باشند. شما هم از همین الآن آماده ی نوشته شدن برنامه ی زیادی بر پایه کیوت و همچنین تجدید نظر تعداد زیادی از توسعه دهنده ها در مورد مجوز برنامشون که بر پایه کیوت نوشته شده بود باشید!

امتحان C…. یعنی همنشینی با عزرائیل

سلامممممممممممممممممممی به گرمی چایی شیرین با کیک! اونم توی یه غروب خونک…

از حال و احوال بگم واستون که آقا بد نمیگذره, خوبم نمیگذره. هنوز نفس بالا میاد. چن روز پیش اولین امتحانمو دادم. “”"C“”". 6 تا سوال بود که سوال 5 رو نصفه نوشتم. سوال 6 رو هم کامل غلط نوشتم. توی سوال 6 باید مرتب سازی حبابی و جستجوی دو دویی انجام میدادیم که من همش با اعداد این کارو کرده بودم. اما این تو گفته بود باید با رشته ها انجام بدیم. من یه لحظه قاط زدمو خلاصه کدهایی نوشتم بس آش شعله قلم کار. امتحان از 12 نمره بود. با این وضعیت من میشم 9.5که با سه نمره ی عملی که کامل گرفتمو اون 1.5 نمره امحان میان ترم میشم 14 که برای یه درسی مثل C از سره من هم زیاده. آخه تا به حال بهتون نگفته بودم. من ریاضیم خیییییییییییییییییییییییییلی ضعیفه. توی C هم که تازه دست استادا باز میشه و ما رو میبندن به سوال های ریاضی. اونم از روی کتاب جعفر نژاد قمی که توی صفحه اولش Java رو به عنوان یه زبان سطح میانی معرفی میکنه!!!! حالا بگذریم که داره C رو با کامپایلر TC درس میده. خدا بداد دانشجوهای مملکت برسه که با یه همچین کتاب ها و منابعی دارن مدرک میگیرن.

امتحان هام نهم همین ماه تموم میشه. بعد از امتحانات اولین کاری که میکنم تموم کردن نسخه جدید xFDC هست که زیادی دراه کش دار میشه. البته در مقایسه با پیشرفت های جدیدش خب چیزی نیست. کل کدهای قسمت مربوط به فایل های XDB با CElementTree نوشته شده که در حال حاظر فکر میکنم سریع ترین کتابخونه کار با فایل های xml توی پایتون هستش. چیزی که خودم دارم بدون آزمایش ها و از نظر احساسی حس میکنم بالاتر رفتن سرعت عمل با مخازن دیکشنری از 5 تا 15 برابر هستش. البته هنوز آخره کار معلوم نیست. شاید یه دفعه تصمیم بگیرم کل کدها رو عوض کنم. به هر حال سعی میکنم این جور فکرها رو به بعد از امتحانات شیفت بدم. فعلا عرضی نیست. زت زیاد!

من صاحب ++C نیستم!

این بار یه سری به سایت سازنده و لیدر C++ زدم. حرف های باحال و جالبی میزد, حرف هایی که شاید من همیشه برعکسشون رو فکر میکردیم. تو این سایت چند تا FAQ باحال گذاشته که تمام شک و شبهه ها رو برطرف میکنه. پیشنهاد میکنم حتما بخونید تا نظرتون در مورد خیلی از مسایل مربوط به C/C++ عوض بشه.( جالب اینه که اقای Stroustrup به هیچ وجه لفظ “C/C++” رو قبول نداره و میگه من به هیچ وجه از این لفظ استفاده نمیکنم مگر این که بخوام در مورد مسایلی که مربوط به جفتشونه صحبت کنم, و گرنه C++ با C فاصله زیادی داره!)

نکته اول: تابع اصلی main() به هیچ وجه نباید به صورت void تعریف بشه و باید همیشه از نوع int استفاده کرد. یه چیز دیگه هم که من نمیدونستم این بود که تو C++ تابع main از نوع int , لازم نیست حتما عبارت return رو همراه خودش داشته باشه و به خودی خود کد 0 برگشت داده میشه!

نکته دوم: برعکس خیلی از زبان ها, نوع null و مقدار عددی 0 در C++ دقیقا یک معنی رو میدن.

نکته سوم: دستور cout باید به صورت “see-out” تلفظ بشه. حرف “c” اول این دستور هم از نوع داده ای char برداشته شده.( یعنی کسی بوده که به غیر از این روش تلفظ کنه؟)

نکته چهارم: تمام پیاده سازی های اصلی C++ از thread ها پشتیبانی میکنند ولی استاندارد ISO هیچ وقت از اون پشتیبانی نکرده!!

نکته پنجم: برنامه پایه ای HelloWord در C++ که با gcc –o2 در یونیکس کامپایل شده باشه, حجمش کوچیکتر از همتای خودش توی C میشه.

نکته ششم: Stroustrup جاوا رو بیشتر شبیه smalltalk (جد قدیمی C++) میبینه تا خود C++ !

نکته هفتم: اینطور که میگه هیچ وقت تو زندگیش نفهمیده که کی این شایعه رو که “ Stroustrup گفته Ada تو پروژه های بزرگ مناسبتر از C++ هست” رو پخش کرده!

نکته هشتم: Stroustrup هیچ وقت خودش رو صاحب C++ نمیدونه و میگه اگه کسی قرار باشه این ادعا رو بکنه, اون شخص باید سازمان ISO باشه.

نکته نهم: اسم C++ از روی عملگر معروف ++ که توی C وجود داشت برداشته شده.

نکته دهم: یه کم به خودتون زحمت بدید و خودتون برید بقیش رو بخونید زیاد بد نیست ها….

libxml هم با من شوخی میکنه…

برای اون هایی که نمیدونن libxml چی هست باید بگم که یکی از سطح پایین ترین کتابخونه های ساخته شده برای کار با فایل های xml در لینوکس هستش که پروژه های زیادی مثل گنوم هم از اون استفاده میکنن(یعنی در واقع libxml برای پروژه گنوم ساخته شد).

این برنامه xFDC(اسمش دوباره عوض شد) که نوشتم از پکیج minidom خود پیتون استفاده میکنه و خوب این پکیج سرعت زیادی برای کار با فایل های xml نداره و توی کار با فایل های بزرگ کم میاره. به خاطر همین هم تصمیم گرفتم قسمت مربوط به کار با قایل های xml رو به طور کامل با رابط libxml بنویسم. اولش هیچ آشنایی با این رابط نداشتم, بعد یه کم گردش توی گوگل فهمیدم که پروژه رابط libxml برای پیتون جر پروژه های معروفی هستش که حتی به اندازه چغندر هم به مستندسازی API ها اهمیت نمیدن(حالا خر بیار و باقالی بار کن!).

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

خلاصه با هر بدبختی که بود این کار انجام شد و اون قسمت از کدها به طور کامل باز نویسی شد اما….

نتیجه اون چیزی که فکر میکردم در نیومد!…

قبلا بارگذاری فایل مخزن کلمه ی computer-elec تو دستگاه من با پکیج minidom هشت ثانیه طول می کشید. اما حالا همین کار و با همون الگوریتم قبلی با 2Libxml هیجده ثانیه طول کشید!!!!!!

انتظارم این بود که با راهکار جدید سرعت حداقل 4 برابر زیاد تر شه اما حالا میبینید که سرعت 2.5 برابر کم تر شده. نمیدونم شاید الگوریتم کار زیاد درست نیست. اما هر چی که فکر میکنم برای کار به این سادگی الگوریتمی از این بهتر پیدا نمی کنم. خواهشا اگه کسی نظری داره حتما بگه شاید مشکل حل شد….

—————————————–

به روز رسانی:

برنامه xFDC دیگر از ماژول minidom برای پردازش فایل های xml استفاده نمی کنه و در حال حاضر از بسته ی cElementTree برای این کار استفاده میشه که سرعت بسیار بالایی داره و منابع سخت افزاری کمتری هم می خواد.