کئی سالوں سے، Python تھریڈز ایک وقت میں ایک سے زیادہ CPU کور استعمال نہیں کر سکتے تھے۔ اسے فری تھریڈڈ بلڈ میں تبدیل کر دیا گیا ہے، جسے اب اس تحریر تک باضابطہ طور پر تائید حاصل ہے۔ یہاں اس کا ایک مختصر تعارف ہے اور یہ ایک بڑا مسئلہ کیوں ہوسکتا ہے۔
تو فری تھریڈڈ ازگر کیا ہے؟
GIL اب اختیاری ہے، لیکن اس کے فوائد اور نقصانات ہیں۔
ازگر کے پاس اپنے آغاز سے ہی گلوبل انٹرپریٹر لاک ہے، جسے GIL کے نام سے جانا جاتا ہے۔ لاکنگ ایک وقت میں صرف ایک تھریڈ کو ایک عمل کے اندر Python بائیک کوڈ کو چلانے کی اجازت دیتا ہے۔ یہ CPython کے میموری مینجمنٹ کو آسان اور محفوظ رکھتا ہے، لیکن اس کا مطلب یہ بھی ہے کہ تھریڈز CPU کے پابند کام کو کور میں تقسیم نہیں کر سکتے۔ حقیقی متوازی کے خواہاں ڈویلپرز نے عام طور پر ملٹی پروسیسنگ کا استعمال کیا ہے، جو ان کی اپنی یادداشت کے ساتھ الگ الگ عمل پیدا کرتا ہے، یا سی ایکسٹینشنز کا سہارا لیتے ہیں جو تالے جاری کرتے ہیں۔ فری تھریڈڈ بلڈز حدود کو مکمل طور پر ہٹا دیتی ہیں۔
PEP 703 میں تجویز کردہ اور اکتوبر 2024 میں Python 3.13 میں تجرباتی طور پر جاری کیا گیا، یہ خصوصیت متعدد تھریڈز کو مختلف کوروں پر متوازی طور پر Python کوڈ چلانے کی اجازت دیتی ہے۔ پہلی ریلیز کے حقیقی اخراجات تھے۔ سنگل تھریڈڈ کوڈ نمایاں طور پر آہستہ چلا، اور کچھ اندرونی اصلاح کو بند کرنا پڑا کیونکہ وہ ابھی تک تھریڈ سے محفوظ نہیں تھے۔ اہم موڑ PEP 779 تھا، جس نے تعمیراتی فروغ کے معیار کو طے کیا اور اسے جون 2025 میں منظور کیا گیا۔ اکتوبر 2025 میں جاری ہونے والے Python 3.14 نے اس پر پورا اترا۔
دستاویزات اسے فری تھریڈڈ بلڈز کہتی ہیں جو اب تعاون یافتہ ہیں اور اب تجرباتی نہیں ہیں، لیکن یہ اب بھی اختیاری ہے اور پہلے سے طے شدہ ترجمان سے الگ ہے۔ بنیادی ٹیم اسے ایک اضافی منصوبے کے فیز 2 کے طور پر بیان کرتی ہے۔ کیا ہم بعد کے مرحلے میں فری تھریڈنگ کو واحد تعمیر بنائیں گے یہ اب بھی ایک کھلا سوال ہے۔
ایک خاص اڈاپٹیو انٹرپریٹر جو کہ ریگولر Python کوڈ کو تیز کرتا ہے اب فری تھریڈڈ موڈ میں چلتا ہے، جس سے معیاری تعمیر کے مقابلے میں سنگل تھریڈ کی سزا کو تقریباً 5-10% تک کم کر دیا جاتا ہے۔ آپ موجودہ انسٹالیشن پر سوئچ پلٹانے کے بجائے اپنی خود کی تعمیر کو انسٹال کرنے کا بھی انتخاب کریں گے، جس پر عام طور پر 3.14t کا لیبل لگا ہوتا ہے۔ uv جیسے ٹولز دو بلڈز کو ساتھ رکھ سکتے ہیں تاکہ آپ ان کا اپنے کوڈ میں موازنہ کر سکیں۔ یہ ایک ہی زبان ہے جس کے نیچے ایک مختلف رن ٹائم ہے۔
اس نے اصل میں آپ کی مدد کیسے کی؟
ملٹی پروسیسنگ اوور ہیڈ کے بغیر حقیقی ہم آہنگی
فائدہ سب سے زیادہ واضح ہے CPU کے پابند کوڈ میں جسے دھاگوں میں تقسیم کیا جا سکتا ہے۔ فائلوں کے بڑے بیچوں کو پارس کرنے اور تبدیل کرنے، بہت سے ریکارڈز پر اسکور یا فیچر کیلکولیشن چلانے، یا ورکرز کے تالاب میں ڈیٹا کے آزاد حصوں پر کارروائی کرنے کے بارے میں سوچیں۔ معیاری تعمیر میں، تھریڈ پول ایسا کرنے سے تقریباً کچھ حاصل نہیں ہوتا ہے کیونکہ لاک حساب کو سیریلائز کرتا ہے۔ لہذا ٹیم نے ملٹی پروسیسنگ کی طرف رخ کیا، جو اپنے ٹیکس کے ساتھ آیا۔ تمام دلائل اور نتائج کو عمل کے درمیان اچار اور منتقل کیا جانا چاہیے، میموری کے استعمال کو بڑھانا اور ابتدائی لاگت میں اضافہ کرنا چاہیے کیونکہ ہر کارکن کے پاس مشترکہ ڈیٹا کی اپنی کاپی ہوتی ہے۔
GIL کے چلے جانے کے بعد، ایک ہی تھریڈ کوڈ کو کور میں پھیلایا جا سکتا ہے جبکہ تمام تھریڈز میموری سے ایک ہی چیز کو پڑھتے ہیں۔ یہ سیریلائزیشن کے مرحلے کو ختم کرتا ہے اور پروگرام کو آسان رکھتا ہے۔ کیونکہ اب آپ کو اس ہارڈ ویئر کو استعمال کرنے کے لیے الگ پروسیس فن تعمیر کی ضرورت نہیں ہے جس کے لیے آپ نے ادائیگی کی ہے۔ فائدہ اس بات پر منحصر ہے کہ کام کو کتنی اچھی طرح سے تقسیم کیا گیا ہے۔ وہ کام جو اپنا زیادہ تر وقت نیٹ ورک کال کرنے یا ڈسک کے انتظار میں گزارتے ہیں وہ تھریڈز کے ساتھ پہلے سے ہی ٹھیک ہیں کیونکہ وہ I/O کے دوران لاک ہوتے ہیں اور شاذ و نادر ہی کوئی تبدیلی نظر آتی ہے۔
مشترکہ حالت پر بہت سارے لاکنگ کے ساتھ بھاری کمپیوٹیشن کو ملانے والے آپریشنز اچھی طرح سے پیمانہ نہیں ہوسکتے ہیں، قطع نظر اس سے کہ کوئی بھی تعمیر چلائی جائے۔ بہترین نتائج کام کے بوجھ سے آتے ہیں جو آزاد حصوں میں تقسیم ہوتے ہیں اور اپنا زیادہ تر وقت Python کوڈ یا لائبریریوں میں گزارتے ہیں جو فری تھریڈنگ کے ساتھ تعاون کرتی ہیں۔ جاننے کا واحد ایماندار طریقہ پیمائش کرنا ہے۔ ہم پروڈکشن میں جن مشینوں کو چلائیں گے ان پر مختلف تھریڈ کی گنتی کے ساتھ ہم دونوں بلڈز پر ایک ہی تھریڈ بینچ مارک چلاتے ہیں۔ توقع کریں کہ سنگل تھریڈڈ موازنہ معیاری تعمیر کو قدرے پسند کرے گا، جبکہ ملٹی تھریڈڈ موازنہ اس بات کا تعین کرے گا کہ آیا سوئچ اس کے قابل ہے۔
کیا یہ hype کے قابل ہے؟
امید افزا اور قابل استعمال، لیکن ابھی تک ڈیفالٹ نہیں ہے۔
جیسا کہ میں ہمیشہ کہتا ہوں کہ مضمون کو ختم کرنے کی کوشش کرتے وقت، یہ منحصر ہے۔ عمارتیں تعاون یافتہ ہیں لیکن آپٹ ان رہتی ہیں اور ان کی لاگت صفر ہے۔ سنگل تھریڈڈ کوڈ اب بھی چند فیصد سست چلتا ہے، اس لیے وہ ایپلیکیشنز جو کمپیوٹیشن کے لیے تھریڈز کا استعمال نہیں کرتی ہیں انہیں کچھ حاصل نہیں ہوتا اور صرف تھوڑا سا نقصان ہوتا ہے۔ 3.14 میں تجرباتی JIT کمپائلر ابھی تک فری تھریڈڈ بلڈز میں دستیاب نہیں ہے، جو اہم ہے اگر آپ اس بہتری کو دیکھنے کے منتظر ہیں۔
یہاں سب سے بڑی رکاوٹ ماحولیاتی نظام ہے۔ سی ایکسٹینشن پر مشتمل پیکجوں کے لیے فری تھریڈڈ ترجمانوں کے لیے بنائے گئے پہیوں کی ضرورت ہوتی ہے، اور بنیادی سائنسی Python لائبریریوں کے باہر کوریج اب بھی پیچیدہ ہے، لہذا ایک غیر تعاون یافتہ انحصار اپنانے کو روک سکتا ہے۔ Python 3.15، اکتوبر 2026 میں ریلیز ہوا، PEP 803 کے ساتھ اس کا پتہ دیتا ہے، جو abi3t کے ساتھ ٹیگ شدہ فری تھریڈڈ بلڈز کے لیے ایک مستحکم ABI کا اضافہ کرتا ہے۔ یہ ایکسٹینشن مصنفین کو ایک وہیل شائع کرنے کی اجازت دیتا ہے جو فری تھریڈڈ ریلیز میں کام کرتا ہے، لیکن تعمیراتی ٹولز اب بھی پکڑ رہے ہیں۔
آپ کے اپنے کوڈ میں بھی پرسکون خطرات ہیں۔ GIL نادانستہ طور پر نسل کی بہت سی شرائط کو چھپاتا ہے، اور GIL کو ہٹانے سے کوڈ میں ایسے کیڑے سامنے آسکتے ہیں جو کبھی تھریڈ سے محفوظ نہیں تھے۔ مشترکہ حالت کا جائزہ لیں، جہاں ضروری ہو تالے شامل کریں، اور نتائج پر بھروسہ کرنے سے پہلے بوجھ کے نیچے ٹیسٹ کریں۔ پھر بھی، سمت واضح ہے۔ بڑی لائبریریاں فری تھریڈڈ تعمیرات فراہم کر رہی ہیں، اور بنیادی ٹیم کام کو ضمنی تجربے کے بجائے طویل مدتی عزم کے طور پر دیکھ رہی ہے۔ اگر آپ کا کام کا بوجھ CPU- محدود، متوازی، اور مطابقت پذیر پیکجوں پر بنایا گیا ہے، تو اسے ابھی آزمائیں۔ بصورت دیگر، دیکھتے رہیں اور ہر ریلیز کے ساتھ دوبارہ ٹیسٹ کریں۔
جانچ کے قابل، لیکن ابھی تک ڈیفالٹ نہیں ہے۔
فری تھریڈڈ ازگر تجسس سے ایک معاون آپشن کی طرف چلا گیا ہے۔ یہ CPU-انتہائی متوازی کارروائیوں کا بدلہ دیتا ہے اور اس کی قیمت کہیں اور ہے۔ انحصار چیک کریں، اپنے کوڈ کو بینچ مارک کریں، اور جہاں نمبر اس کا جواز پیش کرتے ہیں اسے اختیار کریں۔