Здравствуйте, NikeByNike, Вы писали:

NBN>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Хидеры предкомпилируются (надеюсь), а исходников 5-10 Мб.

NBN>Нет, не предкомпилируются.
вот лучще заморачиваться по этому поводу чем с ram дисками

PD>>Это все копейки, и на чтение их уходит не так уж много времени. Если у тебя тормозит, то скорее всего дело не в их чтении.
вот именно! вот например тайминги чтения с диска:

gentop zaufi # hdparm -T /dev/sda

/dev/sda:
 Timing cached reads:   4854 MB in  2.00 seconds = 2427.13 MB/sec
gentop zaufi # hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads: 222 MB in  3.01 seconds =  73.65 MB/sec

5-10-20 МB на фоне ~70MB/sec не даст заметного на глаз выигрыша!

нужно заниматься предкомпилированными хидерами... на проекте с интенсивным использованием boost например я выжимал 10-20% в скорости...
далее уже нужно смотреть в сам код... оптимизировать инснациирование шаблонов например... заменять сложный mpl более простым и тд... но временами с этим ничего не поеделать -- на то оно и метапрограммирование (часть работы выполняет компилятор чтобы не выполнять ее в рантайме)

Intermediate папку делал на "диске" в оперативной памяти — прирост был заметный.

Здравствуйте, Danchik, Вы писали:

D>Сколько компиляторов студия запускает одновременно? Посмотри на процессы.
D>Кажется VS 2005 не умеет запускать паралельно компиляцию одного проєкта. Хотя тут пишут другое
D>http://vagus.wordpress.com/2008/02/15/source-level-parallel-build-in-visual-studio-2005/

И правильно пишшут. На рабочей машине двухядерный процессор. MSVC 2005 без ключа /MP у меня запускает один процес cl.exe, а с этим ключом два.

Здравствуйте, NikeByNike, Вы писали:

[Skip]

NBN>Это возможно?

Помнится знакомые перенаправляли Temp Folder на мемори диск — очень уж много временных файлов создается.

Но все-таки, если есть деньги то однозначно поставить SSD, да и процессор многоядерный даст огромный прирост, i7 например.

Здравствуйте, NikeByNike, Вы писали:

NBN>Здравствуйте, Danchik, Вы писали:

NBN>>>Это возможно?

D>>Помнится знакомые перенаправляли Temp Folder на мемори диск — очень уж много временных файлов создается.

D>>Но все-таки, если есть деньги то однозначно поставить SSD

NBN>Была такая идея, но кто-то говорил, что прироста не даст.

Плюнь ему в глаз Должна подняться в несколько раз. А уж скорость работы самого компа...

D>>, да и процессор многоядерный даст огромный прирост, i7 например.

NBN>i5 стоит. Мне не кажется, что проц тут узкое место...

Сколько компиляторов студия запускает одновременно? Посмотри на процессы.
Кажется VS 2005 не умеет запускать паралельно компиляцию одного проєкта. Хотя тут пишут другое
http://vagus.wordpress.com/2008/02/15/source-level-parallel-build-in-visual-studio-2005/

Пробую разные способы ускорить компиляцию. Хочется попробовать такой способ:

Условие:
Есть некоторый проект весом порядка 5-10 Mb исходников. Кроме того он ссылается на порядка 20 Mb сторонних библиотек и SDK.
Win7 (64), VS 2005, 4 гига (можно расширить до 8).
Ограничение:
Проект должен находиться в специфичной папке (например: c:\work\my_project\, которая обязана быть замаунчена как специальный диск, типа: subst x: c:\my_project\).
Идея:
Если постоянно хранить все исходники и хидеры в оперативке — должно компилироваться быстрее. Как вариант создать технический диск в оперативной памяти и примаунтить его как папку в исходной специфичной папке.

Это возможно?

Здравствуйте, 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>Если постоянно хранить все исходники и хидеры в оперативке — должно компилироваться быстрее. Как вариант создать технический диск в оперативной памяти и примаунтить его как папку в исходной специфичной папке.
NBN>Это возможно?
Возможно, но прирост будет не большой, не в 2 раза.

