Pam mae'r dyraniad C++ (m) cyntaf bob amser yn 72 KB?

Y Dirgelwch y Tu ôl i'ch Dyraniad C++ Cyntaf

Rydych chi'n ysgrifennu rhaglen C++ syml. Un int newydd. Pedwar beit. Rydych chi'n tanio strace neu'ch hoff broffiliwr cof, a dyna ni - mae'ch proses newydd ofyn am tua 72 KB o'r system weithredu. Nid 4 beit. Nid 64 beit. 72 KB llawn. Os ydych chi erioed wedi syllu ar y rhif hwnnw ac wedi meddwl tybed a oedd eich offer yn gorwedd i chi, nid ydych chi ar eich pen eich hun. Yr ymddygiad hwn sy'n ymddangos yn rhyfedd yw un o'r cwestiynau a ofynnir amlaf ymhlith datblygwyr C++ sy'n tyllu i mewn i fewnolion cof am y tro cyntaf, ac mae'r ateb yn mynd â ni ar daith hynod ddiddorol trwy'r haenau sy'n eistedd rhwng eich cod a'r caledwedd gwirioneddol.

Beth Sy'n Digwydd Pan Chi'n Galw newydd

I ddeall y ffigur 72 KB, mae angen ichi olrhain y gadwyn ddyrannu lawn. Pan fydd eich cod C++ yn gweithredu new int, mae'r casglwr yn trosi hynny'n alwad i gweithredwr newydd, sydd ar y rhan fwyaf o systemau Linux yn dirprwyo i malloc o glibc. Ond nid yw malloc yn gofyn yn uniongyrchol i'r cnewyllyn am 4 beit o gof. Mae'r cnewyllyn yn gweithredu mewn tudalennau - fel arfer 4 KB ar x86_64 - ac mae cost galwad system yn enfawr o'i gymharu â mynediad cof syml. Byddai galw brk() neu mmap() ar gyfer pob dyraniad unigol yn golygu bod unrhyw raglen nad yw'n ddibwys yn dod i ben.

Yn lle hynny, mae dyranwr cof glibc - gweithrediad o'r enw ptmalloc2, ei hun yn disgyn o glasur Doug Lea dlmalloc - yn gweithredu fel canolwr. Mae'n gofyn am flociau mawr o gof o'r cnewyllyn ymlaen llaw, yna'n eu cerfio'n ddarnau llai gan fod eich rhaglen eu hangen. Dyma'r rheswm sylfaenol bod eich dyraniad 4-beit cyntaf yn sbarduno cais llawer mwy i'r system weithredu. Nid yw'r dyrannwr yn wastraffus. Mae'n bod yn strategol.

Dyrannu'r 72 KB: Ble mae'r Beitiau'n Mynd

Mae'r gorbenion dyraniad cychwynnol yn dod o nifer o gydrannau gwahanol y mae'n rhaid i'r amser rhedeg eu cychwyn cyn y gall roi hyd yn oed un beit o gof defnyddiadwy i chi. Mae deall pob cydran yn esbonio pam mae'r rhif yn glanio lle mae.

Yn gyntaf, mae malloc glibc yn cychwyn y brif arena — y prif strwythur cadw llyfrau sy'n olrhain yr holl ddyraniadau ar y brif edefyn. Mae'r maes hwn yn cynnwys metadata ar gyfer y domen, awgrymiadau rhestr rydd, a strwythurau bin ar gyfer gwahanol feintiau dyraniad. Mae'r dyrannwr yn ymestyn toriad y rhaglen trwy sbrk(), ac mae'r estyniad cychwynnol yn cael ei reoli gan baramedr mewnol o'r enw M_TOP_PAD, sy'n rhagosod i 128 KB o badin. Fodd bynnag, mae'r cais cychwynnol gwirioneddol yn cael ei addasu ar gyfer aliniad tudalen a'r sefyllfa dorri bresennol, sy'n aml yn arwain at gais cyntaf llai - fel arfer yn glanio'n agos at y ffigur 72 KB hwnnw ar broses sydd newydd ddechrau.

