পাইথন জিআইএল অপসারণের প্রাথমিক প্রয়াস খারাপ ফলাফলের কারণ: কেন?


13

পাইথনের স্রষ্টা, গিডো ভ্যান রসুমের এই পোস্টে পাইথন থেকে জিআইএল অপসারণের প্রাথমিক প্রয়াসের কথা উল্লেখ করা হয়েছে:

হতাশাজনক ফলাফল সহ এটি এর আগে চেষ্টা করা হয়েছিল, এ কারণেই আমি নিজে এটিতে অনেক চেষ্টা করতে নারাজ। ১৯৯৯ সালে গ্রেগ স্টেইন (মার্ক হ্যামন্ডের সাথে?) পাইথনের একটি কাঁটাচামচ তৈরি করেছিলেন (১.৫ আমি বিশ্বাস করি) এটি জিআইএলকে সরিয়ে নিয়েছিল এবং এটি সমস্ত পরিবর্তিত ডেটা স্ট্রাকচারে সূক্ষ্ম দানযুক্ত লক দিয়ে প্রতিস্থাপন করেছিল। তিনি এমন প্যাচও জমা দিয়েছিলেন যা বৈশ্বিক পরিবর্তনীয় ডেটা কাঠামোর উপর নির্ভরতা অনেকগুলি সরিয়ে নিয়েছিল, যা আমি মেনে নিয়েছি। যাইহোক, বেঞ্চমার্কিংয়ের পরে, এটি দেখানো হয়েছিল যে এমনকি প্ল্যাটফর্মে দ্রুততম লকিং আদিম (সেই সময়ে উইন্ডোজ) সহ এটি একক থ্রেডযুক্ত সম্পাদনকে প্রায় দ্বিগুণ করে তোলে, যার অর্থ দুটি সিপিইউতে আপনি আরও কিছুটা কাজ পেতে পারেন জিআইএল ছাড়া জিআইএল ছাড়া একক সিপিইউয়ের চেয়েও সম্পন্ন হয়েছে। এটি যথেষ্ট ছিল না, এবং গ্রেগের প্যাচটি বিস্মৃত হয়ে যায়। (পারফরম্যান্সে গ্রেগের রাইটিংআপ দেখুন))

আমি প্রকৃত ফলাফলের সাথে খুব কমই তর্ক করতে পারি, তবে আমি সত্যিই ভাবছি কেন এটি ঘটেছিল। সম্ভবত, সিপিথন থেকে জিআইএল অপসারণের মূল কারণটি রেফারেন্স কাউন্টিং মেমরি ম্যানেজমেন্ট সিস্টেম। একটি সাধারণ পাইথন প্রোগ্রাম কল করবে Py_INCREFএবং Py_DECREFকয়েক হাজার বা কয়েক মিলিয়ন বার কল করবে , যদি আমরা এর চারপাশে তালা গুটিয়ে রাখি তবে এটি একটি মূল বিষয়বস্তু হিসাবে পরিণত হবে।

তবে, আমি বুঝতে পারছি না কেন পারমাণবিক আদিম সংযোজন একক থ্রেডেড প্রোগ্রামকে ধীর করে দেবে । ধরুন আমরা কেবল সিপিথনকে সংশোধন করেছি যাতে প্রতিটি পাইথন অবজেক্টের রিফকઉન્ટ ভেরিয়েবলটি একটি পারমাণবিক আদিম ছিল। এবং তারপরে আমরা কেবলমাত্র একটি পারমাণবিক বর্ধন করি (রেফার-এন্ড-এড নির্দেশনা) করি যখন আমাদের রেফারেন্সের সংখ্যা বাড়ানো দরকার। এটি পাইথন রেফারেন্স গণনা থ্রেড-নিরাপদ করে তুলবে এবং একক থ্রেডযুক্ত অ্যাপ্লিকেশনটিতে কোনও পারফরম্যান্স জরিমানা করা উচিত নয়, কারণ কোনও লক যুক্তি থাকবে না।

তবে হায়, আমার চেয়ে বেশি স্মার্ট যারা চেষ্টা করেছেন এবং ব্যর্থ হয়েছেন, তাই স্পষ্টতই আমি এখানে কিছু মিস করছি। আমি যেভাবে সমস্যাটি দেখছি তাতে কী ভুল?


1
নোট করুন যে রিফকাউন্ট অপারেশনটি সিঙ্ক্রোনাইজেশনের প্রয়োজনের একমাত্র জায়গা নয়। উদ্ধৃতিতে "সমস্ত পরিবর্তনীয় ডেটা স্ট্রাকচারের উপর সূক্ষ্ম দানযুক্ত লকগুলি" উল্লেখ করা হয়েছে যা আমি অনুমান করি যে প্রতিটি তালিকা এবং অভিধানের অবজেক্টের জন্য কমপক্ষে একটি মিটেক্স অন্তর্ভুক্ত রয়েছে। এছাড়াও, আমি মনে করি না যে পারমাণবিক পূর্ণসংখ্যা অপারেশনগুলি পার্থক্য ছাড়াই অ-পারমাণবিক সমতুলের মতো দক্ষ, আপনি কি তার কোনও উত্স পেয়েছেন?

