Բաշխում Stack-ի վրա

Ինչու՞ է Stack-ի հատկացումը դեռևս կարևոր ժամանակակից ծրագրային ապահովման ճարտարագիտության մեջ

Ամեն անգամ, երբ ձեր հավելվածը մշակում է հարցումը, ստեղծում փոփոխական կամ կանչում է ֆունկցիա, կուլիսներում լուռ որոշում է կայացվում. որտեղ պետք է այս տվյալները մնան հիշողության մեջ: Տասնամյակներ շարունակ stack-ի տեղաբաշխումը եղել է ամենաարագ, կանխատեսելի հիշողության ռազմավարություններից մեկը, որը հասանելի է ծրագրավորողներին, սակայն այն շարունակում է լայնորեն չհասկացված լինել: Կառավարվող գործարկման ժամանակաշրջանում, աղբ հավաքողներին և ամպային բնիկ ճարտարապետություններին, հասկանալը, թե ինչպես և երբ պետք է բաշխել փաթեթում, կարող է նշանակել տարբերություն 10000 միաժամանակ օգտագործող և 500-ից ցածր օգտատերերի միջև: հաշվում է:

Stack vs. Heap. The Fundamental Trade-off

Հիշողությունը ծրագրավորման միջավայրերի մեծ մասում բաժանված է երկու հիմնական շրջանների՝ կույտ և կույտ: Դույլը գործում է որպես վերջին մուտք, առաջին դուրս (LIFO) տվյալների կառուցվածք: Երբ ֆունկցիա է կանչվում, նոր «շրջանակ» դրվում է լոկալ փոփոխականներ, վերադարձի հասցեներ և ֆունկցիայի պարամետրեր պարունակող կույտի վրա: Երբ այդ գործառույթը վերադառնում է, ամբողջ շրջանակն անմիջապես անջատվում է: Չկա որոնում, հաշվապահություն, մասնատում, ընդամենը մեկ ցուցիչի ճշգրտում:

Կույտը, ընդհակառակը, հիշողության մեծ լողավազան է, որտեղ տեղաբաշխումները և տեղաբաշխումները կարող են տեղի ունենալ ցանկացած հերթականությամբ: Այս ճկունությունն ունի ծախսեր. հատկացնողը պետք է հետևի, թե որ բլոկներն են անվճար, կարգավորի մասնատումը և շատ լեզուներով չօգտագործված հիշողությունը վերականգնելու համար հույսը դնի աղբահանի վրա: Տիպիկ C ծրագրում կույտի տեղաբաշխումը տևում է մոտավորապես 10-20 անգամ ավելի երկար, քան կույտի հատկացումը: Աղբով հավաքված լեզուներում, ինչպիսիք են Java-ը կամ C#-ը, ծախսերը կարող են ավելի մեծ լինել, երբ հաշվի են առնվում հավաքագրման դադարները:

Այս փոխզիջման ըմբռնումը սոսկ ակադեմիական չէ: Երբ դուք ծրագրավորում եք մշակում, որը հազարավոր գործարքներ է մշակում վայրկյանում, լինի դա հաշիվ-ապրանքագրերի շարժիչ, իրական ժամանակի վերլուծական վահանակ կամ CRM, որը կառավարում է կոնտակտների զանգվածային ներմուծումները, թեժ ուղիների համար ճիշտ տեղաբաշխման ռազմավարություն ընտրելն ուղղակիորեն ազդում է արձագանքման ժամանակի և ենթակառուցվածքի ծախսերի վրա:

Ինչպես է իրականում աշխատում Stack-ի հատկացումը

Սարքավորումների մակարդակում պրոցեսորների ճարտարապետության մեծ մասը հատկացնում է գրանցամատյան (կույտի ցուցիչ)՝ հետևելու կույտի ընթացիկ վերևին: Հիշողության բաշխումը կույտի վրա նույնքան պարզ է, որքան այս ցուցիչը նվազեցնելը բայթերի անհրաժեշտ քանակով: Տեղաբաշխումը հակառակն է՝ ավելացրեք ցուցիչը: Ոչ մետատվյալների վերնագրեր, ոչ ազատ ցուցակներ, ոչ հարակից բլոկների միավորում: Ահա թե ինչու կույտերի բաշխումը հաճախ նկարագրվում է որպես O(1) հաստատուն ժամանակի կատարողականություն՝ աննշան վերադիր ծախսերով:

