प्रथम C++ (m) वाटप नेहमी 72 KB का असते?

तुमच्या पहिल्या C++ वाटपामागील रहस्य

तुम्ही एक साधा C++ प्रोग्राम लिहा. एकल नवीन इंट. चार बाइट्स. तुम्ही स्ट्रेस किंवा तुमचा आवडता मेमरी प्रोफाइलर फायर करा आणि ते तिथेच आहे — तुमच्या प्रक्रियेने ऑपरेटिंग सिस्टमकडून अंदाजे ७२ KB ची विनंती केली आहे. 4 बाइट नाही. 64 बाइट्स नाही. पूर्ण 72 KB. जर तुम्ही कधीही त्या नंबरकडे टक लावून पाहिलं असेल आणि तुम्हाला वाटलं असेल की तुमचे टूलिंग तुमच्याशी खोटे बोलत असेल तर तुम्ही एकटे नाही आहात. हे विचित्र वाटणारे वर्तन C++ डेव्हलपरमध्ये पहिल्यांदाच मेमरी इंटर्नल्समध्ये खोदून विचारले जाणारे सर्वात वारंवार विचारले जाणारे प्रश्न आहे आणि उत्तर आम्हाला तुमचा कोड आणि वास्तविक हार्डवेअर यांच्यामध्ये बसलेल्या थरांमधून एक आकर्षक प्रवासात घेऊन जाते.

तुम्ही नवीन

72 KB आकृती समजून घेण्यासाठी, तुम्हाला संपूर्ण वाटप साखळी ट्रेस करणे आवश्यक आहे. जेव्हा तुमचा C++ कोड नवीन इंट कार्यान्वित करतो, तेव्हा कंपायलर ते ऑपरेटर नवीन ला कॉलमध्ये भाषांतरित करतो, जे बहुतेक Linux सिस्टमवर glibc कडून malloc ला दिले जाते. पण malloc कर्नलला 4 बाइट्स मेमरी थेट विचारत नाही. कर्नल पृष्ठांमध्ये कार्य करते — सामान्यत: x86_64 वर 4 KB — आणि सिस्टीम कॉलची किंमत साध्या मेमरी ऍक्सेसच्या तुलनेत खूप जास्त असते. प्रत्येक वैयक्तिक वाटपासाठी brk() किंवा mmap() कॉल केल्याने कोणताही गैर-क्षुल्लक कार्यक्रम थांबेल.

त्याऐवजी, glibc चे मेमरी ऍलोकेटर — ptmalloc2 नावाची अंमलबजावणी, स्वतःच डग लीच्या क्लासिक dlmalloc वरून आलेली आहे — मध्यस्थ म्हणून काम करते. हे कर्नल अपफ्रंट वरून मेमरीच्या मोठ्या ब्लॉक्सची विनंती करते, नंतर आपल्या प्रोग्रामला आवश्यकतेनुसार त्यांचे लहान तुकडे करतात. हे मूलभूत कारण आहे की तुमचे पहिले 4-बाइट वाटप ऑपरेटिंग सिस्टमला खूप मोठी विनंती ट्रिगर करते. वाटपाचा अपव्यय होत नाही. हे धोरणात्मक आहे.

72 KB विच्छेदन: बाइट्स कुठे जातात

प्रारंभिक वाटप ओव्हरहेड अनेक भिन्न घटकांमधून येते जे रनटाइमने तुम्हाला वापरता येण्याजोग्या मेमरीचा एक बाइट देण्याआधी आरंभ केला पाहिजे. प्रत्येक घटक समजून घेतल्याने संख्या जिथे येते तिथे का येते हे स्पष्ट करते.