Здравствуйте, NikeByNike, Вы писали:


NBN>Если постоянно хранить все исходники и хидеры в оперативке — должно компилироваться быстрее. Как вариант создать технический диск в оперативной памяти и примаунтить его как папку в исходной специфичной папке.

Прироста практически не будет, т.к. кеш все равно держит все файлы в памяти. Надо конечно иметь достойную память.

Здравствуйте, NikeByNike, Вы писали:

NBN>Пробую разные способы ускорить компиляцию. Хочется попробовать такой способ:

NBN>Если постоянно хранить все исходники и хидеры в оперативке — должно компилироваться быстрее. Как вариант создать технический диск в оперативной памяти и примаунтить его как папку в исходной специфичной папке.

Тогда маунтить еще нужно и временные папки типа obj.

Здравствуйте, Сергей Мухин, Вы писали:

NBN>>Если постоянно хранить все исходники и хидеры в оперативке — должно компилироваться быстрее. Как вариант создать технический диск в оперативной памяти и примаунтить его как папку в исходной специфичной папке.

СМ>Прироста практически не будет, т.к. кеш все равно держит все файлы в памяти. Надо конечно иметь достойную память.

Вопрос в том — сколько он их держит. Нет ли способа заставить его держать эти файлы всё время?

Здравствуйте, Аноним, Вы писали:

NBN>>Если постоянно хранить все исходники и хидеры в оперативке — должно компилироваться быстрее. Как вариант создать технический диск в оперативной памяти и примаунтить его как папку в исходной специфичной папке.

А>Тогда маунтить еще нужно и временные папки типа obj.

Вот тут в способностях кеша я не сомневаюсь.
В исходной ситуации в течении рабочего получаса может происходить обращение к десяткам и сотням тысяч других файлов системы, при этом нужные хидеры может выкидывать из кеша.

Здравствуйте, Danchik, Вы писали:

NBN>>Это возможно?

D>Помнится знакомые перенаправляли Temp Folder на мемори диск — очень уж много временных файлов создается.

D>Но все-таки, если есть деньги то однозначно поставить SSD

Была такая идея, но кто-то говорил, что прироста не даст.

D>, да и процессор многоядерный даст огромный прирост, i7 например.

i5 стоит. Мне не кажется, что проц тут узкое место...

Здравствуйте, NikeByNike, Вы писали:

СМ>>Прироста практически не будет, т.к. кеш все равно держит все файлы в памяти. Надо конечно иметь достойную память.

NBN>Вопрос в том — сколько он их держит. Нет ли способа заставить его держать эти файлы всё время?

чем больше памяти, тем дольше они там задержатся (это очевидно). Менее очевидно, что диск в памяти, также подвержен вытеснению из памяти. И что лучше? Механихм вытеснения практически идентичен.

Здравствуйте, Сергей Мухин, Вы писали:

СМ>>>Прироста практически не будет, т.к. кеш все равно держит все файлы в памяти. Надо конечно иметь достойную память.

NBN>>Вопрос в том — сколько он их держит. Нет ли способа заставить его держать эти файлы всё время?

СМ>чем больше памяти, тем дольше они там задержатся (это очевидно). Менее очевидно, что диск в памяти, также подвержен вытеснению из памяти. И что лучше? Механихм вытеснения практически идентичен.

Смотря что за диск. ОС об его памяти может вообще не знать, и, соответственно, никто ничё не вытеснит.

Здравствуйте, Тот кто сидит в пруду, Вы писали:


СМ>>чем больше памяти, тем дольше они там задержатся (это очевидно). Менее очевидно, что диск в памяти, также подвержен вытеснению из памяти. И что лучше? Механихм вытеснения практически идентичен.

ТКС>Смотря что за диск. ОС об его памяти может вообще не знать, и, соответственно, никто ничё не вытеснит.

с этого места подробней, как это не вытеснит? Если только он руками зафиксит все свои страницы в памяти. А так — это обычное приложение и его память вытеснится на раз.

