Наверно, чаще всего на Rust жалуются из-за его медленного цикла обратной связи и долгого времени компиляции. Я слышу и читаю об этом постоянно; в подкастах по Rust, в постах блогов, опросах, докладах с конференций и офлайн-обсуждениях. Я и сам, как пользователь Rust, регулярно жалуюсь на это!

Кроме того, наряду с обычными жалобами на время компиляции, я начал замечать от раздражённых разработчиков на Rust и подобные заявления: «Почему Rust Project не занимается активнее этой важной и очевидной проблемой? Почему с этим что-нибудь не сделают?». Я участник рабочей группы по производительности компилятора Rust, поэтому воспринимаю такие вопросы очень серьёзно. И, разумеется, у меня есть мнение по этому поводу. В этом посте я приведу свои размышления, способные служить ответами на эти (и похожие) вопросы.

Предупреждение: все выраженные в этом посте мнения исключительно мои и необязательно отражают точку зрения Rust Project (группы контрибьюторов и мейнтейнеров тулчейна Rust).

Важно ли нам это вообще?

Во-первых, должен уверить вас, что да, мы (то есть Rust Project) совершенно точно беспокоимся о производительности нашего любимого компилятора, и мы вкладываем много труда в его совершенствование. Каждую неделю мы проводим оценку улучшений и регрессий производительности. Мы проводим тщательный бенчмаркинг после каждого смердженного PR. Мы с радостью принимаем любые улучшения производительности (если только они не вынуждают идти на сложные компромиссы; подробнее об этом ниже) и пытаемся быстро откатывать (или исправлять) PR, внедряющие регрессии производительности. Очень умные люди постоянно работают на поиском «бутылочных горлышек» и ускорением компилятора. И уже ведутся работы по внедрению существенных улучшений для повышения скорости компиляции.

И все эти усилия приводят к наглядным результатам: за последние несколько лет производительности сборки Rust существенно повысилась! При обсуждении долговременных трендов мы обычно показываем дэшборд, но мне он кажется немного сухим, потому что усредняет результаты множества бенчмарков, а эти бенчмарки довольно короткие, поэтому их результаты становятся всё менее значимыми. Вместо этого я провёл небольшой эксперимент, чтобы показать, как эволюционировала производительность на моём любимом объекте для испытаний — hyperqueue. Я взял его первый коммит (за март 2021 года) и скомпилировал его несколькими версиями компилятора Rust с шагом между ними примерно в год. [Я выбрал старый коммит, чтобы его можно было скомпилировать даже старыми версиями rustc. К счастью, у меня скачаны все стабильные версии компилятора из моего недавнего эксперимента с ошибками компилятора.] Испытания проводились на относительно среднем ноутбуке с 8 ядрами AMD и Linux. Вот результаты:

В этом бенчмарке компилятор почти в три раза быстрее, чем три года назад. Разумеется, это единственный пример данных, в других случаях коэффициент увеличения скорости будет выше или ниже; вероятно, он также будет ниже в целом на всех платформах, кроме Linux x64, потому что основные усилия мы прикладываем к оптимизации под эту конкретную платформу. Но надо признать, что производительность компилятора стабильно повышается.

Но это всё равно недостаточно быстро

Всё это, конечно, здорово, но это не отменяет того факта, что для многих разработчиков на Rust производительность компиляции по-прежнему остаётся серьёзным узким местом; они были гораздо продуктивнее, если бы цикл обратной связи стал на порядок величин быстрее. Честно говоря, это зависит от того, чьё мнение вы узнаёте: например, некоторые разработчики на C++ не имеют претензий к времени компиляции Rust, потому что они привыкли к таким же (а то и более долгим) срокам компиляции; программисты же на Python, вероятно, не впечатлены скоростью цикла обратной связи Rust. Но можно почти наверняка сказать, что многим пользователям скорость компиляции Rust сегодня кажется недостаточно высокой, и это представляет собой проблему.

