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

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

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

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

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

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

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

দাবিত্যাগ

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

আমরা কি ছিল

প্রাথমিকভাবে, আমরা Microsoft Visual Studio ব্যবহার করে 1C:Enterprise 8 প্ল্যাটফর্মের জন্য কোড লিখেছিলাম। প্রকল্পটি 2000 এর দশকের গোড়ার দিকে শুরু হয়েছিল এবং আমাদের কাছে একটি উইন্ডোজ-শুধু সংস্করণ ছিল। স্বাভাবিকভাবেই, তারপর থেকে কোডটি সক্রিয়ভাবে বিকশিত হয়েছে, অনেকগুলি প্রক্রিয়া সম্পূর্ণরূপে পুনর্লিখন করা হয়েছে। কিন্তু কোডটি 1998 স্ট্যান্ডার্ড অনুযায়ী লেখা হয়েছিল, এবং উদাহরণস্বরূপ, আমাদের ডান কোণ বন্ধনীগুলি স্পেস দ্বারা পৃথক করা হয়েছিল যাতে সংকলন সফল হবে, যেমন:

vector<vector<int> > IntV;

2006 সালে, প্ল্যাটফর্ম সংস্করণ 8.1 প্রকাশের সাথে, আমরা লিনাক্সকে সমর্থন করা শুরু করি এবং একটি তৃতীয় পক্ষের স্ট্যান্ডার্ড লাইব্রেরিতে স্যুইচ করি। STLPপোর্ট. স্থানান্তরের একটি কারণ ছিল প্রশস্ত লাইন দিয়ে কাজ করা। আমাদের কোডে, আমরা std::wstring ব্যবহার করি, যা wchar_t প্রকারের উপর ভিত্তি করে, সর্বত্র। উইন্ডোজে এর আকার 2 বাইট এবং লিনাক্সে ডিফল্ট 4 বাইট। এটি ক্লায়েন্ট এবং সার্ভারের পাশাপাশি বিভিন্ন স্থায়ী ডেটার মধ্যে আমাদের বাইনারি প্রোটোকলগুলির অসামঞ্জস্যতার দিকে পরিচালিত করে। gcc বিকল্পগুলি ব্যবহার করে, আপনি নির্দিষ্ট করতে পারেন যে সংকলনের সময় wchar_t এর আকারও 2 বাইট, তবে তারপরে আপনি কম্পাইলার থেকে স্ট্যান্ডার্ড লাইব্রেরি ব্যবহার করার কথা ভুলে যেতে পারেন, কারণ এটি glibc ব্যবহার করে, যা একটি 4-বাইট wchar_t এর জন্য সংকলিত হয়। অন্যান্য কারণগুলি হল স্ট্যান্ডার্ড ক্লাসগুলির আরও ভাল বাস্তবায়ন, হ্যাশ টেবিলের জন্য সমর্থন এবং এমনকি পাত্রের ভিতরে চলার শব্দার্থবিদ্যার অনুকরণ, যা আমরা সক্রিয়ভাবে ব্যবহার করেছি। এবং আরো একটি কারণ, তারা শেষ কিন্তু অন্তত না বলে, স্ট্রিং কর্মক্ষমতা ছিল. স্ট্রিংয়ের জন্য আমাদের নিজস্ব ক্লাস ছিল, কারণ... আমাদের সফ্টওয়্যারের বিশেষত্বের কারণে, স্ট্রিং অপারেশনগুলি ব্যাপকভাবে ব্যবহৃত হয় এবং এটি আমাদের জন্য গুরুত্বপূর্ণ।

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

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

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

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

তৃতীয় উপায়

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

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

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

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

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

রূপান্তরটি

সুতরাং, আমাদের সংশ্লিষ্ট কম্পাইলারগুলির লাইব্রেরির সাথে STLPport এর ব্যবহার প্রতিস্থাপন করতে হয়েছিল (উইন্ডোজের জন্য ভিজ্যুয়াল স্টুডিও 2015, লিনাক্সের জন্য gcc 7, macOS-এর জন্য ক্ল্যাং 8)।

সৌভাগ্যবশত, আমাদের কোডটি মূলত নির্দেশিকা অনুসারে লেখা হয়েছিল এবং সব ধরণের চতুর কৌশল ব্যবহার করেনি, তাই নতুন লাইব্রেরিতে স্থানান্তর তুলনামূলকভাবে মসৃণভাবে এগিয়েছিল, স্ক্রিপ্টগুলির সাহায্যে যা প্রকার, শ্রেণী, নামস্থান এবং উৎসের অন্তর্ভুক্ত নামগুলি প্রতিস্থাপন করেছিল। নথি পত্র. মাইগ্রেশন 10 সোর্স ফাইলকে প্রভাবিত করেছে (000টির মধ্যে)। wchar_t char14_t দ্বারা প্রতিস্থাপিত হয়েছে; আমরা wchar_t ব্যবহার পরিত্যাগ করার সিদ্ধান্ত নিয়েছি, কারণ char000_t সমস্ত ওএসে 16 বাইট নেয় এবং উইন্ডোজ এবং লিনাক্সের মধ্যে কোড সামঞ্জস্য নষ্ট করে না।

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

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

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

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

যেমনটি প্রায়শই বড় প্রকল্পগুলিতে বড় আকারের পরিবর্তনের পরে ঘটে, সোর্স কোডের প্রথম পুনরাবৃত্তি সমস্যা ছাড়াই কাজ করেনি এবং এখানে, বিশেষত, উইন্ডোজ বাস্তবায়নে ডিবাগিং পুনরাবৃত্তির জন্য সমর্থন কাজে এসেছে। ধাপে ধাপে আমরা এগিয়ে গেলাম, এবং 2017 সালের বসন্তে (সংস্করণ 8.3.11 1C:Enterprise) মাইগ্রেশন সম্পন্ন হয়েছে।

ফলাফল

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

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

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

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

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

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

উত্স: www.habr.com