Yn ail, ers glibc 2.26, mae'r dyrannwr yn cychwyn celc edau-lleol (tcache) wrth ei ddefnyddio gyntaf. Mae'r tcache yn cynnwys 64 bin (un fesul dosbarth maint dyraniad bach), pob un yn gallu dal hyd at 7 talp wedi'i storio. Mae'r tcache_perthread_struct ei hun yn defnyddio tua 1 KB, ond mae'r weithred o'i gychwyn yn sbarduno gosod yr arena ehangach. Yn drydydd, mae'r amser rhedeg C++ eisoes wedi cyflawni dyraniadau cyn bod eich prif() hyd yn oed yn rhedeg - adeiladwyr statig, cychwyniad byffer iostream ar gyfer std::cout a ffrindiau, a gosodiad locale i gyd yn cyfrannu at yr ôl troed pentwr cychwynnol hwnnw.

Y System Arena a Pam Mae Rhag-ddyrannu yn Glyfar

Nid yw’r penderfyniad i rag-ddyrannu talp sylweddol o gof yn hytrach na gofyn amdano’n dameidiog yn ddamwain o ran gweithredu. Mae'n gyfaddawd peirianneg bwriadol sydd wedi'i wreiddio mewn degawdau o brofiad rhaglennu systemau. Mae pob galwad i brk() neu mmap() yn cynnwys newid cyd-destun o ofod defnyddiwr i ofod cnewyllyn, addasu mapiau cof rhithwir y broses, a diweddariadau posibl i dablau tudalennau. O ran caledwedd modern, mae galwad system sengl yn costio tua 100-200 nanoseconds - dibwys ar ei ben ei hun, trychinebus ar raddfa.

Ystyriwch raglen sy'n gwneud 10,000 o ddyraniadau bach wrth gychwyn. Heb rag-ddyrannu, byddai hynny'n golygu 10,000 o alwadau system, gan gostio tua 1-2 milieiliad o orbenion pur. Gyda dyrannwr yn seiliedig ar arena, mae'r dyraniad cyntaf yn sbarduno galwad system sengl, ac mae'r 9,999 o ddyraniadau dilynol yn cael eu gwasanaethu'n gyfan gwbl yng ngofod y defnyddiwr trwy weithrediadau rhifyddeg pwyntydd a rhestr gysylltiedig - pob un yn cymryd tua 10-50 nanoeiliad. Mae'r mathemateg yn ddiamwys: mae rhag-ddyraniad yn ennill yn ôl trefn maint.

Nid yw'r 72 KB a welwch ar eich dyraniad cyntaf yn gof wedi'i wastraffu - mae'n fuddsoddiad perfformiad. Mae'r dyrannwr yn betio y bydd eich rhaglen yn gwneud mwy o ddyraniadau yn fuan, ac ym mron pob senario yn y byd go iawn, mae'r bet hwnnw'n talu ar ei ganfed yn sylweddol. Mae cost gofod cyfeiriad rhithwir heb ei ddefnyddio yn y bôn yn sero ar systemau 64-bit modern.

Cof Rhithwir yn erbyn Cof Corfforol: Pam nad yw'n Bwysig

Pryder cyffredin ymhlith datblygwyr sy’n dod ar draws yr ymddygiad hwn am y tro cyntaf yw gwastraff adnoddau. Os mai dim ond 4 beit sydd eu hangen arnaf, pam mae fy rhaglen yn defnyddio 72 KB? Y mewnwelediad hollbwysig yw nad yw cof rhithwir yn gof corfforol. Pan fydd glibc yn ymestyn toriad y rhaglen 72 KB, mae'r cnewyllyn yn diweddaru mapiau cof rhithwir y broses, ond nid yw'n dychwelyd y tudalennau hynny gyda RAM corfforol ar unwaith. Mae'r tudalennau ffisegol gwirioneddol yn cael eu dyrannu ar gais trwy ddiffygion tudalen - dim ond pan fydd eich rhaglen yn ysgrifennu i gyfeiriad penodol y mae'r cnewyllyn yn neilltuo tudalen go iawn o gof iddo.