Здравствуйте, Сергей Мухин, Вы писали:

СМ>>>чем больше памяти, тем дольше они там задержатся (это очевидно). Менее очевидно, что диск в памяти, также подвержен вытеснению из памяти. И что лучше? Механихм вытеснения практически идентичен.

ТКС>>Смотря что за диск. ОС об его памяти может вообще не знать, и, соответственно, никто ничё не вытеснит.

СМ>с этого места подробней, как это не вытеснит? Если только он руками зафиксит все свои страницы в памяти. А так — это обычное приложение и его память вытеснится на раз.

Почему обычное приложение? Драйвер. Есть у меня такой, под вистой 32 использует память за четвертым гигом. Кто ж его такого вытеснит? Наверняка и под x64 что-нибудь подобное есть, особо не интересовался.

Здравствуйте, NikeByNike, Вы писали:

NBN>Пробую разные способы ускорить компиляцию. Хочется попробовать такой способ:

Мы используем распараллеливание. 1Gbit локалка + Incredibuild.

Здравствуйте, Тот кто сидит в пруду, Вы писали:


СМ>>с этого места подробней, как это не вытеснит? Если только он руками зафиксит все свои страницы в памяти. А так — это обычное приложение и его память вытеснится на раз.

ТКС>Почему обычное приложение? Драйвер. Есть у меня такой, под вистой 32 использует память за четвертым гигом. Кто ж его такого вытеснит? Наверняка и под x64 что-нибудь подобное есть, особо не интересовался.

я что-то не улавливаю, какой-то процесс пользует память, как она отображается на пользовательский никак не влияет на способность вытяснения. как приложения используещее так и используемое.

Вам надо или локировать страницы памяти приложения, тем самым говоря, что ваш драйвер лучше знает когда и что вытяснять или идти на поводу у системы.

При использовании диска в памяти пользователь или фиксирует его в памяти (наверно это можно) НО тем самым удаляет из кеша точно такой кусок памяти! При этом диск никогда не будет 100% эффективным с точки зрения заполнения (иначе часты будут переполнения файлов на нем), тем самым вы сразу же теряете используемую память!

Я несколько лет назад ставил эксперимент — монопенициально

Здравствуйте, Сергей Мухин, Вы писали:

СМ>>>с этого места подробней, как это не вытеснит? Если только он руками зафиксит все свои страницы в памяти. А так — это обычное приложение и его память вытеснится на раз.

ТКС>>Почему обычное приложение? Драйвер. Есть у меня такой, под вистой 32 использует память за четвертым гигом. Кто ж его такого вытеснит? Наверняка и под x64 что-нибудь подобное есть, особо не интересовался.

СМ>я что-то не улавливаю, какой-то процесс пользует память, как она отображается на пользовательский никак не влияет на способность вытяснения. как приложения используещее так и используемое.

СМ>Вам надо или локировать страницы памяти приложения, тем самым говоря, что ваш драйвер лучше знает когда и что вытяснять или идти на поводу у системы.

Ну насколько я помню, простому приложению давно никто не разрешает лочить страницы памяти. Т.е., попросить то оно может, но операционка вправе сделать по своему. Поэтому я для ясности и написал про драйвер.

СМ>При использовании диска в памяти пользователь или фиксирует его в памяти (наверно это можно) НО тем самым удаляет из кеша точно такой кусок памяти! При этом диск никогда не будет 100% эффективным с точки зрения заполнения (иначе часты будут переполнения файлов на нем), тем самым вы сразу же теряете используемую память!

Ну мне как бы виднее, чем я собираюсь через 5 минут заняться, и что мне важнее, чем операционке. Откуда она знает, сколько у меня в проекте объектников/pdbшек и что я их все время от времени все сразу пересобираю?

СМ>Я несколько лет назад ставил эксперимент — монопенициально

Я думаю, тут важны конкретные числа. Если, например, в машине памяти гигов эдак 16, а все бинарники проекта помещаются в 8, сомневаюсь, что винда сумеет занять память нужными и правильными вещами. Может она вместо кэширования объектников все 200 вкладок хрома/оперы (условно) решит в своп не выгружать? Т.е., эксперимент экспериментом, но экстраполировать его результаты на всю гамму возможных условий я бы не стал.

