использование ccache
t17fenics 13 октября, 2008 - 01:29
Подскажите
Использует ли ccache при работе результаты предудущих компиляций, лежащих в /var/tmp/portage?
или тока свой кеш /var/tmp/ccache, а портежный кеш можно спокойно удалять?
»
- Для комментирования войдите или зарегистрируйтесь
всё, что в
всё, что в /var/tmp/portage, должно удаляться после компиляции
это не на мой
это не на мой вопрос ответ!
ccache использует
ccache использует только свой кэш, а /var/tmp/portage это не кэш а working directory, фаилы в ней остаются только если компиляция завершилась с ошибкой
точняк,
точняк, лоханулся, думал, что результаты компиляции там остаются после работы, как то не заглядывал ))
спасибо!
рановато
рановато закрыл темку )
еще вопросик возник
когда заплняется кеш ccache происходит какая то ротация?
какие именно данные сливаются в первую очередь?
Простенькая
Простенькая статистика попаданий и дата записи в кэш. Удаляется старье с наименьшим количеством попаданий. Делает само. Тюнингу не подлежит, насколько помню.
получу ли я
получу ли я прирост производительности, смонтировав кеш ccache в /dev/shm
и настроить, чтоб автоматом при выключении кеш из памяти сохранялся образом на диск, а при загрузке так же автоматом закачивался обратно в память )
интересует как опция на время поднятия новой системы, когда память не шибко используется(нагрузки то никакой, кроме компиляций), а вот компиляцию хотелось бы еще ускорить )
Откуда ж
Откуда ж прирост от ccache при первой компиляции?
Пожалуйста, не описывайте своё железо в подписи
ну можно опять
ну можно опять же использовать его при плановых обновлениях
залил в память, попользовался, опять на диск слил...
ccache не поможет
ccache не поможет при _обновлении_
он помогает при перекомпиляции
>>получу ли я
>>получу ли я прирост производительности, смонтировав кеш ccache в /dev/shm
Нет. Более менее эффективный кэш порядка двух трех гигов. Система будет использовать это более эффективно.и настроить, чтоб автоматом при
>>выключении кеш из памяти сохранялся образом на диск, а при загрузке так же автоматом закачивался обратно в память )
Тоесть при каждом запуске компилятора вы хотите загонять два гига в озу, а затем после компиляции записывать два гига с озу на диск? Не думаю, что это хорошая идея. Ибо при сборке среднего пакета компилятор запускается раз сто.
Как уже сказали выше ccache не ускоряет сборку. Он ускоряет пересборку. Тоесть ежели пакет должен быть пересобран то cchacе поможет. Сборку можно ускорить ежели в сети несколько линуксбоксов и развернут distcc
Установку новой системы можно ускорить, подготовив бинари. Ибо нефиг перекомпилировать компилированное. емерге вам в помощь опции -b и -k. Самый быстрый способ установки - растарить готовый корень на диск. Для поддержки бинарных сборок в gentoo существует catalyst.
Я для ускорения
Я для ускорения компиляции, кроме ccache, настроил PORTAGE_TMPDIR="/tmp" и, соответственно, в /etc/fstab добавил строку
tmpfs /tmp tmpfs size=2000m,mode=1777 0 0Ради интереса
Ради интереса проверял сборку пакета (5-6 минут собирался) разницы не отметил, иногда чуть больше, иногда чуть меньше
на вики вроде даже скрипт был temerge :) автоматом делающий это для сборки пакета.
Может быть для больших по размеру эффект есть, не знаю.
А я не проверял,
А я не проверял, так поверил :)
Обращение к оперативной памяти не должно быть медленнее обращения к диску, IMHO.
Насколько я
Насколько я понял, программа в любом случае собирается в памяти, а не на жестком диске, если есть место, конечно.
Я делал
Я делал двухгиговый tmpfs раздел для PORTAGE_TMPDIR, Прирост производительности на операциях ввода-вывода внутри PORTAGE_TMPDIR более чем значительный. Особенно процесс распаковки объёмистых тарболов с кучей файлов (openoffice, gentoo-sources, kde*)
Но понятное дело, какой-либо прирост отсутствовал на этапе configure и прочих процессах, требующих активного обращения к файлам вне PORTAGE_TMPDIR либо усиленно потребляющих процессорное время.
все это, и distcc и
все это, и distcc и tpmfs давно пользую.
Но хочется еще скорости! )
я не собирался загружать образ при каждом вызове компилятора, речь о плановых обновлениях. Загрузил по крону, отработал, сохранил снимок.
по поводу обновления и пересборок. А что, при обновлении пакета абсолютно каждый файл в этом пакете обновляеется?
неизмененные файлы я думаю все же могут браться из кеша... И наверное всетаки берутся )
Еще раз. ccache при
Еще раз. ccache при обновлении бесполезен, так как производимый объектный код будет совершенно другим! ccache создавался для других целей.
_______________________
From Siberia with Love!
ладно, тогда
ладно, тогда какой толк вообще от этого кеша, если он нафих не используется?
во время сборки обновленной программы компилируется не один файл, а много, иногда очень много
и ведь сто процентов не каждый из компилируемых файлов изменился
если нашли ошибку и поменяли 1 строчку кода в одном из 10000 файлов, неужели результат компиляции ВСЕХ ОСТАЛЬНЫХ 9999 файлов будет другим?
>>ладно, тогда
>>ладно, тогда какой толк вообще от этого кеша, если он нафих не используется?
Судя по описалову сскэш хранит объектник. Индексом служит хеш сурса. Берем сурс, хешируем его получаем число, по числу из кэша выдираем объектник. При этом без разницы какой пакет ты собираешь. Ежели для примера в пакете X и Y есть один и тот же идентичный файл, результат его компиляции выдирается с кэша. Чтоб не задавать кучу ненужных вопросов померяйте сборку какого нить мелкого пакета дважды ( с чистым кэшем и с заполненным). Если в портах есть 2 пакета разных версий очитите кеш, соберите старую, а затем новую версию и померяйте разницу.
ЗЫ
У меня сборкой занимаюццо через distcc пяток нехилых серваков. Со скоростью установки бинарного дистра гента не сравнится никогда. Ежели критична скорость установки дистр должен быть собран заранее.
никакой
никакой критичности нет, просто хочу выжать максимум )
значит я всетаки прав, и ccache при обновлениях столь же полезен, как и при пересборке!
я конечно проверю, так как вы рекомендовали, но думаю результит меня не удивит )
root@kms0042 /home/zerkms #
root@kms0042 /home/zerkms # genlop -t mc
* app-misc/mc
Wed Oct 15 09:04:09 2008 >>> app-misc/mc-4.6.1-r4
merge time: 1 minute and 22 seconds.
Wed Oct 15 09:05:19 2008 >>> app-misc/mc-4.6.1-r4
merge time: 58 seconds.
для меня разница во времени очевидна (первая сборка холодная. вторая тёплая)
Ну это-то
Ну это-то пересборка, а не обновление
Пожалуйста, не описывайте своё железо в подписи
а, пардон
а, пардон :-)
коммент, предшествующий моему, несколько невнимательно (см. неправильно) прочитал :-)