प्रथम, glibc चे malloc मुख्य रिंगण सुरू करते — प्राथमिक बुककीपिंग संरचना जी मुख्य थ्रेडवरील सर्व वाटपांचा मागोवा घेते. या रिंगणात ढीग, फ्री-लिस्ट पॉइंटर्स आणि वेगवेगळ्या वाटप आकारांसाठी बिन संरचनांचा मेटाडेटा समाविष्ट आहे. वाटप करणारा प्रोग्राम ब्रेक sbrk() द्वारे वाढवतो आणि प्रारंभिक विस्तार M_TOP_PAD नावाच्या अंतर्गत पॅरामीटरद्वारे नियंत्रित केला जातो, जो 128 KB पॅडिंगवर डीफॉल्ट असतो. तथापि, वास्तविक प्रारंभिक विनंती पृष्ठ संरेखन आणि विद्यमान ब्रेक स्थितीसाठी समायोजित केली जाते, ज्याचा परिणाम सहसा लहान प्रथम विनंतीमध्ये होतो — सामान्यत: नव्याने सुरू केलेल्या प्रक्रियेवर 72 KB आकृतीच्या जवळ उतरणे.

दुसरे, glibc 2.26 पासून, ऍलोकेटर प्रथम वापरावर थ्रेड-लोकल कॅशे (tcache) सुरू करतो. tcache मध्ये 64 डब्बे असतात (एक प्रति लहान-वाटप आकार वर्ग), प्रत्येक 7 कॅशे भाग ठेवण्यास सक्षम असतो. tcache_perthread_struct स्वतःच सुमारे 1 KB वापरते, परंतु ते सुरू करण्याची क्रिया व्यापक क्षेत्र सेटअपला चालना देते. तिसरे, C++ रनटाइमने तुमचे main() अगदी रन होण्यापूर्वीच वाटप केले आहे — स्टॅटिक कन्स्ट्रक्टर, std::cout आणि मित्रांसाठी iostream बफर इनिशिएलायझेशन आणि लोकेल सेटअप हे सर्व त्या प्रारंभिक ढीग फूटप्रिंटमध्ये योगदान देतात.

रिंगण प्रणाली आणि प्री-अलोकेशन स्मार्ट का आहे

मोठ्या प्रमाणात स्मरणशक्तीची विनंती करण्याऐवजी पूर्व-वाटप करण्याचा निर्णय हा अंमलबजावणीचा अपघात नाही. हे एक मुद्दाम अभियांत्रिकी ट्रेडऑफ आहे ज्याचे मूळ अनेक दशकांच्या सिस्टम प्रोग्रामिंग अनुभवामध्ये आहे. brk() किंवा mmap() ला प्रत्येक कॉलमध्ये वापरकर्ता स्पेस ते कर्नल स्पेसमध्ये संदर्भ स्विच, प्रक्रियेच्या आभासी मेमरी मॅपिंगमध्ये बदल आणि संभाव्य पृष्ठ सारणी अद्यतने समाविष्ट असतात. आधुनिक हार्डवेअरवर, एका सिस्टीम कॉलची किंमत अंदाजे 100-200 नॅनोसेकंद असते — अलगावमध्ये क्षुल्लक, मोठ्या प्रमाणावर आपत्तीजनक.

सुरुवात करताना 10,000 लहान वाटप करणाऱ्या प्रोग्रामचा विचार करा. प्री-अलोकेशनशिवाय, याचा अर्थ 10,000 सिस्टम कॉल्स असतील, ज्याची किंमत अंदाजे 1-2 मिलिसेकंद शुद्ध ओव्हरहेड असेल. एरेना-आधारित ऍलोकेटरसह, पहिले वाटप सिंगल सिस्टम कॉल ट्रिगर करते आणि त्यानंतरचे 9,999 वाटप पूर्णपणे वापरकर्ता स्पेसमध्ये पॉइंटर अंकगणित आणि लिंक्ड-लिस्ट ऑपरेशन्सद्वारे सर्व्हिस केले जातात - प्रत्येक अंदाजे 10-50 नॅनोसेकंद घेते. गणित अस्पष्ट आहे: प्री-अलोकेशन परिमाणाच्या ऑर्डरने जिंकते.

