Kial la unua C++ (m)asigno ĉiam estas 72 KB?

La 72 KB, kiujn vi vidas en via unua asigno, ne estas malŝparita memoro — ĝi estas rendimenta investo. La asignanto vetas, ke via programo baldaŭ faros pli da asignoj, kaj en preskaŭ ĉiu reala scenaro, tiu veto bonege pagas. La kosto de neuzata virtuala adresspaco estas esence nula en modernaj 64-bitaj sistemoj.

Virtuala Memoro kontraŭ Fizika Memoro: Kial Ĝi Ne Gravas

Komuna zorgo inter programistoj, kiuj renkontas ĉi tiun konduton unuafoje, estas malŝparo de rimedoj. Se mi bezonas nur 4 bajtojn, kial mia programo konsumas 72 KB? La kritika kompreno estas, ke virtuala memoro ne estas fizika memoro. Kiam glibc etendas la programpaŭzon je 72 KB, la kerno ĝisdatigas la virtualajn memormapadojn de la procezo, sed ĝi ne tuj malantaŭeniras tiujn paĝojn per fizika RAM. La realaj fizikaj paĝoj estas asignitaj laŭpeto pro paĝaj misfunkciadoj — nur kiam via programo skribas al specifa adreso, la kerno asignas al ĝi veran paĝon de memoro.

Ĉi tio signifas, ke kvankam la virtuala grandeco de via procezo pliiĝas je 72 KB, ĝia loĝanta aro grandeco (RSS) — la kvanto de fizika RAM efektive konsumita — pliiĝas nur per la paĝoj, kiujn vi efektive tuŝas. Por unuopa nova int, tio estas tipe unu 4 KB-paĝo, plus kiajn ajn paĝojn okupas la arenmetadatumoj. La restanta virtuala spaco sidas tie, preta por uzo, kostante nenion krom adrespaco — el kiu vi havas 128 TB sur 64-bita Linukso-sistemo.

Tiu distingo estas kritika dum profilado kaj monitorado de produktadaplikoj. Se vi konstruas programaron, kiu bezonas spuri realan konsumon de rimedoj - ĉu ĝi estas SaaS-backend, mikroservo aŭ analiza dukto kiel tiuj, kiuj funkcias sur platformoj kiel ekzemple Mewayzpor komercaj operacioj - vi ĉiam devas monitori RSS prefere ol virtuala grandeco. Iloj kiel /proc/[pid]/smaps, valgrind --tool=massif, kaj pmap povas doni al vi precizajn fizikajn memorpiedsignojn prefere ol misgvidaj virtualaj memorciferoj.

Kiel Malsamaj Asignantoj Pritraktas la Unuan Asignadon

La 72 KB-cifero estas specifa por la ptmalloc2 de glibc. Aliaj atribuantoj faras malsamajn kompromisojn, kaj la komenca asigno-superkosto varias laŭe. Kompreni ĉi tiujn diferencojn estas valora dum elektado de alsignilo por agado-sentemaj aplikoj.