Здравствуйте, Тот кто сидит в пруду, Вы писали:


ТКС>Ну насколько я помню, простому приложению давно никто не разрешает лочить страницы памяти. Т.е., попросить то оно может, но операционка вправе сделать по своему. Поэтому я для ясности и написал про драйвер.

СМ>>При использовании диска в памяти пользователь или фиксирует его в памяти (наверно это можно) НО тем самым удаляет из кеша точно такой кусок памяти! При этом диск никогда не будет 100% эффективным с точки зрения заполнения (иначе часты будут переполнения файлов на нем), тем самым вы сразу же теряете используемую память!

ТКС>Ну мне как бы виднее, чем я собираюсь через 5 минут заняться, и что мне важнее, чем операционке. Откуда она знает, сколько у меня в проекте объектников/pdbшек и что я их все время от времени все сразу пересобираю?

виднее с точностью до файлов и частей их?

СМ>>Я несколько лет назад ставил эксперимент — монопенициально

ТКС>Я думаю, тут важны конкретные числа. Если, например, в машине памяти гигов эдак 16, а все бинарники проекта помещаются в 8, сомневаюсь, что винда сумеет занять память нужными и правильными вещами. Может она вместо кэширования объектников все 200 вкладок хрома/оперы (условно) решит в своп не выгружать? Т.е., эксперимент экспериментом, но экстраполировать его результаты на всю гамму возможных условий я бы не стал.

Если на рабочей машине, во время эксперимента еще кто-то ходит в интернет, или играет в шутер, то как-то странно, т.е. это плохой пример для подражания. и он одинаково будет плохо воздействовать на все системы.

И, повторяю, нельзя диск отхватить ТОЧНО по размеру всех файлов, т.к. временные бывают разные, а это значит будет внещняя дефрагметация дисков (т.е. заказал диск на 2гиг, а юзаешь на один — один в пролете) это полюбому скажется на производительности.

Прения можно бесконечно продолжать. Я замерял и результат сказал. Есть другие _данные_? а не попытки теоризирования?

Здравствуйте, Сергей Мухин, Вы писали:

СМ>>>При использовании диска в памяти пользователь или фиксирует его в памяти (наверно это можно) НО тем самым удаляет из кеша точно такой кусок памяти! При этом диск никогда не будет 100% эффективным с точки зрения заполнения (иначе часты будут переполнения файлов на нем), тем самым вы сразу же теряете используемую память!

ТКС>>Ну мне как бы виднее, чем я собираюсь через 5 минут заняться, и что мне важнее, чем операционке. Откуда она знает, сколько у меня в проекте объектников/pdbшек и что я их все время от времени все сразу пересобираю?

СМ>виднее с точностью до файлов и частей их?

Когда как. Есть ситуации, когда винда точно будет ошибаться, пытаясь поднять из кэша ненужные данные.

СМ>>>Я несколько лет назад ставил эксперимент — монопенициально

ТКС>>Я думаю, тут важны конкретные числа. Если, например, в машине памяти гигов эдак 16, а все бинарники проекта помещаются в 8, сомневаюсь, что винда сумеет занять память нужными и правильными вещами. Может она вместо кэширования объектников все 200 вкладок хрома/оперы (условно) решит в своп не выгружать? Т.е., эксперимент экспериментом, но экстраполировать его результаты на всю гамму возможных условий я бы не стал.

СМ>Если на рабочей машине, во время эксперимента еще кто-то ходит в интернет, или играет в шутер, то как-то странно, т.е. это плохой пример для подражания. и он одинаково будет плохо воздействовать на все системы.

И что предлагается — во время сборки проекта ни почту посмотреть, ни в интернете не пошариться? А если эксперимент не моделирует нормальную рабочую ситуацию — то это эксперимент некорректный, а не жизнь неправильная.

