RAM lecteur pour la compilation - existe-t-il une telle chose?
Une réponse (voir ci-dessous) une des questions ici sur Stack Overflow m’a donné l’idée d’un petit logiciel génial qui pourrait être inestimable pour les codeurs du monde entier.
J'imagine le logiciel de lecteur RAM, mais avec une différence cruciale: il va refléter un vrai dossier sur mon disque dur. Plus précisément, le dossier contenant le projet sur lequel je travaille actuellement. De cette façon, toutes les constructions seraient presque instantanées (ou au moins quelques ordres de grandeur plus rapidement). Le lecteur RAM synchronise son contenu avec le lecteur de disque dur en arrière-plan, en utilisant uniquement des ressources inactives.
Une recherche rapide sur Google n'a rien révélé, mais je ne sais peut-être pas comment utiliser Google. Peut-être que quelqu'un connaît un tel logiciel? De préférence gratuit, mais des frais raisonnables pourraient également convenir.
Ajoutée: Certaines solutions ont été suggérées, que j’ai écartées au tout début. Ils seraient (sans ordre particulier):
- Achetez un disque dur plus rapide ( SSD peut-être ou 10K tr/min). Je ne veux pas de solution matérielle. Non seulement les logiciels peuvent être moins chers (logiciels gratuits, n'importe qui?), Mais ils peuvent également être utilisés dans des environnements où des modifications matérielles seraient importunes, voire impossibles - au bureau par exemple.
- Laissez OS/HDD faire la mise en cache - il sait mieux utiliser votre RAM libre. Les OS/HDD ont des algorithmes de cache génériques qui cachent tout et essaient de prédire quelles données seront le plus nécessaires dans le futur. Ils n'ont aucune idée que pour moi la priorité est mon dossier de projet. Et comme nous le savons tous très bien, de toute façon, ils ne le cachent pas beaucoup. ;)
- Il y a beaucoup de RAM lecteurs; utilisez l'un de ceux-ci. Désolé, ce serait imprudent. J'ai besoin que mes données soient synchronisées sur le disque dur chaque fois qu'il reste un peu de temps libre. En cas de panne de courant, je pourrais supporter de perdre les cinq dernières minutes de travail, mais pas tout depuis mon dernier enregistrement.
Ajouté 2: Une idée qui est venue - utilisez un lecteur RAM normal plus un synchroniseur de dossiers en arrière-plan (mais je veux dire contexte). Y at-il une telle chose?
Ajouté 3: Intéressant. Je viens d’essayer un simple lecteur RAM au travail. Le temps de reconstruction passe de ~ 14 secondes à ~ 7 secondes (pas si mal), mais la construction incrémentielle est toujours à ~ 5 secondes - comme sur le disque dur. Des idées pourquoi? Il utilise aspnet_compiler et aspnet_merge. Peut-être qu'ils font quelque chose avec d'autres fichiers temporaires ailleurs?
Ajouté 4: Oh, belle nouvelle série de réponses! :) OK, j'ai un peu plus d'informations pour tous les naysayers. :)
Une des principales raisons de cette idée n’est pas le logiciel mentionné ci-dessus (temps de construction de 14 secondes), mais un autre auquel je n’avais pas accès à l’époque. Cette autre application a une base de code de 100 Mo et sa compilation complète prend environ 5 minutes. Ah oui, c'est dans Delphi 5 , donc le compilateur n'est pas trop avancé. :) Placer la source sur un lecteur RAM a entraîné une différence BIG. Je pense avoir moins d'une minute. Je n'ai pas mesuré. Donc, pour tous ceux qui disent que le système d’exploitation peut mieux mettre en cache des choses, je ne voudrais pas différer.
Question connexe:
Note sur le premier lien: La question à laquelle il est lié a été supprimée car il s'agissait d'un doublon. Il a demandé:
Que faites-vous pendant la compilation de votre code?
Et la réponse de Dmitri Nesteruk à laquelle j'ai lié était:
Je compile presque instantanément. En partie à cause de la petite taille de mes projets, en partie à cause de l'utilisation de disques RAM.
Sous Linux (vous n’avez jamais indiqué le système d’exploitation sur lequel vous êtes, ce pourrait est pertinent), vous pouvez créer des périphériques bloc à partir de RAM et les monter comme tout autre périphérique bloc un disque dur).
Vous pouvez ensuite créer des scripts qui sont copiés vers et à partir de ce lecteur au démarrage/à l’arrêt, ainsi que périodiquement.
Par exemple, vous pouvez le configurer pour que vous ayez ~/code et ~/code-real. Votre bloc RAM est monté à ~/code au démarrage, puis tout le contenu de ~/code-real (qui se trouve sur votre disque dur standard) est copié. À l’arrêt, tout serait copié ( rsync 'serait plus rapide) en arrière de ~/code à ~/code-real. Vous voudriez probablement aussi que ce script s'exécute périodiquement, afin de ne pas perdre beaucoup de travail en cas de panne de courant, etc.
Je ne le fais plus (je l'utilisais pour Opera lorsque la version bêta de la 9.5 était lente, plus besoin maintenant).
Je suis surpris de voir combien de personnes pensent que le système d'exploitation peut mieux déterminer vos besoins en cache que vous ne le pouvez dans ce cas particulier. Bien que je ne l'aie pas fait pour la compilation, je l'ai fait pour des processus similaires et j'ai fini par utiliser un disque RAM avec des scripts qui automatisaient la synchronisation.
Dans ce cas, je pense que je choisirais un système de contrôle de source moderne. À chaque compilation, le code source (le cas échéant, le long d'une branche expérimentale) sera automatiquement enregistré de sorte que chaque compilation entraîne la sauvegarde des données.
Pour démarrer le développement, démarrez le disque RAM et tracez la ligne de base actuelle. Éditez, compilez, éditez, compilez, etc. - pendant que les modifications sont enregistrées pour vous.
Effectuez l’enregistrement final lorsque vous êtes satisfait et vous n’aurez même pas à utiliser votre disque dur habituel.
Mais il existe des synchroniseurs d'arrière-plan qui automatiseront les tâches. Le problème est qu'ils ne seront pas optimisés non plus pour la programmation et qu'ils devront peut-être effectuer des analyses complètes des répertoires et des fichiers de temps en temps pour détecter les modifications. Un système de contrôle de code source est conçu exactement à cette fin, il serait donc probablement moins coûteux, même s’il existe dans votre configuration.
N'oubliez pas qu'une tâche de synchronisation en arrière-plan, en cas de panne de courant, n'est pas définie. Vous finirez par devoir déterminer ce qui a été enregistré et ce qui ne l’a pas été si les choses tournaient mal. Avec un point de sauvegarde défini (à chaque compilation, ou forcé à la main), vous auriez une assez bonne idée que c'était au moins dans un état où vous pensiez pouvoir le compiler. Utilisez un VCS et vous pourrez facilement le comparer au code précédent et voir quels changements vous avez déjà appliqués.
VoirAccélérer l’émergence avec tmpfs( Gentoo Linux wiki).
Accélérer les compilations en utilisant RAM lecteurs sous Gentoo a fait l’objet d’un tutoriel écrit il ya plusieurs millénaires. Il fournit un exemple concret de ce qui a été fait. En résumé, tous les fichiers intermédiaires source et de construction sont redirigés vers un disque RAM pour la compilation, tandis que les fichiers binaires finaux sont dirigés vers le disque dur pour l'installation.
De même, je vous recommande d'explorer le maintien de votre source sur le disque dur, mais git Push votre dernière source change en un référentiel de clonage résidant sur le disque RAM. Compilez le clone. Utilisez votre script favori pour copier les fichiers binaires créés.
J'espère que ça aide.
Votre système d'exploitation mettra les choses en mémoire cache pendant son fonctionnement. Un disque RAM peut sembler plus rapide, mais c'est parce que vous ne tenez pas compte des temps "copier sur RAMDisk" et "copier à partir de RAMDisk". Le fait de dédier RAM à un disque mémoire de taille fixe réduit simplement la mémoire disponible pour la mise en cache. Le système d'exploitation sait mieux ce qu'il faut dans la RAM.
Je n'ai pas exactement ce que vous cherchez, mais j'utilise maintenant une combinaison de Ramdisk et DRAM ramdisk . Comme il s'agit de Windows, j'ai une limite stricte de 3 Go pour la mémoire principale, ce qui signifie que je ne peux pas utiliser trop de mémoire pour un disque RAM. 4 Go supplémentaires sur le 9010, ça déchire vraiment. Je laisse mon IDE stocker tout son contenu temporaire sur le disque à l'état solide RAM ainsi que dans le répertoire Maven . Le disque DRAM RAM dispose d’une batterie de secours sur la carte flash. Cela ressemble à une publicité, mais c’est vraiment une excellente configuration.
Le disque DRAM a double ports SATA-300 et sort avec une moyenne de 0,0 ms chercher sur la plupart des tests;) Quelque chose pour le bas de Noël?
Utilisez https://wiki.archlinux.org/index.php/Ramdisk pour créer le disque RAM.
Ensuite, j'ai écrit ces scripts pour déplacer des répertoires du disque RAM. La sauvegarde est effectuée dans un fichier tar avant de passer sur le disque RAM. L'avantage de le faire de cette façon est que le chemin reste le même, de sorte que tous vos fichiers de configuration n'ont pas besoin de changer. Lorsque vous avez terminé, utilisez uramdir pour le ramener sur le disque.
Edit: Ajout du code C qui exécutera toutes les commandes qui lui sont données à un intervalle en arrière-plan. Je l'envoie tar avec --update pour mettre à jour l'archive en cas de changement.
Je crois que cette solution polyvalente est supérieure à une solution unique à quelque chose de très simple. BAISER
Assurez-vous de changer le chemin en 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;
}
Nous avions l'habitude de faire cela il y a des années pour un 4GL macro-compilateur; si vous placez la bibliothèque de macros et les bibliothèques de support et votre code sur un disque RAM, la compilation d'une application (sur un 80286) passerait de 20 minutes à 30 secondes.
Profil. Assurez-vous de bien mesurer chaque option. Vous pouvez même acheter des éléments que vous avez déjà rejetés, les mesurer et les renvoyer, de sorte que vous sachiez que vous travaillez à partir de bonnes données.
Obtenez beaucoup de RAM. 2 Go Les DIMM sont très bon marché; Les barrettes DIMM 4 Go coûtent un peu plus de 100 USD/ch, mais ce n’est pas beaucoup d’argent comparé au prix des pièces d’ordinateur il ya quelques années. Que vous vous retrouviez avec un disque RAM ou que vous laissiez simplement le système d'exploitation agir à sa place, cela vous aiderait. Si vous utilisez Windows 32 bits, vous devrez passer à 64 bits pour pouvoir utiliser tout ce qui dépasse 3 Go ou plus.
Live Mesh peut se synchroniser depuis votre lecteur local RAM vers le nuage ou vers un autre ordinateur, vous offrant ainsi une sauvegarde à jour.
Déplace juste les sorties du compilateur. Conservez votre code source sur le disque physique réel, mais indiquez les fichiers .obj, .dll et .exe à créer sur le lecteur RAM.
Considérons un DVCS . Cloner du lecteur réel vers un nouveau référentiel sur le lecteur RAM. Renvoyez souvent vos modifications au parent, par exemple à chaque fois que tous vos tests réussissent.
J'ai eu la même idée et fait des recherches. J'ai trouvé les outils suivants qui font ce que vous recherchez:
Cependant, le deuxième que je n'ai pas réussi à faire fonctionner sous Windows 7 64 bits du tout, et il ne semble pas être maintenu pour le moment.
Le disque VSuite RAM des autres mains fonctionne très bien. Malheureusement, je n'ai pas pu mesurer d'augmentation significative des performances par rapport au disque SSD / en place.
Oui, j'ai rencontré le même problème. Et après une recherche infructueuse sur Google, je viens juste d’écrire un service Windows pour la sauvegarde paresseuse du lecteur RAM (en fait, n’importe quel dossier, car le lecteur RAM peut être monté, par exemple, sur le bureau). .
http://bitbucket.org/xkip/transparentbackup Vous pouvez spécifier un intervalle pour une analyse complète (5 minutes par défaut). Et un intervalle pour analyser uniquement les fichiers notifiés (30 secondes par défaut). Scan détecte les fichiers modifiés à l'aide de l'attribut 'archive' (le système d'exploitation le réinitialise spécialement à des fins d'archivage). Seuls les fichiers modifiés de cette façon sont sauvegardés.
Le service laisse un fichier de marqueur spécial pour s'assurer que la sauvegarde cible est exactement une sauvegarde de la source. Si la source est vide et ne contient pas de fichier de marqueur, le service effectue une restauration automatique à partir d'une sauvegarde. Ainsi, vous pouvez facilement détruire le lecteur RAM et le créer à nouveau avec la restauration automatique des données. Il est préférable d’utiliser un lecteur RAM capable de créer une partition au démarrage du système pour le rendre transparent.
Une autre solution que j'ai récemment détectée est SuperSpeed SuperCache .
Cette société possède également un disque RAM, mais il s’agit d’un autre logiciel. SuperCache vous permet d'utiliser une quantité supplémentaire de RAM pour la mise en cache au niveau du bloc (elle est très différente de la mise en cache de fichiers), et une autre option - vous donnez la miroir à RAM. Dans n'importe quel scénario, vous pouvez spécifier la fréquence à laquelle les blocs altérés doivent être restitués sur le disque dur, en effectuant des écritures similaires à celles du lecteur RAM, mais le scénario miroir permet également de lire comme à partir du RAM conduire. Vous pouvez créer une petite partition, par exemple 2 Go (sous Windows) et mapper la totalité de la partition sur la RAM.
Une chose intéressante et très utile à propos de cette solution: vous pouvez modifier les options de mise en cache et de mise en miroir à tout moment, instantanément, en deux clics. Par exemple, si vous souhaitez récupérer vos 2 Go pour une machine virtuelle ou gamimg, vous pouvez simplement arrêter la mise en miroir instantanément et libérer de la mémoire. Même les descripteurs de fichiers ouverts ne se cassent pas - la partition continue de fonctionner, mais en tant que lecteur habituel.
EDIT: Je vous recommande également vivement de déplacer le dossier TEMP sur le lecteur te RAM, car les compilateurs travaillent généralement beaucoup avec temp. Dans mon cas, cela m'a donné 30% de vitesse de compilation supplémentaire.
Il y a beaucoup de RAMDrives autour, utilisez-en un. Désolé, ce serait imprudent.
Seulement si vous travaillez entièrement sur le disque RAM, ce qui est idiot.
Script shell 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
Ceci dit, votre compilateur peut éventuellement le faire sans scripts supplémentaires. Il vous suffit de changer l’emplacement de sortie de votre construction en disque RAM, par exemple dans Xcode, sous Préférences, Construction, "Placer les produits de compilation dans:" et "Placez les fichiers de construction intermédiaires dans:".
Je me demande si vous pourriez construire quelque chose comme un logiciel RAID 1 où vous avez un disque physique/une partition en tant que membre et un bloc de RAM en tant que membre.
Je parie qu'avec un peu de peaufinage et une configuration vraiment étrange, Linux pourrait le faire. Je ne suis pas convaincu que cela en vaille la peine.
Ce qui peut être super bénéfique, même sur une machine monocœur, est de fabrication parallèle. Disk I/O est un facteur assez important dans le processus de construction. Générer deux instances de compilateur par cœur de processeur peut en réalité améliorer les performances. Comme une instance de compilateur se bloque sur les E/S, l’autre peut généralement se lancer dans la partie de compilation exigeante en ressources CPU.
Vous devez vous assurer que vous disposez de la RAM pour prendre en charge cette opération (cela ne devrait pas poser de problème sur un poste de travail moderne), sinon vous finirez par échanger et cela irait à l'encontre du but recherché.
Sur GNU make vous pouvez simplement utiliser -j[n] où [n] est le nombre de processus simultanés à générer. Assurez-vous de disposer de votre arbre de dépendance avant de l'essayer, sinon les résultats risquent d'être imprévisibles.
Un autre outil vraiment utile (dans la mode parallèle) est distcc . Cela fonctionne un traitement avec GCC (si vous pouvez utiliser GCC ou quelque chose avec une interface de ligne de commande similaire). En fait, distcc divise la tâche de compilation en prétendant être le compilateur et génère des tâches sur des serveurs distants. Vous l'appelez de la même manière que vous appelez GCC et vous profitez de l'option -j [n] de make pour appeler de nombreux processus distcc.
Lors de l’un de mes emplois précédents, nous avions un système d’exploitation Linux assez intensif, exécuté presque quotidiennement pendant un certain temps. Ajouter quelques machines de compilation dédiées et installer distcc sur quelques stations de travail pour accepter les tâches de compilation nous a permis de réduire le temps de génération d'une demi-journée à moins de 60 minutes pour une version complète OS + espace utilisateur.
Il existe de nombreux autres outils pour accélérer la compilation existante. Vous voudrez peut-être explorer davantage que la création de disques RAM; quelque chose qui semble avoir très peu de profit puisque le système d’exploitation met en cache le disque avec de la RAM. Les concepteurs de systèmes d'exploitation consacrent beaucoup de temps à la mise en cache appropriée pour la plupart des charges de travail; ils sont (collectivement) plus intelligents que vous, alors je ne voudrais pas essayer de faire mieux qu'eux.
Si vous mâchez RAM pour RAM disque, le système d'exploitation a moins de travail RAM pour mettre en cache les données et exécuter votre code -> vous en aurez plus d’échanger et d’aggraver les performances du disque, sinon (remarque: vous devez profiler cette option avant de la supprimer complètement).
Ma solution finale au problème est vmtouch: https://hoytech.com/vmtouch/ Cet outil verrouille le dossier actuel dans le cache (ram) et vmtouch démonise en arrière-plan.
Sudo vmtouch -d -L ./
Mettez ceci dans Shell rc pour un accès rapide:
alias cacheThis = 'Sudo vmtouch -d -L ./'
J'ai cherché un script prêt à l'emploi pendant un certain temps, parce que je ne voulais pas perdre trop de temps à écrire mon propre script ramdisk-rsync-script. Je suis sûr que j'aurais manqué certains cas Edge, ce qui serait très désagréable si du code important était impliqué. Et je n’ai jamais aimé l’approche par sondage.
VMtouch semble être la solution parfaite. De plus, il ne gaspille pas de mémoire comme le ferait un disque virtuel. Je n'ai pas fait de benchmark, car 90% de mes dossiers 1Gig source + build étaient déjà mis en cache, mais au moins, c'est plus rapide;)
Le ralentissement du disque que vous rencontrez est principalement dû à l’écriture, et peut-être également à des antivirus. Cela peut aussi varier énormément d'un système d'exploitation à l'autre.
Avec l'idée que les écritures sont les plus lentes, je serais tenté de configurer une construction dans laquelle les fichiers intermédiaires (par exemple, .o) et les fichiers binaires sont exportés vers un autre emplacement, par exemple un lecteur RAM.
Vous pouvez ensuite lier ce dossier bin/intermédiaire à un support plus rapide (à l'aide d'un lien symbolique ou point de jonction NTFS ).
Cela ressemble à une mise en cache de disque que votre système d'exploitation et/ou votre disque dur gérera automatiquement pour vous (à des degrés de performance variables, certes).
Mon conseil est que, si vous n'aimez pas la vitesse de votre disque, achetez un disque à grande vitesse uniquement à des fins de compilation. Moins de travail de votre part et vous pourriez avoir la solution à vos problèmes de compilation.
Depuis que cette question a été posée à l'origine, les disques durs en rotation sont devenus des tortues misérables par rapport aux disques SSD. Ils sont très proches du disque RAM demandé à l'origine dans une SKU que vous pouvez acheter chez Newegg ou Amazon.
Quelques idées qui me viennent à l’esprit:
Utilisez Sysinternals ' Process Monitor (pas Process Explorer ) pour vérifier ce qui se passe pendant la construction - cela vous permettra de voir si %temp% est utilisé, par exemple (n'oubliez pas que les fichiers de réponse sont probablement créés avec FILE_ATTRIBUTE_TEMPORARY qui devrait empêcher les écritures sur disque si possible). J'ai déplacé mon %TEMP% sur un disque RAM, et cela me donne des accélérations mineures en général.
Procurez-vous un disque RAM prenant en charge le chargement/l'enregistrement automatique des images disque, de sorte que vous ne soyez pas obligé d'utiliser des scripts de démarrage pour cela. La lecture/écriture séquentielle d'une seule image disque est plus rapide que la synchronisation de nombreux petits fichiers.
Placez vos fichiers d'en-tête volumineux/fréquemment utilisés sur le disque RAM et remplacez les chemins d'accès standard du compilateur pour qu'ils utilisent les copies de lecteur RAM. Cela n'apportera probablement pas beaucoup d'amélioration à that après la première construction, car le système d'exploitation met en cache les en-têtes standard.
Conservez vos fichiers source sur votre disque dur et synchronisez-les sur le disque RAM - et non l'inverse . Check out MirrorFolder pour effectuer la synchronisation en temps réel entre les dossiers. Pour ce faire, il utilise un pilote de filtre. Il ne synchronise donc que ce qui est nécessaire (et ne modifie que les modifications): une écriture de 4 Ko dans un fichier de 2 Go entraîne uniquement une écriture de 4 Ko. dans le dossier cible). Découvrez comment construire votre IDE à partir du lecteur RAM bien que les fichiers sources se trouvent sur votre disque dur ... et gardez à l'esprit que vous aurez besoin d'un grand RAM lecteur pour les grands projets.