Mae hyn yn golygu, er bod maint rhithwir eich proses yn cynyddu 72 KB, mae ei maint set breswyl (RSS) - faint o RAM corfforol a ddefnyddir mewn gwirionedd - yn cynyddu dim ond y tudalennau rydych chi'n eu cyffwrdd mewn gwirionedd. Ar gyfer un int newydd, sef un dudalen 4 KB fel arfer, a pha dudalennau bynnag y mae metadata'r arena yn eu meddiannu. Mae'r gofod rhithwir sy'n weddill yn eistedd yno, yn barod i'w ddefnyddio, heb gostio dim ond gofod cyfeiriad - ac mae gennych 128 TB ohono ar system Linux 64-bit.

Mae'r gwahaniaeth hwn yn hollbwysig wrth broffilio a monitro cymwysiadau cynhyrchu. Os ydych chi'n adeiladu meddalwedd sydd angen olrhain defnydd gwirioneddol o adnoddau - boed yn gefn SaaS, yn ficrowasanaeth, neu'n biblinell ddadansoddeg fel y rhai sy'n rhedeg ar lwyfannau fel Mewayz ar gyfer gweithrediadau busnes - dylech bob amser fonitro RSS yn hytrach na maint rhithwir. Gall offer fel /proc/[pid]/smaps, valgrind --tool=massif, a pmap roi olion traed cof corfforol cywir i chi yn hytrach na ffigurau cof rhithwir camarweiniol.

Sut mae Dyranwyr Gwahanol yn Ymdrin â'r Dyraniad Cyntaf

Mae'r ffigwr 72 KB yn benodol i ptmalloc2 glibc. Mae dyranwyr eraill yn gwneud cyfaddawdau gwahanol, ac mae'r gorbenion dyraniad cychwynnol yn amrywio yn unol â hynny. Mae deall y gwahaniaethau hyn yn werthfawr wrth ddewis dyrannwr ar gyfer cymwysiadau sy'n sensitif i berfformiad.

