ОЗУ для компиляции - есть такая вещь?
Ответ (см. Ниже) на один из вопросов прямо здесь, на Stack Overflow, дал мне идею для отличного небольшого кусочка программного обеспечения, которое могло бы быть бесценным для программистов во всем мире.
Я представляю программное обеспечение RAM-привода, но с одним принципиальным отличием - оно будет отражать настоящую папку на моем жестком диске. Более конкретно - папка, в которой находится проект, над которым я сейчас работаю. Таким образом, любая сборка будет почти мгновенной (или, по крайней мере, на пару порядков быстрее). ОЗУ будет синхронизировать свое содержимое с жестким диском в фоновом режиме, используя только свободные ресурсы.
Быстрый поиск в Google ничего не показал, но, возможно, я просто не знаю, как Google. Возможно, кто-то знает о таком программном обеспечении? Желательно бесплатно, но разумные сборы тоже могут быть в порядке.
Добавлено: было предложено несколько решений, от которых я отказался в самом начале. Они будут (в произвольном порядке):
- Купите более быстрый жесткий диск (возможно, SSD или 10K RPM). Я не хочу аппаратного решения. Не только программное обеспечение может быть дешевле (бесплатно, кто-нибудь?), Но оно также может быть использовано в средах, где модификации оборудования будут нежелательны, если не невозможны, скажем, в офисе.
- Пусть OS/HDD выполняет кеширование - он лучше знает, как использовать вашу свободную оперативную память. OS/HDD имеют общие алгоритмы кэширования, которые кэшируют все и пытаются предсказать, какие данные будут наиболее необходимы в будущем. Они понятия не имеют, что для меня приоритетной является папка моего проекта. И, как мы все прекрасно знаем, они все равно мало что кешируют.;)
- Есть много RAM-дисков; используйте один из них. Извините, это было бы безрассудно. Мне нужно, чтобы мои данные были синхронизированы обратно на жесткий диск всякий раз, когда есть немного свободного времени. В случае сбоя в электроснабжении я мог потерять последние пять минут работы, но не все со времени моей последней проверки.
Добавлено 2: Идея, которая пришла - использовать обычный RAM-накопитель плюс синхронизатор фоновых папок (но я имею в виду фоновый). Есть ли такая вещь?
Добавлено 3: Интересно. Я только что опробовал простой привод RAM на работе. Время восстановления уменьшается с ~14 секунд до ~7 секунд (неплохо), но приростная сборка по-прежнему составляет ~5 секунд - как на жестком диске. Есть идеи почему? Оно использует aspnet_compiler а также aspnet_merge, Возможно, они делают что-то с другими временными файлами в другом месте?
Добавлено 4: О, хороший новый набор ответов!:) Хорошо, у меня есть немного больше информации для всех вас, скептиков.:)
Одной из основных причин этой идеи является не упомянутое выше программное обеспечение (время сборки 14 секунд), а другая, к которой у меня не было доступа в то время. Это другое приложение имеет базу кода 100 МБ, а полная сборка занимает около 5 минут. Ах да, это в Delphi 5, так что компилятор не слишком продвинутый.:) Размещение источника на RAM-диске привело к большой разнице. Думаю, у меня это меньше минуты. Я не измерял. Так что для всех тех, кто говорит, что ОС может лучше кешировать вещи - я позволю себе не согласиться.
Связанный вопрос:
Примечание к первой ссылке: Вопрос, на который он ссылается, был удален, поскольку он был дубликатом. Он спросил:
Что вы делаете во время компиляции вашего кода?
И ответ Dmitri Nesteruk, с которым я связан, был:
Я компилирую почти мгновенно. Частично из-за небольших проектов, частично из-за использования RAM-дисков.
18 ответов
В Linux (вы никогда не упоминали, в какой ОС вы работаете, так что это может иметь значение) вы можете создавать блочные устройства из ОЗУ и монтировать их, как любое другое блочное устройство (то есть жесткий диск).
Затем вы можете создавать сценарии, которые копируются на этот диск и с него при запуске / завершении работы, а также периодически.
Например, вы можете настроить его так, чтобы вы имели ~/code а также ~/code-real, Ваш блок оперативной памяти устанавливается в ~/code при запуске, а затем все из ~/code-real (который находится на вашем стандартном жестком диске) копируется. При выключении все будет скопировано ( rsync'd будет быстрее) обратно из ~/code в ~/code-real, Возможно, вы также захотите, чтобы этот сценарий запускался периодически, чтобы вы не потеряли много работы в случае сбоя питания и т. Д.
Я больше этим не занимаюсь (я использовал его для Opera, когда бета-версия 9.5 была медленной, больше не нужно).
Я удивлен тем, как много людей полагают, что ОС сможет лучше определить ваши потребности в кешировании, чем вы в этом специализированном случае. Хотя я не делал этого для компиляции, я делал это для аналогичных процессов, и в итоге я использовал RAM-диск со скриптами, которые автоматизировали синхронизацию.
В этом случае, я думаю, я бы использовал современную систему контроля версий. При каждой компиляции он автоматически проверяет исходный код (при необходимости на экспериментальной ветке), чтобы каждая компиляция приводила к сохранению данных.
Чтобы начать разработку, запустите RAM-диск и вытяните текущую базовую строку. Делайте редактирование, компилируйте, редактируйте, компилируйте и т. Д. - все это время изменения сохраняются для вас.
Сделайте окончательный заезд, когда будете довольны, и вам даже не придется задействовать свой обычный жесткий диск.
Но есть фоновые синхронизаторы, которые будут автоматизировать вещи - проблема в том, что они также не будут оптимизированы для программирования и, возможно, придется периодически выполнять полное сканирование каталогов и файлов, чтобы отследить изменения. Система управления исходным кодом разработана именно для этой цели, поэтому она, вероятно, будет меньше накладных расходов, даже если она существует в вашей конфигурации сборки.
Имейте в виду, что задача фоновой синхронизации в случае отключения питания не определена. В конечном итоге вам придется выяснить, что было спасено, а что нет, если что-то пойдет не так. С определенной точкой сохранения (при каждой компиляции или принудительно вручную) у вас будет довольно хорошая идея, что она, по крайней мере, находится в состоянии, когда вы думали, что сможете ее скомпилировать. Используйте VCS, и вы можете легко сравнить его с предыдущим кодом и посмотреть, какие изменения вы уже применили.
Смотрите раздел Ускорение появления с помощью tmpfs ( Gentoo Linux wiki).
Ускорение компиляции с использованием RAM-дисков под Gentoo было предметом практических рекомендаций, написанных много лет назад. Это конкретный пример того, что было сделано. Суть в том, что весь исходный файл и промежуточный файл сборки перенаправляются на RAM-диск для компиляции, а окончательные двоичные файлы направляются на жесткий диск для установки.
Кроме того, я рекомендую изучить поддержку вашего источника на жестком диске, но git push ваш последний исходный код изменяется на репозиторий клонов, который находится на диске RAM. Скомпилируйте клон. Используйте ваш любимый скрипт для копирования созданных двоичных файлов.
Надеюсь, это поможет.
Используйте https://wiki.archlinux.org/index.php/Ramdisk для создания RAM-диска.
Затем я написал эти сценарии для перемещения каталогов на RAM-диск и обратно. Резервное копирование производится в tar- файл перед перемещением на RAM-диск. Преимущество такого способа состоит в том, что путь остается тем же, поэтому все ваши файлы конфигурации не нужно менять. Когда вы закончите, используйте uramdir вернуть на диск.
Изменить: Добавлен код 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 <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <signal.h>
#include <sys/time.h>
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;
}
Да, я встречал ту же проблему. И после бесплодного поиска в Google я просто написал Windows Service для ленивого резервного копирования RAM-диска (фактически - любой папки, потому что RAM-диск может быть подключен, например, к рабочему столу).
http://bitbucket.org/xkip/transparentbackup Вы можете указать интервал для полного сканирования (по умолчанию 5 минут). И интервал для проверки только уведомленных файлов (по умолчанию 30 секунд). Сканирование обнаруживает измененные файлы с помощью атрибута "архив" (ОС сбрасывает этот файл специально для целей архивирования). Резервируются только файлы, измененные таким образом.
Служба оставляет специальный файл маркера, чтобы убедиться, что целевая резервная копия является именно резервной копией источника. Если источник пуст и не содержит файл маркера, служба выполняет автоматическое восстановление из резервной копии. Таким образом, вы можете легко уничтожить диск RAM и создать его заново с автоматическим восстановлением данных. Лучше использовать RAM-диск, который может создать раздел при запуске системы, чтобы он работал прозрачно.
Другое решение, которое я недавно обнаружил, - SuperSpeed SuperCache.
У этой компании также есть RAM-диск, но это другое программное обеспечение. SuperCache позволяет использовать дополнительную оперативную память для кэширования на уровне блоков (она сильно отличается от кэширования файлов), а также другой вариант - полностью зеркалировать диск в оперативную память. В любом сценарии вы можете указать, как часто отбрасывать грязные блоки обратно на жесткий диск, делая записи как на RAM-диске, но зеркальный сценарий также делает чтение как с RAM-диска. Вы можете создать небольшой раздел, например, 2 ГБ (используя Windows) и отобразить весь раздел в ОЗУ.
Одна интересная и очень полезная вещь об этом решении - вы можете изменить параметры кэширования и зеркалирования в любое время, просто мгновенно с помощью двух кликов. Например, если вы хотите вернуть свои 2 ГБ для игры или виртуальной машины - вы можете просто немедленно прекратить зеркалирование и освободить память. Даже открытые файловые дескрипторы не ломаются - раздел продолжает работать, но как обычный диск.
РЕДАКТИРОВАТЬ: Я также настоятельно рекомендую вам переместить папку TEMP на RAM-диск, потому что компиляторы обычно много работают с temp. В моем случае это дало мне еще 30% скорости компиляции.
У меня нет именно того, что вы ищете, но сейчас я использую комбинацию Ramdisk и RAM- диска DRAM. Поскольку это Windows, у меня жесткое ограничение в 3 ГБ для основной памяти, что означает, что я не могу использовать слишком много памяти для RAM-диска. 4 ГБ на 9010 действительно впечатляют. Я позволил своей IDE хранить все свои временные данные на твердотельном RAM-диске, а также в репозитории Maven. На RAM-диске DRAM есть резервная батарея на флэш-карту. Это звучит как реклама, но это действительно отличная установка.
Диск DRAM имеет двойные порты SATA-300 и в большинстве тестов имеет среднее значение 0,0 мс;) Что-нибудь для рождественского чулка?
Мы делали это несколько лет назад для макрокомпилятора 4GL; если вы поместите библиотеку макросов и вспомогательные библиотеки и ваш код на RAM-диск, компиляция приложения (на 80286) займет от 20 минут до 30 секунд.
Ваша ОС будет кэшировать вещи в памяти, как это работает. Диск RAM может показаться быстрее, но это потому, что вы не учитываете время "копирования на RAMDisk" и "копирования с RAMDisk". Выделение ОЗУ на виртуальный диск фиксированного размера просто уменьшает объем памяти, доступной для кэширования. ОС лучше знает, что должно быть в оперативной памяти.
У меня была та же идея, и я провел небольшое исследование. Я нашел следующие инструменты, которые делают то, что вы ищете:
Тем не менее, второй вариант, который мне вообще не удалось заставить работать на 64-битной Windows 7, и, похоже, на данный момент не поддерживается.
С другой стороны, RAM-диск VSuite работает очень хорошо. К сожалению, я не смог измерить сколько-нибудь значительного прироста производительности по сравнению с имеющимся SSD- диском.
Профиль. Убедитесь, что вы делаете хорошие измерения для каждого варианта. Вы даже можете купить вещи, которые вы уже отклонили, измерить их и вернуть их, чтобы вы знали, что работаете с хорошими данными.
Получите много оперативной памяти. 2 ГБ DIMM очень дешевы; Модули DIMM емкостью 4 ГБ стоят чуть более 100 долларов США за штуку, но это все же не так много денег по сравнению с тем, что стоило компьютерных компонентов всего несколько лет назад. Независимо от того, получите ли вы диск с ОЗУ или просто дадите ОС сделать свое дело, это поможет. Если вы используете 32-разрядную версию Windows, вам нужно переключиться на 64-разрядную версию, чтобы использовать что-либо более 3 ГБ или около того.
Live Mesh может синхронизироваться с локального ОЗУ в облаке или на другом компьютере, предоставляя вам актуальную резервную копию.
Переместите только выходные данные компилятора. Сохраняйте исходный код на реальном физическом диске, но прямые файлы.obj, .dll и.exe должны создаваться на диске RAM.
Рассмотрим DVCS. Клонировать с реального диска в новый репозиторий на диске RAM. часто "передавайте" ваши изменения родителю, скажем, каждый раз, когда все ваши тесты пройдены.
То, что может быть супер полезным даже на одноядерном компьютере, - это параллельное изготовление. Дисковый ввод-вывод является довольно важным фактором в процессе сборки. Создание двух экземпляров компилятора на ядро ЦП может фактически повысить производительность. Поскольку один экземпляр компилятора блокирует ввод-вывод, другой обычно может перейти в интенсивную часть ЦП компиляции.
Вы должны убедиться, что у вас есть оперативная память для поддержки этого (это не должно быть проблемой на современной рабочей станции), в противном случае вы в конечном итоге поменяетесь, и это побеждает цель.
На GNU make вы можете просто использовать -j[n] где [n] число одновременных процессов Убедитесь, что у вас есть дерево зависимостей, прежде чем пытаться его использовать, иначе результаты могут быть непредсказуемыми.
Другой инструмент, который действительно полезен (в моде параллельного создания), это distcc. Он работает с GCC (если вы можете использовать GCC или что-то подобное в интерфейсе командной строки). distcc на самом деле разбивает задачу компиляции, притворяясь компилятором и порождая задачи на удаленных серверах. Вы вызываете его так же, как и GCC, и используете опцию make -j[n] для вызова многих процессов distcc.
На одной из моих предыдущих работ у нас была довольно интенсивная сборка операционной системы Linux, которая некоторое время выполнялась почти ежедневно. Добавление нескольких выделенных машин сборки и размещение distcc на нескольких рабочих станциях для принятия заданий компиляции позволило нам сократить время сборки с полдня до менее 60 минут для полной сборки OS + userpace.
Существует множество других инструментов для ускорения компиляции. Возможно, вы захотите исследовать больше, чем создание RAM-дисков; что-то похожее на это будет очень мало, так как ОС выполняет кэширование диска с RAM. Разработчики ОС тратят много времени на правильное кэширование для большинства рабочих нагрузок; они (в совокупности) умнее вас, поэтому я не хотел бы стараться делать их лучше, чем они.
Если вы "жуете" ОЗУ для RAM-диска, у ОС меньше оперативной памяти для кеширования данных и выполнения кода -> вы получите больший объем подкачки и более низкую производительность диска, чем в противном случае (примечание: вам следует профилировать эту опцию перед полным удалением Это).
Интересно, вы могли бы создать что-то вроде программного RAID 1, где у вас есть физический диск / раздел в качестве члена и кусок оперативной памяти в качестве члена.
Бьюсь об заклад, с небольшой подстройкой и некоторыми действительно странными настройками, можно заставить Linux сделать это. Я не уверен, что это стоило бы усилий, хотя.
Есть много RAMDrive вокруг, используйте один из них. Извините, это было бы безрассудно.
Только если вы работаете полностью на 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, он находится в Preferences, Building, "Поместить продукты сборки в:" и "Поместить промежуточные файлы сборки". в:".
Мое окончательное решение проблемы - vmtouch: https://hoytech.com/vmtouch/ Этот инструмент блокирует текущую папку в (ram) кеше и vmtouch превращается в фон.
sudo vmtouch -d -L ./
Поместите это в shell rc для быстрого доступа:
alias cacheThis = 'sudo vmtouch -d -L ./'
Я долго искал готовый скрипт, потому что не хотел тратить много времени на написание своего собственного ramdisk-rsync-script. Я уверен, что я пропустил бы некоторые крайние случаи, которые были бы весьма неприятны, если бы был задействован важный код. И мне никогда не нравился подход к опросу.
Vmtouch кажется идеальным решением. Кроме того, он не тратит память, как это делает рамдиск фиксированного размера. Я не делал бенчмаркинг, потому что 90% моей папки Source + build 1Gig уже были кэшированы, но, по крайней мере, это чувствуется быстрее;)
Некоторые идеи из головы:
Используйте Process Monitor Sysinternals (не Process Explorer), чтобы проверить, что происходит во время сборки - это позволит вам увидеть, если %temp% например, используется (имейте в виду, что файлы ответов, вероятно, создаются с помощью FILE_ATTRIBUTE_TEMPORARY, который должен по возможности предотвращать запись на диск). Я переехал %TEMP% на диск RAM, и это дает мне небольшие ускорения в целом.
Получите RAM-диск, который поддерживает автоматическую загрузку / сохранение образов дисков, так что вам не нужно использовать загрузочные скрипты для этого. Последовательное чтение / запись одного образа диска быстрее, чем синхронизация большого количества маленьких файлов.
Поместите часто используемые / большие заголовочные файлы на RAM-диск и измените стандартные пути вашего компилятора, чтобы использовать копии RAM-диска. Это, вероятно, не даст такого улучшения после первоначальной сборки, поскольку ОС кэширует стандартные заголовки.
Храните исходные файлы на жестком диске и синхронизируйте их с RAM-диском, а не наоборот. Проверьте MirrorFolder для выполнения синхронизации между папками в реальном времени - он достигает этого через драйвер фильтра, поэтому синхронизирует только то, что необходимо (и только вносит изменения - запись 4 КБ в файл 2 ГБ приведет только к записи 4 КБ в целевую папку). Узнайте, как сделать вашу IDE- сборку из ОЗУ, хотя исходные файлы находятся на вашем жестком диске... и имейте в виду, что для больших проектов вам понадобится большой ОЗУ.
Замедление работы диска происходит в основном из-за записи, а также, возможно, из-за антивирусных сканеров. Это может сильно отличаться в зависимости от операционной системы.
С идеей, что запись идет медленнее, я бы соблазнился настроить сборку, где промежуточный (например, .o файлы) и двоичные файлы получают выходные данные в другом месте, например, на диске RAM.
Затем вы можете связать эту папку bin/ промежуточную папку с более быстрым носителем (используя символическую ссылку или точку соединения NTFS).
Это похоже на кеширование диска, которое ваша операционная система и / или жесткий диск будет обрабатывать для вас автоматически (допустимо, с различной степенью производительности).
Мой совет: если вам не нравится скорость вашего диска, купите высокоскоростной диск исключительно для целей компиляции. Меньше труда с вашей стороны, и у вас может быть решение ваших проблем компиляции.
С тех пор как этот вопрос был задан изначально, вращающиеся жесткие диски стали жалкими черепахами по сравнению с твердотельными накопителями. Они очень близки к первоначально запрошенному RAM-диску в SKU, который вы можете приобрести в Newegg или Amazon.
Так же, как говорит Джеймс Керран, тот факт, что большинство программ следуют закону локальности ссылок, частый код и количество страниц данных будут с течением времени сужаться до управляемого размера с помощью дискового кэша ОС.
RAM-диски были полезны, когда операционные системы создавались с такими ограничениями, как тупые кеши (Win 3.x, Win 95, DOS). Преимущество ОЗУ почти равно нулю, и если вы выделите много ОЗУ, оно высосет память, доступную для менеджера системного кэша, что снизит общую производительность системы. Основное правило таково: пусть ваше ядро сделает это. Это то же самое, что и программы "дефрагментация памяти" или "оптимизаторы": они фактически вытесняют страницы из кэша (таким образом, вы в конечном итоге получаете больше оперативной памяти), но заставляете систему делать много сбоев страниц со временем, когда ваши загруженные программы начать просить код / данные, которые были выгружены.
Поэтому для большей производительности приобретите аппаратную подсистему быстрого дискового ввода-вывода, может быть, RAID, более быстрый процессор, лучший чипсет (без VIA!), Больше физической памяти и т. Д.