СМ>И, повторяю, нельзя диск отхватить ТОЧНО по размеру всех файлов, т.к. временные бывают разные, а это значит будет внещняя дефрагметация дисков (т.е. заказал диск на 2гиг, а юзаешь на один — один в пролете) это полюбому скажется на производительности.

Мы какую задачу решаем — максимально ускорить сборку проекта или максимально заполнить память потенциально ненужными данными? Винда вторую задачу решает, мне интересна первая. И я готов переплатить сотку баков за недоиспользуемое ОЗУ.

СМ>Прения можно бесконечно продолжать. Я замерял и результат сказал. Есть другие _данные_? а не попытки теоризирования?

Что конкретно ты замерял? Сферического коня в вакууме? Я пока никакого описания эксперимента тут не видел. И говорить о его применимости к конкретным условиям рановато.

Здравствуйте, Тот кто сидит в пруду, Вы писали:

СМ>>виднее с точностью до файлов и частей их?

ТКС>Когда как. Есть ситуации, когда винда точно будет ошибаться, пытаясь поднять из кэша ненужные данные.

точно так же как и диск


ТКС>И что предлагается — во время сборки проекта ни почту посмотреть, ни в интернете не пошариться? А если эксперимент не моделирует нормальную рабочую ситуацию — то это эксперимент некорректный, а не жизнь неправильная.

Это трудно замерить, как активно используются

СМ>>И, повторяю, нельзя диск отхватить ТОЧНО по размеру всех файлов, т.к. временные бывают разные, а это значит будет внещняя дефрагметация дисков (т.е. заказал диск на 2гиг, а юзаешь на один — один в пролете) это полюбому скажется на производительности.

ТКС>Мы какую задачу решаем — максимально ускорить сборку проекта или максимально заполнить память потенциально ненужными данными? Винда вторую задачу решает, мне интересна первая. И я готов переплатить сотку баков за недоиспользуемое ОЗУ.

так покупай и ставь, зачем говорить. Только не забыдь время, которе надо тратить на копирование во временный диск (и мб обратно)

СМ>>Прения можно бесконечно продолжать. Я замерял и результат сказал. Есть другие _данные_? а не попытки теоризирования?

ТКС>Что конкретно ты замерял? Сферического коня в вакууме? Я пока никакого описания эксперимента тут не видел. И говорить о его применимости к конкретным условиям рановато.

я уже писал. Дело было давно. Подробностей, естественно не помню. Результат был практически одинаков (меньше погрешности измерения).

Я второй раз спрашиваю, Вы замеряли? Хоть что-то? Или просто так

Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>Ну насколько я помню, простому приложению давно никто не разрешает лочить страницы памяти. Т.е., попросить то оно может, но операционка вправе сделать по своему. Поэтому я для ясности и написал про драйвер.

Простому — можно, если у него есть привилегия Lock Pages In Memory. Более того, если она есть, то это простое приложение без всякого драйвера может просто через AWE вывести сать страниц из под управления менедера памяти и свопинга. См. VirtualAlloc/MEM_PHYSICAL, AllocateUserPhysicalPages и т.д.

The AllocateUserPhysicalPages function is used to allocate physical memory. Memory allocated by this function must be physically present in the system. After the memory is allocated, it is locked down and unavailable to the rest of the virtual memory management system.

Здравствуйте, 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>В принципе возможно, но вряд ли что-то даст.

большинство все таки говрят, что это ничего не даст. Давайте или эксперимент ставить (у меня 4 ядра и HT, мне не надо ) или закроем тему.

Здравствуйте, Aen Sidhe, Вы писали:

NBN>>Пробую разные способы ускорить компиляцию. Хочется попробовать такой способ:

AS>Мы используем распараллеливание. 1Gbit локалка + Incredibuild.

Я бы с радостью, но к сожалению нереально пока, по административным и техническим причинам.

Здравствуйте, 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 секунды — на рамдрайве, при многократной поочередной пересборке солюшена. Повторяемость результатов неплохая. Проектец правда маловат, ну да уж какой подвернулся.

