Сборка Chrome для Windows переведена на использование Clang
Как сообщает opennet.ru компания Google перешла на использование свободного компилятора Clang при формировании сборок браузера Chrome для платформы Windows, вместо ранее применявшегося компилятора Microsoft's Visual C++ (MSVC). Таким образом, начиная с Chrome 64 компилятор Clang теперь применяется для всех поддерживаемых платформ - macOS, iOS, Linux, Chrome OS, Android и Windows.
Из привлекательных сторон Clang для сборки Windows-приложений выделяется возможность сохранения совместимости с MSVC на уровне ABI, что позволяет собрать какую-то часть программы при помощи MSVC, а другую часть при помощи Clang и затем скомпоновать их в один исполняемый файл при помощи компоновщика MSVC или LLD. Что касается сборки Chrome, то данный процесс полностью не избавлен от зависимости от Visual Studio и даже после перехода на Clang продолжает использовать заголовочные файлы и библиотеки Microsoft, а также применяет некоторые утилиты из SDK, такие как midl.exe и mc.exe. Также сохранена возможность разработки и отладки кода Chrome в среде Visual Studio IDE.
В свое время перевод Linux-сборок Chrome на Clang в 2014 году позволил сократить размер исполняемого файла на 8% при сохранении производительности на том же уровне. Перевод Windows-сборок на Clang отразился в снижении размера установщика для 64-разрядных систем на 6.33%, но размер 32-разрядных сборок немного увеличился (на 0.04%). Например, итоговый размер mini_installer.exe для 64-разрядных систем при сборке при помощи Clang составил 46.27 MB, а при сборке в MSVC - 49.4 MB. При сборке в Clang размер chrome.dll уменьшился на 5.1%, а chrome.exe на 1.2%, но размер chrome_child.dll увеличился на 10.8%.
При включении оптимизаций на этапе генерации кода (LTCG) и учета данных профилирования (PGO), Clang генерировал код немного большего размера для 64-разрядных систем при установке режима оптимизации "/O2". При выборе режиме "/Os" наоборот, код Clang получался более компактным, чем MSVC. При этом результат сборки в Clang лучше поддавался сжатию LZMA. При измерении производительности код, собранный в Clang и MSVC, показал примерно одинаковые результаты. В отдельных тестах наблюдалось расхождение на уровне 5%, где-то выигрывал Clang, а где-то MSVC.
Так как режимы оптимизации LTCG и PGO использовались MSVC, но пока не используются при сборке релизов Chrome в Clang, имеется определенный задел для дальнейшего улучшения сборок на базе Clang. Различий в стабильности работы сборок в Clang и MSVC не выявлено. По времени локальной сборки Clang отстает от MSVC примерно на 15%, но сборка с отладочной информацией в распределенном сборочном сервисе Goma производится быстрее.
Проект перевода Windows-сборок Chrome на Clang начался в 2013 году и привел к существенному улучшению в Clang поддержки Windows. Ключевым мотивом перехода на Clang стало желание задействовать единый компилятор для всех поддерживаемых платформ и унифицировать сборочный инструментарий. Доводы в пользу единого компилятора:
- Использование при разработке Chrome многочисленных сопутствующих инструментов (ASan, CFI, ClusterFuzz), которые поддерживаются в Clang, но не сочетаются с MSVC;
- Возможность написания плагинов к Clang для добавления специфичных для кодовой базы Chromium проверок и предупреждений;
- Возможность применения инструментов Clang для рефакторинга кода;
- Включение в систему поиска по исходным текстам Chromium кода, специфичного для Windiows;
- Желание использовать открытый инструментарий для сборки открытого проекта Chromium;
- Унификация сборочного инструментария, Chrome поддерживает 6 платформ, но большинство разработчиков знакомы с 1-3 платформами, что может создавать проблемы с компиляцией патчей на незнакомых платформах и воспроизведением специфичных для иных сборочных инструментариев ошибок в своем окружении;
- Возможность использования специфичных для компилятора микро-оптимизаций для всех платформ;
- Упрощение кросс-компиляции - работая в Linux, можно работать с кодом, специфичным для Windows;
- Оперативное выявление проблем через обеспечение непрерывных сборок текущей экспериментальной ветки Chrome при помощи текущей экспериментельной ветки (trunk) Clang. Использование непрерывных сборок позволяет быстро переходить на новые версии компилятора, в то время как переход на новую версию MSVC занимал год или больше из-за длительного процесса выявления регрессий и согласования исправления выявленных в компиляторе ошибок;
- Трудность перехода на новые версии стандарта C++ при применении разных компиляторов;
- Возможность приоритетного развития определенных возможностей в компиляторе, не дожидаясь когда эти возможности будут готовы реализовать разработчики MSVC.
Плюсы использования Clang вместо Visual C++:
- Поддержка 64-разрядных ассемблерных inline-вставок в Clang, которые активно используется в коде библиотеки libyuv для оптимизации декодирования форматов видео;
- Возможность применения единого компилятора на разных платформах. Сборка разными компиляторами может способствовать выявлению дополнительных ошибок, но по мнению разработчиков Chrome средств диагностики Clang достаточно для выявления большинства проблем, а если появятся новые методы диагностики, то их можно перенести в Clang;
- Возможность использования Address Sanitizer для выявления проблем при работе с памятью;
- Clang может генерировать более быстрый код, если не используются оптимизации LTCG и PGO;
- Широкие средства диагностики в Clang с рекомендациями по устранению ошибок.
Минусы перевода проектов на Clang:
- Отсутствие в Clang поддержки расширений C++/CX и конструкции import "foo.dll";
- Наличие платной поддержки MSVC, в то время как патчи к Clang нужно писать самостоятельно или привлекать представителей из сообщества;
- В Clang отсутствуют некоторые расширенные возможности отладки, такие как "Edit & Continue".
