Электронный диск для компиляции - является там такой вещью?

В Linux (Вы никогда не упоминали, который ОС Вы идете, таким образом, это могло быть релевантным) можно создать блочные устройства из RAM и смонтировать их как любое другое блочное устройство (то есть, жесткий диск).

можно тогда создать сценарии, которые копируют в и от того диска на запуске / завершение работы, а также периодически.

, Например, Вы могли настроить его так, Вы имели ~/code и ~/code-real. Ваш блок RAM смонтирован в ~/code на запуске, и затем всем от ~/code-real (который находится на Вашем стандартном жестком диске), копируется. На завершении работы все было бы скопировано (, rsync 'd будет быстрее), назад от ~/code до ~/code-real. Вы также, вероятно, хотели бы, чтобы тот сценарий периодически работал, таким образом, Вы не потеряли много работы в случае сбоя питания, и т.д.

я больше не делаю этого (я использовал его для Opera , когда 9,5 бет были медленными, никакая потребность больше).

Вот то, как создать псевдодиск в Linux.

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

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

, Так как этот вопрос первоначально задали, вращающиеся жесткие диски стали скудными черепахами когда по сравнению с SSD. Они очень близко к первоначально требуемому псевдодиску в SKU, который можно купить у Newegg или Amazon.

Интересно, могли ли Вы создать что-то как программное обеспечение RAID 1, где у Вас есть физический диск / раздел как участник и блок RAM как участник.

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

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

2. Получают много RAM. 2  ГБ DIMMs является очень дешевым; 4  DIMMs ГБ составляют немногим более, чем 100/EA долларов США, но это все еще не много денег по сравнению с тем, чего компьютерные части стоили всего несколько лет назад. Заканчиваете ли Вы с псевдодиском или просто разрешением ОС сделать ее вещь, это поможет. При запуске 32-разрядного Windows необходимо будет переключиться на 64-разрядный для использования чего-либо по 3  ГБ или около этого.

3. Живая Сетка может синхронизироваться от Вашего локального Электронного диска до облака или к другому компьютеру, давая Вам актуальное резервное копирование.

4. Перемещение просто выходы компилятора. Сохраняют Ваш исходный код на реальном физическом диске, но прямой .obj, .dll, и .exe файлы, которые будут созданы на Электронном диске.

5. Рассматривают DVCS. Клон от реального диска до нового репозитория на Электронном диске. "продвиньте" свои изменения назад в родителе часто, скажите каждый раз всю Вашу тестовую передачу.

Я не имею точно, что Вы ищете, но я теперь использую комбинацию Электронный диск и электронный диск DRAM . Так как это - Windows, у меня есть твердое 3  предел ГБ для оперативной памяти, имея в виду я не могу использовать слишком много памяти для псевдодиска. 4  ГБ, дополнительный на 9010 действительно скалы это. Я позволяю своему IDE сохранить весь свой временный материал на твердотельном псевдодиске и также Знаток репозиторий. Псевдодиск DRAM имеет резервный аккумулятор на карту флэш-памяти. Это походит на рекламу, но это действительно - превосходная установка.

диск DRAM имеет двойной SATA 300 портов и выпускает 0.0  среднее число мс ищет на большинстве тестов;) Что-то для Чулка для рождественских подарков?

Мы раньше делали это несколько лет назад для 4GL макрокомпилятор; если Вы помещаете библиотеку макросов и вспомогательные библиотеки, и Ваш код псевдодиска, компилируя приложение (на 80286) пошел бы от 20 минут до 30 секунд.

Ваша ОС будет кэшировать вещи в памяти, поскольку это работает. Псевдодиск мог бы казаться быстрее, но поэтому Вы не включаете в "копию к ЭЛЕКТРОННОМУ ДИСКУ" и "копию с ЭЛЕКТРОННОГО ДИСКА" времена. Выделение RAM к электронному диску фиксированного размера просто уменьшает память, доступную для кэширования. ОС знает лучше что потребности быть в RAM.

См. , Ускорение появляется с tmpfs ( хинду Linux wiki).

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

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

я надеюсь, что это помогает.

Так же, как James Curran говорит, то, что большинство программ следует закону местности ссылок, частое количество кодовой страницы и страницы данных будет сужаться со временем к управляемому размеру дисковым кэшем ОС.

Псевдодиски были полезны, когда операционные системы были созданы с ограничениями, такими как глупые кэши (Win 3.x, Win 95, DOS). Преимуществом псевдодиска является близкий нуль и если Вы присвоите много RAM, то это высосет память, доступную системному диспетчеру кэша, повреждая полную производительность системы. Эмпирическое правило: позвольте своему ядру, чтобы сделать это. Это совпадает с "дефрагментацией памяти" или программами "оптимизаторов": они на самом деле вынуждают страницы покинуть кэш (таким образом, Вы получаете больше RAM в конечном счете), но то, чтобы заставлять систему делать большой сбой страницы со временем, когда Ваши загруженные программы начинают просить код/данные, который был разбит на страницы.