Դիտարկենք մի ֆունկցիա, որը հաշվարկում է հաշիվ-ապրանքագրի տողերի ընդհանուր գումարը: Այն կարող է հայտարարել մի քանի տեղական փոփոխականներ՝ քանակի ամբողջ թիվ, միավոր գնի լողացող, հարկային դրույքաչափի լողացող և արդյունքի լողացող: Բոլոր չորս արժեքները դրվում են կույտի վրա, երբ գործառույթը մուտքագրվում է, և ավտոմատ կերպով վերականգնվում է, երբ այն դուրս է գալիս: Ամբողջ կյանքի ցիկլը դետերմինիստական է և պահանջում է զրոյական միջամտություն ծրագրավորողի կամ աղբահանի կողմից:

Հիմնական պատկերացում. Դույների բաշխումը ոչ միայն արագ է, այլ նաև կանխատեսելի: Կատարման համար կարևոր համակարգերում կանխատեսելիությունը հաճախ ավելի կարևոր է, քան չմշակված արագությունը: Գործառույթը, որը հետևողականորեն ավարտվում է 2 միկրովայրկյանում, ավելի արժեքավոր է, քան այն, որը միջինում 1 մկվ է, բայց երբեմն աճում է մինչև 50 միկրովայրկյան՝ աղբահանության դադարների պատճառով:

Երբ բարենպաստել կույտերի հատկացումը

Տվյալների ոչ բոլոր մասերն են պատկանում փաթեթին: Stack-ի հիշողությունը սահմանափակ է (սովորաբար 1 ՄԲ-ից մինչև 8 ՄԲ յուրաքանչյուր շղթայի միջև՝ կախված օպերացիոն համակարգից), և փաթեթի վրա հատկացված տվյալները չեն կարող գերազանցել այն ստեղծած գործառույթը: Այնուամենայնիվ, կան հստակ սցենարներ, որտեղ կույտերի բաշխումը լավագույն ընտրությունն է:

• Կարճաժամկետ տեղական փոփոխականներ. Հաշվիչները, կուտակիչները, մի քանի կիլոբայթի տակ գտնվող ժամանակավոր բուֆերները և հանգույցի ինդեքսները բնական տեղավորվում են կույտի համար: Դրանք ստեղծվում, օգտագործվում և հեռացվում են մեկ գործառույթի շրջանակում:
• Ֆիքսված չափի տվյալների կառուցվածքներ. Կոմպիլյացիայի ժամանակի հայտնի չափով, փոքր կառուցվածքներով և արժեքների տեսակներով զանգվածները կարող են տեղադրվել կույտի վրա՝ առանց հոսելու վտանգի: 256 բայթանոց բուֆերը՝ ամսաթվի տողի ձևաչափման համար կատարյալ թեկնածու է:
• Արդյունավետության համար կարևոր ներքին օղակներ․ Երբ ֆունկցիան կանչվում է վայրկյանում միլիոնավոր անգամներ, օրինակ՝ գնագոյացման հաշվարկման շարժիչը, որը կրկնվում է արտադրանքի կատալոգների վրա, հանգույցի մարմնի կույտային տեղաբաշխումները վերացնելը կարող է բերել 3x-ից 10x թողունակության բարելավում:
• Իրական ժամանակի կամ հետաձգման նկատմամբ զգայուն ուղիներ. Վճարումների մշակումը, ուղիղ վահանակի թարմացումները և ծանուցումների ուղարկումը օգուտ են քաղում աղբահանության ոչ որոշիչ դադարներից խուսափելուց:
• Սահմանափակ խորությամբ ռեկուրսիվ ալգորիթմներ. Եթե դուք կարող եք երաշխավորել, որ ռեկուրսիայի խորությունը մնում է անվտանգ սահմաններում, ապա կույտով հատկացված շրջանակները պահում են ռեկուրսիվ գործառույթները արագ և պարզ:

