LINUX.ORG.RU

Открыт исходный код компилятора C++ Zapcc

 , , , ,


2

7

Zapcc — компилятор языка C++, основанный на наработках LLVM/Clang, данный компилятор отличается высокой скоростью компиляции из-за применения активного кеширования в различных этапах сборки программы. Данный компилятор может выступать в качестве замены gcc и clang, также он поддерживает интеграцию с любыми системами сборок. Исходный код был открыт под лицензией LLVM и располагается на GitHub.

Данный компилятор заметно ускоряет компиляцию C++, но для C это не настолько заметно, к примеру сборка Boost.Math производится в 10 раз быстрее чем у clang, сборка Webkit происходит в 2-4 раза быстрее, сборка Clang при помощи Zapcc выполняется в два раза быстрее, чем самим Clang.

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

Сборка Boost.Math

Сборка WebKit

Официальный сайт проекта

Репозиторий на GitHub

>>> Подробности

★★

Проверено: Shaman007 ()

Ответ на: комментарий от Dendy

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

Алсо, ты считаешь отсутствие прироста скорости в случае модификации pch.h в сравнении полная пересборка <-> частичная?

Если полная, то pch все равно выиграет (в хидере обычно всякие либы, которые используется более чем в одной единице трансляции).

Если частичная, то обновление либ происходит не так часто. А от какого-нибудь boost filesystem может зависеть пол проекта без всяких pch.

Kuzy ★★★ ()
Ответ на: комментарий от Kuzy

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

Это такие копейки, что даже говорить смешно.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Такое. Можно кинуть в tmpfs и проверить, но мне лень, а ты скорее всего прав. // на самом деле оно и так в ram будет всю сборку сидеть, скорее всего, тому шо линукс

Kuzy ★★★ ()
Последнее исправление: Kuzy (всего исправлений: 1)

Почитал комментарии здесь и в других местах, и большинство, похоже, не понимает, зачем всё это нужно.

Компиляция C++ тормозит, по сравнению с C, главным образом из-за инстанциации шаблонов. Если в коде шаблоны не используются, то и собирается он примерно с той же скоростью, что и код на C. Однако шаблоны замедляют всё адски. Компилятор можно попросить выдать статистику, какой этап занял сколько времени. Я всегда видел одно и то же - большинство времени уходит на шаблоны.

zapcc нужен, чтобы не проводить их инстанциацию каждый раз повторно. И, несмотря на то, что он ускоряет и холодную сборку (избегая повторной инстанциации одних и тех же шаблонов разными файлами), основной его ценностью мне видится ускорение типового цикла «поправил файл-посмотрел что получилось», за скорость которого так любят скриптовые языки типа питона. C++ традиционно проигрывал в этом из-за того, что пересборка даже одного файла могла занимать от двух-трех до десятка секунд, тогда как в скриптовых языках результат можно было лицезреть практически мгновенно.

Вот только что попробовал всё это на деле. Начальная сборка одного тестового файла на C++, который я взял для пробы, занимает 2 секунды. А повторная пересборка - всего лишь 0.3 секунды.

Никакие другие решения такого раньше не позволяли. PCH не инстанциируют шаблоны, ccache - и вовсе просто выдает ранее собранный файл из кэша, если входные данные идентичны. SSD, RAM-диски - всё это мимо кассы. Тормозит просто инстанциация, а она для каждого файла производится в памяти, одним процессором и в один поток. Единственное, что можно было делать раньше - это использовать extern template (ускоряло раза в два за счет того, что не генерировало код, но начальная часть инстанциации всё равно проводилась, и всё это вовлекало ненужную писанину), и покупать самый быстрый процессор на рынке. Так что выход zapcc - это важное событие для тех, кто пишет на C++. Для тех, кто просто собирает код, это событие гораздо меньшего масштаба, конечно - полную сборку всегда можно ускорить, увеличив её параллельность. Однако для одного собираемого файла это не работает, и тут zapcc и интересен.

ikm ★★ ()
Ответ на: комментарий от makoven

По сведениями агентства ОБС, последнее время упоротые линуксоиды плюсами отнюдь не брезгуют.

dimgel ★★★ ()
Ответ на: комментарий от gag

Вот так сюрприз сейчас. Но надолго ли...

А вот и интересная заметка в README.md:

### When was the source last merged with LLVM trunk?

This open-source release was last merged with LLVM r307021 on 2017-07-03.

Т.е. всё, уже как год код более не обновляли (около 28000 коммитов).

gag ★★★★★ ()
Ответ на: комментарий от ikm

А повторная пересборка - всего лишь 0.3 секунды.

Интересно, реально ли теперь покопаться в фаерфоксе с помощью этого zapcc. Перелинкует ли он за несколько секунд...

gag ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.