Прежде, чем мы приступим к более подробному изучению проблемы, думаю, стоит поразмыслить о том, решаема ли она фундаментально, и о том, какую же цель мы в конечном итоге хотим достичь. Может ли Rust с его сложной системой типов, borrow checking, мономорфизацией, макросами proc и скриптами сборки, большими модулями трансляции, генерацией машинного кода и моделью компиляции «воссоздаём мир из исходников» вообще надеяться достичь почти мгновенного времени (пере-)сборки? Ведь в прошлом почти при каждой возможности он отдавал предпочтение производительности в среде выполнения (а не компиляции)?

Думаю, это зависит от сценария использования. Если мы говорим о сборке с нуля проектов с сотнями зависимостей или о создании сверхоптимизированных LTO сборок, то, мне кажется, мы никогда не достигнем по-настоящему мгновенной скорости. С другой стороны, лично я считаю (хотя кто-то может со мной не согласиться!), что не существует каких-то фундаментальных ограничений для того, чтобы компилятор Rust не мог бы почти мгновенно пересобирать проект на Rust почти любого размера в инкрементном (и хотя бы немного оптимизированном) режиме после внесения небольших изменений в исходный код, где время пересборки — это O(количество внесённых изменений), а не O(размер кодовой базы). Вероятно, можно пойти на компромиссы, например, в ущерб производительности во время выполнения, но я считаю, что эта цель достижима. На самом деле, у нас даже сегодня есть примеры достижения чего-то подобного (пока в довольно ограниченных сценариях)!

И не скажу, что у нас нет мыслей, как достичь этой цели (или хотя бы приблизиться к ней). Существует множество подходов для ускорения различными способами процесса компиляции, например, параллельный фронтенд, альтернативные бэкенды генерации кода, использование по умолчанию более быстрого компоновщика, отложенная генерация (rlib только для MIR, -Zhint-mostly-unused), избегания бесполезных пересборок рабочего пространства, более умная инкрементная компиляция (в том числе инкрементная компоновка или даже горячий патчинг двоичных файлов), а также многое другое.

Некоторые из таких подходов пока не готовы для широкого использования, но другие можно применять уже сегодня. Обычно они помогают (но не всегда). Я считаю, что если бы у нас была волшебная палочка, и мы могли бы реализовать все эти изменения уже сегодня, то в большой доле (гораздо большей, чем сегодня) проектов на Rust мы бы добились очень быстрых инкрементных пересборок.

И от этого выиграет не «только» сообщество Rust в целом. Повышение производительности сборок увеличит продуктивность и контрибьюторов в тулчейн Rust. Оно снижает время, необходимое для пересборки самого компилятора при внесении в него изменений, а также ускоряет наши процессы CI, уменьшает время ожидания тестов и бенчмарков производительности компилятора… От этого выиграют все! Так что же нам мешает двигаться к этому быстрее? Почему мы ничего с этим не делаем?! [Простите, не смог сдержаться.]

Так почему же мы не делаем больше?

Это сложный вопрос, не имеющий однозначного ответа. Исходя из личного опыта работы с Rust Project, я попробую привести различные причины (в произвольном порядке) того, почему мы не движемся быстрее.

Технические причины

Начнём с технических причин, понять которые проще всего. Внесение нетривиальных улучшений производительности компилятора Rust — это сложная задача! Он имеет большую кодовую базу с приличной долей технического долга риска, как, вероятно, и другие крупные кодовые базы (компиляторов), и хотя у нас есть руководство по контрибьютингу в неё, для анализа происходящего всё равно требуется время. [Компилятор состоит примерно из шестисот тысяч строк кода на Rust, а стандартная библиотека имеет схожий размер.] На самом деле, вероятно, нет ни одного человека, полностью понимающего кодовую базу компилятора (возможно, за исключением compiler-errors).

Хоть вносить улучшения производительности без глубокого понимания работы компилятора возможно (при помощи профилирования и микрооптимизаций различных его частей), такой подход имеет свои ограничения, а самые простые решения уже реализованы. [Однако, не все из них. Посмотрите недавний гениальный PR.] В различных бенчмарках и сценариях использования было многое оптимизировано для достижения «локального минимума производительности», поэтому даже при внесении улучшений в некоторых сценариях использования происходит регрессия где-то ещё, что может приводить к отказу от применения локализованного улучшения.