Здравствуйте, NikeByNike, Вы писали:

NBN>Не тормозит, просто хочется ускорить как можно сильнее.

А сколько времени сейчас занимает-то ?

NBN>Попытка не пытка.

Пробуй

Здравствуйте, Сергей Мухин, Вы писали:

СМ>большинство все таки говрят, что это ничего не даст. Давайте или эксперимент ставить (у меня 4 ядра и HT, мне не надо ) или закроем тему.

Я готов выбрать второе, но я не ТС, чтобы ее закрывать.

Здравствуйте, Pavel Dvorkin, Вы писали:

NBN>>Не тормозит, просто хочется ускорить как можно сильнее.

PD>А сколько времени сейчас занимает-то ?

Минут 5.

Здравствуйте, zaufi, Вы писали:

PD>>>Хидеры предкомпилируются (надеюсь), а исходников 5-10 Мб.

NBN>>Нет, не предкомпилируются.
Z>вот лучще заморачиваться по этому поводу чем с ram дисками

Предкомпиляция не поддерживается.

Z>5-10-20 МB на фоне ~70MB/sec не даст заметного на глаз выигрыша!

Ок.

Z>нужно заниматься предкомпилированными хидерами... на проекте с интенсивным использованием boost например я выжимал 10-20% в скорости...
Z>далее уже нужно смотреть в сам код... оптимизировать инснациирование шаблонов например... заменять сложный mpl более простым и тд... но временами с этим ничего не поеделать -- на то оно и метапрограммирование (часть работы выполняет компилятор чтобы не выполнять ее в рантайме)

Код не мой, это данность с которой нужно работать.

Здравствуйте, NikeByNike, Вы писали:


PD>>А сколько времени сейчас занимает-то ?

NBN>Минут 5.

Это полная перекомпиляция, так ? Но ведь обычный make затрагивает лишь небольшое число файлов. Или это линковка занимает 5 минут ?

Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>Здравствуйте, Сергей Мухин, Вы писали:

СМ>>>>виднее с точностью до файлов и частей их?

ТКС>>>Когда как. Есть ситуации, когда винда точно будет ошибаться, пытаясь поднять из кэша ненужные данные.

СМ>>точно так же как и диск

ТКС>Тут главное, чтобы выгрузка не делалось в ущерб нужным данным. Диск такую гарантию дает в отношении объектников и 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 хидера. Иначе при изменении хидера не происходило бы перекомпиляции (у других компилеров такое бывает).

СМ>дада, но эта информация у нее уже в голове, это быстро происходит

Это при условии, что компилер помнит используемые хидеры. А если нет — то нужно всё парсить.

Здравствуйте, NikeByNike, Вы писали:


СМ>>дада, но эта информация у нее уже в голове, это быстро происходит

NBN>Это при условии, что компилер помнит используемые хидеры. А если нет — то нужно всё парсить.

парсится один раз, потом хранится (где ниб в suo/ncb) и меняется при изм файлов

Здравствуйте, Сергей Мухин, Вы писали:

СМ>>>дада, но эта информация у нее уже в голове, это быстро происходит

NBN>>Это при условии, что компилер помнит используемые хидеры. А если нет — то нужно всё парсить.

СМ>парсится один раз, потом хранится (где ниб в suo/ncb) и меняется при изм файлов

Это не вижалковский компилятор

Здравствуйте, NikeByNike, Вы писали:

СМ>>парсится один раз, потом хранится (где ниб в suo/ncb) и меняется при изм файлов

NBN>Это не вижалковский компилятор

ну это проблема среды. если нет — так нет. При полном перестроении зависимость и не нужна

Здравствуйте, NikeByNike, Вы писали:

NBN>Это не вижалковский компилятор
А какой?

Здравствуйте, NikeByNike, Вы писали:

PD>>Не знаю как в твоем компиляторе, но VS проверяет не файлы, а их дату и время. Если obj более поздний, чем cpp — значит, не надо компилировать.

NBN>Не. Она так же проверяет все связанные с cpp хидера. Иначе при изменении хидера не происходило бы перекомпиляции (у других компилеров такое бывает).

