පළමු C++ (m) වෙන් කිරීම සැමවිටම 72 KB වන්නේ ඇයි?

ඔබේ පළමු C++ වෙන් කිරීම පිටුපස ඇති අභිරහස

ඔබ සරල C++ වැඩසටහනක් ලියන්න. තනි නව int. බයිට් හතරක්. ඔබ ස්ට්‍රේස් හෝ ඔබේ ප්‍රියතම මතක ප්‍රොෆයිලරය ගිනිබත් කරයි, සහ එය තිබේ — ඔබේ ක්‍රියාවලිය මෙහෙයුම් පද්ධතියෙන් දළ වශයෙන් 72 KB ඉල්ලා ඇත. බයිට් 4ක් නෙවෙයි. බයිට් 64ක් නොවේ. සම්පූර්ණ 72 KB. ඔබ කවදා හෝ එම අංකය දෙස බලා ඔබේ මෙවලම ඔබට බොරුවක් දැයි කල්පනා කර ඇත්නම්, ඔබ තනිවම නොවේ. මෙම පෙනෙන විකාර හැසිරීම C++ සංවර්ධකයින් අතර ප්‍රථම වරට මතක අභ්‍යන්තරයන් හාරා නිතර අසනු ලබන ප්‍රශ්නවලින් එකකි, සහ පිළිතුර ඔබගේ කේතය සහ සැබෑ දෘඪාංග අතර හිඳින ස්ථර හරහා අපව සිත් ඇදගන්නාසුළු ගමනක් ගෙන යයි.

ඔබ නව

72 KB අගය තේරුම් ගැනීමට, ඔබ සම්පූර්ණ විසර්ජන දාමය සොයා ගැනීමට අවශ්‍ය වේ. ඔබගේ C++ කේතය new int ක්‍රියාත්මක කරන විට, සම්පාදකය එය operator new වෙත ඇමතුමක් බවට පරිවර්තනය කරයි, එය බොහෝ Linux පද්ධතිවල glibc වෙතින් malloc වෙත පැවරේ. නමුත් malloc විසින් කර්නලයෙන් බයිට් 4ක මතකයක් සඳහා සෘජුව අසන්නේ නැත. කර්නලය පිටු වල ක්‍රියාත්මක වේ — සාමාන්‍යයෙන් x86_64 මත 4 KB — සහ සරල මතක ප්‍රවේශයකට සාපේක්ෂව පද්ධති ඇමතුමක පිරිවැය අති විශාලය. සෑම තනි ප්‍රතිපාදනයක් සඳහාම brk() හෝ mmap() ඇමතීමෙන් ඕනෑම සුළු නොවන වැඩසටහනක් ඇඹරීමට සිදුවේ.

ඒ වෙනුවට, glibc's memory allocator — ptmalloc2 නම් ක්‍රියාවට නැංවීම, Doug Lea ගේ සම්භාව්‍ය dlmalloc වෙතින් පැවත එන — අතරමැදියෙකු ලෙස ක්‍රියා කරයි. එය ඉදිරිපස කර්නලයෙන් විශාල මතක කොටස් ඉල්ලයි, ඉන්පසු ඔබේ වැඩසටහනට අවශ්‍ය පරිදි ඒවා කුඩා කැබලිවලට කැටයම් කරයි. ඔබගේ පළමු බයිට් 4 වෙන් කිරීම මෙහෙයුම් පද්ධතියට වඩා විශාල ඉල්ලීමක් අවුලුවාලීමට මූලික හේතුව මෙයයි. වෙන් කරන්නා නාස්තිකාර නොවේ. එය උපායශීලී වේ.

72 KB විච්ඡේදනය කිරීම: බයිට් යන තැන

පරිශීලනය කළ හැකි මතකයේ එක් බයිටයක් පවා ඔබට ලබා දීමට පෙර ධාවන කාලය ආරම්භ කළ යුතු වෙනස් සංරචක කිහිපයකින් ආරම්භක වෙන්කිරීමේ උඩිස් කොටස පැමිණේ. එක් එක් සංරචකය අවබෝධ කර ගැනීමෙන් සංඛ්‍යාව එය සිදු වන තැනට වැටෙන්නේ මන්දැයි පැහැදිලි කරයි.

