എന്തുകൊണ്ടാണ് ആദ്യത്തെ C++ (m)അലോക്കേഷൻ എപ്പോഴും 72 KB ആയിരിക്കുന്നത്?

നിങ്ങളുടെ ആദ്യ C++ അലോക്കേഷൻ്റെ പിന്നിലെ രഹസ്യം

നിങ്ങൾ ഒരു ലളിതമായ C++ പ്രോഗ്രാം എഴുതുന്നു. ഒരൊറ്റ പുതിയ സംഖ്യ. നാല് ബൈറ്റുകൾ. നിങ്ങൾ സ്‌ട്രേസ് അല്ലെങ്കിൽ നിങ്ങളുടെ പ്രിയപ്പെട്ട മെമ്മറി പ്രൊഫൈലർ, അവിടെയുണ്ട് - നിങ്ങളുടെ പ്രോസസ്സ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിൽ നിന്ന് ഏകദേശം 72 KB അഭ്യർത്ഥിച്ചു. 4 ബൈറ്റുകൾ അല്ല. 64 ബൈറ്റുകൾ അല്ല. ഒരു മുഴുവൻ 72 കെ.ബി. നിങ്ങൾ എപ്പോഴെങ്കിലും ആ നമ്പറിലേക്ക് നോക്കുകയും നിങ്ങളുടെ ഉപകരണം നിങ്ങളോട് കള്ളം പറയുകയാണോ എന്ന് ചിന്തിക്കുകയും ചെയ്തിട്ടുണ്ടെങ്കിൽ, നിങ്ങൾ ഒറ്റയ്ക്കല്ല. വിചിത്രമായി തോന്നുന്ന ഈ പെരുമാറ്റം C++ ഡെവലപ്പർമാർക്കിടയിൽ ആദ്യമായി മെമ്മറി ഇൻ്റേണലുകളിലേക്ക് ആഴ്ന്നിറങ്ങുന്ന പതിവ് ചോദ്യങ്ങളിൽ ഒന്നാണ്, നിങ്ങളുടെ കോഡിനും യഥാർത്ഥ ഹാർഡ്‌വെയറിനുമിടയിൽ ഇരിക്കുന്ന ലെയറിലൂടെയുള്ള ഒരു കൗതുകകരമായ യാത്രയിലേക്ക് ഉത്തരം ഞങ്ങളെ കൊണ്ടുപോകുന്നു.

നിങ്ങൾ പുതിയ

72 KB കണക്ക് മനസ്സിലാക്കാൻ, നിങ്ങൾ മുഴുവൻ അലോക്കേഷൻ ചെയിൻ കണ്ടെത്തേണ്ടതുണ്ട്. നിങ്ങളുടെ C++ കോഡ് new int എക്സിക്യൂട്ട് ചെയ്യുമ്പോൾ, കംപൈലർ അതിനെ operator new എന്നതിലേക്കുള്ള ഒരു കോളായി വിവർത്തനം ചെയ്യുന്നു, മിക്ക Linux സിസ്റ്റങ്ങളിലും glibc-ൽ നിന്ന് malloc ലേക്ക് ഡെലിഗേറ്റ് ചെയ്യുന്നു. എന്നാൽ malloc കേർണലിനോട് നേരിട്ട് 4 ബൈറ്റുകൾ മെമ്മറി ആവശ്യപ്പെടുന്നില്ല. കേർണൽ പേജുകളിൽ പ്രവർത്തിക്കുന്നു - സാധാരണയായി x86_64-ൽ 4 KB - കൂടാതെ ഒരു ലളിതമായ മെമ്മറി ആക്‌സസുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ഒരു സിസ്റ്റം കോളിൻ്റെ വില വളരെ വലുതാണ്. ഓരോ വ്യക്തിഗത അലോക്കേഷനും brk() അല്ലെങ്കിൽ mmap() എന്ന് വിളിക്കുന്നത് നിസ്സാരമല്ലാത്ത ഏതൊരു പ്രോഗ്രാമും നിർത്തലാക്കും.

പകരം, glibc യുടെ മെമ്മറി അലോക്കേറ്റർ — ptmalloc2 എന്ന് വിളിക്കപ്പെടുന്ന ഒരു നടപ്പാക്കൽ, ഡഗ് ലിയയുടെ ക്ലാസിക് dlmalloc-ൽ നിന്ന് തന്നെ ഇറങ്ങിയതാണ് — ഒരു ഇടനിലക്കാരനായി പ്രവർത്തിക്കുന്നു. ഇത് കേർണലിൽ നിന്ന് വലിയ മെമ്മറി ബ്ലോക്കുകൾ അഭ്യർത്ഥിക്കുന്നു, തുടർന്ന് നിങ്ങളുടെ പ്രോഗ്രാമിന് ആവശ്യമുള്ളതിനാൽ അവയെ ചെറിയ കഷണങ്ങളാക്കി മാറ്റുന്നു. നിങ്ങളുടെ ആദ്യത്തെ 4-ബൈറ്റ് അലോക്കേഷൻ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിലേക്കുള്ള ഒരു വലിയ അഭ്യർത്ഥന ട്രിഗർ ചെയ്യുന്നതിനുള്ള അടിസ്ഥാന കാരണം ഇതാണ്. അലോക്കേറ്റർ പാഴാക്കുന്നില്ല. ഇത് തന്ത്രപ്രധാനമാണ്.