Գործնականում ժամանակակից կոմպիլյատորները զգալիորեն լավ են օպտիմիզացնում stack-ի օգտագործումը: Go-ի և Java-ի JIT կոմպիլյատորի նման փախուստի վերլուծության մեթոդները կարող են ավտոմատ կերպով տեղափոխել կույտային հատկացումները դեպի կույտ, երբ կոմպիլյատորն ապացուցի, որ տվյալները չեն դուրս գալիս ֆունկցիայի շրջանակից: Այս օպտիմիզացումները հասկանալը թույլ է տալիս ավելի մաքուր կոդ գրել՝ միևնույն ժամանակ օգուտ քաղելով stack-ի արդյունավետությունից:

Ընդհանուր որոգայթներ և ինչպես խուսափել դրանցից

Կույտի հետ կապված ամենահռչակավոր վրիպակը stack overflow-ն է. հատկացնում է ավելի շատ տվյալներ, քան կարող է պահել կույտը, սովորաբար անսահմանափակ ռեկուրսիայի կամ չափազանց մեծ տեղական զանգվածների միջոցով: Արտադրական միջավայրում կույտի արտահոսքը սովորաբար խափանում է շարանը կամ ամբողջ գործընթացը՝ առանց վերականգնման նրբագեղ ուղու: Ահա թե ինչու շրջանակները և օպերացիոն համակարգերը սահմանում են կույտի չափի սահմանափակումներ:

Մեկ այլ նուրբ թակարդ է ցուցիչները կամ հղումները վերադարձնելը կույտով հատկացված տվյալներին: Քանի որ կուտակային հիշողությունը վերականգնվում է ֆունկցիայի վերադարձի պահին, այդ հիշողության ցանկացած ցուցիչ դառնում է կախված հղում: C-ում և C++-ում դա հանգեցնում է չսահմանված վարքագծի, որը կարող է թվալ, թե աշխատում է թեստավորման ժամանակ, բայց արտադրության մեջ աղետալիորեն ձախողվում է: Rust's borow checker-ը հայտնաբերում է այս դասի սխալը կոմպիլյացիայի ժամանակ, ինչը պատճառներից մեկն է, որ լեզուն գրավել է համակարգերի ծրագրավորումը:

Երրորդ խնդիրը վերաբերում է թելերի անվտանգությանը: Յուրաքանչյուր շղթա ստանում է իր սեփական ստեկը, ինչը նշանակում է, որ կույտի կողմից հատկացված տվյալները ներածականորեն տեղական են: Սա իրականում շատ դեպքերում առավելություն է. տեղական փոփոխականներ մուտք գործելու համար կողպեքներ չեն պահանջվում: Այնուամենայնիվ, մշակողները երբեմն սխալվում են՝ փորձելով կիսել կույտերով հատկացված տվյալները թելերի միջև, ինչը հանգեցնում է մրցավազքի պայմանների կամ առանց օգտագործման սխալների: Երբ տվյալները պետք է համօգտագործվեն շղթաներով կամ պահպանվեն ֆունկցիայի կանչից հետո, կույտը համապատասխան ընտրություն է:

Տեղաբաշխում լեզուների և շրջանակների միջև

Տարբեր ծրագրավորման լեզուներ մշակում են կույտերի բաշխումը տարբեր աստիճանի թափանցիկությամբ: C-ում և C++-ում ծրագրավորողն ունի հստակ հսկողություն. տեղական փոփոխականները գնում են կույտի վրա, և malloc կամ new տվյալները տեղադրում են կույտի վրա: Go-ում կոմպիլյատորը կատարում է փախուստի վերլուծություն՝ ինքնաբերաբար որոշելու համար, և գորուտինները սկսվում են փոքրիկ 2 ԿԲ կույտերով, որոնք աճում են դինամիկ կերպով՝ նրբագեղ լուծում, որը հավասարակշռում է անվտանգությունն ու կատարողականը: PHP-ն՝ Laravel-ի նման լեզուն սնուցող շրջանակները, արժեքների մեծ մասը հատկացնում է իր ներքին Zend Engine հիշողության կառավարչի միջոցով, սակայն հիմքում ընկած սկզբունքները հասկանալն օգնում է մշակողներին ավելի արդյունավետ կոդ գրել նույնիսկ հավելվածի մակարդակում:

Բարդ հարթակներ կառուցող թիմերի համար, ինչպես Mewayz-ի ինժեներական թիմը, որտեղ մեկ հարցումը կարող է անցնել CRM տրամաբանությամբ, հաշիվ-ապրանքագրերի հաշվարկներով, աշխատավարձի հարկի հաշվարկներով և վերլուծական ագրեգացիայով, այս ցածր մակարդակի որոշումները բարդ են: Երբ 207 մոդուլները կիսում են գործարկման ժամանակը, յուրաքանչյուր հարցման հիշողության հատկացումների կրճատումը նույնիսկ 15%-ով կարող է նշանակալից կրճատումներ ունենալ սերվերի ծախսերի և չափելի բարելավումների պատասխանների ժամանակի վերջնական օգտագործողների համար, ովքեր կառավարում են իրենց բիզնեսը հարթակում:

JavaScript-ը և TypeScript-ը, որոնք ապահովում են ամենաարդիական առջևի մասերը և Node.js-ի հետին մասերը, հիշողության կառավարման համար ամբողջովին հիմնված են V8 շարժիչի աղբահանիչի վրա: Մշակողները չեն կարող ուղղակիորեն բաշխել կույտի վրա, սակայն V8-ի օպտիմալացնող կոմպիլյատորը (TurboFan) կատարում է կույտերի տեղաբաշխում ներքին արժեքների համար, որոնք կարող են ապացուցել, որ կարճատև են: Փոքր, մաքուր գործառույթներ տեղական փոփոխականներով գրելը շարժիչին լավագույն հնարավորություն է տալիս կիրառել այս օպտիմալացումները:

Կույտային ճնշումը նվազեցնելու գործնական ռազմավարություններ

Նույնիսկ եթե դուք աշխատում եք բարձր մակարդակի լեզվով, որտեղ դուք չեք կարող ուղղակիորեն կառավարել կույտը՝ ընդդեմ կույտի բաշխման, կարող եք օրինաչափություններ ընդունել, որոնք նվազեցնում են ավելորդ կույտի ճնշումը և թույլ են տալիս, որ գործարկման ժամանակը ավելի ագրեսիվ օպտիմիզանա:

1. Նախընտրեք արժեքների տեսակները, քան հղումների տեսակները, որտեղ լեզուն աջակցում է դրանք: C#-ում փոքր, հաճախակի ստեղծված օբյեկտների համար class-ի փոխարեն struct օգտագործելը դրանք պահում է փաթեթում: Go-ում փոքր կառուցվածքներ փոխանցելով ըստ արժեքի, այլ ոչ թե ցուցիչի, ստացվում է նույն ազդեցությունը:
2. Խուսափեք փակ օղակների ներսում տեղաբաշխելուց: Նախապես հատկացրեք բուֆերները և նորից օգտագործեք դրանք կրկնությունների ընթացքում: Եթե Ձեզ անհրաժեշտ է ժամանակավոր հատված կամ զանգված 100,000 անգամ գործարկվող օղակի ներսում, հատկացրեք այն մեկ անգամ հանգույցից առաջ և վերակայեք այն յուրաքանչյուր կրկնության վրա:
3. Օգտագործեք օբյեկտների միավորում հաճախակի ստեղծվող և ոչնչացվող օբյեկտների համար: Տվյալների բազայի միացման լողավազանները դասական օրինակ են, սակայն օրինաչափությունը հավասարապես կիրառվում է HTTP հարցման օբյեկտների, սերիականացման բուֆերների և հաշվարկային համատեքստի կառուցվածքների համար:
4. Պրոֆիլը նախքան օպտիմալացնելը: Գործիքները, ինչպիսիք են Go-ի pprof-ը, Java-ի async-profiler կամ PHP-ի Blackfire-ը կարող են ճշգրիտ նշել, թե որտեղ են տեղի ունենում հատկացումները: Առանց տվյալների պրոֆիլավորման օպտիմիզացումը վտանգում է ջանք ծախսել սառը ուղիների վրա, որոնք հազվադեպ են կատարվում:
5. Արենա հատկացնող լծակները խմբաքանակային գործողությունների համար: Երբ մշակում է գրառումների փաթեթը, օրինակ՝ 500 հաշիվ-ապրանքագրեր ստեղծելը կամ 10000 կոնտակտ ներմուծելը, արենա հատկացնողը վերցնում է հիշողության մեկ մեծ բլոկ և փաթեթավորում այն փաթեթի նման արագությամբ, այնուհետև ազատում է ամբողջ բլոկը միանգամից:

Այս ռազմավարությունները միայն տեսական չեն: Երբ SaaS հարթակները կառավարում են իրական աշխատանքային ծանրաբեռնվածությունը՝ փոքր բիզնեսի սեփականատերը, որը ստեղծում է ամսական հաշիվ-ապրանքագրեր, HR մենեջեր, որն աշխատում է 200 աշխատակիցների համար, մարքեթինգային թիմ, որը վերլուծում է քարոզարշավի արդյունավետությունը ալիքներում, արդյունավետ հիշողության կառավարման կուտակային էֆեկտն ավելի արագ և արձագանքող փորձ է, որը օգտատերերը զգում են, նույնիսկ եթե նրանք երբեք չեն մտածում, թե ինչ է կատարվում:

Կառուցում կատարողական-գիտակցական ծրագրակազմը մասշտաբով

Կույտերի բաշխումը շատ ավելի մեծ կատարողական գլուխկոտրուկի մի մասն է, սակայն այն հիմնարար է: Հասկանալը, թե ինչպես է աշխատում հիշողությունը ամենացածր մակարդակում, ինժեներներին տալիս է մտավոր մոդելներ, որոնք նրանց անհրաժեշտ են փաթեթի յուրաքանչյուր շերտում ավելի լավ որոշումներ կայացնելու համար՝ սկսած տվյալների կառուցվածքների ընտրությունից և API-ների նախագծումից մինչև ենթակառուցվածքի կազմաձևում և ռեսուրսների սահմանաչափերի սահմանում կոնտեյներային ծառայությունների համար:

Այն ձեռնարկությունների համար, որոնք հենվում են Mewayz-ի նման հարթակների վրա իրենց ամենօրյա գործառնություններն իրականացնելու համար, այս ինժեներական որոշումների արդյունքը շոշափելի է. էջերի ավելի արագ բեռնում, ավելի հարթ փոխազդեցություններ և վստահություն, որ համակարգը չի քայքայվի առավելագույն ծանրաբեռնվածության պայմաններում: Երբ ամրագրման մոդուլը պետք է իրական ժամանակում ստուգի հասանելիությունը տասնյակ օրացույցներում, կամ վերլուծական վահանակը հավաքում է տվյալները բազմաթիվ բիզնես միավորների միջև, հիմքում ընկած հիշողության ռազմավարությունն ավելի կարևոր է, քան օգտատերերի մեծ մասը երբևէ կհասկանա:

Լավագույն ծրագրաշարը հեշտ է օգտագործել հենց այն պատճառով, որ դրա ստեղծողները քրտնել են այն մանրամասները, որոնք մնում են անտեսանելի: Դույների տեղաբաշխումը` արագ, վճռական և էլեգանտ իր պարզությամբ, այն մանրամասներից մեկն է, որն արժե խորապես հասկանալ, անկախ նրանից՝ գրում եք ձեր առաջին ծրագիրը, թե կառուցում եք հարթակ, որը սպասարկում է հազարավոր բիզնեսներ ամբողջ աշխարհում:

Հաճախակի տրվող հարցեր

Ի՞նչ է stack-ի հատկացումը և ինչո՞ւ է դա կարևոր:

Stack-ի հատկացումը հիշողության կառավարման ռազմավարություն է, որտեղ տվյալները պահվում են վերջին մուտքի, առաջին դուրս եկող կառուցվածքում, որն ավտոմատ կերպով կառավարվում է ծրագրի կատարման հոսքով: Դա կարևոր է, քանի որ կույտով հատկացված հիշողությունը զգալիորեն ավելի արագ է, քան կույտային տեղաբաշխումը. չկա աղբի հավաքիչի վերևում, ոչ մի մասնատում, և տեղաբաշխումը ակնթարթային է, երբ գործառույթը վերադառնում է: Արդյունավետության համար կարևոր հավելվածների համար, կույտերի բաշխումը հասկանալը կարող է կտրուկ նվազեցնել ուշացումը և բարելավել թողունակությունը:

Ե՞րբ պետք է օգտագործեմ կույտերի բաշխումը կույտային բաշխման փոխարեն:

Կոմպիլյացիայի ժամանակ օգտագործեք կույտերի տեղաբաշխումը հայտնի չափով փոքր, կարճատև փոփոխականների համար, ինչպիսիք են տեղային ամբողջ թվերը, կառուցվածքները և ֆիքսված չափի զանգվածները: Կույտային տեղաբաշխումն ավելի հարմար է տվյալների մեծ կառուցվածքների, դինամիկ չափերի հավաքածուների կամ օբյեկտների համար, որոնք պետք է գերազանցեն իրենց ստեղծած գործառույթը: Հիմնական կանոնը. եթե տվյալների գործողության ժամկետը համապատասխանում է ֆունկցիայի շրջանակին, և դրա չափը կանխատեսելի է, ապա կույտը գրեթե միշտ ավելի արագ ընտրություն է:

Հնարավո՞ր է կանխել կույտերի արտահոսքի սխալները արտադրական հավելվածներում:

Այո, կույտերի արտահոսքի սխալները կարելի է կանխել կարգապահ ինժեներական պրակտիկայով: Խուսափեք խորը կամ անսահմանափակ ռեկուրսիայից, սահմանափակեք տեղական փոփոխականների մեծ տեղաբաշխումները և հնարավորության դեպքում օգտագործեք կրկնվող ալգորիթմներ: Լեզուների և օպերացիոն համակարգերի մեծ մասը թույլ է տալիս կարգավորել կույտի չափի սահմանափակումները: Մոնիտորինգի գործիքները և հարթակի լուծումները, ինչպիսիք են Mewayz-ը, 207 մոդուլից բաղկացած բիզնես ՕՀ, որը սկսվում է $19/ամսական արժեքից, կարող են օգնել թիմերին հետևել հավելվածի առողջությանը և վաղաժամ նկատել կատարողականի հետընթացը:

Արդյո՞ք ժամանակակից լեզուները դեռ օգտվում են stack-ի բաշխումից:

Բացարձակապես: Նույնիսկ կառավարվող աշխատաժամանակ ունեցող լեզուները, ինչպիսիք են Go-ը, Rust-ը, C#-ը և Java-ն, օգտագործում են փախուստի վերլուծություն՝ որոշելու համար, թե արդյոք փոփոխականները կարո՞ղ են տեղաբաշխվել կույտ-տեղաբաշխման փոխարեն: Rust-ը պարտադրում է stack-first հատկացումը իր սեփականության մոդելի միջոցով, և Go-ի կոմպիլյատորը ագրեսիվորեն օպտիմիզացնում է դրա համար: Այս մեխանիկան հասկանալն օգնում է մշակողներին գրել կոդ, որը կոմպիլյատորները կարող են ավելի արդյունավետ օպտիմիզացնել, ինչը հանգեցնում է հիշողության ավելի քիչ օգտագործման և կատարման ավելի արագ ժամանակի: