RAM-накопитель для компиляции – есть ли такая вещь?

Ответ (см. Ниже) на один из вопросов прямо здесь, на Stack Overflow, дал мне представление о большом небольшом программном обеспечении, которое может быть бесценным для кодеров во всем мире.

Я представляю программное обеспечение RAM-привода, но с одним решающим отличием – это зеркало реальной папки на моем жестком диске. Более конкретно – папка, в которой находится проект, над которым я сейчас работаю. Таким образом, любые сборки будут почти мгновенными (или, по крайней мере, на пару порядков быстрее). Привод RAM будет синхронизировать его содержимое с жестким диском в фоновом режиме, используя только ресурсы бездействия.

Быстрый поиск Google не показал ничего, но, возможно, я просто не знаю, как Google. Может быть, кто-то знает о таком программном обеспечении? Предпочтительно, бесплатные, но разумные сборы могут быть в порядке.

Добавлено: Некоторые решения были предложены, которые я отбросил в самом начале. Они будут (в определенном порядке):

  • Купите более быстрый жесткий диск (например, SSD или 10K RPM). Я не хочу аппаратного решения. Не только программное обеспечение может быть более дешевым (бесплатное программное обеспечение, любое?), Но оно также может использоваться в средах, где модификации оборудования были бы нежелательными, если не невозможными – скажем, в офисе.
  • Пусть OS / HDD делает кэширование – он лучше знает, как использовать вашу бесплатную оперативную память. ОС / HDD имеют общие алгоритмы кеша, которые кэшируют все и пытаются предсказать, какие данные будут наиболее необходимы в будущем. Они понятия не имеют, что для меня приоритетом является папка моего проекта. И, как мы все хорошо знаем, на самом деле они вообще не кэшируют его. 😉
  • Существует множество RAM-накопителей; используйте один из них. Извините, это было бы безрассудно. Мне нужно, чтобы мои данные были синхронизированы на HDD каждый раз, когда есть немного свободного времени. В случае сбоя питания я мог потерять последние пять минут работы, но не все с момента последней проверки.

Добавлено 2: Идея, которая появилась – используйте обычный RAM-диск и синхронизатор фоновой папки (но я имею в виду фон ). Есть ли такая вещь?

Добавлено 3: Интересно. Я просто попробовал простой RAM-накопитель на работе. Время восстановления сокращается с ~ 14 секунд до ~ 7 секунд (неплохо), но инкрементная assembly все еще находится на ~ 5 секунд – как на HDD. Любые идеи почему? Он использует aspnet_compiler и aspnet_merge . Возможно, они что-то делают с другими временными файлами в другом месте?

Добавлено 4: О, хороший новый набор ответов! 🙂 Хорошо, у меня есть немного больше информации для всех вас, скептиков. 🙂

Одной из основных причин этой идеи является не упомянутое выше программное обеспечение (14 сек. Время сборки), а другое, к которому у меня не было доступа в то время. Это другое приложение имеет базовую базу на 100 МБ, а его полная assembly занимает около 5 минут. Ах да, это в Delphi 5 , поэтому компилятор не слишком продвинут. 🙂 Постановка источника на RAM-привод привела к большой разнице. Думаю, я понял это ниже минуты. Я не измерил. Таким образом, для всех тех, кто говорит, что ОС может кэшировать вещи лучше – я бы попросил разницу.

Связанный вопрос:

RAM-диск для ускорения IDE

Примечание по первой ссылке: вопрос, на который он ссылается, был удален, поскольку это был дубликат. Он спросил:

Что вы делаете, пока компилируете свой код?

И ответ Дмитрия Нестеarm, с которым я связался, был:

Я собираюсь почти мгновенно. Отчасти из-за небольших проектов, отчасти из-за использования RAM-дисков.

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

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

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

Я не делаю этого больше (я использовал его для Opera, когда бета-версия 9.5 была медленной, больше не нужно).

Вот как создать RAM-диск в Linux.

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

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

Чтобы начать разработку, запустите RAM-диск и потяните текущую базовую линию. Делайте редактирование, компиляцию, редактирование, компиляцию и т. Д. – все это время редактирование сохраняется для вас.

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

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

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

См. Ускорение emerge с помощью tmpfs ( Gentoo Linux wiki).

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

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

Надеюсь, это поможет.

Ваша ОС будет кэшировать вещи в памяти, поскольку она работает. RAM-диск может показаться более быстрым, но это связано с тем, что вы не факторизуете «копировать в RAMDisk» и «копировать из RAMDisk» раз. Выделение оперативной памяти на фиксированный размер ramdisk просто уменьшает память, доступную для кеширования. ОС лучше знает, что должно быть в ОЗУ.

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

Диск DRAM имеет два порта SATA-300 и выходит с среднем средним значением 0,0 мс на большинстве тестов;) Что-то для рождественского чулка?

Для создания RAM-диска используйте https://wiki.archlinux.org/index.php/Ramdisk .

