কিভাবে আমরা C++ কোডের 10 মিলিয়ন লাইন C++14 স্ট্যান্ডার্ডে অনুবাদ করেছি (এবং তারপর C++17)

কিছু সময় আগে (2016 সালের শরত্কালে), 1C: এন্টারপ্রাইজ প্রযুক্তি প্ল্যাটফর্মের পরবর্তী সংস্করণের বিকাশের সময়, নতুন মানকে সমর্থন করার বিষয়ে উন্নয়ন দলের মধ্যে প্রশ্ন উঠেছিল সি ++ 14 আমাদের কোডে। একটি নতুন স্ট্যান্ডার্ডে রূপান্তর, যেমন আমরা ধরে নিয়েছিলাম, আমাদের অনেক কিছুকে আরও মার্জিতভাবে, সহজভাবে এবং নির্ভরযোগ্যভাবে লিখতে অনুমতি দেবে এবং কোডের সমর্থন এবং রক্ষণাবেক্ষণকে সহজ করবে। এবং কোড বেসের স্কেলের জন্য এবং আমাদের কোডের নির্দিষ্ট বৈশিষ্ট্যগুলির জন্য না হলে অনুবাদে অসাধারণ কিছু নেই বলে মনে হয়।

যারা জানেন না তাদের জন্য, 1C:Enterprise হল ক্রস-প্ল্যাটফর্ম ব্যবসায়িক অ্যাপ্লিকেশনগুলির দ্রুত বিকাশের জন্য একটি পরিবেশ এবং বিভিন্ন OS এবং DBMS-এ তাদের কার্যকর করার জন্য রানটাইম। সাধারণ শর্তে, পণ্যটিতে রয়েছে:

• অ্যাপ্লিকেশন সার্ভার ক্লাস্টার, কাজ করে Windows и Linux
• ক্রেতাসার্ভারের সাথে http(s) অথবা এর নিজস্ব বাইনারি প্রোটোকলের মাধ্যমে কাজ করে। Windows, Linux, macOS
• ওয়েব ক্লায়েন্ট, Chrome, Internet Explorer, Microsoft Edge, Firefox, Safari ব্রাউজারে চলছে (জাভাস্ক্রিপ্টে লেখা)
• উন্নয়ন পরিবেশ (কনফিগারার), কাজ করে Windows, Linux, macOS
• প্রশাসনিক সরঞ্জাম অ্যাপ্লিকেশন সার্ভারগুলি চলছে Windows, Linux, macOS
• মোবাইল ক্লায়েন্টhttp(s) এর মাধ্যমে সার্ভারের সাথে সংযোগ স্থাপন করে, যা চলমান মোবাইল ডিভাইসগুলিতে কাজ করে। Android, আইওএস, Windows
• মোবাইল প্ল্যাটফর্ম সিঙ্ক্রোনাইজ করার ক্ষমতা সম্পন্ন, অফলাইন মোবাইল অ্যাপ্লিকেশন তৈরির একটি ফ্রেমওয়ার্ক, যা চলে Android, আইওএস, Windows
• উন্নয়ন পরিবেশ 1C: এন্টারপ্রাইজ ডেভেলপমেন্ট টুলস, জাভাতে লেখা
• সার্ভার মিথস্ক্রিয়া সিস্টেম

আমরা যতটা সম্ভব বিভিন্ন অপারেটিং সিস্টেমের জন্য একই কোড লেখার চেষ্টা করি - সার্ভার কোড বেস 99% সাধারণ, ক্লায়েন্ট কোড বেস প্রায় 95%। 1C: এন্টারপ্রাইজ প্রযুক্তি প্ল্যাটফর্মটি প্রাথমিকভাবে C++ এ লেখা হয় এবং আনুমানিক কোড বৈশিষ্ট্য নিচে দেওয়া হল:

• C++ কোডের 10 মিলিয়ন লাইন,
• 14 হাজার ফাইল,
• 60 হাজার ক্লাস,
• অর্ধ মিলিয়ন পদ্ধতি।