কেবলমাত্র, কারণ পারমাণবিক অপারেশনগুলি অ-পারমাণবিক সমতুল্যের চেয়ে ধীর। এটি কেবলমাত্র একক নির্দেশার অর্থ হুডের নীচে তুচ্ছ। কিছু আলোচনার জন্য এটি দেখুন
মার্চ

উত্তর:


9

আমি গ্রেগ স্টেইন পাইথন কাঁটাচামচ সম্পর্কে অপরিচিত, সুতরাং আপনি যদি চান তবে এই তুলনাটি অনুমানমূলক historicalতিহাসিক উপমা হিসাবে ছাড় করুন। তবে একাকী থেকে বহু-থ্রেড বাস্তবায়নে অনেক অবকাঠামো কোডবেসের চলার ঠিক এটি historical তিহাসিক অভিজ্ঞতা ।

মূলত 1990 এর দশকে আমি যে ইউনিক্স বাস্তবায়ন করেছি - এআইএক্স, ডিইসি ওএসএফ / 1, ডিজি / ইউএক্স, ডিওয়াইএনএক্স, এইচপি-ইউএক্স, আইআরআইএক্স, সোলারিস, এসভিআর 4, এবং এসভিআর 4 এমপি - সবই আমরা এই ধরণের "আমরা রেখেছি সূক্ষ্ম দানযুক্ত লকিং - এখন এটি ধীর !! সমস্যা। আমি যে ডিবিএমএস অনুসরণ করেছি - ডিবি 2, ইঙ্গ্রেস, ইনফর্মিক্স, ওরাকল এবং সিবেস - তারা সকলেই এটি পেরেছিলেন।

আমি শুনেছি "যখন আমরা একক থ্রেডযুক্ত চলছি" তখন এক মিলিয়ন বার এই পরিবর্তনগুলি আমাদের ধীর করবে না। এটি কখনই সেভাবে কার্যকর হয় না। শর্তসাপেক্ষে যাচাইয়ের সহজ কাজটি "আমরা মাল্টিথ্রেডেড চালাচ্ছি, না?" বিশেষত উচ্চ-পাইপলাইনযুক্ত সিপিইউগুলিতে প্রকৃত ওভারহেড যুক্ত করে। ভাগ করা ডেটা স্ট্রাকচারের অখণ্ডতা নিশ্চিত করতে পারমাণবিক ক্রিয়াকলাপ এবং মাঝে মাঝে স্পিন-লক যুক্ত করা হয় এবং এগুলি খুব ধীর হয়। প্রথম-প্রজন্মের লক / সিঙ্ক্রোনাইজেশন আদিমগুলিও ধীর ছিল। বেশিরভাগ বাস্তবায়ন দলগুলি বিভিন্ন স্থানে কতগুলি ইন্টারলক সুরক্ষা প্রয়োজন ছিল তার উপর নির্ভর করে বিভিন্ন "শক্তি "গুলিতে শেষ পর্যন্ত বিভিন্ন শ্রেণীর আদিম শ্রেণি যুক্ত করে। তারপরে তারা বুঝতে পেরেছিল যে তারা প্রাথমিকভাবে লক করা আদিমকে সত্যিকার অর্থে সঠিক জায়গা নয়, তাই তাদের প্রোফাইল তৈরি করতে হয়েছিল, খুঁজে পাওয়া বাধা around এবং পদ্ধতিগতভাবে রোটো-টু। এর মধ্যে কিছু স্টিকিং পয়েন্ট অবশেষে ওএস বা হার্ডওয়্যার ত্বরণ পেয়েছিল, তবে পুরো বিবর্তনটি সর্বনিম্ন সর্বনিম্ন 3-5 বছর সময় নেয়। এদিকে, এমপি বা এমটি সংস্করণগুলি হতাশাগ্রস্ত, পারফরম্যান্স ভিত্তিক।

অন্যথায় পরিশীলিত উন্নয়ন দলগুলি যুক্তি দেখিয়েছে যে এই ধরণের মন্দা মূলত জীবনের একটি অবিচল, অবিচলিত সত্য। আইবিএম যেমন প্রতিযোগিতার পরে কমপক্ষে 5 বছর ধরে এআইএক্স-কে এসএমপি-সক্ষম করতে অস্বীকৃতি জানিয়েছিল, একক থ্রেডযুক্ত কেবল নিখুঁতভাবেই ভাল ছিল ad সাইবাসটি একই রকম কিছু যুক্তি ব্যবহার করেছিল। কিছু দল অবশেষে ঘুরে দাঁড়ানোর একমাত্র কারণ ছিল যে সিপিইউ স্তরে একক থ্রেডের পারফরম্যান্স আর যুক্তিসঙ্গতভাবে উন্নত করা যায় না। তারা হয় এমপি / এমটি যেতে বা ক্রমবর্ধমান অপ্রতিযোগিতামূলক পণ্য গ্রহণ করতে বাধ্য হয়েছিল।

