Пут до провере типова 4 милиона линија Питхон кода. Део 2

Данас објављујемо други део превода материјала о томе како је Дропбок организовао контролу типа за неколико милиона линија Питхон кода.

→ Прочитај први део

Званични тип подршке (ПЕП 484)

Своје прве озбиљне експерименте са мипи-јем спровели смо у Дропбок-у током Хацк Веек-а 2014. Хацк Веек је једнонедељни догађај чији је домаћин Дропбок. За то време запослени могу да раде шта год желе! Неки од најпознатијих Дропбок-ових технолошких пројеката почели су на оваквим догађајима. Као резултат овог експеримента, закључили смо да мипи изгледа обећавајуће, иако пројекат још није спреман за широку употребу.

У то време, идеја о стандардизацији система наговештаја типа Питхон била је у ваздуху. Као што сам рекао, од Питхон-а 3.0 било је могуће користити напомене типа за функције, али то су били само произвољни изрази, без дефинисане синтаксе и семантике. Током извршавања програма, ове напомене су, углавном, једноставно игнорисане. После Хацк Веек-а, почели смо да радимо на стандардизацији семантике. Овај рад је довео до појаве ПЕП 484 (Гуидо ван Росум, Łукасз Ланга и ја смо сарађивали на овом документу).

Наши мотиви се могу посматрати са две стране. Прво, надали смо се да би цео Питхон екосистем могао да усвоји заједнички приступ коришћењу наговештаја типа (термин који се користи у Питхон-у као еквивалент „напоменама типа“). Ово би, с обзиром на могуће ризике, било боље него користити многе међусобно некомпатибилне приступе. Друго, желели смо да отворено разговарамо о механизмима означавања типова са многим члановима Питхон заједнице. Ова жеља је делимично била диктирана чињеницом да не бисмо желели да изгледамо као „отпадници“ од основних идеја језика у очима широких маса Питхон програмера. То је динамички куцани језик, познат као „пачје куцање“. У заједници, на самом почетку, није могао а да се не појави помало сумњичав однос према идеји статичког куцања. Али то осећање је на крају спласнуло након што је постало јасно да статичко куцање неће бити обавезно (и након што су људи схватили да је заправо корисно).

Синтакса наговештаја типа која је на крају усвојена била је веома слична оној коју је мипи подржавао у то време. ПЕП 484 је објављен са Питхон-ом 3.5 2015. Питхон више није био динамички куцани језик. Волим да мислим о овом догађају као о значајној прекретници у историји Питхона.

Почетак миграције

Крајем 2015. Дропбок је створио тим од три особе за рад на мипи-ју. Међу њима су били Гвидо ван Росум, Грег Прајс и Дејвид Фишер. Од тог тренутка ситуација је почела да се развија изузетно брзо. Прва препрека расту мипи-ја биле су перформансе. Као што сам горе наговестио, у раним данима пројекта размишљао сам о превођењу мипи имплементације у Ц, али је ова идеја за сада прецртана са листе. Заглавили смо у покретању система помоћу ЦПитхон интерпретера, који није довољно брз за алате као што је мипи. (ПиПи пројекат, алтернативна Питхон имплементација са ЈИТ компајлером, такође нам није помогао.)

На срећу, нека алгоритамска побољшања су нам овде дошла у помоћ. Први моћни „акцелератор” била је примена инкременталне провере. Идеја иза овог побољшања је била једноставна: ако се све зависности модула нису промениле од претходног покретања мипи-ја, онда можемо да користимо податке кеширане током претходног покретања док радимо са зависностима. Требало је само да извршимо проверу типа на измењеним датотекама и на датотекама које зависе од њих. Мипи је чак отишао мало даље: ако се спољни интерфејс модула није променио, мипи је претпоставио да други модули који су увезли овај модул не морају поново да се проверавају.

Инкрементална провера нам је много помогла када бележимо велике количине постојећег кода. Поента је у томе да овај процес обично укључује много итеративних покретања мипи-ја пошто се напомене постепено додају коду и постепено побољшавају. Прво покретање мипи-ја је и даље било веома споро јер је требало проверити много зависности. Затим, да бисмо побољшали ситуацију, имплементирали смо механизам за даљинско кеширање. Ако мипи открије да је локални кеш вероватно застарео, он преузима тренутни снимак кеша за целу базу кода из централизованог спремишта. Затим врши инкременталну проверу користећи овај снимак. Ово нас је довело до још једног великог корака ка повећању перформанси мипи-ја.