• jemalloc (uzita de Facebook, FreeBSD) — Uzas pli grajnecan arenostrukturon kun faden-lokaj kaŝmemoroj. La komenca superkosto tendencas esti pli alta (ofte 200+ KB) sed liveras pli bonan multfadenan rendimenton pro reduktita serurodisputo.
• tcmalloc (Google's Thread-Caching Malloc) — Atribuas po-fadenan kaŝmemoron de proksimume 2 MB defaŭlte, kun agresema antaŭ-atribuo. Komenca superkosto estas pli alta, sed postaj malgrandaj asignoj estas ege rapidaj.
• malloc de musl libc — Uzas multe pli simplan dezajnon bazitan sur mmap por ĉiuj atribuoj. Komenca superkosto estas minimuma (ofte nur 4 KB per asigno), sed po-asigna kosto estas pli alta pro pli oftaj sistemvokoj.
• mimalloc (Mikrosofto) — Uzas segment-bazitan atribuon kun 64 MB-segmentoj. La unua asigno ekigas virtualan rezervadon de 64 MB (kun minimuma fizika engaĝiĝo), komercanta adresspacon por esceptaj loko kaj trairo.

La elekto inter ĉi tiuj atribuantoj dependas tute de via laborkvanto. Por longdaŭraj servilaj aplikoj kun peza multfadena asigno, jemalloc aŭ tcmalloc tipe superas la defaŭlton de glibc. Por memor-limigitaj enkonstruitaj sistemoj, la pli simpla aliro de musl povas esti preferinda malgraŭ pli malalta trairo. Por la plej multaj ĝeneraluzeblaj labortablaj kaj servilaj aplikoj, la komenca superkosto de 72 KB de ptmalloc2 reprezentas akcepteblan defaŭlton kiu funkcias bone sen agordo.

Agordo de la Komenca Asigna Konduto

Se la defaŭlta 72 KB komenca superkosto estas vere problema por via uzokazo — eble vi generas milojn da mallongdaŭraj procezoj, ĉiu farante nur manplenon da asignoj — glibc disponigas plurajn agordeblajn per mallopt() kaj la MALLOC_ familio de mediaj variabloj.

La parametro M_TOP_PAD kontrolas kiom da kroma memoro la asignilo petas preter tio, kio estas tuj bezonata. Agordi ĝin al 0 per mallopt(M_TOP_PAD, 0) diras al la asignanto peti nur tion, kio estas bezonata, reduktante la komencan superkozon signife. La parametro M_MMAP_THRESHOLD kontrolas la grandecon super kiu asignoj uzas mmap anstataŭ la areno. La M_TRIM_THRESHOLD kontrolas kiam liberigita memoro estas resendita al la OS. Kaj ekde glibc 2.26, la agordeblaj glibc.malloc.tcache_count kaj glibc.malloc.tcache_max lasas vin kontroli la fadenkaŝmemorkonduton.

Tamen, zorgema: agordi ĉi tiujn parametrojn sen zorgema benchmarking preskaŭ ĉiam plimalbonigas la aferojn. La defaŭltoj estis elektitaj surbaze de ampleksa real-monda profilado, kaj ili reprezentas dolĉan punkton por la vasta plimulto de laborŝarĝoj. Krom se vi havas fortajn pruvojn de produktadprofilado, ke malloc-superkosto estas proplemkolo - kaj vi mezuris la efikon de viaj ŝanĝoj - lasu la defaŭltojn. Trofrua optimumigo de la asignilo estas precipe insida formo de jaka razado, kiu konsumis sennombrajn inĝenierajn horojn por nekonsiderinda profito.

Kion Ĉi tio Instruas Nin Pri Sistema Programado

La 72 KB unua-asigna mistero estas, en sia kerno, leciono pri abstraktaj tavoloj. C++ donas al vi la iluzion, ke nova int asignas 4 bajtojn. La lingva normo diras tion. Via mensa modelo diras tion. Sed inter via kodo kaj la aparataro sidas stako da kompleksaj sistemoj — la C++ rultempo, la C-biblioteka alsignilo, la virtuala memorsubsistemo de la kerno, kaj la MMU kaj TLB de la aparataro — ĉiu aldonante siajn proprajn kondutojn, optimumojn, kaj superŝarĝon.

Ĉi tio ne estas difekto. Ĝi estas la tuta punkto de sistemaj programoj. Ĉiu tavolo ekzistas por solvi veran problemon: la alsignilo ekzistas do vi ne devas fari sistemajn vokojn por ĉiu asigno. La virtuala memorsistemo ekzistas do vi ne devas administri fizikan memoron rekte. La paĝa faŭltotraktilo ekzistas do memoro estas farita maldiligente kaj efike. Ĉiu tavolo interŝanĝas malgrandan kvanton da travidebleco por granda kvanto de rendimento kaj oportuno.

La programistoj, kiuj konstruas la plej fidindajn, plej altfunkciajn sistemojn, estas tiuj, kiuj komprenas ĉi tiujn tavolojn — ne ĉar ili devas pensi pri ili konstante, sed ĉar kiam okazas io neatendita (kiel mistera 72 KB-atribuo), ili havas la mensan modelon por kompreni kial. Ĉu vi konstruas realtempan komercan sistemon, ludmaŝinon aŭ komercan platformon servantan milojn da uzantoj, la kapablo rezoni pri tio, kion via kodo efektive faras sur la sistemnivelo, estas tio, kio apartigas kompetentajn programistojn de esceptaj. La 72 KB ne estas cimo. Ĝi estas via asignanto, kiu faras sian laboron brile.