Здравствуйте, NikeByNike, Вы писали:
NBN>Пробую разные способы ускорить компиляцию. Хочется попробовать такой способ:
NBN>Условие: NBN>Есть некоторый проект весом порядка 5-10 Mb исходников. Кроме того он ссылается на порядка 20 Mb сторонних библиотек и SDK. NBN>Win7 (64), VS 2005, 4 гига (можно расширить до 8). NBN>Ограничение: NBN>Проект должен находиться в специфичной папке (например: c:\work\my_project\, которая обязана быть замаунчена как специальный диск, типа: subst x: c:\my_project\). NBN>Идея: NBN>Если постоянно хранить все исходники и хидеры в оперативке — должно компилироваться быстрее.
Хидеры предкомпилируются (надеюсь), а исходников 5-10 Мб. Это все копейки, и на чтение их уходит не так уж много времени. Если у тебя тормозит, то скорее всего дело не в их чтении.
NBN>Это возможно?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хидеры предкомпилируются (надеюсь), а исходников 5-10 Мб.
Нет, не предкомпилируются. Про компилятор я немного наврал, это не VS 2005 (это только среда).
PD>Это все копейки, и на чтение их уходит не так уж много времени. Если у тебя тормозит, то скорее всего дело не в их чтении.
Не тормозит, просто хочется ускорить как можно сильнее.
NBN>>Это возможно?
PD>В принципе возможно, но вряд ли что-то даст.
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, Aen Sidhe, Вы писали:
NBN>>>Пробую разные способы ускорить компиляцию. Хочется попробовать такой способ:
AS>>Мы используем распараллеливание. 1Gbit локалка + Incredibuild.
NBN>Я бы с радостью, но к сожалению нереально пока, по административным и техническим причинам.
Ну как. У меня на такой конфигурации С++ часть проекта собирается примерно 3-5 минут. Если локалку отключить (бывает, что дохнет координатор), то 7-10. Core i7 4хядерный.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>>>виднее с точностью до файлов и частей их?
ТКС>>Когда как. Есть ситуации, когда винда точно будет ошибаться, пытаясь поднять из кэша ненужные данные.
СМ>точно так же как и диск
Тут главное, чтобы выгрузка не делалось в ущерб нужным данным. Диск такую гарантию дает в отношении объектников и pdb.
ТКС>>И что предлагается — во время сборки проекта ни почту посмотреть, ни в интернете не пошариться? А если эксперимент не моделирует нормальную рабочую ситуацию — то это эксперимент некорректный, а не жизнь неправильная.
СМ>Это трудно замерить, как активно используются
Т.е., эксперимент был ни о чем. И зачем тогда на него ссылаться?
СМ>>>И, повторяю, нельзя диск отхватить ТОЧНО по размеру всех файлов, т.к. временные бывают разные, а это значит будет внещняя дефрагметация дисков (т.е. заказал диск на 2гиг, а юзаешь на один — один в пролете) это полюбому скажется на производительности.
ТКС>>Мы какую задачу решаем — максимально ускорить сборку проекта или максимально заполнить память потенциально ненужными данными? Винда вторую задачу решает, мне интересна первая. И я готов переплатить сотку баков за недоиспользуемое ОЗУ.
СМ>так покупай и ставь, зачем говорить.
Мой рабочий проект все равно на рамдрайв не влезет, гигов 40 надо, а столько ОЗУ+плата, в которую его воткнуть можно, пока дорого стоят.
СМ>Только не забыдь время, которе надо тратить на копирование во временный диск (и мб обратно)
Копейки, в пересчете на рабочий день.
СМ>>>Прения можно бесконечно продолжать. Я замерял и результат сказал. Есть другие _данные_? а не попытки теоризирования?
ТКС>>Что конкретно ты замерял? Сферического коня в вакууме? Я пока никакого описания эксперимента тут не видел. И говорить о его применимости к конкретным условиям рановато.
СМ>я уже писал. Дело было давно. Подробностей, естественно не помню. Результат был практически одинаков (меньше погрешности измерения).
Есть разница, между размером ОЗУ 16 Гб сегодня и 2 Гб несколько лет назад. Да и от размера проекта многое зависит. Поэтому из того, что пересборка непонятно чего в непонятно каких условиях тогда не выявила разницы, не следует, что это произойдет сейчас, на другом железе, с другой виндой при сборке другого проекта.
СМ>Я второй раз спрашиваю, Вы замеряли? Хоть что-то? Или просто так
Хоть что-то замерить не трудно, но интереса такие измерения не много представляют. Впрочем, раз отсутствие каких попало экспериментальных данных вызывает столь неадекватную реакцию, замерил хоть что-то. Результат — примерно 8.5 секунды при сборке на жестком диске, 6.2 секунды — на рамдрайве, при многократной поочередной пересборке солюшена. Повторяемость результатов неплохая. Проектец правда маловат, ну да уж какой подвернулся.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>большинство все таки говрят, что это ничего не даст. Давайте или эксперимент ставить (у меня 4 ядра и HT, мне не надо ) или закроем тему.
Я готов выбрать второе, но я не ТС, чтобы ее закрывать.
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Хидеры предкомпилируются (надеюсь), а исходников 5-10 Мб.
NBN>Нет, не предкомпилируются.
вот лучще заморачиваться по этому поводу чем с ram дисками
PD>>Это все копейки, и на чтение их уходит не так уж много времени. Если у тебя тормозит, то скорее всего дело не в их чтении.
вот именно! вот например тайминги чтения с диска:
5-10-20 МB на фоне ~70MB/sec не даст заметного на глаз выигрыша!
нужно заниматься предкомпилированными хидерами... на проекте с интенсивным использованием boost например я выжимал 10-20% в скорости...
далее уже нужно смотреть в сам код... оптимизировать инснациирование шаблонов например... заменять сложный mpl более простым и тд... но временами с этим ничего не поеделать -- на то оно и метапрограммирование (часть работы выполняет компилятор чтобы не выполнять ее в рантайме)
Здравствуйте, zaufi, Вы писали:
PD>>>Хидеры предкомпилируются (надеюсь), а исходников 5-10 Мб.
NBN>>Нет, не предкомпилируются. Z>вот лучще заморачиваться по этому поводу чем с ram дисками
Предкомпиляция не поддерживается.
Z>5-10-20 МB на фоне ~70MB/sec не даст заметного на глаз выигрыша!
Ок.
Z>нужно заниматься предкомпилированными хидерами... на проекте с интенсивным использованием boost например я выжимал 10-20% в скорости... Z>далее уже нужно смотреть в сам код... оптимизировать инснациирование шаблонов например... заменять сложный mpl более простым и тд... но временами с этим ничего не поеделать -- на то оно и метапрограммирование (часть работы выполняет компилятор чтобы не выполнять ее в рантайме)
Код не мой, это данность с которой нужно работать.
Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>Здравствуйте, Сергей Мухин, Вы писали:
СМ>>>>виднее с точностью до файлов и частей их?
ТКС>>>Когда как. Есть ситуации, когда винда точно будет ошибаться, пытаясь поднять из кэша ненужные данные.
СМ>>точно так же как и диск
ТКС>Тут главное, чтобы выгрузка не делалось в ущерб нужным данным. Диск такую гарантию дает в отношении объектников и pdb.
ТКС>>>И что предлагается — во время сборки проекта ни почту посмотреть, ни в интернете не пошариться? А если эксперимент не моделирует нормальную рабочую ситуацию — то это эксперимент некорректный, а не жизнь неправильная.
СМ>>Это трудно замерить, как активно используются
ТКС>Т.е., эксперимент был ни о чем. И зачем тогда на него ссылаться?
гм. это Вы пытаетесь в момент эксперимента еще и почту читать.
СМ>>>>И, повторяю, нельзя диск отхватить ТОЧНО по размеру всех файлов, т.к. временные бывают разные, а это значит будет внещняя дефрагметация дисков (т.е. заказал диск на 2гиг, а юзаешь на один — один в пролете) это полюбому скажется на производительности.
ТКС>>>Мы какую задачу решаем — максимально ускорить сборку проекта или максимально заполнить память потенциально ненужными данными? Винда вторую задачу решает, мне интересна первая. И я готов переплатить сотку баков за недоиспользуемое ОЗУ.
СМ>>так покупай и ставь, зачем говорить.
ТКС>Мой рабочий проект все равно на рамдрайв не влезет, гигов 40 надо, а столько ОЗУ+плата, в которую его воткнуть можно, пока дорого стоят.
СМ>>Только не забыдь время, которе надо тратить на копирование во временный диск (и мб обратно)
ТКС>Копейки, в пересчете на рабочий день.
СМ>>>>Прения можно бесконечно продолжать. Я замерял и результат сказал. Есть другие _данные_? а не попытки теоризирования?
ТКС>>>Что конкретно ты замерял? Сферического коня в вакууме? Я пока никакого описания эксперимента тут не видел. И говорить о его применимости к конкретным условиям рановато.
СМ>>я уже писал. Дело было давно. Подробностей, естественно не помню. Результат был практически одинаков (меньше погрешности измерения).
ТКС>Есть разница, между размером ОЗУ 16 Гб сегодня и 2 Гб несколько лет назад. Да и от размера проекта многое зависит. Поэтому из того, что пересборка непонятно чего в непонятно каких условиях тогда не выявила разницы, не следует, что это произойдет сейчас, на другом железе, с другой виндой при сборке другого проекта.
никто не обещал
СМ>>Я второй раз спрашиваю, Вы замеряли? Хоть что-то? Или просто так
ТКС>Хоть что-то замерить не трудно, но интереса такие измерения не много представляют. Впрочем, раз отсутствие каких попало экспериментальных данных вызывает столь неадекватную реакцию, замерил хоть что-то. Результат — примерно 8.5 секунды при сборке на жестком диске, 6.2 секунды — на рамдрайве, при многократной поочередной пересборке солюшена. Повторяемость результатов неплохая. Проектец правда маловат, ну да уж какой подвернулся.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>А сколько времени сейчас занимает-то ?
NBN>>Минут 5.
PD>Это полная перекомпиляция, так ? Но ведь обычный make затрагивает лишь небольшое число файлов. Или это линковка занимает 5 минут ?
Да, обычно перекомпилируется несколько файлов. Но перед этим, как я понимаю, происходит автоматическое создание или обновление make файла (в недрах SDK), в ходе которого компилер пробегает по всем используемым хидерам. Это обновление может занимать больше времени, чем собственно компиляция.
Здравствуйте, NikeByNike, Вы писали:
NBN>Да, обычно перекомпилируется несколько файлов. Но перед этим, как я понимаю, происходит автоматическое создание или обновление make файла (в недрах SDK), в ходе которого компилер пробегает по всем используемым хидерам. Это обновление может занимать больше времени, чем собственно компиляция.
Не знаю как в твоем компиляторе, но VS проверяет не файлы, а их дату и время. Если obj более поздний, чем cpp — значит, не надо компилировать.
Здравствуйте, Pavel Dvorkin, Вы писали:
NBN>>Да, обычно перекомпилируется несколько файлов. Но перед этим, как я понимаю, происходит автоматическое создание или обновление make файла (в недрах SDK), в ходе которого компилер пробегает по всем используемым хидерам. Это обновление может занимать больше времени, чем собственно компиляция.
PD>Не знаю как в твоем компиляторе, но VS проверяет не файлы, а их дату и время. Если obj более поздний, чем cpp — значит, не надо компилировать.
Не. Она так же проверяет все связанные с cpp хидера. Иначе при изменении хидера не происходило бы перекомпиляции (у других компилеров такое бывает).
Здравствуйте, NikeByNike, Вы писали:
PD>>Не знаю как в твоем компиляторе, но VS проверяет не файлы, а их дату и время. Если obj более поздний, чем cpp — значит, не надо компилировать.
NBN>Не. Она так же проверяет все связанные с cpp хидера. Иначе при изменении хидера не происходило бы перекомпиляции (у других компилеров такое бывает).
дада, но эта информация у нее уже в голове, это быстро происходит
Здравствуйте, Сергей Мухин, Вы писали:
NBN>>Не. Она так же проверяет все связанные с cpp хидера. Иначе при изменении хидера не происходило бы перекомпиляции (у других компилеров такое бывает).
СМ>дада, но эта информация у нее уже в голове, это быстро происходит
Это при условии, что компилер помнит используемые хидеры. А если нет — то нужно всё парсить.
СМ>>дада, но эта информация у нее уже в голове, это быстро происходит
NBN>Это при условии, что компилер помнит используемые хидеры. А если нет — то нужно всё парсить.
парсится один раз, потом хранится (где ниб в suo/ncb) и меняется при изм файлов
) или закроем тему.