• jemalloc (a ddefnyddir gan Facebook, FreeBSD) — Yn defnyddio strwythur arena mwy gronynnog gyda storfa edau-local. Mae'r gorbenion cychwynnol yn tueddu i fod yn uwch (yn aml 200+ KB) ond mae'n darparu perfformiad aml-edau gwell oherwydd llai o gynnen clo.
• tcmalloc (Google's Thread-Caching Malloc) — Yn dyrannu celc fesul edau o tua 2 MB yn ddiofyn, gyda rhag-ddyrannu ymosodol. Mae gorbenion cychwynnol yn uwch, ond mae dyraniadau bach dilynol yn hynod o gyflym.
• musl libc's malloc — Yn defnyddio dyluniad llawer symlach yn seiliedig ar mmap ar gyfer pob dyraniad. Mae'r gorbenion cychwynnol yn fach iawn (yn aml dim ond 4 KB fesul dyraniad), ond mae'r gost fesul dyraniad yn uwch oherwydd galwadau system amlach.
• mimalloc (Microsoft) — Yn defnyddio dyraniad ar sail segmentau gyda 64 MB o segmentau. Mae'r dyraniad cyntaf yn sbarduno archeb rithwir o 64 MB (gydag ychydig iawn o ymrwymiad corfforol), gofod cyfeiriad masnachu ar gyfer ardal eithriadol a thrwybwn.

Mae'r dewis rhwng y dyranwyr hyn yn dibynnu'n llwyr ar eich llwyth gwaith. Ar gyfer rhaglenni gweinydd hirsefydlog gyda dyraniad aml-edau trwm, mae jemalloc neu tcmalloc fel arfer yn perfformio'n well na rhagosodiad glibc. Ar gyfer systemau sydd wedi'u mewnosod â chyfyngiadau cof, efallai y byddai dull symlach Musl yn well er gwaethaf trwybwn is. Ar gyfer y rhan fwyaf o gymwysiadau bwrdd gwaith a gweinydd cyffredinol, mae gorben cychwynnol ptmalloc2 72 KB yn cynrychioli rhagosodiad rhesymol sy'n gweithio'n dda heb diwnio.

Tiwnio'r Ymddygiad Dyraniad Cychwynnol

Os yw'r gorbenion cychwynnol diofyn o 72 KB yn wirioneddol broblematig ar gyfer eich achos defnydd - efallai eich bod yn silio miloedd o brosesau byrhoedlog, pob un yn gwneud dim ond llond llaw o ddyraniadau - mae glibc yn darparu sawl teclyn tunable trwy mallopt() a'r MALLOC_ teulu o newidynnau amgylchedd.

Mae'r paramedr M_TOP_PAD yn rheoli faint o gof ychwanegol y mae'r dyrannwr yn gofyn amdano y tu hwnt i'r hyn sydd ei angen ar unwaith. Mae ei osod i 0 gyda mallopt(M_TOP_PAD, 0) yn dweud wrth y dyranwr i ofyn am yr hyn sydd ei angen yn unig, gan leihau'r gorbenion cychwynnol yn sylweddol. Mae'r paramedr M_MMAP_THRESHOLD yn rheoli'r maint y mae dyraniadau'n defnyddio mmap uwchben yn lle'r arena. Mae'r M_TRIM_THRESHOLD yn rheoli pan fydd cof rhydd yn cael ei ddychwelyd i'r OS. Ac ers glibc 2.26, mae'r tunables glibc.malloc.tcache_count a glibc.malloc.tcache_max yn gadael i chi reoli ymddygiad y storfa edau.

Fodd bynnag, gair o rybudd: mae tiwnio’r paramedrau hyn heb feincnodi gofalus bron bob amser yn gwneud pethau’n waeth. Dewiswyd y rhagosodiadau yn seiliedig ar broffilio helaeth yn y byd go iawn, ac maent yn fan melys ar gyfer mwyafrif helaeth y llwythi gwaith. Oni bai bod gennych dystiolaeth gref o broffilio cynhyrchu bod gorbenion malloc yn dagfa—a’ch bod wedi mesur effaith eich newidiadau—gadewch lonydd i’r rhagosodiadau. Mae optimeiddio cynamserol y dyrannwr yn ffurf arbennig o lechwraidd o eillio iacod sydd wedi treulio oriau peirianyddol di-rif er budd dibwys.

Beth Mae Hyn yn Ei Ddysgu I Ni Am Raglennu Systemau

Mae dirgelwch dyraniad cyntaf 72 KB, yn ei graidd, yn wers am haenau echdynnu. Mae C++ yn rhoi'r argraff bod int newydd yn dyrannu 4 beit. Mae'r safon iaith yn dweud hynny. Mae eich model meddwl yn dweud hynny. Ond rhwng eich cod a'r caledwedd mae pentwr o systemau soffistigedig - yr amser rhedeg C ++, y dyraniad llyfrgell C, is-system cof rhithwir y cnewyllyn, ac MMU a TLB y caledwedd - pob un yn ychwanegu ei ymddygiadau, optimeiddiadau a gorbenion ei hun.

Nid yw hyn yn ddiffyg. Dyma bwynt cyfan meddalwedd systemau. Mae pob haen yn bodoli i ddatrys problem wirioneddol: mae'r dyrannwr yn bodoli felly nid oes rhaid i chi wneud galwadau system ar gyfer pob dyraniad. Mae'r system cof rhithwir yn bodoli felly nid oes rhaid i chi reoli cof corfforol yn uniongyrchol. Mae triniwr namau tudalen yn bodoli felly mae'r cof yn cael ei ymrwymo'n ddiog ac yn effeithlon. Mae pob haen yn masnachu ychydig bach o dryloywder ar gyfer llawer iawn o berfformiad a hwylustod.

Y datblygwyr sy'n adeiladu'r systemau mwyaf dibynadwy, sy'n perfformio orau yw'r rhai sy'n deall yr haenau hyn - nid oherwydd bod angen iddynt feddwl amdanynt yn gyson, ond oherwydd pan fydd rhywbeth annisgwyl yn digwydd (fel dyraniad dirgel o 72 KB), mae ganddynt y model meddyliol i ddeall pam. P'un a ydych chi'n adeiladu system fasnachu amser real, injan gêm, neu lwyfan busnes sy'n gwasanaethu miloedd o ddefnyddwyr, y gallu i resymu am yr hyn y mae eich cod yn ei wneud mewn gwirionedd ar lefel y system yw'r hyn sy'n gwahanu datblygwyr cymwys oddi wrth rai eithriadol. Nid byg yw'r 72 KB. Eich dyranwr sy'n gwneud ei waith yn wych.