Принимая решение о внедрении определённых оптимизаций производительности, нам также необходимо учитывать различные компромиссы. Например, мы знаем трюки, способные немного ускорить компилятор в Linux x64 (самой популярной целевой платформе). Мы можем компилировать rustc с поддержкой «новых» архитектур команд, например, AVX256, что, похоже, обеспечивает некоторые преимущества. Однако из-за этого компилятор перестанет работать на старых CPU x64, которые мы по-прежнему официально поддерживаем! Или можно было бы использовать другой распределитель памяти (например, mimalloc), что, кажется, тоже обеспечивает умеренный рост производительности, но ценой увеличения объёма используемой памяти, что может привести к OOM rustc в устройствах с небольшим объёмом ОЗУ. Возможно, вы думаете: почему бы не выпускать несколько разных версий компилятора (для одной целевой платформы) с разными оптимизациями, позволив разработчикам (или rustup) выбирать подходящий? Сборка самого оптимизированного варианта компилятора для Linux и так уже требует огромную кучу ресурсов CI, не говоря уже о том, что распространение тулчейна в нескольких вариантах существенно увеличит объём данных, передаваемых пользователям по сети, а он и так уже огромный. Нужно везде учитывать плюсы и минусы.

Я считаю, что для достижения поистине существенного роста производительности сборок есть два основных пути. Первый, который я считаю очень перспективным — это совершенствование некоторых процессов компиляции. Нам необязательно ускорять весь компилятор, если мы сможем существенно повысить производительность (или снизить объём необходимого труда) специфичных процессов, которые в данный момент существенно ограничивает продуктивность большой доли разработчиков на Rust. Пример этого — предложение Relink, don’t rebuild, потенциально способное снизить объём компиляции, который необходимо выполнять при изменении крейта в большом рабочем пространстве Cargo. Подобные решения необязательно ускорят сам компилятор, но сделают более умным процесс компиляции; а в этой сфере rustc можно существенно улучшить. Многие из этих потенциальных улучшений процессов не всегда связаны строго с самим компилятором, но и могут находиться на пересечении rustc и используемой системы сборки (чаще всего это Cargo).

Я надеюсь, что некоторые из этих идей в скором будущем существенно ускорят процессы компиляции Rust, не требуя при этом крупных изменений в реализации компилятора. Тем не менее, даже такие целевые оптимизации внедрить не так просто. Достижение впечатляющей производительности для proof-of-concept — это самое «простое». Но за этим следует длинный хвост очень сложной работы — обеспечение поддержки изменения всеми пограничными случаями и особенностями процесса компиляции Rust, работы на всех целевых платформах, отсутствия регрессии важных сценариев использования и бенчмарков, простоты поддержки, обратной совместимости и так далее.

Второй путь, как вы могли догадаться — это… внесение существенных изменений и/или рефакторинга в реализации компилятора. Однако это, разумеется, сложная по множеству причин задача. Для начала нам нужно согласовать общий настрой с остальными участниками команды разработки компилятора при помощи Major Change Proposal, чтобы другие мейнтейнеры компилятора приняли столь важное изменение. Затем, очевидно, нужно внести эти изменения, что потребует много усилий. Например, если мы изменим один элемент в «нижнем» слое компилятора, то придётся исправлять сотни разных мест, а также, потенциально, и множество тестовых случаев, а это очень длительный процесс. [Если вы задались вопросом «почему этим не может заняться ИИ?», то отвечу, что он, вероятно, мог бы помочь со многими вещами в этой области, но различия в диагностике компиляторов (которая остаётся большой частью того, что проверяет наш набор тестов) часто сводятся к субъективным решениям, которые мы (к счастью) по-прежнему оставляем принимать людям.] Также придётся найти ревьюера, обладающего достаточными ресурсами для принятия изменений, и этот процесс может растянуться на множество PR и недель, месяцев или даже лет.

Внесение крупных сквозных изменений — это тоже непростой процесс, потому что он обязательно будет конфликтовать со множеством других изменений, параллельно вносимых в компилятор. Можно попробовать внести изменений вне основного дерева компилятора, но это почти наверняка обречено на провал, учитывая скорость изменения компилятора. [В среднем мы каждый день мерджим примерно 25-30 PR.] Или же можно попробовать внедрить изменения в одном огромном PR, что может привести к бесконечным rebase (и усложнит поиск ревьюера). Или же придётся выполнять миграцию инкрементно, для чего может потребоваться длительная (и, возможно, утомительная) поддержка двух отдельных реализаций одного и того же аспекта.

Примером большого внутреннего изменения (хотя и не связанного с производительностью напрямую) может служить повторная реализация солвера трейтов компилятора. Хоть над ним работают очень умные и опытные люди, для завершения этого процесса потребовалось множество лет. Именно с подобным масштабом придётся иметь дело, если мы захотим выполнить подобный крупный рефакторинг внутреннего устройства компилятора. Об этом стоит помнить людям, спрашивающих, когда мы наконец перепишем весь компилятор в парадигме Data-oriented Design, чтобы он стал в миллиард раз быстрее.

Кстати, о DOD: стоит также учитывать удобство поддержки кодовой базы компилятора. Представьте, что мы опять взмахнули волшебной палочкой и за ночь переписали всё за ночь с использованием DOD, SIMD-векторизации, вручную развёртываемого ассемблера и так далее. Вероятно, компилятор стал бы в разы быстрее. Ура! Однако нас волнует не только непосредственная производительность, но и её улучшения на дальнюю перспективу. Если бы мы улучшили производительности при помощи кода, который сложно развивать, понимать, отлаживать и поддерживать, то это оказало бы нам плохую услугу. Над компилятором работают сотни добровольцев, поэтому мы хотим, чтобы кодовая база оставалась понятной для них (хотя бы частично). Поэтому стоит учитывать и удобство поддержки кодовой базы в долговременной перспективе.

Описанные выше сложности вполне реальны, но, разумеется, не совсем уникальны для rustc. Наверно, никого не удивляет то, что внесение крупных изменений в большую кодовую базу (компилятора) — сложный процесс. Я уверен, что у мейнтейнеров GCC/LLVM/Clang тоже есть множество идей по улучшению или ускорению этих проектов, но для их реализации потребуется множество усилий и времени. Но есть и другие причины того, что для нас важна не только производительность компилятора.

Приоритеты

Хотя многие пользователи Rust, похоже, хотят, чтобы производительность компилятора была основным приоритетом Rust Project, нам не стоит забывать и о других аспектах.

Компилятор Rust очень стабилен и надёжен (по крайней мере, на мой взгляд), и можно рассчитывать, что новые версии будут выпускаться раз в полгода. А это не так уж просто! И не надо воспринимать это, как нечто само собой разумеющееся. Для этого нельзя просто начать с работающего состояния и ничего не делать. Очень много времени требуется для обеспечения стабильности, работы инфраструктуры и CI, своевременного устранения особо серьёзных багов, рассмотрения входящих issue, поддержки обратной совместимости, проверки PR, быстрого устранения проблем безопасности, обеспечения актуальности внешних зависимостей, например, LLVM и ещё многого другого. И всё это должно работать со всеми поддерживаемыми целевыми платформами! На данный момент есть 8 самых важных платформ (для которых должны выполняться сборка и прохождение всех тестов) и 91 (!) платформа второго уровня (для которых должна хотя бы происходить сборка). По большей мере эту работу выполняют добровольцы, которым очень важен Rust и его тулчейн и которые хотят продолжать обеспечивать его работоспособность. Для этого в Rust нужна куча работы. [Я люблю говорить, что если дать нам сотню работающих на полную ставку инженеров, то я мгновенно найду, чем им заняться в тулчейне Rust.]

И вся эта работа, разумеется, отъедает время, которое, например, можно было потратить на ускорение компилятора. Если вы не считаете, что эта работа так уж важна, задайтесь вопросом, понравится ли вам вдвое более быстрый компилятор, который время от времени компилирует код неправильно.