এবং এই সমস্ত জিনিসগুলি C++14 এ অনুবাদ করতে হয়েছিল। আজ আমরা আপনাকে বলব কিভাবে আমরা এটি করেছি এবং প্রক্রিয়াটিতে আমরা কী সম্মুখীন হয়েছি।

দাবিত্যাগ

বিভিন্ন লাইব্রেরিতে স্ট্যান্ডার্ড ক্লাস বাস্তবায়নের মাধ্যমে ধীর/দ্রুত কাজ, (নয়) বৃহৎ মেমরি খরচ সম্পর্কে নীচে লেখা সমস্ত কিছুর মানে হল: এটি আমাদের জন্য সত্য। এটা খুবই সম্ভব যে আদর্শ বাস্তবায়ন আপনার কাজের জন্য সবচেয়ে উপযুক্ত হবে। আমরা আমাদের নিজস্ব কাজগুলি থেকে শুরু করেছি: আমরা আমাদের ক্লায়েন্টদের জন্য সাধারণ ডেটা নিয়েছি, তাদের উপর সাধারণ পরিস্থিতি চালিয়েছি, কর্মক্ষমতা দেখেছি, মেমরির পরিমাণ ইত্যাদির দিকে নজর রেখেছি, এবং বিশ্লেষণ করেছি যে আমরা এবং আমাদের ক্লায়েন্টরা এই ধরনের ফলাফলে সন্তুষ্ট কিনা। . এবং তারা উপর নির্ভর করে অভিনয়.

আমরা কি ছিল

প্রাথমিকভাবে, আমরা মাইক্রোসফট ভিজ্যুয়াল স্টুডিওতে 1C:Enterprise 8 প্ল্যাটফর্মের কোড লিখেছিলাম। প্রকল্পটি ২০০০-এর দশকের গোড়ার দিকে শুরু হয়েছিল, এবং আমাদের কাছে কেবল একটি সংস্করণ ছিল Windowsস্বাভাবিকভাবেই, তারপর থেকে কোডটি দ্রুত বিকশিত হয়েছে এবং অনেক প্রক্রিয়া সম্পূর্ণরূপে নতুন করে লেখা হয়েছে। কিন্তু কোডটি ১৯৯৮ সালের মান অনুযায়ী লেখা হয়েছিল এবং, উদাহরণস্বরূপ, সফল কম্পাইলেশন নিশ্চিত করার জন্য আমরা ডান কোণা বন্ধনীগুলোকে স্পেস দিয়ে আলাদা করতাম, যেমনটা এখানে দেখানো হয়েছে:

vector<vector<int> > IntV;

২০০৬ সালে, প্ল্যাটফর্ম সংস্করণ ৮.১ প্রকাশের সাথে সাথে, আমরা সমর্থন করা শুরু করি Linux এবং একটি তৃতীয় পক্ষের স্ট্যান্ডার্ড লাইব্রেরিতে স্থানান্তরিত হয়েছে STLPপোর্টএই পরিবর্তনের অন্যতম কারণ ছিল প্রশস্ত স্ট্রিং নিয়ে কাজ করা। আমাদের কোডে আমরা সর্বত্র std::wstring ব্যবহার করি, যা wchar_t টাইপের উপর ভিত্তি করে তৈরি। এর আকার হলো Windows ২ বাইট, এবং এর মধ্যে Linux ডিফল্ট সাইজ হলো ৪ বাইট। এর ফলে ক্লায়েন্ট ও সার্ভারের মধ্যে আমাদের বাইনারি প্রোটোকল এবং বিভিন্ন পারসিস্টেন্ট ডেটার মধ্যে অসামঞ্জস্যতা দেখা দেয়। gcc অপশন ব্যবহার করে কম্পাইলেশনের সময় wchar_t-এর সাইজ ২ বাইট করতে বাধ্য করা যায়, কিন্তু সেক্ষেত্রে কম্পাইলারের স্ট্যান্ডার্ড লাইব্রেরি ব্যবহারের কথা ভুলে যেতে হয়, কারণ এটি glibc ব্যবহার করে, যা আবার ৪-বাইটের wchar_t-এর জন্য কম্পাইল করা হয়। অন্যান্য কারণগুলোর মধ্যে ছিল স্ট্যান্ডার্ড ক্লাসগুলোর উন্নত মানের ইমপ্লিমেন্টেশন, হ্যাশ টেবিল সাপোর্ট, এবং এমনকি কন্টেইনার মুভমেন্ট সিম্যান্টিক্সের এমুলেশন, যা আমরা সক্রিয়ভাবে ব্যবহার করতাম। এবং সবশেষে, যেমনটা বলা হয়ে থাকে, স্ট্রিং পারফরম্যান্স একটি গুরুত্বপূর্ণ বিষয় ছিল। আমাদের নিজস্ব একটি স্ট্রিং ক্লাস ছিল, কারণ আমাদের সফটওয়্যারে স্ট্রিং অপারেশন ব্যাপকভাবে ব্যবহৃত হয় এবং এটি আমাদের জন্য অত্যন্ত জরুরি।

