શા માટે પ્રથમ C++ (m) ફાળવણી હંમેશા 72 KB હોય છે?

તમારા પ્રથમ C++ ફાળવણી પાછળનું રહસ્ય

તમે એક સરળ C++ પ્રોગ્રામ લખો. એક નવી પૂર્ણાંક. ચાર બાઇટ્સ. તમે સ્ટ્રેસ અથવા તમારા મનપસંદ મેમરી પ્રોફાઇલરને ફાયર કરો છો, અને તે ત્યાં છે — તમારી પ્રક્રિયાએ ઑપરેટિંગ સિસ્ટમમાંથી આશરે 72 KBની વિનંતી કરી છે. 4 બાઇટ્સ નહીં. 64 બાઇટ્સ નથી. સંપૂર્ણ 72 KB. જો તમે ક્યારેય તે નંબર પર નજર નાખી હોય અને વિચાર્યું હોય કે શું તમારું ટૂલિંગ તમારી સાથે ખોટું બોલે છે, તો તમે એકલા નથી. આ દેખીતી રીતે વિચિત્ર વર્તણૂક એ C++ ડેવલપર્સ વચ્ચે સૌથી વધુ વારંવાર પૂછાતા પ્રશ્નો પૈકી એક છે જે મેમરી ઇન્ટરનલ્સમાં પ્રથમ વખત ખોદકામ કરે છે, અને જવાબ અમને તમારા કોડ અને વાસ્તવિક હાર્ડવેર વચ્ચે બેઠેલા સ્તરોમાંથી એક આકર્ષક પ્રવાસ પર લઈ જાય છે.

જ્યારે તમે નવું

72 KB આકૃતિને સમજવા માટે, તમારે સંપૂર્ણ ફાળવણી શૃંખલાને ટ્રેસ કરવાની જરૂર છે. જ્યારે તમારો C++ કોડ નવું int એક્ઝિક્યુટ કરે છે, ત્યારે કમ્પાઈલર તેને ઓપરેટર ન્યૂને કૉલમાં અનુવાદિત કરે છે, જે મોટાભાગની 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++ રનટાઇમ પહેલેથી જ ફાળવણી કરી ચૂક્યું છે — સ્ટેટિક કન્સ્ટ્રક્ટર, 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-બીટ Linux સિસ્ટમ પર 128 TB છે.

ઉત્પાદન એપ્લિકેશનોની પ્રોફાઇલિંગ અને દેખરેખ કરતી વખતે આ તફાવત મહત્વપૂર્ણ છે. જો તમે એવા સૉફ્ટવેરનું નિર્માણ કરી રહ્યાં છો કે જેને વાસ્તવિક સંસાધન વપરાશને ટ્રૅક કરવાની જરૂર છે — પછી ભલે તે SaaS બેકએન્ડ હોય, માઇક્રોસર્વિસ હોય, અથવા બિઝનેસ ઑપરેશન્સ માટે Mewayz જેવા પ્લેટફોર્મ પર ચાલતી એનાલિટિક્સ પાઇપલાઇન હોય — તમારે વર્ચ્યુઅલ કદને બદલે હંમેશા RSSનું નિરીક્ષણ કરવું જોઈએ. /proc/[pid]/smaps, valgrind --tool=massif, અને pmap જેવા સાધનો તમને ભ્રામક વર્ચ્યુઅલ મેમરી આકૃતિઓને બદલે સચોટ ભૌતિક મેમરી ફૂટપ્રિન્ટ આપી શકે છે.

વિવિધ ફાળવણીકર્તાઓ પ્રથમ ફાળવણીને કેવી રીતે હેન્ડલ કરે છે

72 KB આકૃતિ glibc ના ptmalloc2 માટે વિશિષ્ટ છે. અન્ય ફાળવણીકારો અલગ અલગ ટ્રેડઓફ કરે છે અને પ્રારંભિક ફાળવણી ઓવરહેડ તે મુજબ બદલાય છે. પ્રદર્શન-સંવેદનશીલ એપ્લિકેશનો માટે ફાળવણીકર્તા પસંદ કરતી વખતે આ તફાવતોને સમજવું મૂલ્યવાન છે.