Ну и жедера тоже, конечно.

Здравствуйте, NikeByNike, Вы писали:

NBN>Пробую разные способы ускорить компиляцию.

Случайно нашел в студии 2010 ключик, который показывает таймирование, что-то вроде такого:

1> 1 ms MakeDir 11 calls
1> 2 ms WriteLinesToFile 4 calls
1> 2 ms SetEnv 4 calls
1> 15 ms CppClean 1 calls
1> 45 ms RC 1 calls
1> 305 ms Link 1 calls
1> 692 ms BSCMake 1 calls
1> 1063 ms CL 2 calls

может пригодиться

Tools\Options...\Projects and Solutions\VC++ Project Settings\Build Timing

Здравствуйте, NikeByNike, Вы писали:

D>>, да и процессор многоядерный даст огромный прирост, i7 например.

NBN>i5 стоит. Мне не кажется, что проц тут узкое место...

Это вам кажется. Проц при компиляции и есть узкое место!
См. загрузку проца во время компиляции — она практически всегда 100%. Если бы проседал дисковый ввод/вывод то проц бы не использовался так интенсивно.

Увеличение количества ядер и ключик /MP (VS компилятор) дают практически линейный прирост производительности.

А компилятор то поддерживает параллельное компилирование?

Здравствуйте, NikeByNike, Вы писали:

NBN>Пробую разные способы ускорить компиляцию.
NBN>Есть некоторый проект весом порядка 5-10 Mb исходников. Кроме того он ссылается на порядка 20 Mb сторонних библиотек и SDK.

Неужели на полный билд этого проекта требуется более чем 10 минут?
Из собственного опыта: куда более достаёт работа линкера, когда даже на минорные правки система откликается молниеносной компиляцией, но долгим ворочанием объектников всяких либ, собирая монолитный EXE или "супер-главную DLL". Поэтому может быть полезно переосмыслить набор свой бинарей, хотя бы для debug-сборки.

NBN>Win7 (64), VS 2005, 4 гига (можно расширить до 8).

А смысл расширять есть? Всё равно 64-битной версии самой Студии пока нет и не предвидится, вроде.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Неужели на полный билд этого проекта требуется более чем 10 минут?
10 минут — раздражают. Хочется чтобы оно происходило за минуту или быстрее

MD>Из собственного опыта: куда более достаёт работа линкера, когда даже на минорные правки система откликается молниеносной компиляцией, но долгим ворочанием объектников всяких либ, собирая монолитный EXE или "супер-главную DLL". Поэтому может быть полезно переосмыслить набор свой бинарей, хотя бы для debug-сборки.
Он и так переосмыслен.

NBN>>Win7 (64), VS 2005, 4 гига (можно расширить до 8).

MD>А смысл расширять есть? Всё равно 64-битной версии самой Студии пока нет и не предвидится, вроде.

Меня интересовал алгоритм создания диска в оперативной памяти и моунтинг его в качестве определённой папки на другом диске.

Здравствуйте, NikeByNike, Вы писали:

NBN>Здравствуйте, Mr.Delphist, Вы писали:

MD>>Неужели на полный билд этого проекта требуется более чем 10 минут?
NBN>10 минут — раздражают. Хочется чтобы оно происходило за минуту или быстрее

Уточню вопрос: это именно инкрементальный билд — 10 минут?
Если да, то что за фарш из шаблонов там применяется? Хотя, тогда вряд ли что-то заметно поможет, кроме IncrediBuild и прочих "облаков".
Если нет, то зачем на дев-машине всегда делать полные билды? Для этого билд-сервер можно припрячь.

Здравствуйте, Mr.Delphist, Вы писали:

MD>>>Неужели на полный билд этого проекта требуется более чем 10 минут?
NBN>>10 минут — раздражают. Хочется чтобы оно происходило за минуту или быстрее

MD>Уточню вопрос: это именно инкрементальный билд — 10 минут?
Нет, это полный билд. Который приходится устраивать сравнительно часто по техническим причинам.