तुमच्या पहिल्या वाटपावर तुम्ही पहात असलेली 72 KB ही मेमरी वाया जात नाही — ही एक कामगिरी गुंतवणूक आहे. तुमचा प्रोग्राम लवकरच अधिक वाटप करेल अशी अलोकेटर पैज लावत आहे, आणि अक्षरशः प्रत्येक वास्तविक-जगातील परिस्थितीमध्ये, त्या पैजचा चांगला मोबदला मिळतो. आधुनिक 64-बिट सिस्टीमवर न वापरलेल्या व्हर्च्युअल ॲड्रेस स्पेसची किंमत मूलत: शून्य आहे.

व्हर्च्युअल मेमरी विरुद्ध भौतिक मेमरी: का काही फरक पडत नाही

प्रथमच या वर्तनाचा सामना करणाऱ्या विकासकांमध्ये एक सामान्य चिंतेची बाब म्हणजे संसाधनांचा अपव्यय. जर मला फक्त 4 बाइट्स हवे असतील, तर माझा प्रोग्राम 72 KB का वापरत आहे? गंभीर अंतर्दृष्टी अशी आहे की आभासी मेमरी भौतिक मेमरी नाही. जेव्हा glibc प्रोग्राम ब्रेक 72 KB ने वाढवते, तेव्हा कर्नल प्रक्रियेचे आभासी मेमरी मॅपिंग अद्यतनित करते, परंतु ते त्या पृष्ठांना भौतिक RAM सह त्वरित बॅक करत नाही. वास्तविक भौतिक पृष्ठे पृष्ठ दोष द्वारे मागणीनुसार वाटप केली जातात — जेव्हा तुमचा प्रोग्राम विशिष्ट पत्त्यावर लिहितो तेव्हाच कर्नल त्यास मेमरीचे वास्तविक पृष्ठ नियुक्त करते.

याचा अर्थ असा आहे की जरी तुमच्या प्रक्रियेचा आभासी आकार 72 KB ने वाढला असला तरी, त्याचा निवासी सेट आकार (RSS) — प्रत्यक्षात वापरलेल्या भौतिक RAM चे प्रमाण — तुम्ही प्रत्यक्ष स्पर्श करता त्या पृष्ठांनीच वाढते. एकल नवीन इंट साठी, ते सामान्यत: एक 4 KB पृष्ठ आहे, तसेच एरेना मेटाडेटा व्यापलेली कोणतीही पृष्ठे. उर्वरित व्हर्च्युअल स्पेस तेथे बसते, वापरासाठी तयार आहे, पत्त्याच्या जागेशिवाय काहीही लागत नाही — त्यापैकी तुमच्याकडे 64-बिट लिनक्स सिस्टमवर 128 TB आहे.

उत्पादन अनुप्रयोगांचे प्रोफाइलिंग आणि निरीक्षण करताना हा फरक महत्त्वपूर्ण आहे. तुम्ही असे सॉफ्टवेअर तयार करत असाल ज्याला रिअल रिसोर्सचा वापर ट्रॅक करणे आवश्यक आहे — मग ते SaaS बॅकएंड असो, मायक्रोसर्व्हिस असो किंवा व्यवसाय ऑपरेशन्ससाठी Mewayz सारख्या प्लॅटफॉर्मवर चालणारी विश्लेषण पाइपलाइन असो — तुम्ही नेहमी आभासी आकारापेक्षा RSS चे निरीक्षण केले पाहिजे. /proc/[pid]/smaps, valgrind --tool=massif आणि pmap सारखी साधने तुम्हाला चुकीच्या आभासी मेमरी आकृत्यांऐवजी अचूक भौतिक मेमरी फूटप्रिंट देऊ शकतात.

भिन्न वाटप करणारे पहिले वाटप कसे हाताळतात

72 KB आकृती glibc च्या ptmalloc2 साठी विशिष्ट आहे. इतर वाटप करणारे वेगवेगळे ट्रेडऑफ करतात आणि प्रारंभिक वाटप ओव्हरहेड त्यानुसार बदलते. कार्यप्रदर्शन-संवेदनशील अनुप्रयोगांसाठी वाटपकर्ता निवडताना हे फरक समजून घेणे मौल्यवान आहे.