আমাদের স্ট্রিং 2000 এর দশকের প্রথম দিকে প্রকাশিত স্ট্রিং অপ্টিমাইজেশান ধারণার উপর ভিত্তি করে আন্দ্রেই আলেকজান্দ্রেসকু. পরে, যখন আলেকজান্ডারেস্কু ফেসবুকে কাজ করেন, তখন তার পরামর্শে, ফেসবুক ইঞ্জিনে একটি লাইন ব্যবহার করা হয়েছিল যা একই নীতিতে কাজ করে (লাইব্রেরি দেখুন মূর্খতা).

আমাদের লাইন দুটি প্রধান অপ্টিমাইজেশান প্রযুক্তি ব্যবহার করেছে:

1. সংক্ষিপ্ত মানগুলির জন্য, স্ট্রিং অবজেক্টের একটি অভ্যন্তরীণ বাফার ব্যবহার করা হয় (অতিরিক্ত মেমরি বরাদ্দের প্রয়োজন নেই)।
2. অন্য সব জন্য, যান্ত্রিক ব্যবহার করা হয় অনুরূপ লিখ. স্ট্রিং মান এক জায়গায় সংরক্ষণ করা হয়, এবং নিয়োগ/পরিবর্তনের সময় একটি রেফারেন্স কাউন্টার ব্যবহার করা হয়।

প্ল্যাটফর্ম সংকলনের গতি বাড়ানোর জন্য, আমরা আমাদের STLPport ভেরিয়েন্ট (যা আমরা ব্যবহার করিনি) থেকে স্ট্রিম বাস্তবায়ন বাদ দিয়েছি, এটি আমাদের প্রায় 20% দ্রুত সংকলন দিয়েছে। পরবর্তীকালে আমাদের সীমিত ব্যবহার করতে হয়েছিল সাহায্য. বুস্ট স্ট্রিমের ব্যাপক ব্যবহার করে, বিশেষ করে এর পরিষেবা APIগুলিতে (উদাহরণস্বরূপ, লগিংয়ের জন্য), তাই আমাদের স্ট্রিমের ব্যবহার অপসারণ করতে এটি সংশোধন করতে হয়েছিল। এর ফলে, আমাদের জন্য বুস্টের নতুন সংস্করণে স্থানান্তর করা কঠিন হয়ে পড়ে।

তৃতীয় উপায়

C++14 স্ট্যান্ডার্ডে যাওয়ার সময়, আমরা নিম্নলিখিত বিকল্পগুলি বিবেচনা করি:

1. আমরা C++14 স্ট্যান্ডার্ডে পরিবর্তিত STLPport আপগ্রেড করুন। বিকল্পটি খুব কঠিন, কারণ ... STLPport-এর জন্য সমর্থন 2010 সালে বন্ধ করা হয়েছিল, এবং আমাদের নিজেরাই এর সমস্ত কোড তৈরি করতে হবে।
2. C++14-এর সাথে সামঞ্জস্যপূর্ণ অন্য একটি STL ইমপ্লিমেন্টেশনে পরিবর্তন করা হচ্ছে। এটি অত্যন্ত কাম্য যে এই ইমপ্লিমেন্টেশনটি সামঞ্জস্যপূর্ণ হবে Windows и Linux.
3. প্রতিটি ওএসের জন্য কম্পাইল করার সময়, সংশ্লিষ্ট কম্পাইলারে তৈরি লাইব্রেরি ব্যবহার করুন।

অত্যধিক কাজের কারণে প্রথম বিকল্পটি সরাসরি প্রত্যাখ্যান করা হয়েছিল।

আমরা কিছু সময়ের জন্য দ্বিতীয় বিকল্প সম্পর্কে চিন্তা; প্রার্থী হিসেবে বিবেচিত libc++কিন্তু সেই সময় তিনি অধীনে কাজ করছিলেন না Windowslibc++ পোর্ট করতে Windowsআমাদের অনেক কাজ করতে হতো — উদাহরণস্বরূপ, থ্রেড, থ্রেড সিনক্রোনাইজেশন এবং অ্যাটোমিসির সাথে সম্পর্কিত সবকিছু নিজেদেরই লিখতে হতো, যেহেতু libc++ ব্যবহার করত POSIX API.

এবং আমরা তৃতীয় পথ বেছে নিলাম।

রূপান্তরটি

সুতরাং, আমাদের STLPort-এর ব্যবহার প্রতিস্থাপন করে সংশ্লিষ্ট কম্পাইলারের লাইব্রেরিগুলো ব্যবহার করতে হয়েছিল (যেমন ভিজ্যুয়াল স্টুডিও ২০১৫)। Windows, জিসিসি ৭ এর জন্য Linux, ক্ল্যাং ৮ এর জন্য macOS).

সৌভাগ্যবশত, আমাদের কোড মূলত নির্দেশিকা অনুসারে লেখা হয়েছিল এবং এতে কোনো চালাকি ব্যবহার করা হয়নি, তাই সোর্স ফাইলগুলিতে টাইপ, ক্লাস, নেমস্পেস এবং ইনক্লুডগুলির নাম প্রতিস্থাপনকারী স্ক্রিপ্ট ব্যবহার করে নতুন লাইব্রেরিগুলিতে স্থানান্তর তুলনামূলকভাবে মসৃণভাবে সম্পন্ন হয়েছিল। এই স্থানান্তরটি ১৪,০০০ সোর্স ফাইলের মধ্যে ১০,০০০ ফাইলকে প্রভাবিত করেছিল। wchar_t-কে char16_t দিয়ে প্রতিস্থাপন করা হয়েছিল; আমরা wchar_t-এর ব্যবহার পরিত্যাগ করার সিদ্ধান্ত নিয়েছি, কারণ char16_t সমস্ত অপারেটিং সিস্টেমে ২ বাইট জায়গা নেয় এবং বিভিন্ন সিস্টেমের মধ্যে কোডের সামঞ্জস্যকে প্রভাবিত করে না। Windows и Linux.

কিছু ছোট অ্যাডভেঞ্চার ছিল। উদাহরণস্বরূপ, STLPport-এ একটি ইটারেটরকে একটি উপাদানের পয়েন্টারে নিহিতভাবে নিক্ষেপ করা যেতে পারে এবং আমাদের কোডের কিছু জায়গায় এটি ব্যবহার করা হয়েছিল। নতুন লাইব্রেরিতে এটি করা আর সম্ভব ছিল না, এবং এই প্যাসেজগুলিকে ম্যানুয়ালি বিশ্লেষণ এবং পুনরায় লিখতে হয়েছিল।

সুতরাং, কোড স্থানান্তর সম্পূর্ণ হয়েছে, কোডটি সমস্ত অপারেটিং সিস্টেমের জন্য সংকলিত হয়েছে। এটা পরীক্ষার জন্য সময়.