সক্রিয় সম্মতিটি হার্ড। এবং এটি প্রতারণামূলক। "এটি এত খারাপ হবে না" এই ভেবে সবাই ছুটে যায়। তারপরে তারা কুইকস্যান্ডে আঘাত করেছিল এবং তাদের মধ্যে দিয়ে প্লড করতে হয়েছিল। আমি কমপক্ষে এক ডজন নাম-ব্র্যান্ড, ভাল অর্থায়িত, স্মার্ট দলগুলির সাথে এটি দেখতে পেয়েছি। সাধারণত এমপি / এমটি পণ্যাদির সাথে "তারা যেখানে হওয়া উচিত, পারফরম্যান্স-ওয়াইস" করতে মাল্টি-থ্রেড বেছে নেওয়ার পরে কমপক্ষে পাঁচ বছর সময় লাগবে; বেশিরভাগগুলি এমপি / এমটি দক্ষতা / স্কেলিবিলিটিটি স্থানান্তরিত হওয়ার দশ বছর পরেও অর্থবহভাবে উন্নত করেছিলেন।

সুতরাং আমার জল্পনাটি হ'ল, জিভিআর এর অনুপস্থিতি এবং সমর্থন অনুপস্থিত, পাইথন এবং এর জিআইএল-এর পক্ষে কেউই দীর্ঘ যাত্রা শুরু করে নি। এমনকি যদি তারা আজ এটি করে থাকে তবে আপনি "ওয়াও! আমরা এমটি হ্যাম্পের উপর দিয়ে এসেছি!" বলার আগে এটি পাইথন ৪.x সময়সীমার হতে হবে!

সম্ভবত কিছু ম্যাজিক রয়েছে যা পাইথন এবং তার রানটাইমকে অন্যান্য সমস্ত রাষ্ট্রীয় অবকাঠামো সফ্টওয়্যার থেকে পৃথক করে - এর আগে চলে গেছে সমস্ত ভাষা রানটাইম, অপারেটিং সিস্টেম, লেনদেন মনিটর এবং ডাটাবেস পরিচালক। তবে যদি তা হয়, এটি অনন্য বা প্রায় তাই। জিআইএল-সমতুল্য অপসারণকারী প্রত্যেকে এমটি-না থেকে এমটি-হটে যাওয়ার জন্য পাঁচ-বেশি বছর কঠোর, প্রতিশ্রুতিবদ্ধ প্রচেষ্টা এবং বিনিয়োগ নিয়েছে।


2
+1 বিকাশকারীদের মোটামুটি ছোট দলের সাথে একাধিক থ্রেড টিসিএল এ ধরণের সময় লেগেছিল। কোডটি এর আগে এমটি-নিরাপদ ছিল, তবে বেশিরভাগ মেমরি পরিচালনায় (যা আমি সন্দেহ করি গতিশীল ভাষাগুলির জন্য খুব উষ্ণ অঞ্চল) এটিতে বাজে পারফরম্যান্স সমস্যা ছিল। অভিজ্ঞতাটি যদিও সর্বাধিক সাধারণ ব্যতীত অন্য কোনও কিছুতে পাইথনের কাছে পৌঁছে দেয় না; দুটি ভাষার সম্পূর্ণ আলাদা থ্রেডিং মডেল রয়েছে। ঠিক ... একটি শ্লোগান আশা এবং অদ্ভুত বাগ প্রত্যাশা ...
ডোনাল ফেলো

-1

আরেকটি বুনো অনুমান: ১৯৯৯ সালে লিনাক্স এবং অন্যান্য ইউনিয়নে futex(2)( http://en.wikedia.org/wiki/Futex ) এর মতো পারফরম্যান্ট সিঙ্ক্রোনাইজেশন ছিল না । এগুলি ২০০২ এর কাছাকাছি এসেছিল (এবং 2004 এর প্রায় 2.6 এ একীভূত হয়েছিল)।

যেহেতু সমস্ত বিল্টিন ডেটা স্ট্রাকচারগুলিকে সিঙ্ক্রোনাইজ করতে হয় লকিংয়ের জন্য অনেক বেশি খরচ হয়। Ӎσᶎ ইতিমধ্যে চিহ্নিত করা হয়েছে যে পারমাণবিক অপারেশন সস্তার প্রয়োজন হয় না।


1
আপনার এটিকে ব্যাক আপ করার মতো কিছু আছে? নাকি এই প্রায় জল্পনা?

1
জিভিআর উদ্ধৃতিটি "দ্রুততম লকিং আদিম (সেই সময়ে উইন্ডোজ) সহ প্ল্যাটফর্মে" পারফরম্যান্সের বর্ণনা দেয় তাই লিনাক্সের উপর ধীর লক প্রাসঙ্গিক নয়।
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.