• jemalloc (Facebook, FreeBSD द्वारे वापरलेले) — थ्रेड-लोकल कॅशेसह अधिक दाणेदार रिंगण रचना वापरते. प्रारंभिक ओव्हरहेड जास्त असतो (बहुतेकदा 200+ KB) परंतु लॉक विवाद कमी झाल्यामुळे चांगले मल्टी-थ्रेडेड कार्यप्रदर्शन देते.
• tcmalloc (Google चे Thread-Caching Malloc) — आक्रमक प्री-अलोकेशनसह, डीफॉल्टनुसार अंदाजे 2 MB प्रति-थ्रेड कॅशे वाटप करते. प्रारंभिक ओव्हरहेड जास्त आहे, परंतु त्यानंतरचे छोटे वाटप अत्यंत जलद आहेत.
• musl libc's malloc — सर्व वाटपांसाठी mmap वर आधारित अधिक सोपी रचना वापरते. प्रारंभिक ओव्हरहेड किमान आहे (अनेकदा प्रति वाटप फक्त 4 KB), परंतु अधिक वारंवार सिस्टम कॉलमुळे प्रति-वाटप खर्च जास्त असतो.
• mimalloc (Microsoft) — 64 MB विभागांसह सेगमेंट-आधारित वाटप वापरते. पहिले वाटप 64 MB व्हर्च्युअल आरक्षण (किमान भौतिक बांधिलकीसह), अपवादात्मक परिसर आणि थ्रूपुटसाठी ट्रेडिंग ॲड्रेस स्पेस ट्रिगर करते.

या वाटपकर्त्यांमधील निवड पूर्णपणे तुमच्या वर्कलोडवर अवलंबून असते. हेवी मल्टी-थ्रेडेड ऍलोकेशनसह दीर्घकाळ चालणाऱ्या सर्व्हर ऍप्लिकेशन्ससाठी, jemalloc किंवा tcmalloc सामान्यत: glibc च्या डीफॉल्टपेक्षा जास्त कामगिरी करतात. मेमरी-प्रतिबंधित एम्बेडेड सिस्टमसाठी, कमी थ्रूपुट असूनही मसलचा सोपा दृष्टीकोन श्रेयस्कर असू शकतो. बहुतेक सामान्य-उद्देशीय डेस्कटॉप आणि सर्व्हर अनुप्रयोगांसाठी, ptmalloc2 चे 72 KB प्रारंभिक ओव्हरहेड वाजवी डीफॉल्टचे प्रतिनिधित्व करते जे ट्यूनिंगशिवाय चांगले कार्य करते.

प्रारंभिक वाटप वर्तन ट्यूनिंग

जर डीफॉल्ट 72 KB प्रारंभिक ओव्हरहेड तुमच्या वापरासाठी खरोखर समस्याप्रधान असेल — कदाचित तुम्ही हजारो अल्पायुषी प्रक्रिया निर्माण करत असाल, त्या प्रत्येकाने मोजकेच वाटप केले आहे — glibc mallopt() आणि MALLOC_परिवाराच्या कुटुंबाच्या द्वारे अनेक ट्यूनेबल प्रदान करते.

M_TOP_PAD पॅरामीटर ताबडतोब आवश्यक असलेल्यापेक्षा किती अतिरिक्त मेमरीची विनंती करतो हे नियंत्रित करते. मॅलॉपट(M_TOP_PAD, 0) सह 0 वर सेट केल्याने वाटपकर्त्याला फक्त आवश्यक असलेली विनंती करण्यास सांगते, प्रारंभिक ओव्हरहेड लक्षणीयरीत्या कमी करते. M_MMAP_THRESHOLD पॅरामीटर एरेनाऐवजी mmap वापरत असलेल्या वरील आकार नियंत्रित करते. M_TRIM_THRESHOLD OS वर मोकळी मेमरी परत केल्यावर नियंत्रित करते. आणि glibc 2.26 पासून, glibc.malloc.tcache_count आणि glibc.malloc.tcache_max ट्यूनेबल्स तुम्हाला थ्रेड कॅशे वर्तन नियंत्रित करू देतात.