72 കെബി വിച്ഛേദിക്കുന്നു: ബൈറ്റുകൾ എവിടെ പോകുന്നു

പ്രാരംഭ അലോക്കേഷൻ ഓവർഹെഡ്, ഉപയോഗയോഗ്യമായ മെമ്മറിയുടെ ഒരു ബൈറ്റ് പോലും നിങ്ങൾക്ക് കൈമാറുന്നതിന് മുമ്പ് റൺടൈം ആരംഭിക്കേണ്ട നിരവധി വ്യത്യസ്ത ഘടകങ്ങളിൽ നിന്നാണ് വരുന്നത്. ഓരോ ഘടകങ്ങളും മനസ്സിലാക്കുന്നത്, സംഖ്യ എവിടെയായിരിക്കുമെന്ന് വിശദീകരിക്കുന്നു.

ആദ്യം, glibc-ൻ്റെ malloc പ്രധാന മേഖല ആരംഭിക്കുന്നു - പ്രധാന ത്രെഡിലെ എല്ലാ അലോക്കേഷനുകളും ട്രാക്ക് ചെയ്യുന്ന പ്രാഥമിക ബുക്ക് കീപ്പിംഗ് ഘടന. ഈ രംഗത്ത് ഹീപ്പിനുള്ള മെറ്റാഡാറ്റ, ഫ്രീ-ലിസ്റ്റ് പോയിൻ്ററുകൾ, വ്യത്യസ്ത അലോക്കേഷൻ വലുപ്പങ്ങൾക്കുള്ള ബിൻ ഘടനകൾ എന്നിവ ഉൾപ്പെടുന്നു. അലോക്കേറ്റർ പ്രോഗ്രാം ബ്രേക്ക് sbrk() വഴി നീട്ടുന്നു, കൂടാതെ പ്രാരംഭ വിപുലീകരണം നിയന്ത്രിക്കുന്നത് M_TOP_PAD എന്ന ആന്തരിക പാരാമീറ്ററാണ്, ഇത് സ്ഥിരസ്ഥിതിയായി 128 KB പാഡിംഗിലേക്ക് മാറുന്നു. എന്നിരുന്നാലും, യഥാർത്ഥ പ്രാരംഭ അഭ്യർത്ഥന പേജ് വിന്യാസത്തിനും നിലവിലുള്ള ബ്രേക്ക് പൊസിഷനുമായി ക്രമീകരിച്ചിരിക്കുന്നു, ഇത് പലപ്പോഴും ഒരു ചെറിയ ആദ്യ അഭ്യർത്ഥനയിൽ കലാശിക്കുന്നു - പുതുതായി ആരംഭിച്ച പ്രക്രിയയിൽ സാധാരണയായി ആ 72 KB സംഖ്യയ്ക്ക് സമീപം ഇറങ്ങുന്നു.