• jemalloc (Facebook, FreeBSD દ્વારા વપરાયેલ) — થ્રેડ-લોકલ કેશ સાથે વધુ દાણાદાર એરેના સ્ટ્રક્ચરનો ઉપયોગ કરે છે. પ્રારંભિક ઓવરહેડ વધારે હોય છે (ઘણી વખત 200+ KB) પરંતુ લૉક વિવાદમાં ઘટાડો થવાને કારણે બહેતર મલ્ટિ-થ્રેડેડ પ્રદર્શન આપે છે.
• tcmalloc (Google's 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++ તમને ભ્રમણા આપે છે કે નવું int 4 બાઇટ્સ ફાળવે છે. ભાષા ધોરણ આમ કહે છે. તમારું માનસિક મોડેલ આમ કહે છે. પરંતુ તમારા કોડ અને હાર્ડવેરની વચ્ચે અત્યાધુનિક સિસ્ટમોનો સ્ટેક બેસે છે — C++ રનટાઇમ, C લાઇબ્રેરી એલોકેટર, કર્નલની વર્ચ્યુઅલ મેમરી સબસિસ્ટમ અને હાર્ડવેરની MMU અને TLB — દરેક તેના પોતાના વર્તન, ઑપ્ટિમાઇઝેશન અને ઓવરહેડ ઉમેરે છે.

આ કોઈ ખામી નથી. તે સિસ્ટમ સૉફ્ટવેરનો સંપૂર્ણ મુદ્દો છે. વાસ્તવિક સમસ્યાને ઉકેલવા માટે દરેક સ્તર અસ્તિત્વમાં છે: ફાળવણીકર્તા અસ્તિત્વમાં છે તેથી તમારે દરેક ફાળવણી માટે સિસ્ટમ કૉલ કરવાની જરૂર નથી. વર્ચ્યુઅલ મેમરી સિસ્ટમ અસ્તિત્વમાં છે તેથી તમારે ભૌતિક મેમરીને સીધી રીતે સંચાલિત કરવાની જરૂર નથી. પૃષ્ઠ ફોલ્ટ હેન્ડલર અસ્તિત્વમાં છે તેથી મેમરી આળસુ અને અસરકારક રીતે પ્રતિબદ્ધ છે. દરેક સ્તર મોટી માત્રામાં પ્રદર્શન અને સગવડતા માટે થોડી માત્રામાં પારદર્શિતાનો વેપાર કરે છે.

વિકાસકર્તાઓ કે જેઓ સૌથી વિશ્વસનીય, સર્વોચ્ચ-પ્રદર્શન પ્રણાલીઓનું નિર્માણ કરે છે તે તે છે જેઓ આ સ્તરોને સમજે છે — એટલા માટે નહીં કે તેમને તેમના વિશે સતત વિચારવાની જરૂર છે, પરંતુ કારણ કે જ્યારે કંઈક અણધારી બને છે (જેમ કે રહસ્યમય 72 KB ફાળવણી), શા માટે તે સમજવા માટે તેમની પાસે માનસિક મોડેલ છે. ભલે તમે રીઅલ-ટાઇમ ટ્રેડિંગ સિસ્ટમ, ગેમ એન્જિન, અથવા હજારો વપરાશકર્તાઓને સેવા આપતું વ્યવસાય પ્લેટફોર્મ બનાવી રહ્યાં હોવ, સિસ્ટમ સ્તરે તમારો કોડ ખરેખર શું કરે છે તે વિશે તર્ક આપવાની ક્ષમતા સક્ષમ વિકાસકર્તાઓને અસાધારણ લોકોથી અલગ પાડે છે. 72 KB એ બગ નથી. તે તમારું એલોકટર છે જે તેનું કામ શાનદાર રીતે કરે છે.