Таким образом для большего количества производительности, получите быстрый диск аппаратная подсистема ввода-вывода, возможно, RAID, более быстрый ЦП, лучший чипсет (не ЧЕРЕЗ!), больше физической RAM, и т.д.

Некоторые идеи первое, что пришло на ум:

Используйте Монитор Процесса Sysinternals (не  Проводник Процесса) для проверки то, что продолжается во время сборки - это позволит Вам видеть если %temp% используется, например (имейте в виду, что файлы ответа, вероятно, создаются с FILE_ATTRIBUTE_TEMPORARY, который должен предотвратить записи на диск, если это возможно, хотя). Я переместил мой %TEMP% к псевдодиску, и это дает мне незначительные ускорения в целом.

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

Поместите свои often-used/large заголовочные файлы в псевдодиск и переопределите Ваши пути стандарта компилятора для использования копий Электронного диска. Это, вероятно, не даст так большую часть улучшения после новых сборок, тем не менее, поскольку ОС кэширует стандартные заголовки.

Сохраните свои исходные файлы на Вашем жестком диске и синхронизацию к псевдодиску - не наоборот. Проверьте MirrorFolder для того, чтобы сделать синхронизацию в реальном времени между папками - это достигает этого через драйвер фильтра, поэтому только синхронизирует то, что необходимо (и только делает изменения - запись на 4 КБ в файл на 2 ГБ только вызовет запись на 4 КБ к целевой папке). Фигура, как заставить Ваш IDE создать из Электронного диска, хотя исходные файлы находятся на Вашем жестком диске... и имеют в виду необходимость в большом Электронном диске для крупных проектов.

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

Необходимо удостовериться, что у Вас есть RAM для поддержки этого (не должна быть проблема на современной рабочей станции), иначе Вы закончите тем, что подкачали, и это побеждает цель.

На GNU делают, можно просто использовать -j[n] где [n] количество одновременных процессов для порождения. Удостоверьтесь, что Вы имеете свое право дерева зависимостей прежде, чем попробовать его, хотя или результаты может быть непредсказуемым.

Другой инструмент это действительно полезно (в параллели делают вид) является distcc. Это работает обработка с GCC (если можно использовать GCC или что-то с подобным интерфейсом командной строки). distcc на самом деле разбивает задачу компиляции, симулируя быть компилятором и порождая задачи на удаленных серверах. Вы называете его таким же образом, как Вы назвали бы GCC, и Вы используете в своих интересах-j make [n] опция назвать много процессов distcc.

В одном из моих предыдущих заданий у нас была довольно интенсивная сборка операционной системы Linux, которая выполнялась почти ежедневно некоторое время. Добавление в нескольких выделенных машинах сборки и помещение distcc на нескольких рабочих станциях для принятия заданий компиляции позволили нам снижать время изготовления от половины дня к менее чем 60 минутам для полной ОС + сборка пространства пользователя.

Существует много других инструментов для ускорения существующих компиляций. Вы могли бы хотеть исследовать больше, чем создание псевдодисков; что-то, что похоже на него, будет иметь очень мало усиления, так как ОС делает кэширование диска с RAM. Разработчики ОС тратят большой разбирающийся времени, кэширующийся для большинства рабочих нагрузок; они (коллективно) более умны, чем Вы, таким образом, я не хотел бы пытаться добиться большего успеха, чем они.

Если Вы уничтожаете RAM для псевдодиска, ОС имеет менее рабочую RAM к данным кэша и выполнять Ваш код-> Вы закончите с большим свопингом и худшей производительностью диска, чем иначе (примечание: необходимо представить эту опцию прежде полностью отбросить его).

Существует много RAMDrives вокруг, использует одного из тех. Извините, это было бы опрометчиво.

Только если Вы работаете полностью в диске RAM, который глуп..

Сценарий оболочки Psuedo-выхода, ramMake:

# setup locations
$ramdrive = /Volumes/ramspace
$project = $HOME/code/someproject

# ..create ram drive..

# sync project directory to RAM drive
rsync -av $project $ramdrive

# build
cd $ramdrive
make

#optional, copy the built data to the project directory:
rsync $ramdrive/build $project/build

Тем не менее Ваш компилятор может возможно сделать это без дополнительных сценариев.. Просто измените свое выходное местоположение сборки к диску RAM, например, в XCode, оно находится под Предпочтениями, Зданием, "Продукты Сборки места в": и "Промежуточные Файлы типа "build" места в":.

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

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

Для запуска разработки запустите псевдодиск и вытяните текущую основную линию. Сделайте редактирование, скомпилируйте, отредактируйте, скомпилируйте, и т.д. - все время, редактирования сохраняются для Вас.

Выполните в последней проверке, когда счастливый, и Вы не должны даже включать свой обычный жесткий диск.

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

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