രണ്ടാമതായി, glibc 2.26 മുതൽ, അലോക്കേറ്റർ ആദ്യ ഉപയോഗത്തിൽ ഒരു ത്രെഡ്-ലോക്കൽ കാഷെ (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 വർദ്ധിപ്പിക്കുമ്പോൾ, പ്രോസസിൻ്റെ വെർച്വൽ മെമ്മറി മാപ്പിംഗുകൾ കേർണൽ അപ്‌ഡേറ്റ് ചെയ്യുന്നു, പക്ഷേ അത് ഫിസിക്കൽ റാം ഉപയോഗിച്ച് ആ പേജുകളെ ഉടനടി ബാക്ക് ചെയ്യുന്നില്ല. യഥാർത്ഥ ഫിസിക്കൽ പേജുകൾ പേജ് പിഴവുകൾ വഴി ആവശ്യാനുസരണം അലോക്കേറ്റ് ചെയ്യപ്പെടുന്നു - നിങ്ങളുടെ പ്രോഗ്രാം ഒരു നിർദ്ദിഷ്ട വിലാസത്തിലേക്ക് എഴുതുമ്പോൾ മാത്രമേ കേർണൽ അതിന് മെമ്മറിയുടെ യഥാർത്ഥ പേജ് നൽകൂ.

ഇതിനർത്ഥം നിങ്ങളുടെ പ്രോസസ്സിൻ്റെ വെർച്വൽ വലുപ്പം 72 KB വർദ്ധിക്കുന്നുണ്ടെങ്കിലും, അതിൻ്റെ റെസിഡൻ്റ് സെറ്റ് വലുപ്പം (RSS) - യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന ഫിസിക്കൽ റാമിൻ്റെ അളവ് - നിങ്ങൾ യഥാർത്ഥത്തിൽ സ്പർശിക്കുന്ന പേജുകൾ കൊണ്ട് മാത്രം വർദ്ധിക്കുന്നു. ഒരൊറ്റ പുതിയ int-ന്, അത് സാധാരണയായി ഒരു 4 KB പേജും കൂടാതെ അറീന മെറ്റാഡാറ്റ ഉൾക്കൊള്ളുന്ന ഏത് പേജും ആണ്. ശേഷിക്കുന്ന വെർച്വൽ സ്‌പെയ്‌സ് അവിടെ ഇരിക്കുന്നു, ഉപയോഗത്തിന് തയ്യാറാണ്, അഡ്രസ് സ്‌പെയ്‌സല്ലാതെ മറ്റൊന്നും ചെലവാകുന്നില്ല - ഇതിൽ നിങ്ങൾക്ക് 64-ബിറ്റ് ലിനക്‌സ് സിസ്റ്റത്തിൽ 128 ടിബി ഉണ്ട്.

പ്രൊഡക്ഷൻ ആപ്ലിക്കേഷനുകൾ പ്രൊഫൈൽ ചെയ്യുമ്പോഴും നിരീക്ഷിക്കുമ്പോഴും ഈ വ്യത്യാസം നിർണായകമാണ്. യഥാർത്ഥ റിസോഴ്സ് ഉപഭോഗം ട്രാക്ക് ചെയ്യേണ്ട സോഫ്‌റ്റ്‌വെയറാണ് നിങ്ങൾ നിർമ്മിക്കുന്നതെങ്കിൽ - അത് 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-യുടെ ഡിഫോൾട്ടിനെ മറികടക്കുന്നു. മെമ്മറി-നിയന്ത്രിത എംബഡഡ് സിസ്റ്റങ്ങൾക്ക്, കുറഞ്ഞ ത്രൂപുട്ട് ഉണ്ടായിരുന്നിട്ടും musl-ൻ്റെ ലളിതമായ സമീപനം അഭികാമ്യമാണ്. മിക്ക പൊതു-ഉദ്ദേശ്യ ഡെസ്‌ക്‌ടോപ്പ്, സെർവർ ആപ്ലിക്കേഷനുകൾക്കും, ptmalloc2-ൻ്റെ 72 KB പ്രാരംഭ ഓവർഹെഡ് ട്യൂണിംഗ് കൂടാതെ നന്നായി പ്രവർത്തിക്കുന്ന ഒരു ന്യായമായ സ്ഥിരസ്ഥിതിയെ പ്രതിനിധീകരിക്കുന്നു.

പ്രാരംഭ അലോക്കേഷൻ ബിഹേവിയർ ട്യൂൺ ചെയ്യുന്നു

ഡിഫോൾട്ട് 72 KB പ്രാരംഭ ഓവർഹെഡ് നിങ്ങളുടെ ഉപയോഗത്തിന് ശരിക്കും പ്രശ്നമാണെങ്കിൽ - നിങ്ങൾ ആയിരക്കണക്കിന് ഹ്രസ്വകാല പ്രക്രിയകൾ ഉണ്ടാക്കുന്നു, ഓരോന്നും ഒരുപിടി അലോക്കേഷനുകൾ മാത്രമേ ഉണ്ടാക്കുന്നുള്ളൂ - glibc mallopt() വഴിയും MALLOC_ എന്ന പരിതസ്ഥിതിയിലൂടെയും നിരവധി ട്യൂണബിളുകൾ നൽകുന്നു.

അലോക്കേറ്റർ ഉടനടി ആവശ്യമുള്ളതിനേക്കാൾ എത്ര അധിക മെമ്മറി അഭ്യർത്ഥിക്കുന്നു എന്ന് M_TOP_PAD പാരാമീറ്റർ നിയന്ത്രിക്കുന്നു. mallopt(M_TOP_PAD, 0) ഉപയോഗിച്ച് ഇത് 0 ആയി സജ്ജീകരിക്കുന്നത്, ആവശ്യമുള്ളത് മാത്രം അഭ്യർത്ഥിക്കാൻ അലോക്കേറ്ററോട് പറയുന്നു, ഇത് പ്രാരംഭ ഓവർഹെഡ് ഗണ്യമായി കുറയ്ക്കുന്നു. M_MMAP_THRESHOLD പരാമീറ്റർ, അറേനയ്‌ക്ക് പകരം അലോക്കേഷനുകൾ mmap ഉപയോഗിക്കുന്ന വലുപ്പത്തെ നിയന്ത്രിക്കുന്നു. സ്വതന്ത്രമായ മെമ്മറി OS-ലേക്ക് തിരികെ നൽകുമ്പോൾ M_TRIM_THRESHOLD നിയന്ത്രിക്കുന്നു. 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 ഒരു ബഗ് അല്ല. നിങ്ങളുടെ അലോക്കേറ്ററാണ് അതിൻ്റെ ജോലി മികച്ച രീതിയിൽ ചെയ്യുന്നത്.