রূপান্তরের পরে পরীক্ষাগুলি কোডের পুরানো সংস্করণের তুলনায় কার্যক্ষমতা হ্রাস (কিছু জায়গায় 20-30% পর্যন্ত) এবং মেমরি খরচ বৃদ্ধি (10-15% পর্যন্ত) দেখিয়েছে। এটি ছিল, বিশেষত, স্ট্যান্ডার্ড স্ট্রিংগুলির সাবঅপ্টিমাল পারফরম্যান্সের কারণে। অতএব, আমাদের আবার আমাদের নিজস্ব, সামান্য পরিবর্তিত লাইন ব্যবহার করতে হয়েছিল।

এমবেডেড লাইব্রেরিতে কন্টেইনার বাস্তবায়নের একটি আকর্ষণীয় বৈশিষ্ট্যও প্রকাশিত হয়েছিল: খালি (উপাদান ছাড়া) std::map এবং std::সেট বিল্ট-ইন লাইব্রেরি থেকে মেমরি বরাদ্দ করে। এবং বাস্তবায়ন বৈশিষ্ট্যগুলির কারণে, কোডের কিছু জায়গায় এই ধরণের অনেকগুলি খালি পাত্র তৈরি করা হয়। একটি মূল উপাদানের জন্য স্ট্যান্ডার্ড মেমরি কন্টেনারগুলি সামান্য বরাদ্দ করা হয়, কিন্তু আমাদের জন্য এটি সমালোচনামূলক হয়ে উঠেছে - বেশ কয়েকটি পরিস্থিতিতে, আমাদের কর্মক্ষমতা উল্লেখযোগ্যভাবে হ্রাস পেয়েছে এবং মেমরি খরচ বেড়েছে (STLPport-এর তুলনায়)। অতএব, আমাদের কোডে আমরা বুস্ট থেকে তাদের বাস্তবায়নের সাথে বিল্ট-ইন লাইব্রেরি থেকে এই দুই ধরনের পাত্রে প্রতিস্থাপন করেছি, যেখানে এই কন্টেইনারগুলিতে এই বৈশিষ্ট্যটি ছিল না, এবং এটি স্লোডাউন এবং মেমরি খরচ বৃদ্ধির সাথে সমস্যার সমাধান করেছে।

বড় প্রজেক্টে ব্যাপক পরিবর্তনের পর যেমনটা প্রায়ই ঘটে, সোর্স কোডের প্রথম সংস্করণটি সমস্যাবিহীন ছিল না, এবং এখানে, বিশেষ করে, ডিবাগ ইটারেটরের সাপোর্টের বিষয়টি ছিল একটি সমস্যা। Windowsবাস্তবায়ন। আমরা ধাপে ধাপে এগিয়েছিলাম এবং ২০১৭ সালের বসন্তের মধ্যে (1C:Enterprise-এর সংস্করণ 8.3.11) মাইগ্রেশনটি সম্পন্ন হয়েছিল।

ফলাফল

C++14 স্ট্যান্ডার্ডে রূপান্তর করতে আমাদের প্রায় 6 মাস সময় লেগেছে। বেশিরভাগ সময়, একজন (কিন্তু অত্যন্ত যোগ্য) বিকাশকারী প্রকল্পে কাজ করেছেন এবং চূড়ান্ত পর্যায়ে নির্দিষ্ট এলাকার জন্য দায়ী দলের প্রতিনিধিরা যোগ দিয়েছেন - UI, সার্ভার ক্লাস্টার, উন্নয়ন এবং প্রশাসন সরঞ্জাম ইত্যাদি।

রূপান্তরটি স্ট্যান্ডার্ডের সর্বশেষ সংস্করণগুলিতে স্থানান্তরিত করার জন্য আমাদের কাজকে ব্যাপকভাবে সরল করেছে৷ এইভাবে, সংস্করণ 1C: এন্টারপ্রাইজ 8.3.14 (উন্নয়নে, পরবর্তী বছরের শুরুতে প্রকাশের জন্য নির্ধারিত) ইতিমধ্যেই স্ট্যান্ডার্ডে স্থানান্তরিত হয়েছে C++17.