Стоит также учитывать, что в языке и компиляторе постоянно появляются новые фичи: новые флаги компилятора для поддержки проектов наподобие Rust for Linux, синтаксические улучшения, сложные фичи языка и многое другое. В целом, язык далеко ещё не «завершён», поэтому многие его аспекты по-прежнему находятся в процессе развития; есть почти двести открытых пул-реквестов RFC и принимается множество других RFC, которые пока не были реализованы и стабилизированы. В любой момент времени у нас открыто порядка семисот открытых PR в основном репозитории Rust, ещё более десяти тысяч открытых issue, поэтому активность высока.

И похоже, пользователи Rust хотят, чтобы он эволюционировал с той же скоростью или даже быстрее, а значит, предстоит ещё больше изменений! У вас ведь возникала когда-нибудь мысль «мне хочется, чтобы эта мелкая фича X наконец-то стабилизировалась», чтобы ваш код был лучше? Абсолютно нормально хотеть от языка новых фич, но мы не должны забывать, что для этого требуется много экспериментов, устранений ошибок, тестирования и труда по реализации, что тоже отнимает время у оптимизации производительности. Не говоря уже о том, что добавление новых фич обычно слегка снижает производительность компилятора, потому что ему приходится выполнять больше работы.

Контрибьюторы

В конечном итоге, объём усилий, который тратится на оптимизацию производительности компилятора, зависит от контрибьютеров и мейнтейнеров. Часто они работают в качестве добровольцев и имеют разнообразные интересы. Некоторых контрибьюторов вообще не интересуют оптимизации производительности. И это абсолютно нормально! Стоит помнить, что Rust — это не компания (это отличный пост Мары Бос, рекомендую его прочитать!). Мы не приказываем людям, над чем они должны работать, и не назначаем им таски или тикеты. Если не будет людей, заинтересованных в ускорении работы компилятора, то, вероятно, над этим и не будет никто работать. Всё просто.

Тем не менее, есть определённые способы, позволяющие обеспечить условия для работы над производительностью компилятора. У Rust Project теперь есть программа Project Goals, определяющая набор целей и проектов, которые мы считаем важными. И мы приветствуем контрибьюторов (обещая им обеспечить ревью и поддержку) в этих областях. В ближайшем будущем я постараюсь сделать производительность компилятора одной из главных целей, потому что считаю, что она того заслуживает. Вероятно, это поможет мотивировать больше людей работать над ней.

И хотя это может прозвучать немного банально, но ускорение прогресса — это вопрос финансирования (хотя бы частично). Иногда я слышу жалобы на то, что некоторые проекты, нацеленные на повышение производительности компиляции, требуют слишком много времени для реализации. Они как будто ожидают, что над этими проектами работает укомплектованная команда хорошо оплачиваемых инженеров. Не стоит забывать, что Rust Project по-прежнему по большей мере состоит из добровольцев и что многие люди делают вклад в него в своё свободное время. Многие улучшения (в том числе и важные проекты по повышению производительности компилятора) Rust в буквальном смысле стали возможными благодаря единственному студенту вуза, ежедневно безустанно работавшему над совершенствованием Rust, часто без малейшей оплаты. Его прогресс может замедляться (например) потому, что ему нужно сдать экзамены или трудиться на оплачиваемой работе, позволяющей оплачивать жильё и еду.

На недавней конференции RustWeek и связанном с ней мероприятии All Hands я увидел нарастающий интерес со стороны различных компаний, желающих вложить средства в повышение производительности компилятора Rust. И это замечательно! Для улучшения производительности rustc требуются долгие сосредоточенные усилия, и предоставление стабильного финансирования контрибьюторам — это один из способов ускорения прогресса. Однако важно понимать, что внесение улучшений — это не только работа над реализацией: кто-то должен проверять её и поддерживать в будущем. В идеальном мире компании финансировали бы длительную работу по поддержке компилятора, а не платили бы своим сотрудникам за то, чтобы те реализовали нужную им оптимизацию, после чего пропадали. Иногда лучший способ помочь развиваться какой-то области Rust — не реализовывать её, а накапливать знания, становиться специалистом в какой-то сфере компилятора и помогать проверять код других, чтобы освободить других людей и позволить им выполнять свою работу. Но, разумеется, для этого требуются длительные вложения.

