Buildcache: различия между версиями

Материал из ALT Linux Wiki
Нет описания правки
Нет описания правки
Строка 4: Строка 4:
Начиная с версии пакета gcc-common >= 1.4.27-alt1, воспользоваться buildcache'ом можно установив
Начиная с версии пакета gcc-common >= 1.4.27-alt1, воспользоваться buildcache'ом можно установив
переменную окружения GCC_USE_BUILDCACHE=1:
переменную окружения GCC_USE_BUILDCACHE=1:
<blockquote>$export GCC_USE_BUILDCACHE=1</blockquote>
<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''

Версия от 13:51, 8 декабря 2020

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