Затем я написал эти сценарии для перемещения каталогов на и с RAM-диска. Резервное копирование производится в файле tar перед перемещением в RAM-диск. Преимущество этого заключается в том, что путь остается неизменным, поэтому все ваши файлы конфигурации не нужно изменять. Когда вы закончите, используйте uramdir для возврата на диск.

Edit: Добавлен код C, который будет запускать любую команду, которую он задает на интервал в фоновом режиме. Я отправляю его tar с --update для обновления архива, если какие-либо изменения.

Я считаю, что это универсальное решение превосходит уникальное решение чего-то очень простого. ПОЦЕЛУЙ

Убедитесь, что вы изменили путь к rdbackupd

ramdir

 #!/bin/bash # May need some error checking for bad input. # Convert relative path to absolute # /bin/pwd gets real path without symbolic link on my system and pwd # keeps symbolic link. You may need to change it to suit your needs. somedir=`cd $1; /bin/pwd`; somedirparent=`dirname $somedir` # Backup directory /bin/tar cf $somedir.tar $somedir # Copy, tried move like https://wiki.archlinux.org/index.php/Ramdisk # suggests, but I got an error. mkdir -p /mnt/ramdisk$somedir /bin/cp -r $somedir /mnt/ramdisk$somedirparent # Remove directory /bin/rm -r $somedir # Create symbolic link. It needs to be in parent of given folder. /bin/ln -s /mnt/ramdisk$somedir $somedirparent #Run updater ~/bin/rdbackupd "/bin/tar -uf $somedir.tar $somedir" & 

uramdir

 #!/bin/bash #Convert relative path to absolute #somepath would probably make more sense # pwd and not /bin/pwd so we get a symbolic path. somedir=`cd $1; pwd`; # Remove symbolic link rm $somedir # Copy dir back /bin/cp -r /mnt/ramdisk$somedir $somedir # Remove from ramdisk /bin/rm -r /mnt/ramdisk$somedir # Stop killall rdbackupd 

rdbackupd.cpp

 #include  #include  #include  #include  #include  struct itimerval it; char* command; void update_archive(int sig) { system(command); } int main(int argc, char**argv) { it.it_value.tv_sec = 1; // Start right now it.it_value.tv_usec = 0; it.it_interval.tv_sec = 60; // Run every 60 seconds it.it_interval.tv_usec = 0; if (argc < 2) { printf("rdbackupd: Need command to run\n"); return 1; } command = argv[1]; signal(SIGALRM, update_archive); setitimer(ITIMER_REAL, &it, NULL); // Start while(true); return 0; } в #include  #include  #include  #include  #include  struct itimerval it; char* command; void update_archive(int sig) { system(command); } int main(int argc, char**argv) { it.it_value.tv_sec = 1; // Start right now it.it_value.tv_usec = 0; it.it_interval.tv_sec = 60; // Run every 60 seconds it.it_interval.tv_usec = 0; if (argc < 2) { printf("rdbackupd: Need command to run\n"); return 1; } command = argv[1]; signal(SIGALRM, update_archive); setitimer(ITIMER_REAL, &it, NULL); // Start while(true); return 0; } 

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

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

  2. Получите много оперативной памяти. 2 ГБ DIMM очень дешевы; Модули DIMM емкостью 4 ГБ – чуть более US $ 100 / ea, но это все еще не так много денег по сравнению с тем, что компьютерные части стоят всего несколько лет назад. Если вы закончите с RAM-диском или просто позволяете ОС делать свое дело, это поможет. Если вы используете 32-битную Windows, вам нужно переключиться на 64-разрядную версию, чтобы использовать что-либо более 3 ГБ или около того.

  3. Live Mesh может синхронизироваться с вашего локального RAM-накопителя на облаке или на другом компьютере, предоставляя вам обновленную резервную копию.

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

  5. Рассмотрим DVCS . Клон с реального диска в новый repository на RAM-диске. «Нажимайте» свои изменения обратно на родителя часто, скажите каждый раз, когда все ваши тесты проходят.

У меня была такая же идея, и я сделал некоторые исследования. Я нашел следующие инструменты, которые делают то, что вы ищете:

  • RAM-диск VSuite
  • DiskBoost

Тем не менее, второй, который мне не удался вообще работать с 64-разрядной Windows 7, и он, похоже, не поддерживается на данный момент.

RAM-диск VSuite с другой стороны работает очень хорошо. К сожалению, я не смог измерить значительный прирост производительности по сравнению с диском SSD на месте.

Да, я встретил ту же проблему. И после бесплодного googling я просто написал службу Windows для ленивой резервной копии RAM-диска (на самом деле – любую папку, потому что RAM-диск можно смонтировать, например, на рабочем столе).