පළමුව, glibc's 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 ක් පමණ වැය වේ. Arena-පාදක වෙන් කරන්නෙකු සමඟින්, පළමු වෙන් කිරීම තනි පද්ධති ඇමතුමක් ක්‍රියාරම්භ කරන අතර, පසුව ලැබෙන 9,999 ප්‍රතිපාදන පොයින්ටර් අංක ගණිතය සහ සම්බන්ධිත-ලැයිස්තු මෙහෙයුම් හරහා සම්පූර්ණයෙන්ම පරිශීලක අවකාශයේ සේවය කරනු ලැබේ - එක් එක් නැනෝ තත්පර 10-50ක් පමණ ගත වේ. ගණිතය නොපැහැදිලි ය: පෙර වෙන් කිරීම විශාලත්වයේ අනුපිළිවෙලින් ජය ගනී.

ඔබේ පළමු වෙන්කිරීමේදී ඔබ දකින 72 KB මතකය අපතේ නොයයි - එය කාර්ය සාධන ආයෝජනයකි. වෙන් කරන්නා ඔට්ටු අල්ලමින් සිටින්නේ ඔබේ වැඩසටහන ඉක්මනින් වැඩි ප්‍රතිපාදන ලබා දෙනු ඇති බවත්, සෑම තථ්‍ය-ලෝක තත්වයක් තුළම, එම ඔට්ටුව ඉතා හොඳින් ගෙවන බවත්ය. භාවිතයට නොගත් අතථ්‍ය ලිපින අවකාශයේ පිරිවැය නවීන 64-bit පද්ධති මත අත්‍යවශ්‍යයෙන්ම ශුන්‍ය වේ.

අථත්‍ය මතකය එදිරිව භෞතික මතකය: එය වැදගත් නොවන්නේ ඇයි

පළමු වරට මෙම හැසිරීමට මුහුණ දෙන සංවර්ධකයින් අතර පොදු සැලකිල්ලක් වන්නේ සම්පත් නාස්තියයි. මට අවශ්‍ය වන්නේ බයිට් 4ක් පමණක් නම්, මගේ වැඩසටහන 72 KB පරිභෝජනය කරන්නේ ඇයි? තීරනාත්මක අවබෝධය නම් අථත්‍ය මතකය භෞතික මතකය නොවේ. glibc වැඩසටහනේ විවේකය 72 KB කින් දිගු කරන විට, කර්නලය ක්‍රියාවලියේ අතථ්‍ය මතක සිතියම් යාවත්කාලීන කරයි, නමුත් එය භෞතික RAM සමඟ එම පිටු වහාම ආපසු නොයවයි. සැබෑ භෞතික පිටු පිටු දෝෂ හරහා ඉල්ලුම මත වෙන් කරනු ලැබේ - ඔබේ වැඩසටහන නිශ්චිත ලිපිනයකට ලියන විට පමණක් කර්නලය එයට සැබෑ මතක පිටුවක් පවරයි.

මෙයින් අදහස් වන්නේ ඔබේ ක්‍රියාවලියේ අතථ්‍ය ප්‍රමාණය 72 KB කින් වැඩි වුවද, එහි නේවාසික කට්ටල ප්‍රමාණය (RSS) - ඇත්ත වශයෙන්ම පරිභෝජනය කරන භෞතික RAM ප්‍රමාණය - ඔබ සැබවින්ම ස්පර්ශ කරන පිටු වලින් පමණක් වැඩි වන බවයි. තනි නව int සඳහා, එය සාමාන්‍යයෙන් එක් 4 KB පිටුවක් වන අතර, පිටිය පාර-දත්ත අල්ලා ගන්නා කවර හෝ පිටු වේ. ඉතිරි අතථ්‍ය අවකාශය එහි පවතී, භාවිතයට සූදානම්, ලිපින අවකාශය හැර අන් කිසිවක් වැය නොවේ — එයින් ඔබට 64-bit Linux පද්ධතියක TB 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 (මයික්‍රොසොෆ්ට්) — 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 tunables ඔබට නූල් හැඹිලි හැසිරීම පාලනය කිරීමට ඉඩ සලසයි.