तथापि, सावधगिरीचा एक शब्द: काळजीपूर्वक बेंचमार्किंगशिवाय हे पॅरामीटर्स ट्यून करणे जवळजवळ नेहमीच गोष्टी खराब करते. डीफॉल्ट विस्तृत वास्तविक-जागतिक प्रोफाइलिंगवर आधारित निवडले गेले होते आणि ते बहुसंख्य वर्कलोड्ससाठी एक गोड ठिकाण दर्शवतात. malloc ओव्हरहेड एक अडचण आहे - आणि तुम्ही तुमच्या बदलांचा प्रभाव मोजला आहे - याचा प्रॉडक्शन प्रोफाइलिंगमधून तुमच्याकडे मजबूत पुरावा असल्याशिवाय - डीफॉल्ट्स सोडा. ऍलोकेटरचे अकाली ऑप्टिमायझेशन हा याक शेव्हिंगचा एक विशेषतः कपटी प्रकार आहे ज्याने नगण्य फायद्यासाठी असंख्य अभियांत्रिकी तास वापरले आहेत.

सिस्टम प्रोग्रामिंगबद्दल हे आम्हाला काय शिकवते

72 KB फर्स्ट-ऍलोकेशन मिस्ट्री, त्याच्या गाभ्यामध्ये, ॲब्स्ट्रॅक्शन लेयर्स बद्दलचा धडा आहे. C++ तुम्हाला असा भ्रम देतो की नवीन इंट 4 बाइट्स वाटप करतो. भाषा मानक असेच सांगतात. तुमचे मानसिक मॉडेल तसे सांगते. परंतु तुमचा कोड आणि हार्डवेअर यांच्यामध्ये अत्याधुनिक प्रणालींचा एक स्टॅक आहे — C++ रनटाइम, C लायब्ररी ऍलोकेटर, कर्नलची व्हर्च्युअल मेमरी सबसिस्टम आणि हार्डवेअरची MMU आणि TLB — प्रत्येकजण स्वतःचे वर्तन, ऑप्टिमायझेशन आणि ओव्हरहेड जोडतो.

हा दोष नाही. हे सिस्टम सॉफ्टवेअरचे संपूर्ण बिंदू आहे. वास्तविक समस्या सोडवण्यासाठी प्रत्येक स्तर अस्तित्वात आहे: वाटपकर्ता अस्तित्वात आहे म्हणून तुम्हाला प्रत्येक वाटपासाठी सिस्टम कॉल करण्याची गरज नाही. व्हर्च्युअल मेमरी सिस्टम अस्तित्वात आहे त्यामुळे तुम्हाला प्रत्यक्ष मेमरी व्यवस्थापित करण्याची गरज नाही. पृष्ठ फॉल्ट हँडलर अस्तित्वात आहे म्हणून मेमरी आळशीपणे आणि कार्यक्षमतेने वचनबद्ध आहे. प्रत्येक स्तर मोठ्या प्रमाणात कार्यप्रदर्शन आणि सोयीसाठी थोड्या प्रमाणात पारदर्शकतेचा व्यापार करतो.

विकासक जे सर्वात विश्वासार्ह, सर्वोच्च-कार्यक्षम प्रणाली तयार करतात ते हे स्तर समजतात — कारण त्यांना त्यांच्याबद्दल सतत विचार करणे आवश्यक आहे म्हणून नाही, परंतु जेव्हा काहीतरी अनपेक्षित घडते (अनाकलनीय 72 KB वाटप करण्यासारखे), ते का समजण्यासाठी त्यांच्याकडे मानसिक मॉडेल आहे. तुम्ही रिअल-टाइम ट्रेडिंग सिस्टीम, गेम इंजिन किंवा हजारो वापरकर्त्यांना सेवा देणारे बिझनेस प्लॅटफॉर्म तयार करत असलात तरीही, तुमचा कोड सिस्टम स्तरावर प्रत्यक्षात काय करतो याबद्दल तर्क करण्याची क्षमता सक्षम विकासकांना अपवादात्मक लोकांपासून वेगळे करते. 72 KB हा दोष नाही. तुमचा वाटपकर्ता त्याचे काम चोखपणे करत आहे.