Ово је био период брзог и природног усвајања провере типа у Дропбок-у. До краја 2016. већ смо имали приближно 420000 линија Питхон кода са напоменама типа. Многи корисници су били одушевљени провером типа. Све више развојних тимова користи Дропбок мипи.

Све је тада изгледало добро, али имали смо још много тога да урадимо. Почели смо да спроводимо периодичне интерне анкете корисника како бисмо идентификовали проблематична подручја пројекта и разумели која питања прво треба да се реше (ова пракса се и данас користи у компанији). Најважнија, како је постало јасно, била су два задатка. Прво, било нам је потребно више типова кода, друго, био нам је потребан мипи да би радио брже. Било је апсолутно јасно да је наш рад на убрзању мипи-ја и имплементацији у пројекте компаније још увек далеко од завршетка. Ми смо, потпуно свесни важности ова два задатка, кренули у њихово решавање.

Више продуктивности!

Инкременталне провере су учиниле мипи бржим, али алатка и даље није била довољно брза. Многе инкременталне провере су трајале око минут. Разлог за то је био циклични увоз. Ово вероватно неће изненадити никога ко је радио са великим кодним базама написаним у Питхон-у. Имали смо сетове од стотине модула, од којих је сваки индиректно увозио све остале. Ако је било која датотека у увозној петљи промењена, мипи је морао да обради све датотеке у тој петљи, а често и све модуле који су увезли модуле из те петље. Један од таквих циклуса био је злогласни „замршен проблем“ који је изазвао много проблема у Дропбок-у. Некада је ова структура садржавала неколико стотина модула, док је увезено, директно или индиректно, много тестова, коришћена је и у производном коду.

Разматрали смо могућност „распетљавања“ кружних зависности, али нисмо имали ресурсе да то урадимо. Било је превише кода са којима нисмо били упознати. Као резултат тога, дошли смо до алтернативног приступа. Одлучили смо да учинимо да мипи брзо функционише чак и у присуству „замршености зависности“. Овај циљ смо постигли користећи мипи демон. Даемон је серверски процес који имплементира две занимљиве карактеристике. Прво, он чува информације о целој бази кода у меморији. То значи да сваки пут када покренете мипи, не морате да учитавате кеширане податке који се односе на хиљаде увезених зависности. Друго, он пажљиво, на нивоу малих структурних јединица, анализира зависности између функција и других ентитета. На пример, ако функција foo позива функцију bar, онда постоји зависност foo из bar. Када се датотека промени, демон прво, у изолацији, обрађује само промењену датотеку. Затим посматра спољашње видљиве промене у тој датотеци, као што су промењени потписи функција. Демон користи детаљне информације о увозу само да би поново проверио оне функције које заправо користе измењену функцију. Обично, са овим приступом, морате да проверите врло мало функција.

Имплементација свега овога није била лака, пошто је оригинална имплементација мипи-ја била у великој мери фокусирана на обраду једне по једне датотеке. Морали смо да се носимо са многим граничним ситуацијама, чија је појава захтевала поновљене провере у случајевима када се нешто променило у коду. На пример, ово се дешава када се класи додели нова основна класа. Када смо урадили оно што смо желели, могли смо да смањимо време извршења већине инкременталних провера на само неколико секунди. Ово нам се чинило као велика победа.

Још више продуктивности!

Заједно са даљинским кеширањем о коме сам горе говорио, мипи демон је скоро у потпуности решио проблеме који настају када програмер често покреће проверу типа, правећи измене у малом броју датотека. Међутим, перформансе система у најнеповољнијем случају још увек су биле далеко од оптималних. Чисто покретање мипи-ја може трајати више од 15 минута. А ово је било много више него што бисмо били задовољни. Сваке недеље ситуација се погоршавала јер су програмери наставили да пишу нови код и додају напомене постојећем коду. Наши корисници су и даље били гладни више перформанси, али смо били срећни што смо их упознали на пола пута.