කෙසේ වෙතත්, අවවාදයයි: ප්‍රවේශමෙන් මිණුම් සලකුණු කිරීමකින් තොරව මෙම පරාමිතීන් සුසර කිරීම සෑම විටම පාහේ තත්වය නරක අතට හැරේ. විස්තීරණ සැබෑ ලෝක පැතිකඩ මත පදනම්ව පෙරනිමියන් තෝරාගෙන ඇති අතර, ඒවා වැඩ බරින් අතිමහත් බහුතරයක් සඳහා මිහිරි ස්ථානයක් නියෝජනය කරයි. malloc උඩිස් හෙඩ් බාධකයක් බවට නිෂ්පාදන පැතිකඩෙන් ඔබට ප්‍රබල සාක්ෂි නොමැති නම් - සහ ඔබ ඔබේ වෙනස්කම්වල බලපෑම මැන බැලුවේ නම් - පෙරනිමිය පමණක් තබන්න. නොසැලකිය හැකි ප්‍රතිලාභයක් සඳහා ගණන් කළ නොහැකි ඉංජිනේරු පැය ගණනක් වැය කර ඇති යක් රැවුල කැපීමේ විෙශේෂෙයන් ද්‍රෝහී ආකාරයකි විබෙදුම්කරු අකාල ප්‍රශස්ත කිරීම.

මෙය පද්ධති ක්‍රමලේඛනය ගැන අපට උගන්වන දේ

72 KB පළමු වෙන් කිරීමේ අභිරහස, එහි හරය, වියුක්ත ස්තර පිළිබඳ පාඩමකි. C++ මඟින් ඔබට නව int බයිට් 4ක් වෙන් කරන බවට මිත්‍යාවක් ලබා දෙයි. භාෂා ප්‍රමිතිය එහෙම කියනවා. ඔබේ මානසික ආකෘතිය එසේ කියයි. නමුත් ඔබේ කේතය සහ දෘඪාංග අතර සංකීර්ණ පද්ධති තොගයක් - C++ ධාවන කාලය, C පුස්තකාලය වෙන් කරන්නා, කර්නලයේ අතථ්‍ය මතක උප පද්ධතිය, සහ දෘඪාංගයේ MMU සහ TLB - ඒ සෑම එකක්ම තමන්ගේම හැසිරීම්, ප්‍රශස්තකරණයන් සහ උඩින් එකතු කරයි.

මෙය දෝෂයක් නොවේ. එය පද්ධති මෘදුකාංගයේ සමස්ත ලක්ෂ්‍යය වේ. සෑම ස්ථරයක්ම සැබෑ ගැටළුවක් විසඳීම සඳහා පවතී: වෙන් කරන්නා පවතින බැවින් ඔබට සෑම වෙන් කිරීමක් සඳහාම පද්ධති ඇමතුම් කිරීමට අවශ්‍ය නොවේ. අතථ්‍ය මතක පද්ධතිය පවතින බැවින් ඔබට භෞතික මතකය සෘජුව කළමනාකරණය කිරීමට අවශ්‍ය නොවේ. පිටු දෝෂ හසුරුවන්නා පවතින නිසා මතකය අලසව සහ කාර්යක්ෂමව සිදු වේ. සෑම ස්ථරයක්ම විශාල කාර්ය සාධනයක් සහ පහසුවක් සඳහා කුඩා විනිවිදභාවයක් වෙළඳාම් කරයි.

වඩාත් විශ්වාසදායක, ඉහළම ක්‍රියාකාරී පද්ධති ගොඩනඟන සංවර්ධකයින් වන්නේ මෙම ස්ථර තේරුම් ගන්නා අයයි - ඔවුන් නිරන්තරයෙන් ඒවා ගැන සිතිය යුතු නිසා නොව, අනපේක්ෂිත දෙයක් සිදු වූ විට (අභිරහස් 72 KB වෙන් කිරීමක් වැනි) මන්ද යන්න තේරුම් ගැනීමට ඔවුන්ට මානසික ආකෘතියක් ඇත. ඔබ තත්‍ය කාලීන වෙළඳ පද්ධතියක්, ක්‍රීඩා එන්ජිමක් හෝ දහස් ගණනක් පරිශීලකයින්ට සේවා සපයන ව්‍යාපාරික වේදිකාවක් ගොඩනඟන්නේ නම්, ඔබේ කේතය පද්ධති මට්ටමින් ඇත්ත වශයෙන්ම කරන්නේ කුමක්ද යන්න පිළිබඳව තර්ක කිරීමේ හැකියාව දක්ෂ සංවර්ධකයින් සුවිශේෂී අයගෙන් වෙන් කරයි. 72 KB යනු දෝෂයක් නොවේ. එය ඔබේ වෙන් කරන්නා එහි කාර්යය විශිෂ්ට ලෙස කරයි.