মাইগ্রেশনের পরে, বিকাশকারীদের আরও বিকল্প রয়েছে। আগে যদি আমাদের STL-এর নিজস্ব পরিবর্তিত সংস্করণ এবং একটি std নেমস্পেস থাকত, এখন আমাদের কাছে std namespace-এ, stdx নামস্থানে অন্তর্নির্মিত কম্পাইলার লাইব্রেরি থেকে স্ট্যান্ডার্ড ক্লাস আছে - আমাদের লাইন এবং কন্টেইনারগুলি আমাদের কাজের জন্য অপ্টিমাইজ করা হয়েছে, বুস্টে - বুস্টের সর্বশেষ সংস্করণ। এবং বিকাশকারী সেই ক্লাসগুলি ব্যবহার করে যা তার সমস্যাগুলি সমাধানের জন্য সর্বোত্তমভাবে উপযুক্ত।

মুভ কনস্ট্রাক্টরগুলির "নেটিভ" বাস্তবায়নও উন্নয়নে সহায়তা করে (কনস্ট্রাক্টর সরান) বেশ কয়েকটি ক্লাসের জন্য। যদি একটি ক্লাসে একটি মুভ কনস্ট্রাক্টর থাকে এবং এই ক্লাসটি একটি পাত্রে স্থাপন করা হয়, তাহলে STL কন্টেইনারের ভিতরে উপাদানগুলির অনুলিপিকে অপ্টিমাইজ করে (উদাহরণস্বরূপ, যখন ধারকটি প্রসারিত হয় এবং এটির ক্ষমতা পরিবর্তন করা এবং মেমরি পুনরায় বরাদ্দ করা প্রয়োজন)।

মৃত্তিকা মধ্যে উড়ে

সম্ভবত মাইগ্রেশনের সবচেয়ে অপ্রীতিকর (কিন্তু সমালোচনামূলক নয়) পরিণতি হল যে আমরা ভলিউম বৃদ্ধির সম্মুখীন হচ্ছি। obj ফাইল, এবং সমস্ত মধ্যবর্তী ফাইল সহ বিল্ডের সম্পূর্ণ ফলাফল 60-70 গিগাবাইট নিতে শুরু করে। এই আচরণটি আধুনিক স্ট্যান্ডার্ড লাইব্রেরিগুলির বিশেষত্বের কারণে, যা তৈরি করা পরিষেবা ফাইলগুলির আকারের জন্য কম সমালোচনামূলক হয়ে উঠেছে। এটি সংকলিত অ্যাপ্লিকেশনটির ক্রিয়াকলাপকে প্রভাবিত করে না, তবে এটি বিকাশে বেশ কয়েকটি অসুবিধার কারণ হয়, বিশেষত, এটি সংকলনের সময় বাড়ায়। বিল্ড সার্ভার এবং ডেভেলপার মেশিনে বিনামূল্যে ডিস্ক স্থানের প্রয়োজনীয়তাও বাড়ছে। আমাদের ডেভেলপাররা প্ল্যাটফর্মের বিভিন্ন সংস্করণে সমান্তরালভাবে কাজ করে এবং কয়েকশো গিগাবাইট মধ্যবর্তী ফাইল কখনও কখনও তাদের কাজে অসুবিধা সৃষ্টি করে। সমস্যাটি অপ্রীতিকর, কিন্তু সমালোচনামূলক নয়; আমরা আপাতত এর সমাধান স্থগিত করেছি। আমরা প্রযুক্তিকে এটি সমাধানের অন্যতম বিকল্প হিসাবে বিবেচনা করছি ঐক্য গড়ে তোলা (বিশেষত, ক্রোম ব্রাউজার বিকাশ করার সময় Google এটি ব্যবহার করে)।

উত্স: www.habr.com