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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

Я надеюсь, что это поможет.

Ответ 4

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

Ответ 5

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

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

Ответ 6

Используйте 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;
}

Ответ 7

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

Ответ 8

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

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

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

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

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

Ответ 9

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

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

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

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

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

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

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

Ответ 10

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

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

Ответ 11

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

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

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

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

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

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

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

Ответ 12

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

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

Psuedo-ish shell script, 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, в разделе "Настройки", "Строительство", "Построить продукты в:" и "Место Промежуточные файлы сборки в:".

Ответ 13

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

• RAM-диск VSuite
• DiskBoost

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

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

Ответ 14

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

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

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

Ответ 15

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

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

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

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

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

Ответ 16

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

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

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

Ответ 17

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

sudo vmtouch -d -L ./

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

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

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

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

Ответ 18

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

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

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