http://bitbucket.org/xkip/transparentbackup Вы можете указать интервал для полного сканирования (по умолчанию 5 минут). И интервал для сканирования только уведомленных файлов (по умолчанию 30 секунд). Сканирование обнаруживает измененные файлы с использованием атрибута «archive» (ОС сбрасывает его специально для целей архивирования). Только резервные копии файлов, модифицированных таким образом.

Служба оставляет специальный файл маркера, чтобы убедиться, что целевая резервная копия является в точности резервной копией источника. Если источник пуст и не содержит файла маркера, служба выполняет автоматическое восстановление из резервной копии. Таким образом, вы можете легко уничтожить RAM-диск и создать его снова с автоматическим восстановлением данных. Лучше использовать RAM-накопитель, который может создать раздел при запуске системы, чтобы он работал прозрачно.

Еще одно решение, которое я недавно обнаружил, – SuperCache SuperSpeed .

У этой компании также есть RAM-диск, но это еще одно программное обеспечение. SuperCache позволяет использовать дополнительную ОЗУ для кэширования на уровне блоков (он сильно отличается от кэширования файлов), а другой вариант – зеркало, которое вы полностью управляете ОЗУ. В любом сценарии вы можете указать, как часто отбрасывать грязные блоки обратно на жесткий диск, делая записи, как на RAM-диске, но в зеркальном сценарии также делаются чтения, как с диска RAM. Вы можете создать небольшой раздел, например, 2 ГБ (с использованием Windows) и сопоставить весь раздел с ОЗУ.

Одна интересная и очень полезная вещь в этом решении – вы можете изменить параметры кеширования и зеркалирования в любое время только мгновенно двумя щелчками мыши. Например, если вы хотите, чтобы ваш 2 ГБ назад для gamimg или виртуальной машины – вы можете просто прекратить зеркалирование сразу и освободить память. Даже открытые дескрипторы файлов не прерываются – раздел продолжает работать, но как обычный диск.

EDIT: Я также настоятельно рекомендую вам перемещать папку TEMP в дисковод RAM, поскольку компиляторы обычно выполняют большую работу с temp. В моем случае это дало мне еще 30% скорости компиляции.

Интересно, можете ли вы создать что-то вроде программного RAID 1, в котором у вас есть физический диск / раздел в качестве члена, и кусок ОЗУ в качестве члена.

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

Есть много RAMDrives, используйте один из них. Извините, это было бы безрассудно.

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

Скрипт оболочки Psuedo-ish, 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, он находится в разделе «Настройки», «Строительство», «Разместить сборку продуктов в:» и «Разместить файлы промежуточной сборки» в:”.

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

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

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

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

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

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

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

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

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

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

Некоторые идеи с головы:

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

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

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

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

Замедление вашего диска в основном записывается, а также, возможно, из-за вирусных сканеров. Он также может сильно различаться между ОС.

С идеей, что записи медленнее, у меня возникнет соблазн установить сборку, где промежуточные (например, .o файлы) и двоичные файлы будут выводиться в другое место, такое как RAM-диск.

Затем вы можете связать эту папку bin / intermediate с более быстрым носителем (используя символическую ссылку или точку соединения NTFS ).

Моим окончательным решением проблемы является vmtouch: https://hoytech.com/vmtouch/ Этот инструмент блокирует текущую папку в (ram) кеш, а vmtouch – в фоновом режиме.

 sudo vmtouch -d -L ./ 

Поместите это в shell rc для быстрого доступа:

 alias cacheThis = 'sudo vmtouch -d -L ./' 

Я долго искал готовый скрипт, потому что не хотел тратить много времени на создание собственного скрипта ramdisk-rsync. Я уверен, что я бы пропустил некоторые крайние случаи, что было бы весьма неприятно, если бы был задействован важный код. И мне никогда не нравился подход к опросу.

Vmtouch кажется идеальным решением. Кроме того, он не теряет память, как это делает ramdisk с фиксированным размером. Я не делал бенчмарка, потому что 90% моей исходной + build-папки 1Gig уже были кешированы, но по крайней мере она чувствует себя быстрее;)

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

RAM-диски были полезны, когда операционные системы были созданы с такими ограничениями, как глупые кеши (Win 3.x, Win 95, DOS). Преимущество RAM-диска почти нулевое, и если вы назначаете много оперативной памяти, он будет отсосать память, доступную диспетчеру системного кеша, что ухудшит общую производительность системы. Эмпирическое правило: пусть ваше kernel ​​это сделает. Это то же самое, что и программы «деfragmentации памяти» или «оптимизаторы»: они фактически вытесняют страницы из кеша (поэтому в конечном итоге вы получаете больше ОЗУ), но заставляя систему делать много сбоев страниц с течением времени, когда ваши загруженные программы начните запрашивать код / ​​данные, которые были выгружены.

Таким образом, для повышения производительности, получите аппаратную подсистему быстрого ввода-вывода на диске, возможно, RAID, более быстрый процессор, лучший чипсет (без VIA!), Больше физической памяти и т. Д.

Давайте будем гением компьютера.