MD>Если нет, то зачем на дев-машине всегда делать полные билды? Для этого билд-сервер можно припрячь.
Недостаточно крупный проект.

Здравствуйте, NikeByNike, Вы писали:

MD>>Если нет, то зачем на дев-машине всегда делать полные билды? Для этого билд-сервер можно припрячь.
NBN>Недостаточно крупный проект.

Это похоже уже на оффтоп, но ИМХО тут надо менять начальство, либо компанию вместе с начальством. У нас даже для самого маленького пилота найдется вся инфраструктура: билд-сервер, репозиторий кода, баг-трекер, портал SharePoint для документов. Ибо это поставлено у админов на поток, достаточно кинуть email с заявкой, они соберут всё как конструктор.

Здравствуйте, Mr.Delphist, Вы писали:

MD>>>Если нет, то зачем на дев-машине всегда делать полные билды? Для этого билд-сервер можно припрячь.
NBN>>Недостаточно крупный проект.

MD>Это похоже уже на оффтоп, но ИМХО тут надо менять начальство, либо компанию вместе с начальством. У нас даже для самого маленького пилота найдется вся инфраструктура: билд-сервер, репозиторий кода, баг-трекер, портал SharePoint для документов. Ибо это поставлено у админов на поток, достаточно кинуть email с заявкой, они соберут всё как конструктор.

Компания замечательная. Меня админы уговаривали компилировать на билдсервере.
Я считаю, что для данного проекта это неудобно и неразумно. Особенно если удастся повысить скорость компиляции ещё немного

Здравствуйте, NikeByNike, Вы писали:

NBN>Есть некоторый проект весом порядка 5-10 Mb исходников. Кроме того он ссылается на порядка 20 Mb сторонних библиотек и SDK.
NBN>Win7 (64), VS 2005, 4 гига (можно расширить до 8).

Ага — переехать на VS2008 и заюзать ключик /MP.

Я после увиденного свернул все работы на 2005-ой. Хотя её компилятор меня полностью устраивал.

На 8 гигах будет реально комфортнее работать. У меня Vista x64.

---
Проект на чистом C++. Габариты приблизительно такие же — в районе 25MB исходников.

До поры до времени его мог асилить и компилятор от BCB5. Кстати — он в один поток компилировал практически с той же скоростью, что и VC9 на четырех ядрах. Правда бинарник получался в 2.5 раза тяжелее и он не работал

Здравствуйте, ilvi, Вы писали:

D>>Кажется VS 2005 не умеет запускать паралельно компиляцию одного проєкта. Хотя тут пишут другое

I>И правильно пишшут. На рабочей машине двухядерный процессор. MSVC 2005 без ключа /MP у меня запускает один процес cl.exe, а с этим ключом два.

Во блин. А я свято верил, что эта фича появилась только в VS2008

Здравствуйте, Коваленко Дмитрий, Вы писали:

NBN>>Есть некоторый проект весом порядка 5-10 Mb исходников. Кроме того он ссылается на порядка 20 Mb сторонних библиотек и SDK.
NBN>>Win7 (64), VS 2005, 4 гига (можно расширить до 8).

КД>Ага — переехать на VS2008 и заюзать ключик /MP.

КД>Я после увиденного свернул все работы на 2005-ой. Хотя её компилятор меня полностью устраивал.

Просмотрел сообщения этого топика.

Гы — оказывается VC8 тоже поддерживает /MP. Попробовал — действительно поддерживает и распараллеливает компиляцию.

Жаль потерянное время...

---
Век живи — век учись

вроде должно получиться, хотя "примаунтить как папку" я никогда не пробовал.
способ с RAM диском — хороший вариант ускорения компиляции,
но не стоит забывать и о "классике" — компиляции в несколько потоков.
начиная с VS2008 появилась соответствующая опция компилятора.
а так большие проекты обычно собираются не VS-проектами, а тулзами,
которые позволяют делать эти и другие удобные вещи (gnumake, scons, etc).
другие менее радикальные средства — это precompiled header и написание
кода с минимумом зависимостей.