کلف کلک کریں۔ - Cratus کے CTO (عمل میں بہتری کے لیے IoT سینسر)، کئی اسٹارٹ اپس کے بانی اور شریک بانی (بشمول راکٹ ریئل ٹائم اسکول، نیورینسک اور H2O.ai) کئی کامیاب ایگزٹ کے ساتھ۔ کلف نے اپنا پہلا مرتب 15 سال کی عمر میں لکھا (TRS Z-80 کے لیے پاسکل)! وہ جاوا میں C2 پر اپنے کام کے لیے مشہور ہے (بحیرہ نوڈس IR)۔ اس مرتب کرنے والے نے دنیا کو دکھایا کہ جے آئی ٹی اعلیٰ معیار کا کوڈ تیار کر سکتی ہے، جو جاوا کے ایک اہم جدید سافٹ ویئر پلیٹ فارم کے طور پر ابھرنے کے عوامل میں سے ایک تھا۔ پھر Cliff نے Azul Systems کو خالص Java سافٹ ویئر کے ساتھ ایک 864 کور مین فریم بنانے میں مدد کی جو 500 ملی سیکنڈ کے اندر 10 گیگا بائٹ ہیپ پر GC توقف کو سپورٹ کرتا ہے۔ عام طور پر، کلف JVM کے تمام پہلوؤں پر کام کرنے میں کامیاب رہا۔
یہ habrapost کلف کے ساتھ ایک زبردست انٹرویو ہے۔ ہم درج ذیل موضوعات پر بات کریں گے۔
- نچلی سطح کی اصلاح میں منتقلی۔
- ایک بڑا ری فیکٹرنگ کیسے کریں۔
- لاگت کا ماڈل
- کم سطح کی اصلاح کی تربیت
- کارکردگی میں بہتری کی عملی مثالیں۔
- اپنی پروگرامنگ زبان کیوں بنائیں
- پرفارمنس انجینئر کیریئر
- تکنیکی چیلنجز
- رجسٹر ایلوکیشن اور ملٹی کور کے بارے میں تھوڑا سا
- زندگی کا سب سے بڑا چیلنج
انٹرویو کی طرف سے منعقد کیا جاتا ہے:
- آندرے ستارن ایمیزون ویب سروسز سے۔ اپنے کیرئیر میں، وہ بالکل مختلف پروجیکٹس میں کام کرنے میں کامیاب ہوا: اس نے Yandex میں NewSQL تقسیم شدہ ڈیٹا بیس، Kaspersky Lab میں کلاؤڈ ڈٹیکشن سسٹم، Mail.ru میں ایک ملٹی پلیئر گیم اور ڈوئچے بینک میں زرمبادلہ کی قیمتوں کا حساب لگانے کی سروس کا تجربہ کیا۔ بڑے پیمانے پر بیک اینڈ اور تقسیم شدہ نظاموں کی جانچ میں دلچسپی رکھتے ہیں۔
- ولادیمیر سیٹنکوف نیٹ کریکر سے۔ NetCracker OS کی کارکردگی اور اسکیل ایبلٹی پر دس سال کا کام، ٹیلی کام آپریٹرز کے ذریعے نیٹ ورک اور نیٹ ورک آلات کے انتظام کے عمل کو خودکار کرنے کے لیے استعمال کیا جاتا ہے۔ جاوا اور اوریکل ڈیٹا بیس کی کارکردگی کے مسائل میں دلچسپی رکھتے ہیں۔ آفیشل PostgreSQL JDBC ڈرائیور میں ایک درجن سے زیادہ کارکردگی میں بہتری کا مصنف۔
نچلی سطح کی اصلاح میں منتقلی۔
اینڈریو: آپ جے آئی ٹی کی تالیف، جاوا، اور عمومی طور پر کارکردگی کے کام کی دنیا میں ایک بڑا نام ہیں، ٹھیک ہے؟
چٹان: ایسا ہی ہے!
اینڈریو: آئیے کارکردگی کے کام کے بارے میں کچھ عمومی سوالات کے ساتھ شروع کرتے ہیں۔ سی پی یو کی سطح پر کام کرنے جیسی اعلیٰ سطح اور کم سطح کی اصلاح کے درمیان انتخاب کے بارے میں آپ کا کیا خیال ہے؟
چٹان: ہاں، یہاں سب کچھ آسان ہے۔ تیز ترین کوڈ وہ ہے جو کبھی نہیں چلتا ہے۔ لہذا، آپ کو ہمیشہ ایک اعلی سطح سے شروع کرنے کی ضرورت ہے، الگورتھم پر کام کریں. ایک بہتر O اشارے بدتر O اشارے کو شکست دے گا، جب تک کہ کچھ کافی بڑے مستقل مداخلت نہ کریں۔ نچلی سطح کی چیزیں آخری چلتی ہیں۔ عام طور پر، اگر آپ نے اپنے باقی اسٹیک کو کافی حد تک بہتر کر لیا ہے اور ابھی بھی کچھ دلچسپ چیزیں باقی ہیں، تو یہ ایک نچلی سطح ہے۔ لیکن ایک اعلی سطح سے کیسے شروع کریں؟ آپ کیسے جانتے ہیں کہ کافی اعلیٰ سطحی کام ہو چکا ہے؟ ٹھیک ہے... کوئی راستہ نہیں۔ کوئی تیار شدہ ترکیبیں نہیں ہیں۔ آپ کو مسئلہ کو سمجھنے کی ضرورت ہے، فیصلہ کریں کہ آپ کیا کرنے جا رہے ہیں (تاکہ مستقبل میں غیر ضروری قدم نہ اٹھائیں) اور پھر آپ پروفائلر کو ننگا کر سکتے ہیں، جو کچھ مفید کہہ سکتا ہے۔ کسی وقت، آپ کو خود احساس ہوتا ہے کہ آپ نے غیر ضروری چیزوں سے چھٹکارا حاصل کر لیا ہے اور اب وقت آگیا ہے کہ کچھ کم درجے کی ٹھیک ٹیوننگ کریں۔ یہ یقیناً ایک خاص قسم کا فن ہے۔ بہت سارے لوگ غیر ضروری کام کرتے ہیں، لیکن اتنی تیزی سے آگے بڑھ رہے ہیں کہ ان کے پاس پیداواری صلاحیت کے بارے میں فکر کرنے کا وقت نہیں ہے۔ لیکن یہ اس وقت تک ہے جب تک سوال دو ٹوک طور پر نہیں اٹھتا۔ عام طور پر 99% وقت میں کوئی بھی پرواہ نہیں کرتا کہ میں کیا کرتا ہوں، اس لمحے تک جب کوئی اہم چیز اس نازک راستے پر آجائے جس کی کوئی پرواہ نہیں کرتا۔ اور یہاں ہر کوئی آپ کو اس بارے میں تنگ کرنا شروع کر دیتا ہے کہ "یہ شروع سے ہی کام کیوں نہیں کر رہا"۔ عام طور پر، کارکردگی میں بہتری کے لیے ہمیشہ کچھ نہ کچھ ہوتا ہے۔ لیکن 99% وقت آپ کے پاس کوئی لیڈ نہیں ہے! آپ صرف کچھ کام کرنے کی کوشش کر رہے ہیں اور اس عمل میں آپ کو پتہ چلتا ہے کہ کیا ضروری ہے۔ آپ کبھی بھی پہلے سے نہیں جان سکتے کہ اس ٹکڑے کو کامل ہونے کی ضرورت ہے، لہذا، حقیقت میں، آپ کو ہر چیز میں کامل ہونا پڑے گا۔ لیکن یہ ناممکن ہے اور آپ ایسا نہیں کرتے۔ ٹھیک کرنے کے لیے ہمیشہ بہت سی چیزیں ہوتی ہیں - اور یہ بالکل عام بات ہے۔
ایک بڑا ری فیکٹرنگ کیسے کریں۔
اینڈریو: آپ کارکردگی پر کیسے کام کرتے ہیں؟ یہ ایک کراس کٹنگ مسئلہ ہے۔ مثال کے طور پر، کیا آپ کو کبھی ان مسائل پر کام کرنا پڑا ہے جو بہت ساری موجودہ فعالیت کے چوراہے سے پیدا ہوتے ہیں؟
چٹان: میں اس سے بچنے کی کوشش کرتا ہوں۔ اگر میں جانتا ہوں کہ کارکردگی ایک مسئلہ ہو گی، میں کوڈنگ شروع کرنے سے پہلے اس کے بارے میں سوچتا ہوں، خاص طور پر ڈیٹا ڈھانچے کے ساتھ۔ لیکن اکثر آپ کو یہ سب بہت بعد میں پتہ چلتا ہے۔ اور پھر آپ کو انتہائی اقدامات پر جانا ہوگا اور وہ کرنا ہوگا جسے میں "دوبارہ لکھنا اور فتح کرنا" کہتا ہوں: آپ کو کافی بڑا ٹکڑا پکڑنے کی ضرورت ہے۔ کارکردگی کے مسائل یا کسی اور چیز کی وجہ سے کچھ کوڈ کو اب بھی دوبارہ لکھنا پڑے گا۔ کوڈ کو دوبارہ لکھنے کی وجہ کچھ بھی ہو، چھوٹے ٹکڑے سے بڑے ٹکڑے کو دوبارہ لکھنا تقریباً ہمیشہ بہتر ہوتا ہے۔ اس وقت، ہر کوئی خوف سے کانپنے لگتا ہے: "اوہ میرے خدا، آپ اتنے کوڈ کو چھو نہیں سکتے!" لیکن حقیقت میں، یہ نقطہ نظر تقریبا ہمیشہ بہت بہتر کام کرتا ہے. آپ کو فوری طور پر ایک بڑا مسئلہ اٹھانا ہوگا، اس کے گرد ایک بڑا دائرہ کھینچنا ہوگا اور کہنا ہوگا: میں دائرے کے اندر ہر چیز کو دوبارہ لکھوں گا۔ بارڈر اس کے اندر موجود مواد سے بہت چھوٹا ہے جسے تبدیل کرنے کی ضرورت ہے۔ اور اگر اس طرح کی حد بندی آپ کو اندر سے کام کرنے کی اجازت دیتی ہے، تو آپ کے ہاتھ آزاد ہیں، جو چاہیں کریں. ایک بار جب آپ مسئلہ کو سمجھتے ہیں، تو دوبارہ لکھنے کا عمل بہت آسان ہو جاتا ہے، لہذا ایک بڑا کام لیں!
ایک ہی وقت میں، جب آپ ایک بڑی تحریر کرتے ہیں اور محسوس کرتے ہیں کہ کارکردگی ایک مسئلہ بننے والی ہے، تو آپ فوری طور پر اس کے بارے میں فکر کرنا شروع کر سکتے ہیں۔ یہ عام طور پر آسان چیزوں میں بدل جاتا ہے جیسے کہ "ڈیٹا کاپی نہ کریں، جتنا ممکن ہو ڈیٹا کا نظم کریں، اسے چھوٹا بنائیں۔" بڑی دوبارہ تحریروں میں، کارکردگی کو بہتر بنانے کے معیاری طریقے ہیں۔ اور وہ تقریباً ہمیشہ ڈیٹا کے گرد گھومتے ہیں۔
لاگت کا ماڈل
اینڈریو: ایک پوڈ کاسٹ میں آپ نے پیداواری صلاحیت کے تناظر میں لاگت کے ماڈلز کے بارے میں بات کی۔ کیا آپ بتا سکتے ہیں کہ آپ کا اس سے کیا مطلب ہے؟
چٹان: یقیناً۔ میں ایک ایسے دور میں پیدا ہوا تھا جب پروسیسر کی کارکردگی انتہائی اہم تھی۔ اور یہ دور دوبارہ لوٹتا ہے - قسمت ستم ظریفی کے بغیر نہیں ہے۔ میں نے آٹھ بٹ مشینوں کے دنوں میں رہنا شروع کیا؛ میرا پہلا کمپیوٹر 256 بائٹس کے ساتھ کام کرتا تھا۔ بالکل بائٹس۔ سب کچھ بہت چھوٹا تھا۔ ہدایات کو شمار کرنا پڑا، اور جیسے ہی ہم نے پروگرامنگ لینگویج اسٹیک کو بڑھانا شروع کیا، زبانیں زیادہ سے زیادہ بڑھ گئیں۔ اسمبلر تھا، پھر بنیادی، پھر C، اور C نے بہت ساری تفصیلات کا خیال رکھا، جیسے کہ رجسٹر ایلوکیشن اور انسٹرکشن سلیکشن۔ لیکن وہاں سب کچھ بالکل واضح تھا، اور اگر میں نے متغیر کی مثال کی طرف اشارہ کیا، تو مجھے بوجھ ملے گا، اور اس ہدایت کی قیمت معلوم ہے۔ ہارڈ ویئر ایک مخصوص تعداد میں مشین سائیکل تیار کرتا ہے، لہذا مختلف چیزوں کے عمل کی رفتار کا حساب صرف ان تمام ہدایات کو شامل کرکے لگایا جا سکتا ہے جو آپ چلانے جا رہے ہیں۔ ہر ایک موازنہ/ٹیسٹ/برانچ/کال/لوڈ/اسٹور کو شامل کیا جا سکتا ہے اور کہا جا سکتا ہے: یہ آپ کے لیے عمل درآمد کا وقت ہے۔ کارکردگی کو بہتر بنانے پر کام کرتے وقت، آپ یقینی طور پر اس بات پر دھیان دیں گے کہ چھوٹے گرم چکروں سے کون سے نمبر ملتے ہیں۔
لیکن جیسے ہی آپ جاوا، ازگر اور اسی طرح کی چیزوں پر سوئچ کرتے ہیں، آپ بہت جلد نچلی سطح کے ہارڈ ویئر سے دور ہو جاتے ہیں۔ جاوا میں گیٹر کو کال کرنے کی قیمت کیا ہے؟ اگر ہاٹ اسپاٹ میں جے آئی ٹی درست ہے۔ ، یہ لوڈ ہو جائے گا، لیکن اگر اس نے ایسا نہیں کیا، تو یہ ایک فنکشن کال ہوگی۔ چونکہ کال ہاٹ لوپ پر ہے، اس لیے یہ اس لوپ میں موجود دیگر تمام اصلاحوں کو اوور رائیڈ کر دے گی۔ لہذا، حقیقی قیمت بہت زیادہ ہوگی. اور آپ فوری طور پر کوڈ کے ٹکڑے کو دیکھنے اور سمجھنے کی صلاحیت کھو دیتے ہیں کہ ہمیں اسے پروسیسر کی گھڑی کی رفتار، میموری اور استعمال شدہ کیش کے لحاظ سے عمل میں لانا چاہیے۔ یہ سب صرف اس صورت میں دلچسپ ہو جاتا ہے جب آپ واقعی کارکردگی میں شامل ہوں۔
اب ہم خود کو ایسی صورتحال میں پاتے ہیں جہاں پروسیسر کی رفتار ایک دہائی سے مشکل سے بڑھی ہے۔ پرانے دن واپس آ گئے ہیں! اب آپ اچھی سنگل تھریڈڈ کارکردگی پر اعتماد نہیں کر سکتے۔ لیکن اگر آپ اچانک متوازی کمپیوٹنگ میں آجاتے ہیں تو یہ ناقابل یقین حد تک مشکل ہے، ہر کوئی آپ کو جیمز بانڈ کی طرح دیکھتا ہے۔ یہاں دس گنا تیز رفتاریاں عام طور پر ایسی جگہوں پر ہوتی ہیں جہاں کسی نے کچھ گڑبڑ کیا ہو۔ ہم آہنگی کو بہت زیادہ کام کی ضرورت ہے۔ اس XNUMXx اسپیڈ اپ کو حاصل کرنے کے لیے، آپ کو لاگت کے ماڈل کو سمجھنا ہوگا۔ اس کی قیمت کیا اور کتنی ہے؟ اور ایسا کرنے کے لیے، آپ کو یہ سمجھنے کی ضرورت ہے کہ زبان کس طرح بنیادی ہارڈ ویئر پر فٹ بیٹھتی ہے۔
مارٹن تھامسن نے اپنے بلاگ کے لیے ایک بہترین لفظ کا انتخاب کیا۔ ! آپ کو یہ سمجھنے کی ضرورت ہے کہ ہارڈ ویئر کیا کرنے جا رہا ہے، یہ بالکل کیسے کرے گا، اور یہ کیوں کرتا ہے جو یہ پہلی جگہ کرتا ہے۔ اس کا استعمال کرتے ہوئے، ہدایات کی گنتی شروع کرنا اور یہ معلوم کرنا کافی آسان ہے کہ عمل درآمد کا وقت کہاں جا رہا ہے۔ اگر آپ کے پاس مناسب تربیت نہیں ہے تو، آپ صرف ایک اندھیرے کمرے میں کالی بلی کی تلاش کر رہے ہیں۔ میں ایسے لوگوں کو دیکھتا ہوں جو ہر وقت کارکردگی کو بہتر بناتے ہیں جنہیں اندازہ نہیں ہوتا کہ وہ کیا کر رہے ہیں۔ وہ بہت نقصان اٹھا رہے ہیں اور زیادہ ترقی نہیں کر رہے ہیں۔ اور جب میں کوڈ کا وہی ٹکڑا لیتا ہوں، چند چھوٹے ہیکس میں پھسل جاتا ہوں اور پانچ یا دس گنا اسپیڈ اپ حاصل کرتا ہوں، تو وہ اس طرح ہیں: ٹھیک ہے، یہ مناسب نہیں ہے، ہمیں پہلے ہی معلوم تھا کہ آپ بہتر ہیں۔ حیرت انگیز میں کس کے بارے میں بات کر رہا ہوں... لاگت کا ماڈل اس بارے میں ہے کہ آپ کس قسم کا کوڈ لکھتے ہیں اور بڑی تصویر میں یہ اوسطاً کتنی تیزی سے چلتا ہے۔
اینڈریو: اور آپ اپنے سر میں اتنی مقدار کیسے رکھ سکتے ہیں؟ کیا یہ زیادہ تجربے کے ساتھ حاصل کیا گیا ہے، یا؟ ایسا تجربہ کہاں سے آتا ہے؟
چٹان: ٹھیک ہے، میں نے اپنا تجربہ آسان ترین طریقے سے حاصل نہیں کیا۔ میں نے ان دنوں اسمبلی میں پروگرام کیا جب آپ ہر ایک ہدایت کو سمجھ سکتے تھے۔ یہ احمقانہ لگتا ہے، لیکن اس کے بعد سے Z80 انسٹرکشن سیٹ ہمیشہ میرے ذہن میں، میری یادداشت میں رہتا ہے۔ مجھے بات کرنے کے ایک منٹ میں لوگوں کے نام یاد نہیں ہیں، لیکن مجھے 40 سال پہلے لکھا ہوا کوڈ یاد ہے۔ یہ مضحکہ خیز ہے، یہ ایک سنڈروم کی طرح لگتا ہے"'.
کم سطح کی اصلاح کی تربیت
اینڈریو: کیا اندر جانے کا کوئی آسان طریقہ ہے؟
چٹان: ہاں اور نہ. ہم سب جو ہارڈ ویئر استعمال کرتے ہیں وہ وقت کے ساتھ اتنا زیادہ تبدیل نہیں ہوا ہے۔ آرم اسمارٹ فونز کے علاوہ ہر کوئی x86 استعمال کرتا ہے۔ اگر آپ کسی قسم کی کٹر ایمبیڈنگ نہیں کر رہے ہیں، تو آپ وہی کام کر رہے ہیں۔ ٹھیک ہے، اگلا۔ ہدایات بھی صدیوں سے تبدیل نہیں ہوئیں۔ آپ کو اسمبلی میں جاکر کچھ لکھنا ہوگا۔ زیادہ نہیں، لیکن سمجھنے کے لئے شروع کرنے کے لئے کافی ہے. آپ مسکرا رہے ہیں، لیکن میں پوری سنجیدگی سے بات کر رہا ہوں۔ آپ کو زبان اور ہارڈ ویئر کے درمیان خط و کتابت کو سمجھنے کی ضرورت ہے۔ اس کے بعد آپ کو جاکر تھوڑا سا لکھنا ہوگا اور ایک چھوٹی کھلونا زبان کے لیے ایک چھوٹا سا کھلونا کمپائلر بنانا ہوگا۔ کھلونا کی طرح کا مطلب ہے کہ اسے مناسب وقت میں بنانے کی ضرورت ہے۔ یہ انتہائی آسان ہو سکتا ہے، لیکن اس میں ہدایات پیدا کرنی چاہئیں۔ ایک انسٹرکشن تیار کرنے کا عمل آپ کو اعلی سطحی کوڈ کے درمیان پل کے لیے لاگت کے ماڈل کو سمجھنے میں مدد کرے گا جسے ہر کوئی لکھتا ہے اور مشین کوڈ جو ہارڈ ویئر پر چلتا ہے۔ اس خط و کتابت کو اس وقت دماغ میں جلا دیا جائے گا جب مرتب لکھا جائے گا۔ یہاں تک کہ سب سے آسان کمپائلر۔ اس کے بعد، آپ جاوا کو دیکھنا شروع کر سکتے ہیں اور اس حقیقت کو کہ اس کی معنوی کھائی بہت گہری ہے، اور اس پر پل بنانا زیادہ مشکل ہے۔ جاوا میں، یہ سمجھنا زیادہ مشکل ہے کہ آیا ہمارا پل اچھا نکلا یا برا، اس کے ٹوٹنے کی وجہ کیا ہوگی اور کیا نہیں۔ لیکن آپ کو کسی قسم کے نقطہ آغاز کی ضرورت ہے جہاں آپ کوڈ کو دیکھتے ہیں اور سمجھتے ہیں: "ہاں، یہ گیٹر ہر بار ان لائن ہونا چاہیے۔" اور پھر پتہ چلتا ہے کہ کبھی کبھی ایسا ہوتا ہے، سوائے اس صورت حال کے جب طریقہ بہت بڑا ہو جائے، اور جے آئی ٹی ہر چیز کو ان لائن کرنے لگتی ہے۔ ایسی جگہوں کی کارکردگی کا فوری اندازہ لگایا جا سکتا ہے۔ عام طور پر حاصل کرنے والے اچھی طرح سے کام کرتے ہیں، لیکن پھر آپ بڑے ہاٹ لوپس کو دیکھتے ہیں اور محسوس کرتے ہیں کہ وہاں کچھ فنکشن کالز موجود ہیں جو نہیں جانتے کہ وہ کیا کر رہے ہیں۔ یہ حاصل کرنے والوں کے وسیع پیمانے پر استعمال کا مسئلہ ہے، ان کے مائل نہ ہونے کی وجہ یہ ہے کہ یہ واضح نہیں ہے کہ آیا وہ حاصل کرنے والے ہیں۔ اگر آپ کے پاس بہت چھوٹا کوڈ بیس ہے، تو آپ اسے آسانی سے یاد رکھ سکتے ہیں اور پھر کہہ سکتے ہیں: یہ ایک گیٹر ہے، اور یہ ایک سیٹر ہے۔ ایک بڑے کوڈ بیس میں، ہر فنکشن کی اپنی تاریخ رہتی ہے، جو عام طور پر کسی کو معلوم نہیں ہوتی۔ پروفائلر کا کہنا ہے کہ ہم نے کچھ لوپ پر 24 فیصد وقت ضائع کیا اور یہ سمجھنے کے لیے کہ یہ لوپ کیا کر رہا ہے، ہمیں ہر فنکشن کو اندر سے دیکھنے کی ضرورت ہے۔ فنکشن کا مطالعہ کیے بغیر اسے سمجھنا ناممکن ہے، اور یہ سمجھنے کے عمل کو سنجیدگی سے سست کر دیتا ہے۔ اس لیے میں گیٹرز اور سیٹرز کا استعمال نہیں کرتا، میں ایک نئی سطح پر پہنچ گیا ہوں!
قیمت کا ماڈل کہاں سے حاصل کیا جائے؟ ٹھیک ہے، آپ کچھ پڑھ سکتے ہیں، یقیناً... لیکن میرے خیال میں بہترین طریقہ عمل کرنا ہے۔ ایک چھوٹا کمپائلر بنانا لاگت کے ماڈل کو سمجھنے اور اسے اپنے سر میں فٹ کرنے کا بہترین طریقہ ہوگا۔ ایک چھوٹا کمپائلر جو مائیکرو ویو کو پروگرام کرنے کے لیے موزوں ہو گا ایک ابتدائی کے لیے ایک کام ہے۔ ٹھیک ہے، میرا مطلب ہے، اگر آپ کے پاس پہلے سے ہی پروگرامنگ کی مہارت ہے، تو یہ کافی ہونا چاہئے۔ یہ تمام چیزیں جیسے کسی تار کو پارس کرنا جو آپ کے پاس کسی قسم کے الجبری ایکسپریشن کے طور پر ہے، وہاں سے ریاضی کی کارروائیوں کے لیے صحیح ترتیب میں ہدایات نکالنا، رجسٹروں سے صحیح قدریں لینا - یہ سب ایک ہی وقت میں کیا جاتا ہے۔ اور جب آپ یہ کرتے ہیں تو یہ آپ کے دماغ میں نقش ہو جائے گا۔ میرے خیال میں ہر کوئی جانتا ہے کہ مرتب کرنے والا کیا کرتا ہے۔ اور یہ لاگت کے ماڈل کی سمجھ دے گا۔
کارکردگی میں بہتری کی عملی مثالیں۔
اینڈریو: پیداواری صلاحیت پر کام کرتے وقت آپ کو اور کس چیز پر توجہ دینی چاہئے؟
چٹان: ڈیٹا ڈھانچے ویسے، ہاں، میں نے ان کلاسوں کو کافی عرصے سے نہیں پڑھایا... . یہ مزہ تھا، لیکن اس کے لیے بہت محنت کی ضرورت تھی، اور میری بھی ایک زندگی ہے! ٹھیک ہے. لہذا، ایک بڑی اور دلچسپ کلاس میں، "آپ کی کارکردگی کہاں جاتی ہے،" میں نے طلباء کو ایک مثال دی: CSV فائل سے ڈھائی گیگا بائٹ فنٹیک ڈیٹا پڑھا گیا اور پھر انہیں فروخت ہونے والی مصنوعات کی تعداد کا حساب لگانا پڑا۔ . باقاعدہ ٹک مارکیٹ ڈیٹا۔ UDP پیکٹ 70 کی دہائی سے ٹیکسٹ فارمیٹ میں تبدیل ہو گئے۔ شکاگو مرکنٹائل ایکسچینج - ہر طرح کی چیزیں جیسے مکھن، مکئی، سویابین، اس جیسی چیزیں۔ ان مصنوعات، لین دین کی تعداد، فنڈز اور سامان کی نقل و حرکت کا اوسط حجم وغیرہ شمار کرنا ضروری تھا۔ یہ بہت آسان تجارتی ریاضی ہے: پروڈکٹ کوڈ تلاش کریں (جو کہ ہیش ٹیبل میں 1-2 حروف ہیں)، رقم حاصل کریں، اسے تجارتی سیٹوں میں سے ایک میں شامل کریں، حجم شامل کریں، ویلیو شامل کریں، اور کچھ دوسری چیزیں۔ بہت سادہ ریاضی. کھلونا عمل درآمد بہت سیدھا تھا: سب کچھ ایک فائل میں ہے، میں فائل کو پڑھتا ہوں اور اس میں سے گزرتا ہوں، انفرادی ریکارڈز کو جاوا سٹرنگز میں تقسیم کرتا ہوں، ان میں ضروری چیزیں تلاش کرتا ہوں اور اوپر بیان کردہ ریاضی کے مطابق ان کو شامل کرتا ہوں۔ اور یہ کچھ کم رفتار پر کام کرتا ہے۔
اس نقطہ نظر کے ساتھ، یہ واضح ہے کہ کیا ہو رہا ہے، اور متوازی کمپیوٹنگ مدد نہیں کرے گی، ٹھیک ہے؟ یہ پتہ چلتا ہے کہ کارکردگی میں پانچ گنا اضافہ صرف صحیح ڈیٹا ڈھانچے کو منتخب کرکے حاصل کیا جاسکتا ہے۔ اور یہ تجربہ کار پروگرامرز کو بھی حیران کر دیتا ہے! میرے خاص معاملے میں ، چال یہ تھی کہ آپ کو گرم لوپ میں میموری مختص نہیں کرنا چاہئے۔ ٹھیک ہے، یہ پوری سچائی نہیں ہے، لیکن عام طور پر - جب X کافی بڑا ہو تو آپ کو "ایک بار X میں" کو نمایاں نہیں کرنا چاہیے۔ جب X ڈھائی گیگا بائٹس ہے، تو آپ کو "ایک بار فی حرف"، یا "ایک بار فی لائن"، یا "ایک بار فی فیلڈ"، ایسی کوئی چیز مختص نہیں کرنی چاہیے۔ یہیں وقت گزارا جاتا ہے۔ یہ کیسے کام کرتا ہے؟ تصور کریں کہ میں کال کر رہا ہوں۔ String.split() یا BufferedReader.readLine(). Readline نیٹ ورک پر آنے والے بائٹس کے سیٹ سے ایک سٹرنگ بناتا ہے، ہر ایک لائن کے لیے، لاکھوں لائنوں میں سے ہر ایک کے لیے۔ میں یہ لائن لیتا ہوں، اسے پارس کرتا ہوں اور اسے پھینک دیتا ہوں۔ میں اسے کیوں پھینک رہا ہوں - ٹھیک ہے، میں نے پہلے ہی اس پر کارروائی کر لی ہے، بس۔ لہٰذا، ان 2.7G سے پڑھے جانے والے ہر بائٹ کے لیے، لائن میں دو حروف لکھے جائیں گے، یعنی پہلے سے 5.4G، اور مجھے ان کی مزید کسی چیز کی ضرورت نہیں ہے، اس لیے انہیں پھینک دیا جاتا ہے۔ اگر آپ میموری بینڈ وڈتھ کو دیکھیں تو ہم 2.7G لوڈ کرتے ہیں جو پروسیسر میں میموری اور میموری بس سے گزرتا ہے اور پھر اس سے دوگنا زیادہ میموری میں پڑی لائن پر بھیج دیا جاتا ہے اور یہ سب کچھ اس وقت بھڑکا جاتا ہے جب ہر نئی لائن بنتی ہے۔ لیکن مجھے اسے پڑھنے کی ضرورت ہے، ہارڈ ویئر اسے پڑھتا ہے، چاہے سب کچھ بعد میں خراب ہو جائے۔ اور مجھے اسے لکھنا پڑے گا کیونکہ میں نے ایک لائن بنائی ہے اور کیشز بھری ہوئی ہیں - کیش 2.7G کو ایڈجسٹ نہیں کر سکتا۔ لہذا، ہر بائٹ کے لیے جو میں پڑھتا ہوں، میں دو مزید بائٹس پڑھتا ہوں اور مزید دو بائٹس لکھتا ہوں، اور آخر میں ان کا تناسب 4:1 ہے - اس تناسب میں ہم میموری کی بینڈوتھ کو ضائع کر رہے ہیں۔ اور پھر پتہ چلتا ہے کہ اگر میں کرتا ہوں۔ String.split() - یہ آخری بار نہیں ہے جب میں ایسا کرتا ہوں، اس کے اندر مزید 6-7 فیلڈز ہوسکتے ہیں۔ لہذا CSV کو پڑھنے اور پھر تاروں کو پارس کرنے کا کلاسک کوڈ تقریباً 14:1 میموری بینڈوڈتھ کو ضائع کر دیتا ہے جو آپ اصل میں چاہتے ہیں۔ اگر آپ ان انتخابوں کو پھینک دیتے ہیں، تو آپ پانچ گنا رفتار حاصل کر سکتے ہیں۔
اور یہ اتنا مشکل نہیں ہے۔ اگر آپ کوڈ کو صحیح زاویہ سے دیکھتے ہیں، تو آپ کو مسئلہ کا احساس ہونے کے بعد یہ سب کافی آسان ہو جاتا ہے۔ آپ کو میموری کو مکمل طور پر مختص کرنا بند نہیں کرنا چاہئے: صرف ایک مسئلہ یہ ہے کہ آپ کسی چیز کو مختص کرتے ہیں اور وہ فوری طور پر مر جاتا ہے، اور راستے میں یہ ایک اہم وسائل کو جلا دیتا ہے، جو اس صورت میں میموری بینڈوڈتھ ہے۔ اور اس سب کا نتیجہ پیداواری صلاحیت میں کمی کا باعث بنتا ہے۔ x86 پر آپ کو عام طور پر پروسیسر سائیکلوں کو فعال طور پر جلانے کی ضرورت ہوتی ہے، لیکن یہاں آپ نے بہت پہلے تمام میموری کو جلا دیا۔ اس کا حل یہ ہے کہ اخراج کی مقدار کو کم کیا جائے۔
مسئلہ کا دوسرا حصہ یہ ہے کہ اگر آپ پروفائلر کو چلاتے ہیں جب میموری کی پٹی ختم ہو جاتی ہے، بالکل اسی وقت جب ایسا ہوتا ہے، آپ عام طور پر کیشے کے واپس آنے کا انتظار کر رہے ہوتے ہیں کیونکہ یہ کچرے سے بھرا ہوتا ہے جو آپ نے ابھی پیدا کیا ہے، وہ تمام لائنیں۔ لہذا، ہر بوجھ یا اسٹور کا عمل سست ہو جاتا ہے، کیونکہ یہ کیش کی کمی کا باعث بنتے ہیں - پورا کیش سست ہو گیا ہے، کچرا چھوڑنے کا انتظار کر رہا ہے۔ لہذا، پروفائلر صرف پورے لوپ میں گرم بے ترتیب شور کو ظاہر کرے گا - کوڈ میں کوئی الگ گرم ہدایات یا جگہ نہیں ہوگی۔ صرف شور۔ اور اگر آپ GC سائیکلوں کو دیکھیں تو وہ تمام ینگ جنریشن اور انتہائی تیز ہیں - مائیکرو سیکنڈز یا ملی سیکنڈز زیادہ سے زیادہ۔ سب کے بعد، یہ تمام میموری فوری طور پر مر جاتا ہے. آپ اربوں گیگا بائٹس مختص کرتے ہیں، اور وہ انہیں کاٹتا ہے، اور انہیں کاٹتا ہے، اور دوبارہ کاٹتا ہے۔ یہ سب بہت تیزی سے ہوتا ہے۔ یہ پتہ چلتا ہے کہ سستے GC سائیکل ہیں، پورے سائیکل کے ساتھ گرم شور، لیکن ہم 5x رفتار حاصل کرنا چاہتے ہیں۔ اس وقت، آپ کے سر میں کچھ بند ہونا چاہئے اور آواز: "یہ کیوں ہے؟!" میموری سٹرپ اوور فلو کلاسک ڈیبگر میں ظاہر نہیں ہوتا ہے؛ آپ کو ہارڈویئر پرفارمنس کاؤنٹر ڈیبگر کو چلانے اور اسے خود اور براہ راست دیکھنے کی ضرورت ہے۔ لیکن ان تین علامات سے براہ راست اس کا شبہ نہیں کیا جا سکتا۔ تیسری علامت یہ ہے کہ جب آپ اسے دیکھتے ہیں جو آپ نمایاں کرتے ہیں، پروفائلر سے پوچھیں، اور وہ جواب دیتا ہے: "آپ نے ایک ارب قطاریں بنائیں، لیکن GC نے مفت کام کیا۔" جیسے ہی ایسا ہوتا ہے، آپ کو احساس ہوتا ہے کہ آپ نے بہت ساری چیزیں بنائی ہیں اور پوری میموری لین کو جلا دیا ہے۔ اس کا پتہ لگانے کا ایک طریقہ ہے، لیکن یہ واضح نہیں ہے۔
مسئلہ ڈیٹا سٹرکچر میں ہے: جو کچھ ہو رہا ہے اس کے اندر موجود ننگی ساخت، یہ بہت بڑی ہے، یہ ڈسک پر 2.7G ہے، اس لیے اس چیز کی کاپی بنانا بہت ناپسندیدہ ہے - آپ اسے نیٹ ورک بائٹ بفر سے لوڈ کرنا چاہتے ہیں۔ فوری طور پر رجسٹروں میں، تاکہ لائن کو آگے پیچھے پانچ بار نہ پڑھا جائے۔ بدقسمتی سے، جاوا آپ کو پہلے سے طے شدہ JDK کے حصے کے طور پر ایسی لائبریری نہیں دیتا ہے۔ لیکن یہ معمولی بات ہے، ٹھیک ہے؟ بنیادی طور پر، یہ کوڈ کی 5-10 لائنیں ہیں جو آپ کے اپنے بفرڈ سٹرنگ لوڈر کو لاگو کرنے کے لیے استعمال ہوں گی، جو سٹرنگ کلاس کے رویے کو دہراتا ہے، جبکہ بنیادی بائٹ بفر کے ارد گرد ریپر ہوتا ہے۔ نتیجے کے طور پر، یہ پتہ چلتا ہے کہ آپ تقریبا اس طرح کام کر رہے ہیں جیسے تاروں کے ساتھ، لیکن حقیقت میں بفر کی طرف اشارہ کرنے والے وہاں منتقل ہو رہے ہیں، اور خام بائٹس کو کہیں بھی کاپی نہیں کیا جاتا ہے، اور اس طرح ایک ہی بفر کو بار بار دوبارہ استعمال کیا جاتا ہے، اور آپریٹنگ سسٹم ان چیزوں کو اپنے اوپر لے کر خوش ہوتا ہے جن کے لیے اسے ڈیزائن کیا گیا ہے، جیسے کہ ان بائٹ بفرز کی پوشیدہ ڈبل بفرنگ، اور آپ اب غیر ضروری ڈیٹا کے لامتناہی سلسلے کو پیس نہیں رہے ہیں۔ ویسے، کیا آپ سمجھتے ہیں کہ GC کے ساتھ کام کرتے وقت، اس بات کی ضمانت دی جاتی ہے کہ آخری GC سائیکل کے بعد ہر میموری ایلوکیشن پروسیسر کو نظر نہیں آئے گا؟ لہذا، یہ سب ممکنہ طور پر کیش میں نہیں ہوسکتا ہے، اور پھر 100% گارنٹی شدہ مس واقع ہوتی ہے۔ پوائنٹر کے ساتھ کام کرتے وقت، x86 پر، میموری سے رجسٹر کو گھٹانے میں 1-2 گھڑیوں کے چکر لگتے ہیں، اور جیسے ہی ایسا ہوتا ہے، آپ ادائیگی کرتے ہیں، ادا کرتے ہیں، ادا کرتے ہیں، کیونکہ میموری سب آن ہے۔ - اور یہ میموری مختص کرنے کی لاگت ہے۔ حقیقی قدر
دوسرے لفظوں میں، ڈیٹا ڈھانچے کو تبدیل کرنا مشکل ترین چیز ہے۔ اور ایک بار جب آپ کو یہ احساس ہو جائے کہ آپ نے ڈیٹا کے غلط ڈھانچے کا انتخاب کیا ہے جو بعد میں کارکردگی کو ختم کر دے گا، تو عام طور پر بہت زیادہ کام کرنا باقی ہے، لیکن اگر آپ ایسا نہیں کرتے ہیں تو چیزیں خراب ہو جائیں گی۔ سب سے پہلے، آپ کو ڈیٹا ڈھانچے کے بارے میں سوچنے کی ضرورت ہے، یہ ضروری ہے۔ یہاں بنیادی لاگت چربی والے ڈیٹا ڈھانچے پر پڑتی ہے، جو "میں نے ڈیٹا اسٹرکچر X کو ڈیٹا اسٹرکچر Y میں کاپی کیا کیونکہ مجھے Y کی شکل زیادہ پسند ہے۔" لیکن کاپی آپریشن (جو سستا لگتا ہے) درحقیقت میموری بینڈوڈتھ کو ضائع کرتا ہے اور اسی جگہ پر عمل درآمد کا تمام ضائع شدہ وقت دفن ہوجاتا ہے۔ اگر میرے پاس JSON کا ایک بڑا سٹرنگ ہے اور میں اسے POJOs یا کسی اور چیز کے سٹرکچرڈ DOM ٹری میں تبدیل کرنا چاہتا ہوں، تو اس سٹرنگ کو پارس کرنے اور POJO کو بنانے کا عمل، اور پھر بعد میں POJO تک دوبارہ رسائی کے نتیجے میں غیر ضروری لاگت آئے گی - یہ سستا نہیں. سوائے اس کے کہ اگر آپ POJOs کے ارد گرد اسٹرنگ کے ارد گرد بھاگنے سے کہیں زیادہ بھاگتے ہیں۔ آف ہینڈ، آپ اس کے بجائے سٹرنگ کو ڈکرپٹ کرنے کی کوشش کر سکتے ہیں اور اسے کسی POJO میں تبدیل کیے بغیر، وہاں سے صرف وہی نکال سکتے ہیں جس کی آپ کو ضرورت ہے۔ اگر یہ سب کچھ ایسے راستے پر ہوتا ہے جہاں سے زیادہ سے زیادہ کارکردگی کی ضرورت ہوتی ہے، آپ کے لیے کوئی POJO نہیں ہے، آپ کو کسی نہ کسی طرح براہ راست لائن میں کھودنے کی ضرورت ہے۔
اپنی پروگرامنگ زبان کیوں بنائیں
اینڈریو: آپ نے کہا کہ لاگت کے ماڈل کو سمجھنے کے لیے، آپ کو اپنی چھوٹی زبان لکھنی ہوگی...
چٹان: زبان نہیں بلکہ ایک مرتب کرنے والا۔ ایک زبان اور ایک مرتب کرنے والا دو مختلف چیزیں ہیں۔ سب سے اہم فرق آپ کے سر میں ہے۔
اینڈریو: ویسے، جہاں تک میں جانتا ہوں، آپ اپنی زبانیں بنانے کا تجربہ کر رہے ہیں۔ کس لیے؟
چٹان: کیونکہ میں کر سکتا ہوں! میں نیم ریٹائرڈ ہوں، اس لیے یہ میرا شوق ہے۔ میں ساری زندگی دوسرے لوگوں کی زبانوں کو نافذ کرتا رہا ہوں۔ میں نے اپنے کوڈنگ اسٹائل پر بھی بہت کام کیا۔ اور اس لیے بھی کہ میں دوسری زبانوں میں مسائل دیکھتا ہوں۔ میں دیکھتا ہوں کہ واقف چیزیں کرنے کے بہتر طریقے ہیں۔ اور میں انہیں استعمال کروں گا۔ میں صرف اپنے آپ میں، جاوا میں، ازگر میں، کسی دوسری زبان میں مسائل دیکھ کر تھک گیا ہوں۔ میں اب React Native، JavaScript اور Elm میں ایک مشغلے کے طور پر لکھتا ہوں جو ریٹائرمنٹ کے بارے میں نہیں بلکہ فعال کام کے بارے میں ہے۔ میں Python میں بھی لکھتا ہوں اور، غالباً، جاوا بیک اینڈز کے لیے مشین لرننگ پر کام جاری رکھوں گا۔ بہت سی مشہور زبانیں ہیں اور ان سب میں دلچسپ خصوصیات ہیں۔ ہر کوئی اپنے طریقے سے اچھا ہے اور آپ ان تمام خصوصیات کو ایک ساتھ لانے کی کوشش کر سکتے ہیں۔ لہذا، میں ان چیزوں کا مطالعہ کر رہا ہوں جن میں مجھے دلچسپی ہے، زبان کا برتاؤ، معقول الفاظ کے ساتھ آنے کی کوشش کر رہا ہوں۔ اور اب تک میں کامیاب ہوں! اس وقت میں میموری سیمنٹکس کے ساتھ جدوجہد کر رہا ہوں، کیونکہ میں اسے C اور Java کی طرح رکھنا چاہتا ہوں، اور لوڈز اور اسٹورز کے لیے ایک مضبوط میموری ماڈل اور میموری سیمنٹکس حاصل کرنا چاہتا ہوں۔ ایک ہی وقت میں، ہاسکل کی طرح خودکار قسم کا اندازہ لگائیں۔ یہاں، میں C اور جاوا دونوں میں میموری کے کام کے ساتھ ہاسکل نما قسم کا اندازہ ملانے کی کوشش کر رہا ہوں۔ مثال کے طور پر میں پچھلے 2-3 ماہ سے یہی کر رہا ہوں۔
اینڈریو: اگر آپ ایک ایسی زبان بناتے ہیں جو دوسری زبانوں سے بہتر پہلوؤں کو لیتی ہے، تو کیا آپ کو لگتا ہے کہ کوئی اس کے برعکس کرے گا: اپنے خیالات لیں اور ان کا استعمال کریں؟
چٹان: بالکل اسی طرح نئی زبانیں ظاہر ہوتی ہیں! جاوا کیوں سی سے ملتا جلتا ہے؟ کیونکہ C کا ایک اچھا نحو تھا جسے ہر کوئی سمجھتا تھا اور جاوا اس نحو سے متاثر ہوا تھا، جس میں ٹائپ سیفٹی، ارے باؤنڈ چیکنگ، GC شامل کیا گیا تھا، اور انہوں نے C سے کچھ چیزیں بھی بہتر کیں۔ لیکن وہ بہت زیادہ متاثر ہوئے، ٹھیک ہے؟ ہر کوئی ان جنات کے کندھوں پر کھڑا ہے جو آپ سے پہلے آئے - اسی طرح ترقی ہوتی ہے۔
اینڈریو: جیسا کہ میں سمجھتا ہوں، آپ کی زبان میموری محفوظ رہے گی۔ کیا آپ نے کسی چیز کو نافذ کرنے کے بارے میں سوچا ہے جیسے مورچا سے قرض لینے والے چیکر؟ تم نے اس کی طرف دیکھا ہے، اس کے بارے میں تمہارا کیا خیال ہے؟
چٹان: ٹھیک ہے، میں عمر بھر سے C لکھ رہا ہوں، اس سارے malloc اور مفت کے ساتھ، اور دستی طور پر زندگی بھر کا انتظام کر رہا ہوں۔ آپ جانتے ہیں، دستی طور پر کنٹرول شدہ زندگی کے 90-95% کا ڈھانچہ ایک ہی ہے۔ اور اسے دستی طور پر کرنا بہت، بہت تکلیف دہ ہے۔ میں چاہتا ہوں کہ مرتب کرنے والا آپ کو صرف یہ بتائے کہ وہاں کیا ہو رہا ہے اور آپ نے اپنے اعمال سے کیا حاصل کیا ہے۔ کچھ چیزوں کے لیے، ادھار چیکر یہ کام باکس سے باہر کرتا ہے۔ اور یہ خود بخود معلومات کو ظاہر کرے، ہر چیز کو سمجھے، اور مجھ پر اس تفہیم کو پیش کرنے کا بوجھ بھی نہ ڈالے۔ اسے کم از کم مقامی فرار کا تجزیہ ضرور کرنا چاہیے، اور صرف اس صورت میں جب یہ ناکام ہو جاتا ہے، تب اسے ایسی تشریحات شامل کرنے کی ضرورت ہوتی ہے جو زندگی بھر کی وضاحت کریں گے - اور اس طرح کی اسکیم قرض لینے والے چیکر، یا درحقیقت کسی موجودہ میموری چیکر سے کہیں زیادہ پیچیدہ ہے۔ "سب کچھ ٹھیک ہے" اور "مجھے کچھ سمجھ نہیں آرہا" کے درمیان انتخاب - نہیں، کچھ بہتر ہونا چاہیے۔
لہذا، کسی ایسے شخص کے طور پر جس نے C میں بہت زیادہ کوڈ لکھا ہے، میں سمجھتا ہوں کہ خود کار طریقے سے لائف ٹائم کنٹرول کے لیے سپورٹ حاصل کرنا سب سے اہم چیز ہے۔ میں اس سے بھی تنگ آ گیا ہوں کہ جاوا کتنی میموری استعمال کرتا ہے اور بنیادی شکایت جی سی ہے۔ جب آپ جاوا میں میموری مختص کرتے ہیں، تو آپ کو وہ میموری واپس نہیں ملے گی جو آخری GC سائیکل میں مقامی تھی۔ زیادہ درست میموری مینجمنٹ والی زبانوں میں ایسا نہیں ہے۔ اگر آپ malloc کو کال کرتے ہیں، تو آپ کو فوری طور پر وہ میموری مل جاتی ہے جو عام طور پر صرف استعمال ہوتی تھی۔ عام طور پر آپ میموری کے ساتھ کچھ عارضی کام کرتے ہیں اور اسے فوراً واپس کر دیتے ہیں۔ اور یہ فوری طور پر malloc پول میں واپس آجاتا ہے، اور اگلا malloc سائیکل اسے دوبارہ باہر نکالتا ہے۔ لہذا، حقیقی میموری کا استعمال ایک مقررہ وقت پر زندہ اشیاء کے سیٹ تک کم کر دیا جاتا ہے، نیز لیکس۔ اور اگر سب کچھ مکمل طور پر غیر مہذب طریقے سے لیک نہیں ہوتا ہے، تو زیادہ تر میموری کیچز اور پروسیسر میں ختم ہو جاتی ہے، اور یہ تیزی سے کام کرتی ہے۔ لیکن malloc کے ساتھ بہت زیادہ دستی میموری مینجمنٹ کی ضرورت ہوتی ہے اور صحیح جگہ پر صحیح ترتیب میں بلایا جاتا ہے۔ زنگ اپنے طور پر اسے ٹھیک طریقے سے سنبھال سکتا ہے، اور بہت سے معاملات میں اس سے بھی بہتر کارکردگی دے سکتا ہے، کیونکہ میموری کی کھپت کو صرف موجودہ کمپیوٹیشن تک محدود کر دیا گیا ہے - جیسا کہ میموری کو خالی کرنے کے لیے اگلے جی سی سائیکل کا انتظار کرنے کے برخلاف ہے۔ نتیجے کے طور پر، ہمیں کارکردگی کو بہتر بنانے کا ایک بہت ہی دلچسپ طریقہ ملا۔ اور کافی طاقتور - میرا مطلب ہے، میں نے فنٹیک کے لیے ڈیٹا پر کارروائی کرتے وقت ایسی چیزیں کیں، اور اس سے مجھے تقریباً پانچ گنا کی رفتار حاصل ہوئی۔ یہ ایک بہت بڑا فروغ ہے، خاص طور پر ایسی دنیا میں جہاں پروسیسر تیز نہیں ہو رہے ہیں اور ہم ابھی بھی بہتری کا انتظار کر رہے ہیں۔
پرفارمنس انجینئر کیریئر
اینڈریو: میں عام طور پر کیریئر کے بارے میں بھی پوچھنا چاہوں گا۔ آپ ہاٹ اسپاٹ پر اپنے جے آئی ٹی کے کام سے نمایاں ہوئے اور پھر ازول چلے گئے جو کہ ایک JVM کمپنی بھی ہے۔ لیکن ہم پہلے ہی سافٹ ویئر سے زیادہ ہارڈ ویئر پر کام کر رہے تھے۔ اور پھر وہ اچانک بگ ڈیٹا اور مشین لرننگ اور پھر دھوکہ دہی کا پتہ لگانے پر چلے گئے۔ یہ کیسے ہوا؟ یہ ترقی کے بہت مختلف شعبے ہیں۔
چٹان: میں کافی عرصے سے پروگرامنگ کر رہا ہوں اور بہت سی مختلف کلاسیں لینے میں کامیاب ہوا ہوں۔ اور جب لوگ کہتے ہیں: "اوہ، آپ وہ ہیں جس نے جاوا کے لیے جے آئی ٹی بنائی!"، یہ ہمیشہ مضحکہ خیز ہوتا ہے۔ لیکن اس سے پہلے، میں پوسٹ اسکرپٹ کے کلون پر کام کر رہا تھا - وہ زبان جسے ایپل کبھی اپنے لیزر پرنٹرز کے لیے استعمال کرتا تھا۔ اور اس سے پہلے میں نے فورتھ زبان کا نفاذ کیا۔ میرے خیال میں میرے لیے عام تھیم ٹول ڈویلپمنٹ ہے۔ میں ساری زندگی ایسے اوزار بناتا رہا ہوں جن سے دوسرے لوگ اپنے زبردست پروگرام لکھتے ہیں۔ لیکن میں آپریٹنگ سسٹمز، ڈرائیورز، کرنل لیول ڈیبگرز، او ایس ڈیولپمنٹ کے لیے لینگوئجز کی ڈیولپمنٹ میں بھی شامل تھا، جو کہ معمولی سی شروع ہوئی، لیکن وقت کے ساتھ ساتھ پیچیدہ ہوتی گئی۔ لیکن اہم موضوع اب بھی اوزار کی ترقی ہے. میری زندگی کا ایک بڑا حصہ ازول اور سورج کے درمیان گزرا، اور یہ جاوا کے بارے میں تھا۔ لیکن جب میں بگ ڈیٹا اور مشین لرننگ میں داخل ہوا، تو میں نے اپنی فینسی ہیٹ واپس رکھی اور کہا، "اوہ، اب ہمارے پاس ایک غیر معمولی مسئلہ ہے، اور وہاں بہت ساری دلچسپ چیزیں چل رہی ہیں اور لوگ کام کر رہے ہیں۔" یہ ترقی کا ایک بہت بڑا راستہ ہے۔
ہاں، مجھے واقعی تقسیم شدہ کمپیوٹنگ پسند ہے۔ میری پہلی نوکری C میں طالب علم کے طور پر ایک اشتہاری پروجیکٹ پر تھی۔ یہ Zilog Z80 چپس پر کمپیوٹنگ تقسیم کیا گیا تھا جس نے ینالاگ OCR کے لیے ڈیٹا اکٹھا کیا تھا، جو ایک حقیقی اینالاگ تجزیہ کار کے ذریعے تیار کیا گیا تھا۔ یہ ایک ٹھنڈا اور مکمل طور پر پاگل موضوع تھا۔ لیکن کچھ مسائل تھے، کچھ حصہ درست طریقے سے پہچانا نہیں گیا تھا، لہذا آپ کو ایک تصویر نکال کر کسی ایسے شخص کو دکھانی پڑی جو پہلے ہی اپنی آنکھوں سے پڑھ سکتا تھا اور جو کچھ اس میں کہا گیا تھا اس کی اطلاع دیتا تھا، اور اس وجہ سے اعداد و شمار کے ساتھ ملازمتیں تھیں، اور یہ ملازمتیں تھیں۔ ان کی اپنی زبان تھی۔ ایک بیک اینڈ تھا جس نے اس سب پر کارروائی کی - Z80s متوازی طور پر چل رہا ہے vt100 ٹرمینلز کے ساتھ چل رہا ہے - ایک فی شخص، اور Z80 پر ایک متوازی پروگرامنگ ماڈل تھا۔ ستارے کی ترتیب میں تمام Z80s کے ذریعے مشترکہ میموری کا کچھ عام حصہ؛ بیک پلین بھی شیئر کیا گیا تھا، اور آدھی RAM نیٹ ورک کے اندر شیئر کی گئی تھی، اور دوسرا آدھا نجی تھا یا کسی اور چیز پر چلا گیا تھا۔ مشترکہ... نیم مشترکہ میموری کے ساتھ ایک معنی خیز پیچیدہ متوازی تقسیم شدہ نظام۔ یہ کب تھا... مجھے یاد بھی نہیں ہے، 80 کی دہائی کے وسط میں۔ کافی عرصہ پہلے۔
ہاں، چلو مان لیتے ہیں کہ 30 سال کافی عرصہ پہلے کی بات ہے۔ - کلسٹرز اس طرح کے کلسٹرز کی طرح نظر آتے ہیں... مثال کے طور پر: وہاں ایتھرنیٹ ہے اور آپ کا فاسٹ x86 اس ایتھرنیٹ سے منسلک ہے، اور اب آپ جعلی مشترکہ میموری حاصل کرنا چاہتے ہیں، کیونکہ اس وقت کوئی بھی ڈسٹری بیوٹڈ کمپیوٹنگ کوڈنگ نہیں کر سکتا تھا، یہ بہت مشکل تھا اور اس لیے وہاں x86 پر حفاظتی میموری کے صفحات کے ساتھ جعلی مشترکہ میموری تھی، اور اگر آپ نے اس صفحہ پر لکھا، تو ہم نے دوسرے پروسیسرز سے کہا کہ اگر وہ اسی مشترکہ میموری تک رسائی حاصل کرتے ہیں، تو اسے آپ سے لوڈ کرنے کی ضرورت ہوگی، اور اس طرح معاونت کے لیے پروٹوکول کی طرح کچھ cache coherence ظاہر ہوا اور اس کے لیے سافٹ ویئر۔ دلچسپ تصور۔ اصل مسئلہ یقیناً کچھ اور تھا۔ اس سب نے کام کیا، لیکن آپ کو تیزی سے کارکردگی کے مسائل کا سامنا کرنا پڑا، کیونکہ کوئی بھی اچھی سطح پر کارکردگی کے ماڈلز کو نہیں سمجھتا تھا - میموری تک رسائی کے کیا نمونے تھے، اس بات کو کیسے یقینی بنایا جائے کہ نوڈس ایک دوسرے کو لامتناہی طور پر پنگ نہ کریں، وغیرہ۔
میں نے H2O میں جو چیز پیش کی ہے وہ یہ ہے کہ یہ خود ڈویلپرز ہیں جو اس بات کا تعین کرنے کے ذمہ دار ہیں کہ متوازی کہاں چھپی ہوئی ہے اور کہاں نہیں۔ میں ایک کوڈنگ ماڈل لے کر آیا ہوں جس نے اعلی کارکردگی والے کوڈ کو لکھنا آسان اور آسان بنا دیا۔ لیکن آہستہ چلنے والا کوڈ لکھنا مشکل ہے، برا لگے گا۔ آپ کو سنجیدگی سے سست کوڈ لکھنے کی کوشش کرنے کی ضرورت ہے، آپ کو غیر معیاری طریقے استعمال کرنے ہوں گے۔ بریک کوڈ پہلی نظر میں نظر آتا ہے۔ نتیجے کے طور پر، آپ عام طور پر کوڈ لکھتے ہیں جو تیزی سے چلتا ہے، لیکن آپ کو یہ معلوم کرنا ہوگا کہ مشترکہ میموری کے معاملے میں کیا کرنا ہے۔ یہ سب بڑی صفوں سے جڑا ہوا ہے اور وہاں کا برتاؤ متوازی جاوا میں غیر اتار چڑھاؤ والے بڑے ارے جیسا ہے۔ میرا مطلب ہے، تصور کریں کہ دو تھریڈز ایک متوازی صف پر لکھتے ہیں، ان میں سے ایک جیت جاتا ہے، اور دوسرا، اس کے مطابق، ہار جاتا ہے، اور آپ نہیں جانتے کہ کون سا ہے۔ اگر وہ غیر مستحکم نہیں ہیں، تو آرڈر آپ کی مرضی کے مطابق ہوسکتا ہے - اور یہ واقعی اچھی طرح سے کام کرتا ہے. لوگ واقعی عمل کی ترتیب کا خیال رکھتے ہیں، وہ صحیح جگہوں پر اتار چڑھاؤ رکھتے ہیں، اور وہ صحیح جگہوں پر میموری سے متعلق کارکردگی کے مسائل کی توقع کرتے ہیں۔ بصورت دیگر، وہ صرف 1 سے N تک لوپ کی شکل میں کوڈ لکھیں گے، جہاں N کچھ ٹریلین ہے، اس امید پر کہ تمام پیچیدہ معاملات خود بخود متوازی ہو جائیں گے - اور یہ وہاں کام نہیں کرتا ہے۔ لیکن H2O میں یہ نہ تو جاوا ہے اور نہ ہی Scala؛ اگر آپ چاہیں تو آپ اسے "جاوا مائنس مائنس" سمجھ سکتے ہیں۔ یہ ایک بہت واضح پروگرامنگ اسٹائل ہے اور یہ لوپس اور اری کے ساتھ سادہ سی یا جاوا کوڈ لکھنے کے مترادف ہے۔ لیکن ایک ہی وقت میں، میموری کو ٹیرا بائٹس میں پروسیس کیا جا سکتا ہے. میں اب بھی H2O استعمال کرتا ہوں۔ میں اسے وقتاً فوقتاً مختلف پروجیکٹس میں استعمال کرتا ہوں - اور یہ اب بھی تیز ترین چیز ہے، اپنے حریفوں سے درجنوں گنا تیز۔ اگر آپ کالمر ڈیٹا کے ساتھ بگ ڈیٹا کر رہے ہیں، تو H2O کو شکست دینا بہت مشکل ہے۔
تکنیکی چیلنجز
اینڈریو: آپ کے پورے کیریئر میں آپ کا سب سے بڑا چیلنج کیا رہا ہے؟
چٹان: کیا ہم مسئلے کے تکنیکی یا غیر تکنیکی حصے پر بات کر رہے ہیں؟ میں کہوں گا کہ سب سے بڑے چیلنج تکنیکی نہیں ہیں۔
جہاں تک تکنیکی چیلنجز کا تعلق ہے۔ میں نے انہیں صرف شکست دی۔ میں یہ بھی نہیں جانتا کہ سب سے بڑا کیا تھا، لیکن کچھ بہت دلچسپ تھے جن میں کافی وقت لگا، ذہنی جدوجہد۔ جب میں سن کے پاس گیا تو مجھے یقین تھا کہ میں ایک تیز کمپائلر بناؤں گا، اور سینئرز کے ایک گروپ نے جواب میں کہا کہ میں کبھی کامیاب نہیں ہوں گا۔ لیکن میں نے اس راستے کی پیروی کی، رجسٹر مختص کرنے والے کو ایک کمپائلر لکھا، اور یہ کافی تیز تھا۔ یہ جدید C1 کی طرح تیز تھا، لیکن اس وقت مختص کرنے والا بہت سست تھا، اور پیچھے کی نظر میں یہ ڈیٹا کی ساخت کا ایک بڑا مسئلہ تھا۔ مجھے گرافیکل رجسٹر ایلوکیٹر لکھنے کے لیے اس کی ضرورت تھی اور میں کوڈ کے اظہار اور رفتار کے درمیان اس مخمصے کو نہیں سمجھ سکا، جو اس دور میں موجود تھا اور بہت اہم تھا۔ یہ پتہ چلا کہ ڈیٹا کا ڈھانچہ عام طور پر اس وقت کے x86s پر کیشے کے سائز سے زیادہ ہوتا ہے، اور اس لیے، اگر میں نے شروع میں فرض کیا کہ رجسٹر مختص کرنے والا کل گھمبیر وقت کا 5-10 فیصد کام کرے گا، تو حقیقت میں یہ نکلا۔ 50 فیصد
جوں جوں وقت گزرتا گیا، کمپائلر صاف ستھرا اور زیادہ موثر ہوتا گیا، زیادہ صورتوں میں خوفناک کوڈ بنانا بند کر دیا، اور کارکردگی تیزی سے اس سے مشابہہ ہونے لگی جو ایک سی کمپائلر تیار کرتا ہے۔ جب تک کہ، یقیناً، آپ کچھ ایسی گھٹیا تحریر لکھتے ہیں جو C کی رفتار میں بھی اضافہ نہیں ہوتا ہے۔ . اگر آپ C جیسا کوڈ لکھتے ہیں، تو آپ کو زیادہ صورتوں میں C جیسی کارکردگی ملے گی۔ اور آپ جتنا آگے گئے، اتنی ہی کثرت سے آپ کو کوڈ ملتا ہے جو غیر علامتی طور پر لیول C کے ساتھ ملتا ہے، رجسٹر ایلوکیٹر کچھ مکمل نظر آنے لگا... قطع نظر اس سے کہ آپ کا کوڈ تیز چلتا ہے یا سست۔ میں نے مختص کرنے والے پر کام جاری رکھا تاکہ یہ بہتر انتخاب کر سکے۔ وہ سست اور سست ہوتا گیا، لیکن اس نے ایسے معاملات میں بہتر اور بہتر کارکردگی دکھائی جہاں کوئی دوسرا مقابلہ نہیں کر سکتا تھا۔ میں ایک رجسٹر ایلوکیٹر میں غوطہ لگا سکتا ہوں، وہاں ایک ماہ کا کام دفن کر سکتا ہوں، اور اچانک پورا کوڈ 5% تیزی سے کام کرنا شروع کر دے گا۔ یہ وقت کے بعد ہوتا رہا اور رجسٹر مختص کرنے والا فن کا ایک کام بن گیا - ہر کوئی اسے پسند کرتا تھا یا اس سے نفرت کرتا تھا، اور اکیڈمی کے لوگوں نے "سب کچھ اس طرح کیوں کیا جاتا ہے" کے عنوان پر سوالات پوچھے، کیوں نہیں؟ ، اور کیا فرق ہے؟ جواب اب بھی وہی ہے: گراف پینٹنگ پر مبنی ایک مختص کرنے والا اور بفر کوڈ کے ساتھ بہت محتاط کام فتح کے ہتھیار کے برابر ہے، بہترین مجموعہ جسے کوئی شکست نہیں دے سکتا۔ اور یہ ایک غیر واضح چیز ہے۔ باقی جو کچھ بھی مرتب کرنے والا کرتا ہے وہ کافی اچھی طرح سے مطالعہ شدہ چیزیں ہیں، حالانکہ انہیں فن کی سطح پر بھی لایا گیا ہے۔ میں نے ہمیشہ وہ کام کیے جو مرتب کرنے والے کو آرٹ کے کام میں تبدیل کرنے والے تھے۔ لیکن اس میں سے کوئی بھی غیر معمولی چیز نہیں تھی - سوائے رجسٹر ایلوکیٹر کے۔ چال یہ ہے کہ محتاط رہیں بوجھ کے تحت اور، اگر ایسا ہوتا ہے (اگر میں دلچسپی رکھتا ہوں تو میں مزید تفصیل سے وضاحت کر سکتا ہوں)، اس کا مطلب ہے کہ آپ کارکردگی کے شیڈول میں گرنے کے خطرے کے بغیر، زیادہ جارحانہ انداز میں ان لائن کر سکتے ہیں۔ ان دنوں، پورے پیمانے پر مرتب کرنے والوں کا ایک گروپ تھا، جو باؤبلز اور سیٹیوں کے ساتھ لٹکا ہوا تھا، جن میں رجسٹر ایلوکیٹر تھے، لیکن کوئی اور نہیں کر سکتا تھا۔
مسئلہ یہ ہے کہ اگر آپ ایسے طریقے شامل کرتے ہیں جو ان لائننگ ایریا کو ان لائن کرنے، بڑھانے اور بڑھانے سے مشروط ہیں، استعمال شدہ اقدار کا سیٹ فوری طور پر رجسٹروں کی تعداد سے آگے نکل جاتا ہے، اور آپ کو انہیں کاٹنا پڑتا ہے۔ اہم سطح عام طور پر اس وقت آتی ہے جب مختص کرنے والا دستبردار ہو جاتا ہے، اور اسپل کے لیے ایک اچھا امیدوار دوسرے کے قابل ہوتا ہے، آپ کچھ عام طور پر جنگلی چیزیں بیچیں گے۔ یہاں ان لائننگ کی قدر یہ ہے کہ آپ کالنگ اور سیونگ کے لیے اوور ہیڈ، اوور ہیڈ کا کچھ حصہ کھو دیتے ہیں، آپ اندر کی قدریں دیکھ سکتے ہیں اور انہیں مزید بہتر بنا سکتے ہیں۔ ان لائننگ کی قیمت یہ ہے کہ لائیو ویلیوز کی ایک بڑی تعداد بنتی ہے، اور اگر آپ کا رجسٹر ایلوکیٹر ضرورت سے زیادہ جل جاتا ہے، تو آپ فوری طور پر کھو جاتے ہیں۔ لہذا، زیادہ تر مختص کرنے والوں کو ایک مسئلہ درپیش ہے: جب ان لائننگ ایک مخصوص لائن کو عبور کرتی ہے، تو دنیا کی ہر چیز کاٹنا شروع ہو جاتی ہے اور پیداواری صلاحیت کو بیت الخلا میں پھینکا جا سکتا ہے۔ جو لوگ کمپائلر کو لاگو کرتے ہیں وہ کچھ ہیورسٹکس شامل کرتے ہیں: مثال کے طور پر، ان لائننگ کو روکنے کے لیے، کچھ کافی بڑے سائز سے شروع کرتے ہوئے، کیونکہ مختص کرنے سے سب کچھ برباد ہو جائے گا۔ اس طرح کارکردگی کے گراف میں ایک کنک بنتا ہے - آپ ان لائن، ان لائن، کارکردگی آہستہ آہستہ بڑھتی ہے - اور پھر تیزی! - یہ ایک سوئفٹ جیک کی طرح گرتا ہے کیونکہ آپ نے بہت زیادہ قطار لگائی تھی۔ جاوا کی آمد سے پہلے سب کچھ اس طرح کام کرتا تھا۔ جاوا کو بہت زیادہ ان لائننگ کی ضرورت ہوتی ہے، اس لیے مجھے اپنے ایلوکیٹر کو بہت زیادہ جارحانہ بنانا پڑا تاکہ یہ کریش ہونے کے بجائے سطح سے باہر ہو جائے، اور اگر آپ بہت زیادہ ان لائن کرتے ہیں، تو یہ پھیلنا شروع ہو جاتا ہے، لیکن پھر "مزید نہیں پھیلنے" کا لمحہ اب بھی آتا ہے۔ یہ ایک دلچسپ مشاہدہ ہے اور یہ میرے پاس کہیں سے بھی نہیں آیا، واضح نہیں، لیکن اس کا اچھا نتیجہ نکلا۔ میں نے جارحانہ ان لائننگ اختیار کی اور یہ مجھے ایسی جگہوں پر لے گیا جہاں جاوا اور سی کی کارکردگی ساتھ ساتھ کام کرتی ہے۔ وہ واقعی قریب ہیں - میں جاوا کوڈ لکھ سکتا ہوں جو سی کوڈ اور اس جیسی چیزوں سے نمایاں طور پر تیز ہے، لیکن اوسطا، چیزوں کی بڑی تصویر میں، وہ تقریباً موازنہ ہیں۔ میرے خیال میں اس میرٹ کا حصہ رجسٹر مختص کرنے والا ہے، جو مجھے ہر ممکن حد تک احمقانہ طور پر ان لائن کرنے کی اجازت دیتا ہے۔ میں جو کچھ دیکھتا ہوں بس ان لائن کرتا ہوں۔ یہاں سوال یہ ہے کہ آیا مختص کرنے والا اچھی طرح سے کام کرتا ہے، کیا نتیجہ ذہانت سے کام کرنے والا کوڈ ہے۔ یہ ایک بڑا چیلنج تھا: اس سب کو سمجھنا اور اسے کام میں لانا۔
رجسٹر ایلوکیشن اور ملٹی کور کے بارے میں تھوڑا سا
ولادیمیر: رجسٹر ایلوکیشن جیسے مسائل کسی قسم کا ابدی، لامتناہی موضوع لگتا ہے۔ میں حیران ہوں کہ کیا کبھی کوئی ایسا خیال آیا ہے جو امید افزا لگتا ہو اور پھر عملی طور پر ناکام ہو گیا ہو؟
چٹان: یقیناً! رجسٹر ایلوکیشن ایک ایسا علاقہ ہے جس میں آپ NP-مکمل مسئلے کو حل کرنے کے لیے کچھ ہیورسٹکس تلاش کرنے کی کوشش کرتے ہیں۔ اور آپ کبھی بھی کامل حل حاصل نہیں کر سکتے، ٹھیک ہے؟ یہ محض ناممکن ہے۔ دیکھو، وقت کی تالیف سے پہلے - یہ بھی خراب کام کرتا ہے۔ یہاں گفتگو کچھ اوسط کیسز کے بارے میں ہے۔ عام کارکردگی کے بارے میں، تاکہ آپ جا کر کسی ایسی چیز کی پیمائش کر سکیں جو آپ کے خیال میں اچھی عام کارکردگی ہے - آخرکار، آپ اسے بہتر بنانے کے لیے کام کر رہے ہیں! رجسٹر ایلوکیشن کارکردگی کے بارے میں ایک موضوع ہے۔ ایک بار جب آپ کے پاس پہلا پروٹو ٹائپ ہوتا ہے، یہ کام کرتا ہے اور جس چیز کی ضرورت ہوتی ہے اسے پینٹ کرتا ہے، کارکردگی کا کام شروع ہوتا ہے۔ آپ کو اچھی طرح سے پیمائش کرنا سیکھنے کی ضرورت ہے۔ یہ کیوں ضروری ہے؟ اگر آپ کے پاس واضح ڈیٹا ہے، تو آپ مختلف علاقوں کو دیکھ سکتے ہیں اور دیکھ سکتے ہیں: ہاں، اس نے یہاں مدد کی، لیکن یہیں سے سب کچھ ٹوٹ گیا! کچھ اچھے آئیڈیاز سامنے آتے ہیں، آپ نئے ہیورسٹکس کو شامل کرتے ہیں اور اچانک ہر چیز اوسطاً کچھ بہتر کام کرنے لگتی ہے۔ یا یہ شروع نہیں ہوتا ہے۔ میرے پاس ایسے کیسز کا ایک گروپ تھا جہاں ہم پانچ فیصد کارکردگی کے لیے لڑ رہے تھے جس نے ہماری ترقی کو پچھلے مختص کرنے والے سے مختلف کیا۔ اور ہر بار ایسا لگتا ہے: کہیں آپ جیت گئے، کہیں آپ ہار گئے۔ اگر آپ کے پاس کارکردگی کے تجزیہ کے اچھے ٹولز ہیں، تو آپ کھونے والے آئیڈیاز تلاش کر سکتے ہیں اور سمجھ سکتے ہیں کہ وہ کیوں ناکام ہو جاتے ہیں۔ ہو سکتا ہے کہ ہر چیز کو ویسا ہی چھوڑنے کے قابل ہو، یا شاید ٹھیک ٹیوننگ کے لیے زیادہ سنجیدہ انداز اختیار کرنا، یا باہر جا کر کچھ اور ٹھیک کرنا۔ یہ چیزوں کا ایک مکمل گروپ ہے! میں نے یہ ٹھنڈا ہیک بنایا ہے، لیکن مجھے اس کی بھی ضرورت ہے، اور یہ ایک، اور یہ ایک - اور ان کا مجموعی مجموعہ کچھ بہتری لاتا ہے۔ اور تنہا رہنے والے ناکام ہو سکتے ہیں۔ یہ NP-مکمل مسائل پر کارکردگی کے کام کی نوعیت ہے۔
ولادیمیر: کسی کو یہ احساس ہوتا ہے کہ مختص کرنے والوں میں پینٹنگ جیسی چیزیں ایک ایسا مسئلہ ہے جو پہلے ہی حل ہوچکا ہے۔ ٹھیک ہے، یہ آپ کے لیے فیصلہ کیا گیا ہے، آپ جو کہہ رہے ہیں اس کے مطابق، تو کیا یہ اس کے قابل بھی ہے...
چٹان: یہ اس طرح حل نہیں ہوا ہے۔ یہ آپ ہی ہیں جو اسے "حل شدہ" میں تبدیل کریں۔ مشکل مسائل ہیں اور انہیں حل کرنے کی ضرورت ہے۔ ایک بار یہ ہو جانے کے بعد، یہ پیداواری صلاحیت پر کام کرنے کا وقت ہے۔ آپ کو اسی کے مطابق اس کام سے رجوع کرنے کی ضرورت ہے - بینچ مارکس کریں، میٹرکس جمع کریں، حالات کی وضاحت کریں جب، جب آپ پچھلے ورژن پر واپس چلے گئے، تو آپ کے پرانے ہیک نے دوبارہ کام کرنا شروع کیا (یا اس کے برعکس، رک گیا)۔ اور جب تک آپ کچھ حاصل نہ کر لیں ہمت نہ ہاریں۔ جیسا کہ میں پہلے ہی کہہ چکا ہوں، اگر ایسے اچھے خیالات ہیں جو کام نہیں کرتے، لیکن آئیڈیاز کے رجسٹروں کو مختص کرنے کے میدان میں یہ تقریبا لامتناہی ہے۔ آپ، مثال کے طور پر، سائنسی اشاعتیں پڑھ سکتے ہیں۔ اگرچہ اب یہ علاقہ بہت آہستہ آہستہ آگے بڑھنے لگا ہے اور جوانی کے مقابلے میں زیادہ واضح ہو گیا ہے۔ تاہم اس شعبے میں بے شمار لوگ کام کر رہے ہیں اور ان کے تمام آئیڈیاز آزمانے کے قابل ہیں، وہ سب پروں میں انتظار کر رہے ہیں۔ اور آپ یہ نہیں بتا سکتے کہ وہ کتنے اچھے ہیں جب تک کہ آپ ان کی کوشش نہ کریں۔ وہ آپ کے مختص کرنے والے میں ہر چیز کے ساتھ کتنی اچھی طرح سے ضم ہو جاتے ہیں، کیونکہ ایک مختص کرنے والا بہت ساری چیزیں کرتا ہے، اور کچھ آئیڈیاز آپ کے مخصوص مختص کرنے والے میں کام نہیں کریں گے، لیکن دوسرے مختص کرنے والے میں وہ آسانی سے کام کریں گے۔ مختص کرنے والے کے لیے جیتنے کا بنیادی طریقہ یہ ہے کہ سست چیزوں کو مرکزی راستے سے باہر نکالا جائے اور اسے سست راستوں کی حدود میں تقسیم کرنے پر مجبور کیا جائے۔ لہذا اگر آپ ایک GC چلانا چاہتے ہیں، سست راستہ اختیار کریں، deoptimize کریں، ایک استثناء پھینک دیں، یہ سب چیزیں - آپ جانتے ہیں کہ یہ چیزیں نسبتاً نایاب ہیں۔ اور وہ واقعی نایاب ہیں، میں نے چیک کیا۔ آپ اضافی کام کرتے ہیں اور اس سے ان سست راستوں پر سے بہت سی پابندیاں ہٹ جاتی ہیں، لیکن اس سے کوئی فرق نہیں پڑتا کیونکہ وہ سست اور شاذ و نادر ہی سفر کرتے ہیں۔ مثال کے طور پر، ایک کالعدم پوائنٹر - یہ کبھی نہیں ہوتا، ٹھیک ہے؟ آپ کے پاس مختلف چیزوں کے لیے کئی راستے ہونے کی ضرورت ہے، لیکن انھیں اہم راستے میں مداخلت نہیں کرنی چاہیے۔
ولادیمیر: آپ ملٹی کور کے بارے میں کیا سوچتے ہیں، جب ایک ساتھ ہزاروں کور ہوتے ہیں؟ کیا یہ کوئی مفید چیز ہے؟
چٹان: GPU کی کامیابی سے پتہ چلتا ہے کہ یہ کافی مفید ہے!
ولادیمیر: وہ کافی ماہر ہیں۔ عام مقصد کے پروسیسرز کے بارے میں کیا خیال ہے؟
چٹان: ٹھیک ہے، یہ ازول کا بزنس ماڈل تھا۔ جواب ایک ایسے دور میں واپس آیا جب لوگ واقعی قابل پیشن گوئی کارکردگی کو پسند کرتے تھے۔ اس وقت متوازی کوڈ لکھنا مشکل تھا۔ H2O کوڈنگ ماڈل انتہائی قابل توسیع ہے، لیکن یہ عام مقصد کا ماڈل نہیں ہے۔ شاید GPU استعمال کرنے کے مقابلے میں تھوڑا سا زیادہ عام۔ کیا ہم ایسی چیز کو تیار کرنے کی پیچیدگی یا اس کے استعمال کی پیچیدگی کے بارے میں بات کر رہے ہیں؟ مثال کے طور پر، ازول نے مجھے ایک دلچسپ سبق سکھایا، ایک غیر واضح سبق: چھوٹے کیچز نارمل ہیں۔
زندگی کا سب سے بڑا چیلنج
ولادیمیر: غیر تکنیکی چیلنجز کے بارے میں کیا خیال ہے؟
چٹان: سب سے بڑا چیلنج لوگوں کے ساتھ مہربان اور اچھا نہ بننا تھا۔ اور اس کے نتیجے میں، میں نے خود کو مسلسل انتہائی تنازعات کے حالات میں پایا۔ وہ جہاں میں جانتا تھا کہ چیزیں غلط ہو رہی ہیں، لیکن میں نہیں جانتا تھا کہ ان مسائل کے ساتھ کیسے آگے بڑھنا ہے اور ان کو سنبھال نہیں سکتا تھا۔ کئی دہائیوں تک جاری رہنے والے طویل المدتی مسائل اسی طرح پیدا ہوئے۔ حقیقت یہ ہے کہ جاوا میں C1 اور C2 مرتب کرنے والے ہیں اس کا براہ راست نتیجہ ہے۔ یہ حقیقت کہ جاوا میں مسلسل دس سال تک کوئی کثیر سطحی تالیف نہیں ہوئی اس کا بھی براہ راست نتیجہ ہے۔ یہ ظاہر ہے کہ ہمیں ایسے نظام کی ضرورت تھی، لیکن یہ واضح نہیں ہے کہ یہ کیوں موجود نہیں تھا۔ مجھے ایک انجینئر... یا انجینئرز کے ایک گروپ کے ساتھ مسئلہ تھا۔ ایک دفعہ کا ذکر ہے، جب میں نے سن میں کام کرنا شروع کیا تھا، میں... ٹھیک ہے، صرف تب ہی نہیں، میں عام طور پر ہر چیز پر اپنی رائے رکھتا ہوں۔ اور میں نے سوچا کہ یہ سچ ہے کہ آپ اپنی اس سچائی کو لے سکتے ہیں اور اسے آگے بڑھا سکتے ہیں۔ خاص طور پر چونکہ میں زیادہ تر وقت حیران کن طور پر درست تھا۔ اور اگر آپ کو یہ طریقہ پسند نہیں ہے... خاص طور پر اگر آپ واضح طور پر غلط ہیں اور بکواس کر رہے ہیں... عام طور پر، بہت کم لوگ مواصلات کی اس شکل کو برداشت کر سکتے ہیں۔ اگرچہ کچھ میری طرح کر سکتے تھے۔ میں نے اپنی پوری زندگی میرٹ کے اصولوں پر گزاری ہے۔ اگر آپ مجھے کچھ غلط دکھائیں تو میں فوراً پلٹ جاؤں گا اور کہوں گا: آپ نے بکواس کہا۔ اس کے ساتھ ہی، یقیناً، میں معذرت خواہ ہوں اور یہ سب، میں خوبیوں کو نوٹ کروں گا، اگر کوئی ہے، اور دیگر درست اقدامات اٹھاؤں گا۔ دوسری طرف، میں کل وقت کے چونکا دینے والے بڑے فیصد کے بارے میں حیران کن طور پر درست ہوں۔ اور یہ لوگوں کے ساتھ تعلقات میں بہت اچھا کام نہیں کرتا ہے۔ میں اچھا بننے کی کوشش نہیں کر رہا ہوں، لیکن میں سوال دو ٹوک انداز میں پوچھ رہا ہوں۔ "یہ کبھی کام نہیں کرے گا، کیونکہ ایک، دو اور تین۔" اور وہ ایسے تھے، "اوہ!" اس کے اور بھی نتائج تھے جنہیں نظر انداز کرنا شاید بہتر تھا: مثال کے طور پر، وہ جو میری بیوی سے طلاق اور اس کے بعد دس سال تک ڈپریشن کا باعث بنے۔
چیلنج لوگوں کے ساتھ جدوجہد ہے، ان کے اس خیال کے ساتھ کہ آپ کیا کر سکتے ہیں یا نہیں، کیا اہم ہے اور کیا نہیں۔ کوڈنگ سٹائل کے بارے میں بہت سے چیلنجز تھے۔ میں اب بھی بہت سارے کوڈ لکھتا ہوں، اور ان دنوں میں مجھے سست بھی کرنا پڑا کیونکہ میں ایک پر توجہ مرکوز کرنے کے بجائے بہت سارے متوازی کام کر رہا تھا اور انہیں خراب طریقے سے کر رہا تھا۔ پیچھے مڑ کر، میں نے جاوا JIT کمانڈ، C2 کمانڈ کے لیے آدھا کوڈ لکھا۔ اگلے تیز ترین کوڈر نے آدھا سست لکھا، اگلا نصف آہستہ لکھا، اور یہ ایک واضح کمی تھی۔ اس قطار میں ساتواں شخص بہت، بہت سست تھا - ایسا ہمیشہ ہوتا ہے! میں نے بہت سارے کوڈ کو چھوا۔ میں نے دیکھا کہ کس نے کیا لکھا ہے، بغیر کسی استثنا کے، میں نے ان کے کوڈ کو دیکھا، ان میں سے ہر ایک کا جائزہ لیا، اور پھر بھی ان میں سے کسی سے زیادہ خود لکھنا جاری رکھا۔ یہ نقطہ نظر لوگوں کے ساتھ بہت اچھا کام نہیں کرتا ہے۔ کچھ لوگوں کو یہ پسند نہیں ہے۔ اور جب وہ سنبھل نہیں پاتے تو ہر طرح کی شکایات شروع ہو جاتی ہیں۔ مثال کے طور پر، مجھے ایک بار کوڈنگ بند کرنے کو کہا گیا تھا کیونکہ میں بہت زیادہ کوڈ لکھ رہا تھا اور یہ ٹیم کو خطرے میں ڈال رہا تھا، اور یہ سب میرے لیے ایک مذاق کی طرح لگتا تھا: یار، اگر باقی ٹیم غائب ہو جائے اور میں کوڈ لکھتا رہوں، تو تم صرف آدھی ٹیمیں ہاریں گی۔ دوسری طرف، اگر میں کوڈ لکھتا رہتا ہوں اور آپ آدھی ٹیم سے محروم ہو جاتے ہیں، تو یہ بہت برا انتظام لگتا ہے۔ میں نے واقعی اس کے بارے میں کبھی نہیں سوچا، اس کے بارے میں کبھی بات نہیں کی، لیکن یہ اب بھی میرے سر میں کہیں تھا۔ میرے دماغ کے پیچھے یہ خیال گھوم رہا تھا: "کیا تم سب مجھ سے مذاق کر رہے ہو؟" لہذا، سب سے بڑا مسئلہ میرا اور لوگوں کے ساتھ میرے تعلقات تھے۔ اب میں اپنے آپ کو بہت بہتر سمجھتا ہوں، میں ایک طویل عرصے تک پروگرامرز کے لیے ٹیم لیڈ تھا، اور اب میں لوگوں کو براہ راست کہتا ہوں: آپ جانتے ہیں، میں وہی ہوں جو میں ہوں، اور آپ کو مجھ سے نمٹنا پڑے گا - کیا یہ ٹھیک ہے اگر میں کھڑا ہوں یہاں اور جب انہوں نے اس سے نمٹنا شروع کیا تو سب کچھ کام کر گیا۔ درحقیقت، میں نہ برا ہوں اور نہ ہی اچھا، میرے کوئی برے ارادے یا خود غرضانہ خواہشات نہیں ہیں، یہ صرف میرا جوہر ہے، اور مجھے اس کے ساتھ کسی نہ کسی طرح جینا ہے۔
اینڈریو: ابھی حال ہی میں سب نے انٹروورٹس کے لیے خود آگاہی، اور عام طور پر نرم مہارتوں کے بارے میں بات کرنا شروع کی ہے۔ آپ اس بارے میں کیا کہہ سکتے ہیں؟
چٹان: ہاں، یہی وہ بصیرت اور سبق تھا جو میں نے اپنی بیوی سے طلاق سے سیکھا تھا۔ میں نے طلاق سے جو کچھ سیکھا وہ خود کو سمجھ رہا تھا۔ اس طرح میں نے دوسرے لوگوں کو سمجھنا شروع کیا۔ سمجھیں کہ یہ تعامل کیسے کام کرتا ہے۔ یہ ایک کے بعد ایک دریافتوں کا باعث بنی۔ ایک آگاہی تھی کہ میں کون ہوں اور میں کس کی نمائندگی کرتا ہوں۔ میں کیا کر رہا ہوں: یا تو میں کام میں مصروف ہوں، یا میں تنازعات سے گریز کر رہا ہوں، یا کچھ اور - اور خود آگاہی کی یہ سطح واقعی اپنے آپ کو قابو میں رکھنے میں مدد کرتی ہے۔ اس کے بعد سب کچھ بہت آسان ہو جاتا ہے۔ ایک چیز جو میں نے نہ صرف اپنے آپ میں بلکہ دوسرے پروگرامرز میں بھی دریافت کی وہ ہے جب آپ جذباتی دباؤ کی حالت میں ہوتے ہیں تو خیالات کو زبانی بیان کرنے سے قاصر ہوتے ہیں۔ مثال کے طور پر، آپ وہاں بیٹھ کر کوڈنگ کر رہے ہیں، بہاؤ کی حالت میں، اور پھر وہ آپ کے پاس دوڑتے ہوئے آتے ہیں اور ہسٹریکس میں چیخنے لگتے ہیں کہ کچھ ٹوٹ گیا ہے اور اب آپ کے خلاف انتہائی سخت اقدامات کیے جائیں گے۔ اور آپ ایک لفظ بھی نہیں کہہ سکتے کیونکہ آپ جذباتی تناؤ کی حالت میں ہیں۔ حاصل کردہ علم آپ کو اس لمحے کے لیے تیاری کرنے، اس سے بچنے اور اعتکاف کے منصوبے پر جانے کی اجازت دیتا ہے، جس کے بعد آپ کچھ کر سکتے ہیں۔ تو ہاں، جب آپ کو یہ احساس ہونا شروع ہو جاتا ہے کہ یہ سب کیسے کام کرتا ہے، تو یہ زندگی کو بدلنے والا ایک بہت بڑا واقعہ ہے۔
مجھے خود صحیح الفاظ نہیں مل رہے تھے، لیکن مجھے اعمال کی ترتیب یاد تھی۔ بات یہ ہے کہ یہ ردعمل اتنا ہی جسمانی ہے جتنا کہ زبانی ہے، اور آپ کو جگہ کی ضرورت ہے۔ ایسی جگہ، زین کے معنی میں۔ یہ بالکل وہی ہے جس کی وضاحت کرنے کی ضرورت ہے، اور پھر فوری طور پر ایک طرف ہٹ جاؤ - خالصتا جسمانی طور پر ہٹ جاؤ۔ جب میں زبانی طور پر خاموش رہتا ہوں، تو میں جذباتی طور پر صورتحال پر کارروائی کر سکتا ہوں۔ جیسے ہی ایڈرینالین آپ کے دماغ تک پہنچتی ہے، آپ کو لڑائی یا پرواز کے موڈ میں بدل دیتی ہے، آپ مزید کچھ نہیں کہہ سکتے، نہیں - اب آپ ایک بیوقوف، کوڑے مارنے والے انجینئر، مہذب جواب دینے یا حملے کو روکنے سے بھی قاصر ہیں، اور حملہ آور آزاد ہے۔ بار بار حملہ کرنا۔ آپ کو پہلے خود بننا ہوگا، دوبارہ کنٹرول حاصل کرنا ہوگا، "لڑائی یا پرواز" کے موڈ سے باہر نکلنا ہوگا۔
اور اس کے لیے ہمیں زبانی جگہ کی ضرورت ہے۔ بس خالی جگہ۔ اگر آپ کچھ بھی کہتے ہیں، تو آپ بالکل وہی کہہ سکتے ہیں، اور پھر جا کر واقعی اپنے لیے "جگہ" تلاش کریں: پارک میں سیر کے لیے جائیں، اپنے آپ کو شاور میں بند کر لیں - اس سے کوئی فرق نہیں پڑتا۔ اہم چیز اس صورت حال سے عارضی طور پر منقطع ہونا ہے۔ جیسے ہی آپ کم از کم چند سیکنڈ کے لیے سوئچ آف کرتے ہیں، واپسی کو کنٹرول کرتے ہیں، آپ سنجیدگی سے سوچنا شروع کر دیتے ہیں۔ "ٹھیک ہے، میں کسی قسم کا بیوقوف نہیں ہوں، میں احمقانہ کام نہیں کرتا، میں ایک بہت مفید شخص ہوں۔" ایک بار جب آپ اپنے آپ کو قائل کرنے میں کامیاب ہو گئے تو، یہ اگلے مرحلے پر جانے کا وقت ہے: یہ سمجھنا کہ کیا ہوا ہے۔ آپ پر حملہ ہوا، حملہ وہیں سے ہوا جہاں سے آپ کو اس کی توقع نہیں تھی، یہ ایک بے ایمانی، گھٹیا حملہ تھا۔ یہ برا ہے. اگلا مرحلہ یہ سمجھنا ہے کہ حملہ آور کو اس کی ضرورت کیوں تھی۔ واقعی کیوں؟ شاید اس لیے کہ وہ خود غصے میں ہے؟ وہ پاگل کیوں ہے؟ مثال کے طور پر، کیونکہ اس نے خود کو خراب کیا اور ذمہ داری قبول نہیں کر سکتا؟ پوری صورتحال کو احتیاط سے سنبھالنے کا یہ طریقہ ہے۔ لیکن اس کے لیے پینتریبازی، زبانی جگہ کی ضرورت ہے۔ پہلا قدم زبانی رابطہ منقطع کرنا ہے۔ الفاظ سے بحث کرنے سے گریز کریں۔ اسے منسوخ کریں، جتنی جلدی ممکن ہو وہاں سے چلے جائیں۔ اگر یہ ٹیلی فون پر بات چیت ہے، تو بس بند کر دیں - یہ ایک ہنر ہے جو میں نے اپنی سابقہ بیوی کے ساتھ بات چیت سے سیکھا ہے۔ اگر بات چیت کہیں اچھی نہیں ہو رہی ہے، تو بس "الوداع" کہہ دیں اور بند کر دیں۔ فون کے دوسری طرف سے: "بلا بلہ بلہ"، آپ جواب دیتے ہیں: "ہاں، الوداع!" اور پھانسی. تم بس بات ختم کرو۔ پانچ منٹ بعد، جب آپ میں سمجھداری سے سوچنے کی صلاحیت واپس آجاتی ہے، آپ تھوڑا سا ٹھنڈا ہو جاتے ہیں، ہر چیز کے بارے میں سوچنا ممکن ہو جاتا ہے، کیا ہوا اور آگے کیا ہو گا۔ اور جذباتی ردعمل ظاہر کرنے کے بجائے سوچ سمجھ کر جواب دینا شروع کریں۔ میرے لیے خود آگاہی میں پیش رفت یہ حقیقت تھی کہ جذباتی دباؤ کی صورت میں میں بول نہیں سکتا۔ اس حالت سے نکلنا، سوچنا اور منصوبہ بندی کرنا کہ کس طرح جواب دیا جائے اور مسائل کی تلافی کی جائے - یہ اس صورت میں صحیح اقدامات ہیں جب آپ بول نہیں سکتے۔ سب سے آسان طریقہ یہ ہے کہ اس صورتحال سے بھاگیں جس میں جذباتی تناؤ خود ظاہر ہوتا ہے اور اس تناؤ میں حصہ لینا چھوڑ دیں۔ اس کے بعد آپ سوچنے کے قابل ہو جاتے ہیں، جب آپ سوچ سکتے ہیں، آپ بولنے کے قابل ہو جاتے ہیں، وغیرہ۔
ویسے، عدالت میں، مخالف وکیل آپ کے ساتھ ایسا کرنے کی کوشش کرتا ہے - اب اس کی وجہ واضح ہے۔ کیونکہ وہ آپ کو ایسی حالت تک دبانے کی صلاحیت رکھتا ہے کہ آپ اپنے نام کا تلفظ بھی نہیں کر سکتے، مثلاً۔ بہت حقیقی معنوں میں، آپ بات نہیں کر پائیں گے۔ اگر آپ کے ساتھ ایسا ہوتا ہے، اور اگر آپ جانتے ہیں کہ آپ اپنے آپ کو ایسی جگہ پائیں گے جہاں زبانی لڑائی ہو رہی ہو، عدالت جیسی جگہ، تو آپ اپنے وکیل کے ساتھ آ سکتے ہیں۔ وکیل آپ کے لیے کھڑا ہو گا اور زبانی حملے کو روک دے گا، اور اسے مکمل قانونی طریقے سے کرے گا، اور کھوئی ہوئی زین کی جگہ آپ کو واپس کر دی جائے گی۔ مثال کے طور پر مجھے اپنے گھر والوں کو ایک دو بار فون کرنا پڑا، اس بارے میں جج کافی دوستانہ تھا، لیکن مخالف وکیل نے چیخ کر مجھ پر شور مچایا، مجھے ایک لفظ بھی نہ نکل سکا۔ ان معاملات میں، ثالث کا استعمال میرے لیے بہترین کام کرتا ہے۔ ثالث اس سارے دباؤ کو روکتا ہے جو آپ پر ایک مسلسل ندی میں ڈال رہا ہے، آپ کو ضروری زین کی جگہ مل جاتی ہے، اور اس کے ساتھ بولنے کی صلاحیت واپس آتی ہے۔ یہ علم کا ایک پورا شعبہ ہے جس میں مطالعہ کرنے کے لیے بہت کچھ ہے، اپنے اندر دریافت کرنے کے لیے بہت کچھ ہے، اور یہ سب اعلیٰ سطح کے اسٹریٹجک فیصلوں میں بدل جاتا ہے جو مختلف لوگوں کے لیے مختلف ہوتے ہیں۔ کچھ لوگوں کے پاس اوپر بیان کردہ مسائل نہیں ہیں؛ عام طور پر، جو لوگ پیشہ ور سیلز ہیں ان کے پاس نہیں ہوتے۔ یہ تمام لوگ جو اپنی زندگی لفظوں سے بناتے ہیں یعنی مشہور گلوکار، شاعر، مذہبی رہنما اور سیاست دان، ان کے پاس ہمیشہ کچھ نہ کچھ کہنا ہوتا ہے۔ انہیں ایسی کوئی پریشانی نہیں ہے، لیکن مجھے ہے۔
اینڈریو: یہ غیر متوقع تھا۔ بہت اچھا، ہم پہلے ہی بہت بات کر چکے ہیں اور یہ انٹرویو ختم کرنے کا وقت ہے۔ ہم کانفرنس میں ضرور ملیں گے اور اس بات چیت کو جاری رکھنے کے قابل ہو جائیں گے۔ Hydra میں ملتے ہیں!
آپ Hydra 2019 کانفرنس میں Cliff کے ساتھ اپنی بات چیت جاری رکھ سکتے ہیں، جو 11-12 جولائی 2019 کو سینٹ پیٹرزبرگ میں منعقد ہوگی۔ وہ رپورٹ لے کر آئے گا۔ . ٹکٹ خریدے جا سکتے ہیں۔ .
ماخذ: www.habr.com