Судя по моему опыту, интерес среди контрибьюторов в компилятор Rust к работе над производительностью компилятора плохо соотносится с объёмом обсуждений этой темы онлайн (и это тоже совершенно нормально!). Если бы я снова воспользовался волшебной палочкой и смог убедить интересоваться этим большее количество контрибьюторов, то сделал бы я это? Вероятно, да. Пошло ли бы это на пользу Rust в долговременной перспективе? Я не знаю! Пока похоже, что разработка языка и компилятора идёт хорошо, да и кто я такой, чтобы определять приоритеты. Я доверяю участникам проекта и верю, что коллективно они делают то, что лучше всего для Rust, и сегодня, и в будущем.

Мне кажется интересным то, что, вероятно, многие люди занимались бы улучшением производительности, если бы им не приходилось выполнять слишком много работы одновременно. Пример: когда я начал контрибьютить в Rust в 2021 году, меня в первую очередь интересовала производительность компилятора. Поэтому я занялся оптимизацией. Потом я заметил, что полезно будет поработать над набором бенчмарков компилятора, поэтому занялся им. Далее я заметил, что мы компилируем сам компилятор не со всеми возможными оптимизациями, поэтому приступил к добавлению поддержки LTO/PGO/BOLT, что в дальнейшем привело к совершенствованию инфраструктуры CI. Потом я обратил внимание, что мы долго ждём завершения процессов CI, и занялся их оптимизацией. Затем я занялся проведением ежегодного опроса Rust, затем программой GSoC, затем улучшением bors, затем… Многие из этих трудов косвенно повлияли на производительность компилятора (во всяком случае, я на это надеюсь), или сняв нагрузку с других контрибьюторов, или улучшив инфраструктуру (в разных смыслах этого слова). Однако только сейчас, спустя несколько лет постоянного отхождения от своей основной цели, я наконец пытаюсь вернуться к непосредственной работе над производительностью компилятора.

Иными словами, чем больше помощи мы сможем получить в мейнтейнинге Rust (вне зависимости от конкретной области!), тем выше вероятность, что у нас совместно будет больше времени на повышение производительности компилятора.

Заключение

Забавно, что после написания этого поста я осознал, что можно заменить словосочетание «производительность компилятора» почти чем угодно, чего люди хотят от Rust («почему в Rust нет X»), и многие мои аргументы останутся актуальными. В этом смысле производительность компилятора — это не что-то особенное, а лишь один из множества аспектов (очень важных!), которые нам важны и которые мы максимально стремимся улучшить.

Что касается будущих работ по повышению производительности компилятора, я надеюсь на различные инициативы, обсуждавшиеся на мероприятиях All Hands, а также на то, что LLD станет компоновщиком по умолчанию в Linux (надеюсь, это произойдёт в ближайшие месяцы). Также я планирую вскоре провести опрос о производительности компилятора, чтобы понять, какие процессы становятся узкими местами для пользователей Rust, и хочу совершенствовать инфраструктуру профилирования того, чем же на самом деле занимается компилятор в процессе компиляции.

Надеюсь, благодаря этому посту вы поймёте, почему прогресс в производительности сборок — это не такая простая задача. Если вы захотите присоединиться к команде, то рад буду вас видеть!

1. I used an old commit so that it can be compiled even with old(er) versions of rustc. ↩

2. Luckily, I still had all the stable compiler versions downloaded from my recent compiler errors experiment 

    ↩

3. Sorry, couldn’t resist. ↩

4. At least for some definition of large. The compiler consists of ~600k lines of Rust code, and the standard library has a similar size. ↩

5. Not all of it though. Check out this recent gem of a PR. ↩

6. I recently saw someone call this vibeck (named after the abbreviated terms typeck and borrowck used in the compiler), which I find super cute. ↩

7. If you are thinking “why can’t AI do this?”, it probably could help with a lot of things in this area, but especially differences in compiler diagnostics (which is a large part of what our test suite checks) often come down to judgement calls that we still (luckily) leave to humans. ↩

8. On average, we merge around 25-30 PRs each day. ↩

9. I like to say that if you gave me a hundred full-time engineers, I would find all of them something to work on in the Rust toolchain immediately. ↩