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

Условие:
Есть некоторый проект весом порядка 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.

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

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

[Skip]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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/

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

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

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.