Работа ccache
aes78 6 марта, 2010 - 09:20
стоит ccache, в make.conf прописано
CC=gcc CXX=g++ CCACHE_SIZE="2G" FEATURES="ccache
однако при переустановке xulrunner было замечено, что никакого убыстрения не идет
в emerge --info
version 2.4 [enabled] dev-util/ccache: 2.4-r8 FEATURES="assume-digests ccache...
»
- Для комментирования войдите или зарегистрируйтесь
┌┌(ra@taaroa)┌(264/pts/2)┌(12
Ну, если вас не устраивает работа ccache, то просто не используйте.
P.S. а еще лучше просто внимательно прочитать|перечитать _как_ его настраивать и как оно работает.
а что может устраивать, если
а что может устраивать, если место занимается, а пользы никакой? У меня то же самое показывается, толку от этого только нет. Что я не так использую, что нужно перечитать?
Место?
При нонешних дисковых объёмах место, занимаемое ccache - капля пива
в кружке с водкой :D
Вот если Вы перенесёте /var и /ccache на другой физический диск, то в производительности
только выиграете.
Еще раз: taaroa
Еще раз:
Смотрим выше, повторяем как мантру: я осознаю то что я делаю, за все что я делаю, отвечаю только я.
taaroa, зачем писать ненужные
taaroa, зачем писать ненужные сообщения? Если нечего сказать, лучше промолчать. ccache должен ускорять обновление как заявлено в 5-10 раз, а он не ускоряет, мне не нужно никуда ничего переносить. Я согласен,что место небольшое, но зачем я буду его занимать, если программа не выполняет своего назначения?
aes78 написал(а): taaroa,
Это модераторам решать, что есть нужные сообщения, а что есть флэйм, хорошо?
Свою точку зрения озвучил выше.
Можно мне все таки самому решать, что и где писать и насколько оно полезно? Можно?
Ccache не поможет при _обновлении_, он помогает при перекомпиляции. Ccache вам ничего не должен, и вообще это _быстрый_кэш_компилятора_, такие дела. Ccache - это кэширующий препроцессор - для каждого файла вычисляется хэш, на основании которого в последствии можно определить уже скомпилированный файл, - это дает серьезный прирост в скорости на 2 и последующих сборках.
Ну если вы так считаете, то напишу еще раз: не используйте ccache.
Меня его работа устраивает.
Нельзя. Вы сами себе
Нельзя. Вы сами себе противоречите.
Зачем?
Давай те хоть я поблагодарю вас за развернутый верный ответ, но бисер вы мечете имхо совершенно напрасно?
Он не хочет знать про ccache, он все давно для себя решил, просто ему наверно поговорить не с кем :)
Вы знаете, как то так
Вы знаете, как то так получилось, что этот развернутый ответ я уже давно знаю, и я не его спрашивал. На форуме слишком много самоуверенных ничего из себя не представляющих людей, которые мало того, что ничего не знают сами, так еще и других поучать пытаются.
Тем не менее он прав. ccache
Тем не менее он прав.
ccache помогает далеко не всегда. Он может не быть задействованным даже при пересборке, а не обновлении пакета (мне кажется, это если обновились зависимости, например).
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
aes78 написал(а):Вы знаете,
А вот совсем не похоже на то. Я скажу даже больше - ccache на первой сборке пакета местами ощутимо её замедляет, бывает приводит к ошибкам сборки, и иногда приводит к смерти домашних животных. После проблем со сборкой icedtea я его удалил, хотя мне он помогал весьма сильно - я использую полторы сотни live-пакетов сборку которых он серьёзно ускорял, в 2-3 раза, к тому же я эти пакеты по статистике, в среднем раз в 3 дня — неделю пересобираю... Если же тебе действительно хочется что-то узнать, почитай http://blog.flameeyes.eu/2008/06/21/debuking-ccache-myths возможно перестанешь нести чушь.
Может тогда воспользоваться платной техподдержкой ? Или нанять грамотных специалистов для обучения? А то получается что люди пробуют помочь а их обзывают «тупыми упырями» и сетуют на то что «я всё и без вас знаю», в тоже время не можешь нормально сообщить об ошибке. Нехорошо.
Об ошибке нормально сообщено,
Об ошибке нормально сообщено, со всеми необходимыми приложениями.
aes78 написал(а): Об ошибке
Это твое личное мнение, никто тебя в этом не собирается переубеждать, пока сам не захочеш.
Почему-то мнение большинства отличное от твоего.
Я к примеру и ошибки то не увидел в твоем посте.
Так что думать-думать и думать прежде чем писать.
Мнение большинства всегда
Мнение большинства всегда ошибочно, поэтому я не увижу. Ошибки в моем посте нет, я спрашивал, почему ccache не действует так, как заявлено.
:)
Да откуда вы знаете что ccache не действует так как должно?
Я же говорю - это ваше личное субьективное мнение.
Где вы указали измерения времени сборки без ccache, затем с ним, но с его пустым кешем,
потом время сборки того же приложения повторно, и т.д.
Так что я повторю - ваш стартовый топик больше похож на мысли вслух, но ни как на
конкретное описание какой-то ошибки. И вопроса нет в стартовом посте.
Так, просто поговорить нескем было, вот и написали о ccashe.
Что такое ccache? ccache -
Что такое ccache? ccache - это быстрый кэш компилятора. Временные файлы, которые будут созданы во время компиляции программы будут закэшированы, в результате чего во время обновления установленного программного обеспечения, время , затраченное на компиляцию программного значительно cокращается.
Из handbook:
А то, что вопроса нет - это ясно видно из того, что приводится в первом посте и почитав форум я понял, что вопросы здесь не очень принято задавать, все идет к краткости. 5-10 раз для xulrunner не нужно замерять, это было бы видно невооруженным глазом.
aes78 написал(а): Что такое
И тут же вы приводите выдержку из handbook
Чем фактически подтверждаете - что абсолютно не поняли суть вопроса.
Невооруженный глаз - офигенный инструмент диагностики, не спорю. :)
Вот если бы вы показали настройки свои и время сборки того же xulrunner в различных режимах, как я указал в посте выше - тогда есть о чем говорить, а так
я подчеркиваю - ваш топик - разговор ни о чем, просто мысли вслух человека, который не разобрался в сути происходящего.
В общем я понял, что никто
В общем я понял, что никто ничего конкретного сказать не может, а разговоры о том, что я не вник в суть вопроса ни к чему, поскольку я в суть вопроса как раз таки вник. Мне ccache нужен только для того, чтобы время обновления программ сократить и ни для чего больше. xulrunner собирается около 2 часов, если он начнет даже собираться 1 час 30 минут - это мне ничего не даст. Мне не интересно сокращение на минуты. Мой топик был направлен на то, чтобы выяснить у людей, которые давно в генту - может быть у меня где-то в конфигах ошибки, может еще что-то нужно указать, может быть я работаю не в типичных, а в экстремальных условиях и т.д., но идут просто сплошные оскорбления.
Да всё было сказано сразу,
Да всё было сказано сразу, только не надо было считать себя самым умным и внимательно читать.
Это вот ускорение из-за ccache, познакомьтесь.
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
krigstask написал(а):Да всё
Это, конечно, интересно для ознакомления, но меня больше интересует почему у меня xulrunner после неоднократных пересборок не дал никакого ускорения.
Я себя не считаю самым умным, но вы путаете ум и разум, а это есть суть две разные вещи. Знание не порождает ум, но это ближе к философии. И что было сказано с самого начала? С самого начала было сказано, что если не нравится - не пользуйтесь. Я бы не пользовался, если бы я знал альтернативу по сокращению времени компиляции или если бы в бинарных дистрибутивах перестали насаждать policykit и pulseaudio.
2SysA:
http://gentoo.ru/philosophy
Aga, eto my uze proxodili, -
Aga, eto my uze proxodili, - "...ves vzvod ne v nogu, tolko startsina v nogu!".
Scastlivo ostavatsja s vasimi zabluzdenijami...
BTW: Linus kak-to skazal v interv'ju BBC, cto na svete 99% durakov, a Linux prednaznacen dlja ostavsegosja 1%. Ot sebja ja mogu dobavit, cto Gentoo dlja esce bolee uzkoj auditorii, vozmozno tot ze 1% ot vsex linuxoidov, poskolku Linux sam po sebe trebuet osmyslenija svoix dejstvij, a Gentoo - tem bolee...
:)
aes78, специально чтоб тебе доказать что ccache все-таки работает, и при том работает точно так как указано в handbook,
а не так как тебе хочется, судя из твоего поста - снес у себя его кеш. :(
Вот последовательность действий и их результаты.
Очищаем кеш компилятора, дабы никак не влиял на наши измерения.
Запускаем сборку без ccache - вывод ее здесь и далее направляем в /dev/null, дабы не влиял тормоз в виде вывода на консоль.
Теперь сборка с ccache - должна немного медленней быть, так как надо время на наполнение его кеша.
И опять сборка того же пакета - но с заполненным кешем компилятора.
И после этого вы продолжите утверждать что незаметно результатов? Почти в 3 раза быстрее - это незаметно? Ого... плохой у вас инструмент под именем глаз. :)
Если у вас их все-таки незаметно - так телепаты в весеннем отпуске, конфиги ваши и результаты измерений сборки никто так и не увидел.
Какие еще могут быть вопросы?
Желаете получить полный исчерпывающий ответ - задайте правильно вопрос - в нем сами сможете обнаружить 50% ответа.
Я вам могу точно сказать, что
Я вам могу точно сказать, что ни в одном правильно заданном вопросе вы не увидите и 10% ответа. Последую вашим рекомендациям месяца через два, когда буду обновляться, а сейчас часовые пересборки для тестирования мне ни к чему
aes78 написал(а): месяца
Да нихрена вы не поняли, судя по этому.
Перечитайте внимательно что сами писали и что я выделил в ваших цитатах, если не поймете - тогда уж извините, помочь нечем.
Сойдемся на том, что я
Сойдемся на том, что я безнадежен.
не совсем верно
Ключевые слова - "перекомпилируете ту же самую программу", "в типичных случаях", "может сокращаться".
Иными словами - эффект возможен только при повторной сборке некоей одной и той же программы.
И, опять же - в "типичных" случаях. Как правило это относится к целиком сишным/плюсовым проектам. Если программа большей частью на других языках программирования - ccache отступает.
Или, к примеру, если сборка включает генерацию/модификацию исходников прямо в процессе. Например - вставляет в какой-нибудь всеобщий хедер дату и время сборки. В этом случае все файлы, куда будет включён этот хедер, уже не попадут под ccache из-за изменений.
Поэтому - время может сокращаться, а может и нет.
Никаких гарантий и обещаний по этому поводу не даётся.
И поэтому по меньшей мере глупо предъявлять претензии по поводу отсутствия ускорения в каком-то конкретном проекте.
Если бы в хэндбуке было бы прямо написано, что ccache ускоряет сборку xulrunner в 10 раз - это был бы другой разговор.
Ваше объяснение
Ваше объяснение представляется мне более целесообразным, однако я никаких претензий не предъявляю, достаточно глупо предъявлять претензии по СПО, где никто никому ничего не должен. Я это пытался выяснить для себя, а не для того, чтобы предъявить какие-то претензии. xulrunner - это одна и та же программа перекомпилируется или вы имеете в виду одну и ту же версию программы (но об этом нигде ничего не сказано), собственно, она занимает одно из наибольших единиц времени компиляции, и лично для меня, если у нее время компиляции не уменьшается, смысла в ccache особого нет (возможно, что на других сильнокомпилирующихся пакетах будет, но другие пакеты еще не прошли всю цепочку, поэтому я ничего сказать не могу, а тратить сейчас время на перекомпиляцию таких сильнозатратных по времени программ я не могу).
Ну... что ж вы хотите... Это
Ну... что ж вы хотите... Это source-based дистрибутив. Будьте готовы к многочасовым компиляциям.
ЗЫ: я обычно разные emerge -uDN @system @world запускаю на выходные. + пользуюсь distcc и помощью простаивающих в сети компов (это РЕАЛЬНО ускоряет сборку).
Я понимаю, что это
Я понимаю, что это source-based и хотелось бы облегчить участь многочасовых компиляций. У меня знакомый за два часа с помощью ccache обновляет мир, у меня последний раз ушло на обновление мира 37 часов. У меня сети нет и простаивающих в ней компов то же. Моя работа требует практически постоянной работы на компьютере. Если же включен ccache, то CPU занято процентов на 40-50, что делает неудобной работу в других приложениях.
Я допускаю, что вам по молодости лет логичные доводы кажутся непробиваемым апломбом, нормальные аргументы странными, те авторитеты, которые вам не нравятся и посты, которые вы не поняли - странными. Поверьте, они таковыми не являются.
При том, что я довольно сносно владею английским языком, мой родной язык - русский, компьютер мне нужен для работы, а не для того, чтобы сидеть и изучать различные английские статьи, которые не относятся напрямую к моей работе. С учетом того, что есть русскоязычное сообщество генту, я предпочел спросить там, и я бы назвал странным то, что на русскоязычном ресурсе отсылают к англоязычным.
aes78
Дело не в том что какие-то посты мне нравятся а какие-то нет, или я что-то не понял.
А тебе не кажется странным то, что Диего, который итальянец, пишет на английском, который тоже не очень хорошо знает?
aes78 написал(а):Об ошибке
Возможно, тут есть и моя проблема - перед тем как писать ответ я почитал твои сообщения в других темах, там ведутся такие-же разговоры — с непробиваемым апломбом, закидывая странными аргументами и ссылаясь на не менее странные авторитеты пишутся не совсем вменяемые посты.
В этой теме нет сообщения о ошибке, но с твоей точки зрения поведение пакета некорректно. С одной стороны есть заявления о том что ты знаешь как работает ccache но на практике «невооружённым взглядом» видно что нет. Я даже оставил ссылку на запись в блоге одного из разработчиков gentoo который так и называется - «мифы о ccache» но он похоже прочитан не был, а заявления и апломб — остались.
Когда говорят что кэш помогает собирать одну и туже программу то то имеется в виду то, что собирается ровно один и тот-же код, ведь компилятор имеет дело с отдельными файлами исходников а не с некими абстрактными «программами» и вот каждый такой кусочек он сохраняет и кэширует. А далее появляется некое соревнование - что быстрее:
собрать кусочек кода
найти результат сборки на диске
Также есть усложнение в плане самих кусочков кода - в больших проектах их тысячи, и какаято часть вполне может остаться неизменной на разных версиях программы, и таких тонкостей хватает. Для меня гораздо больший прирост в скорости дало перемещение сборочного каталога в ОЗУ. Но с какой стати я буду переписывать то что до меня написал Диего?
После прочтения трэда всё же
После прочтения трэда всё же понятно что вы недопоняли как работает ccache или хотите чтобы он работал там где он работать не должен.
Тесты специально для вас:
1я компиляция xulrunner-1.9.2-r4:
2я компиляция xulrunner-1.9.2-r4:
Откомпилированые файлы брались из кэша, по md5 хэшу прекомпиленого файла - поэтому при пересборке оно ускоряется, а при обновлении хэши файлов будут скорее всего другими поэтому оно будет их компилить и ускорения не будет. Кроме тех случаев, когда версия пакета обновилась а программы нет, т.е всякие -p и -r релизы, в которых скорее всего идут косметические правки ебилдов. Т.е держать ccache нужно, ибо таких обновлений много, а вам я так понимаю вовсе не для работы нужны эти обноления, а для душевного успокоения что вы имете полностью обновленную систему. Если вам уж так нужно работать, то зачем вам постоянно обновляться?
Вот теперь я недопонял...
То есть вы, без зазрения совести, хотите сказать, что если я сделаю расшаренный кеш для нескольких (идентичных
машин с одннаковыми флагами), то он заработает? ;)
Gentoo - Symphony of Creations
Если передача файла по каналу
Если передача файла по каналу связывающего ваши машины будет быстрее, чем его компиляция, а также будут совпадать chost ,cflags, use флаги то вроде как да
Интересно ...
Спасибо за информацию для размышлений, испытаю на досуге.
(Хотя отчасти и сомневаюсь что оно должно работать, слишком много параметров должны быть соблюдены)
Gentoo - Symphony of Creations
тут лучше сделать binhost или
тут лучше сделать binhost или distcc
Это я понимаю и реализовал
Просто для информации подковываюсь...
distcc не всегда устраивает, потому что не все задачи компиляции - распределяемы.
над binhost подумаю, так ли необходимо (ветки не совпадают).
кстати не по теме, но раз тут люди грамотные на этот счет:
почему distcc работает нормально, но в определенный момент пишет
что-то типа - распределение невозможно, компилирую локально,
хотя на не распределяемых задачах такое не выдает (например дрова от NV)
Ткните носом где смотреть. Спасибо.
Gentoo - Symphony of Creations
Обновление системы без ccache
Обновление системы без ccache никак работе не мешает, оно идет само по себе, я работаю сам по себе. Постоянно я не обновляюсь, периодически, по мере поступления сообщений о найденных критических уязвимостях.
Если эти -r и -р релизы имеют незначительное время компиляции, то ccache мне не нужен.
Поделитесь, как у вас xulrunner за 16 минут без ccache собрался, у меня вроде и компьютер не такой слабый: 3,1GHz, 1 GB.
aes78 написал(а): Поделитесь,
Машинка все-таки посильнее немного - Intel Q6600 8Gb RAM, дисковая подсистема честная, на Adaptec 5405 с дисками в 10000 rpm - хотя в данном случае кроме процессора ничего остальное так не влияет на скорость сборки. Да, и сборка в 5 потоков одновременно, т.е. MAKEOPTS="-j5" - больше вроде никаких секретов...
если в новом ебилде что-то
если в новом ебилде что-то исправили, в итоге не затрагивающие ваши выходнык use флаги, то получается что вы просто будете компилировать тот же код что и раньше, поэтому кэш тут поможет, и это часто бывает. Также в кэш кладется работа autoconf (если я правильно понимаю строку autoconf compile/link ), а она идет в один поток, так что иногда занимает время большее чем сама компиляция.
В быстрой сборке нет никакой магии, просто новый ноут на i7 в 8 потоков