Buildcache: различия между версиями
Savin (обсуждение | вклад) Нет описания правки |
Savin (обсуждение | вклад) Нет описания правки |
||
(не показаны 3 промежуточные версии этого же участника) | |||
Строка 4: | Строка 4: | ||
Начиная с версии пакета gcc-common >= 1.4.27-alt1, воспользоваться buildcache'ом можно установив | Начиная с версии пакета gcc-common >= 1.4.27-alt1, воспользоваться buildcache'ом можно установив | ||
переменную окружения GCC_USE_BUILDCACHE=1: | переменную окружения GCC_USE_BUILDCACHE=1: | ||
< | <pre>$export GCC_USE_BUILDCACHE=1</pre> | ||
(для ccache аналогично: $export GCC_USE_CCACHE=1) | (для ccache аналогично: $export GCC_USE_CCACHE=1) | ||
Строка 168: | Строка 168: | ||
|- | |- | ||
|} | |} | ||
''Примечание. В настоящее время только серверная часть TI C6x поддерживает параметр cache_link_commands.'' | |||
Пример файла конфигурации: | |||
<pre> | |||
{ | |||
"max_cache_size": 10000000000, | |||
"prefix": "icecc", | |||
"remote": "redis://my-server:6379", | |||
"debug": 3, | |||
"lua_paths": [ | |||
"/home/myname/buildcache-lua", | |||
"/opt/buildcache-lua" | |||
], | |||
"compress": true | |||
} | |||
</pre> | |||
Чтобы увидеть действующие параметры конфигурации, выполните: | |||
<pre> | |||
$ buildcache --show-config | |||
</pre> | |||
===Отладка=== | |||
Чтобы получить отладочную информацию, установите для переменной BUILDCACHE_DEBUG значение нужного вам уровня отладки (по умолчанию вывод отладочной информации отключен): | |||
{| class="wikitable" | |||
|- | |||
! scope="col"| BUILDCACHE_DEBUG | |||
! scope="col"| Level | |||
! scope="col"| Комментарий | |||
|- | |||
| 1 | |||
| DEBUG | |||
| Максимум информации | |||
|- | |||
|- | |||
| 2 | |||
| INFO | |||
| | |||
|- | |||
|- | |||
| 3 | |||
| ERROR | |||
| | |||
|- | |||
|- | |||
| 4 | |||
| FATAL | |||
| | |||
|- | |||
|- | |||
| -1 | |||
| - | |||
| Отключить вывод отладочной информации | |||
|- | |||
|} | |||
Также можно перенаправить вывод лога в файл с помощью параметра BUILDCACHE_LOG_FILE. | |||
===Точность кеширования=== | |||
С помощью параметра BUILDCACHE_ACCURACY можно контролировать, насколько строгим является Buildcache при проверке попаданий в кеш. Это дает возможность менять точность на производительность. | |||
{| class="wikitable" | |||
|- | |||
! BUILDCACHE_ACCURACY | |||
! scope="col"| Комментарий | |||
|- | |||
|- | |||
| STRICT | |||
| Максимальная корректность | |||
|- | |||
|- | |||
| DEFAULT | |||
| Баланс между производительностью и точностью | |||
|- | |||
|- | |||
| SLOPPY | |||
| Оптимизация для максимального коэффициента попадания в кеш | |||
|- | |||
|} | |||
Режим точности по умолчанию - DEFAULT. | |||
====STRICT==== | |||
В режиме STRICT поиск в кэше будет учитывать абсолютные пути к файлам и номера строк всякий раз, когда генерируются отладочные символы или информация о покрытии. Это означает, что когда ваша сборка включает символы отладки или информацию о покрытии, вы получите промах в кеше, если изменился абсолютный путь к файлу или любой номер строки. | |||
Этот режим подходит, если вы собираетесь использовать финальный исполняемый файл для запуска тестов покрытия кода или для отладки. Обратной стороной является то, что вы часто можете получить промахи кеша, особенно в общем централизованном кэше, который содержит объекты с разных машин с разными путями сборки. | |||
====DEFAULT==== | |||
Режим DEFAULT аналогичен режиму STRICT, за исключением того, что он игнорирует информацию о пути к файлу и номере строки для отладочных сборок. | |||
Обратите внимание, что во многих ситуациях все еще можно использовать сгенерированные исполняемые файлы для отладки. Например, с помощью GDB вы можете указать собственный путь к исходному коду во время сеанса отладки. | |||
Двоичные файлы, созданные в этом режиме, можно использовать для генерации покрытия кода. | |||
====SLOPPY==== | |||
В режиме SLOPPY абсолютные пути к файлам и информация о номерах строк всегда игнорируются во время поиска в кэше, что улучшает коэффициент попадания в кэш. Обратной стороной является то, что вы не сможете использовать двоичные файлы для покрытия кода. | |||
===Формат сжатия кеша=== | |||
С помощью параметра BUILDCACHE_COMPRESS_FORMAT можно управлять тем, как сжимаются созданные кеши. | |||
''Примечание. Для использования этого параметра параметр «compress» должен иметь значение true.'' | |||
{| class="wikitable" | |||
|- | |||
! BUILDCACHE_COMPRESS_FORMAT | |||
! scope="col"| Комментарий | |||
|- | |||
|- | |||
| LZ4 | |||
| Более быстрое сжатие, больший размер кеша | |||
|- | |||
|- | |||
| ZSTD | |||
| Более медленное сжатие, меньший размер кеша | |||
|- | |||
|- | |||
| DEFAULT | |||
| LZ4 | |||
|- | |||
|} | |||
Формат сжатия по умолчанию - DEFAULT. | |||
===Уровень сжатия кеша=== | |||
Установив уровень сжатия кэша, BUILDCACHE_COMPRESS_LEVEL, можно контролировать усилия, прилагаемые архиватором, чтобы создавать файлы кэша меньшего размера. См. Документацию на выбранный вами архиватор для получения дополнительной информации. | |||
Уровень сжатия по умолчанию -1, что значит использование уровня сжатия по умолчанию для архиватора. | |||
''Примечание. Для использования этого параметра параметр «compress» должен иметь значение true.'' | |||
===BUILDCACHE_HASH_EXTRA_FILES=== | |||
При вычислении хэша единицы трансляции buildcache пытается учесть все факторы, влияющие на вывод. Сюда входят такие вещи, как командная строка или исходный код препроцессора. Но иногда существуют дополнительные факторы, о которых buildcache не знает. | |||
Например, компилятор Clang имеет возможность читать список исключений для -fsanitize-blacklist. Это влияет на вывод компиляции, но buildcache не знает об этом. При передаче имени файла в параметре конфигурации BUILDCACHE_HASH_EXTRA_FILES его содержимое будет добавлено в хэш единицы трансляции и учтено при поиске в кэше. | |||
Другой вариант использования - это управление версиями содержимого кеша. Используя приведенный выше пример, вы могли испортить свой кеш, поскольку забыли о the sanitizer exception list при первом запуске. Одним из решений было бы удалить весь кеш. Но в случае общего удаленного кеша это может повлиять на другие инструменты кэширования, и вы даже не сможете заблокировать удаленный кеш. Создание текстового файла с простым номером версии и добавление его к BUILDCACHE_HASH_EXTRA_FILES приведет к тому, что предыдущий вывод кэша будет отменен. | |||
''Перевод далёк от идеала. Особенно последний параграф. В случае необходимости обратитесь к первоисточнику: | |||
https://github.com/mbitsnbites/buildcache/blob/master/doc/configuration.md'' | |||
[[Категория:Руководства]] |
Текущая версия от 11:21, 20 апреля 2021
Buildcache
Это простой "ускоритель" компилятора, который кэширует и повторно использует результаты сборки, чтобы избежать ненужных повторных компиляций и тем самым ускорить процесс сборки. Начиная с версии пакета gcc-common >= 1.4.27-alt1, воспользоваться buildcache'ом можно установив переменную окружения GCC_USE_BUILDCACHE=1:
$export GCC_USE_BUILDCACHE=1
(для ccache аналогично: $export GCC_USE_CCACHE=1)
Конфигурация
BuildCache можно настроить с помощью переменных окружения и файла конфигурации JSON ($ HOME / .buildcache / config.json). Следующие параметры управляют поведением BuildCache:
Env | JSON | Описание | По умолчанию |
---|---|---|---|
BUILDCACHE_DIR | - | Корневая директория кэша | $HOME/.buildcache |
BUILDCACHE_PREFIX | prefix | Prefix command for cache misses | None |
BUILDCACHE_REMOTE | remote | Адрес удалённого кэш сервера (protocol://host:port/path, где протокол это redis или s3, а port и path опциональны) | None |
BUILDCACHE_ACCURACY | accuracy | Точность (см. Ниже) | DEFAULT |
BUILDCACHE_CACHE_LINK_COMMANDS | cache_link_commands | Enable caching of link commands | false |
BUILDCACHE_COMPRESS | compress | Разрешить использование сжатия при кешировании (отменяет жесткие ссылки) | false |
BUILDCACHE_COMPRESS_FORMAT | compress_format | Формат сжатия кеша (см. Ниже) | DEFAULT |
BUILDCACHE_COMPRESS_LEVEL | compress_level | Уровень сжатия кеша (см. Ниже) | -1 |
BUILDCACHE_DEBUG | debug | Уровень отладки | None |
BUILDCACHE_DISABLE | disable | Отключить кеширование (обходить Buildcache) | false |
BUILDCACHE_HARD_LINKS | hard_links | Разрешить использование жестких ссылок при кешировании | false |
BUILDCACHE_HASH_EXTRA_FILES | hash_extra_files | Дополнительные файлы, содержимое которых нужно добавить в хеш. | None |
BUILDCACHE_IMPERSONATE | impersonate | Explicitly set the executable to wrap | None |
BUILDCACHE_LOG_FILE | log_file | Путь к файлу журнала (пустой для стандартного вывода) | None |
BUILDCACHE_LUA_PATH | lua_paths | Extra path(s) to Lua wrappers | None |
BUILDCACHE_MAX_CACHE_SIZE | max_cache_size | Ограничение размера кеша в байтах | 5368709120 |
BUILDCACHE_MAX_LOCAL_ENTRY_SIZE | max_local_entry_size | Ограничение размера записи локального кэша в байтах (без сжатия) | 134217728 |
BUILDCACHE_MAX_REMOTE_ENTRY_SIZE | max_remote_entry_size | Ограничение размера записи удаленного кэша в байтах (без сжатия) | 134217728 |
BUILDCACHE_PERF | perf | Enable performance logging | false |
BUILDCACHE_READ_ONLY | read_only | Только читать и использовать кеш, не обновляя его | false |
BUILDCACHE_READ_ONLY_REMOTE | read_only_remote | Только чтение и использование удаленного кеша без его обновления (подразумевается BUILDCACHE_READ_ONLY) | false |
BUILDCACHE_REMOTE_LOCKS | remote_locks | Использовать (потенциально более медленный) механизм блокировки файлов, который безопасен, если локальный кеш находится на общей папке. | false |
BUILDCACHE_S3_ACCESS | s3_access | S3 access key | None |
BUILDCACHE_S3_SECRET | s3_secret | S3 secret key | None |
BUILDCACHE_TERMINATE_ON_MISS | terminate_on_miss | Прекратить сборку, если запись в кеше не найдена | false |
Примечание. В настоящее время только серверная часть TI C6x поддерживает параметр cache_link_commands.
Пример файла конфигурации:
{ "max_cache_size": 10000000000, "prefix": "icecc", "remote": "redis://my-server:6379", "debug": 3, "lua_paths": [ "/home/myname/buildcache-lua", "/opt/buildcache-lua" ], "compress": true }
Чтобы увидеть действующие параметры конфигурации, выполните:
$ buildcache --show-config
Отладка
Чтобы получить отладочную информацию, установите для переменной BUILDCACHE_DEBUG значение нужного вам уровня отладки (по умолчанию вывод отладочной информации отключен):
BUILDCACHE_DEBUG | Level | Комментарий |
---|---|---|
1 | DEBUG | Максимум информации |
2 | INFO | |
3 | ERROR | |
4 | FATAL | |
-1 | - | Отключить вывод отладочной информации |
Также можно перенаправить вывод лога в файл с помощью параметра BUILDCACHE_LOG_FILE.
Точность кеширования
С помощью параметра BUILDCACHE_ACCURACY можно контролировать, насколько строгим является Buildcache при проверке попаданий в кеш. Это дает возможность менять точность на производительность.
BUILDCACHE_ACCURACY | Комментарий |
---|---|
STRICT | Максимальная корректность |
DEFAULT | Баланс между производительностью и точностью |
SLOPPY | Оптимизация для максимального коэффициента попадания в кеш |
Режим точности по умолчанию - DEFAULT.
STRICT
В режиме STRICT поиск в кэше будет учитывать абсолютные пути к файлам и номера строк всякий раз, когда генерируются отладочные символы или информация о покрытии. Это означает, что когда ваша сборка включает символы отладки или информацию о покрытии, вы получите промах в кеше, если изменился абсолютный путь к файлу или любой номер строки. Этот режим подходит, если вы собираетесь использовать финальный исполняемый файл для запуска тестов покрытия кода или для отладки. Обратной стороной является то, что вы часто можете получить промахи кеша, особенно в общем централизованном кэше, который содержит объекты с разных машин с разными путями сборки.
DEFAULT
Режим DEFAULT аналогичен режиму STRICT, за исключением того, что он игнорирует информацию о пути к файлу и номере строки для отладочных сборок. Обратите внимание, что во многих ситуациях все еще можно использовать сгенерированные исполняемые файлы для отладки. Например, с помощью GDB вы можете указать собственный путь к исходному коду во время сеанса отладки. Двоичные файлы, созданные в этом режиме, можно использовать для генерации покрытия кода.
SLOPPY
В режиме SLOPPY абсолютные пути к файлам и информация о номерах строк всегда игнорируются во время поиска в кэше, что улучшает коэффициент попадания в кэш. Обратной стороной является то, что вы не сможете использовать двоичные файлы для покрытия кода.
Формат сжатия кеша
С помощью параметра BUILDCACHE_COMPRESS_FORMAT можно управлять тем, как сжимаются созданные кеши. Примечание. Для использования этого параметра параметр «compress» должен иметь значение true.
BUILDCACHE_COMPRESS_FORMAT | Комментарий |
---|---|
LZ4 | Более быстрое сжатие, больший размер кеша |
ZSTD | Более медленное сжатие, меньший размер кеша |
DEFAULT | LZ4 |
Формат сжатия по умолчанию - DEFAULT.
Уровень сжатия кеша
Установив уровень сжатия кэша, BUILDCACHE_COMPRESS_LEVEL, можно контролировать усилия, прилагаемые архиватором, чтобы создавать файлы кэша меньшего размера. См. Документацию на выбранный вами архиватор для получения дополнительной информации. Уровень сжатия по умолчанию -1, что значит использование уровня сжатия по умолчанию для архиватора. Примечание. Для использования этого параметра параметр «compress» должен иметь значение true.
BUILDCACHE_HASH_EXTRA_FILES
При вычислении хэша единицы трансляции buildcache пытается учесть все факторы, влияющие на вывод. Сюда входят такие вещи, как командная строка или исходный код препроцессора. Но иногда существуют дополнительные факторы, о которых buildcache не знает. Например, компилятор Clang имеет возможность читать список исключений для -fsanitize-blacklist. Это влияет на вывод компиляции, но buildcache не знает об этом. При передаче имени файла в параметре конфигурации BUILDCACHE_HASH_EXTRA_FILES его содержимое будет добавлено в хэш единицы трансляции и учтено при поиске в кэше. Другой вариант использования - это управление версиями содержимого кеша. Используя приведенный выше пример, вы могли испортить свой кеш, поскольку забыли о the sanitizer exception list при первом запуске. Одним из решений было бы удалить весь кеш. Но в случае общего удаленного кеша это может повлиять на другие инструменты кэширования, и вы даже не сможете заблокировать удаленный кеш. Создание текстового файла с простым номером версии и добавление его к BUILDCACHE_HASH_EXTRA_FILES приведет к тому, что предыдущий вывод кэша будет отменен.
Перевод далёк от идеала. Особенно последний параграф. В случае необходимости обратитесь к первоисточнику: https://github.com/mbitsnbites/buildcache/blob/master/doc/configuration.md