Одлучили смо да се вратимо на једну од ранијих идеја у вези са мипи. Наиме, претворити Питхон код у Ц код. Експериментисање са Цитхон-ом (системом који вам омогућава да преведете код написан у Питхон-у у Ц код) није нам дало никакво видљиво убрзање, па смо одлучили да оживимо идеју ​​писања сопственог компајлера. Пошто је мипи кодна база (написана у Питхон-у) већ садржала све потребне напомене типа, сматрали смо да би било вредно покушати да искористимо ове напомене да бисмо убрзали систем. Брзо сам направио прототип да тестирам ову идеју. Показао је више од 10 пута повећање перформанси на различитим микро-бенцхмарковима. Наша идеја је била да компајлирамо Питхон модуле у Ц модуле користећи Цитхон, и да претворимо напомене типа у провере типа током извршавања (обично се напомене типа занемарују током извршавања и користе их само системи за проверу типа). Заправо смо планирали да преведемо имплементацију мипи са Питхон-а на језик који је дизајниран да буде статички куцан, који би изгледао (и, углавном, функционисао) баш као Питхон. (Ова врста међујезичке миграције постала је нешто као традиција мипи пројекта. Оригинална имплементација мипија је написана у Алоре-у, затим је постојао синтаксички хибрид Јаве и Питхон-а).

Фокусирање на АПИ проширења ЦПитхон било је кључно да се не изгубе способности управљања пројектима. Нисмо морали да имплементирамо виртуелну машину или било које библиотеке које су биле потребне мипи-ју. Поред тога, и даље бисмо имали приступ целом Питхон екосистему и свим алатима (као што је питест). То је значило да можемо да наставимо да користимо интерпретирани Питхон код током развоја, што нам омогућава да наставимо да радимо са веома брзим обрасцем измене кода и тестирањем, уместо да чекамо да се код компајлира. Изгледало је као да радимо одличан посао седећи на две столице, да тако кажем, и то нам се допало.

Компајлер, који смо назвали мипиц (пошто користи мипи као фронт-енд за анализу типова), показао се као веома успешан пројекат. Све у свему, постигли смо приближно 4к убрзање за честа покретања мипи без кеширања. За развој језгра мипиц пројекта потребно је малом тиму Мајкла Саливана, Ивана Левкивског, Хју Хана и мене око 4 календарска месеца. Ова количина посла је била много мања од онога што би било потребно да се препише мипи, на пример, у Ц++ или Го. И морали смо да унесемо много мање промена у пројекат него што бисмо морали да урадимо када смо га преписали на другом језику. Такође смо се надали да бисмо могли да доведемо мипиц до таквог нивоа да би други Дропбок програмери могли да га користе за компајлирање и убрзање свог кода.

Да бисмо постигли овај ниво перформанси, морали смо да применимо нека занимљива инжењерска решења. Дакле, компајлер може убрзати многе операције коришћењем брзих конструкција ниског нивоа Ц. На пример, преведени позив функције се преводи у позив Ц функције. А такав позив је много бржи од позивања интерпретиране функције. Неке операције, као што је тражење речника, и даље су укључивале коришћење редовних Ц-АПИ позива из ЦПитхон-а, који су били само незнатно бржи када су се компајлирали. Успели смо да елиминишемо додатно оптерећење система настало интерпретацијом, али ово је у овом случају дало само мали добитак у погледу перформанси.

Да бисмо идентификовали најчешће „споре“ операције, извршили смо профилисање кода. Наоружани овим подацима, покушали смо или да подесимо мипиц тако да генерише бржи Ц код за такве операције, или да препишемо одговарајући Питхон код користећи брже операције (а понекад једноставно нисмо имали довољно једноставно решење за тај или други проблем) . Поновно писање Питхон кода је често било лакше решење проблема него да компајлер аутоматски изврши исту трансформацију. Дугорочно, желели смо да аутоматизујемо многе од ових трансформација, али у то време смо били фокусирани на убрзавање мипи-ја уз минималан напор. И крећући се ка овом циљу, пресекли смо неколико углова.

Наставиће се ...

Драги читаоци! Какви су били ваши утисци о пројекту мипи када сте сазнали за његово постојање?

Извор: ввв.хабр.цом