RAM drive pour compiler - existe - t-il une telle chose?
une réponse (voir ci-dessous) à l'une des questions ici sur le débordement de pile m'a donné une idée pour un grand petit morceau de logiciel qui pourrait être inestimable pour les codeurs partout.
j'imagine un logiciel de disque RAM, mais avec une différence cruciale - il serait miroir d'un vrai dossier sur mon disque dur. Plus précisément, le dossier qui contient 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 rapides). Le lecteur de mémoire vive synchroniserait son contenu avec le disque dur en arrière-plan en utilisant seulement des ressources inactives.
une recherche rapide sur Google n'a rien révélé, mais peut-être que je ne sais pas comment Google. Peut-être que quelqu'un connaît un tel logiciel? De préférence gratuitement, mais des frais raisonnables peuvent aussi être acceptés.
ajouté: quelques solutions ont été suggérés que j'ai écartés au tout début. Ils seraient (sans ordre particulier):
- acheter un lecteur de disque dur plus rapide ( SSD peut-être ou 10K RPM). Je ne veux pas de solution matérielle. Non seulement le logiciel a le potentiel d'être moins cher (freeware, n'importe qui?), mais il peut également être utilisé dans des environnements où des modifications matérielles seraient indésirables, voire impossibles - par exemple, au bureau.
- laissez OS/HDD faire la mise en cache - il sait mieux comment utiliser votre RAM libre. L'OS/HDD ont des algorithmes de cache génériques qui cache tout et essayer de prédire quelles données seront les plus nécessaires à l'avenir. 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 - ils ne le cachent pas vraiment beaucoup de toute façon. ;)
- il y a beaucoup de disques durs autour; utilisez l'un d'eux. Désolé, ce serait imprudent. J'ai besoin que mes données soient synchronisées avec le HDD chaque fois qu'il y a un peu de temps libre. Dans le cas d'une panne de courant, je pourrais supporter de perdre les cinq dernières minutes de travail, mais pas tout depuis ma dernière vérification.
ajouté 2: une idée qui est venu - utiliser un lecteur de RAM normal plus un synchroniseur de dossier d'arrière-plan (mais je veux dire arrière-plan ). Est-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 mal), mais la construction incrémentale est toujours à ~5 secondes - tout comme sur le HDD. Des idées pourquoi? Il utilise aspnet_compiler
et aspnet_merge
. Peut-être font-ils quelque chose avec d'autres dossiers temporaires ailleurs?
, a Ajouté 4: Oh, la belle nouvelle série de réponses! :) OK, j'ai un peu plus d'infos pour tous ceux qui disent le contraire. :)
L'une des principales raisons de cette idée n'est pas le logiciel mentionné ci-dessus (14 secondes de temps de construction), mais un autre que je n'avais pas accès à l'époque. Cette autre application a une base de code de 100 Mo, et sa construction complète prend environ 5 minutes. Ah oui , c'est dans Delphi 5 , donc le compilateur n'est pas trop avancé. :) Mettre la source sur un disque RAM a entraîné une grande différence. Je l'ai en moins d'une minute, je crois. Je n'ai pas mesuré. Donc, pour tous ceux qui disons que L'OS peut cacher des choses mieux - Je ne suis pas d'accord.
Question Connexe:
Note sur le premier lien: La question à laquelle elle renvoie a été supprimée parce qu'il s'agissait d'un duplicata. Il a demandé:
Que faites-vous pendant que votre code est compilé?
Et la réponse par Dmitri Nesteruk à qui j'ai fait un lien a été:
Je compilais presque instantanément. En partie à cause de mes petits projets, en partie à cause de l'utilisation de disques RAM.
18 réponses
sous Linux (vous n'avez jamais mentionné sur quel OS vous êtes, donc ce pourrait être pertinent) vous pouvez créer des périphériques block à partir de la RAM et les monter comme n'importe quel autre périphérique block (c'est-à-dire un HDD).
vous pouvez alors créer des scripts qui copient vers et depuis ce lecteur lors du démarrage / de l'arrêt, ainsi que périodiquement.
Par exemple, vous pouvez le configurer de sorte que vous avez ~/code
et ~/code-real
. Votre BLOC DE RAM est monté à ~/code
au démarrage, et ensuite tout de ~/code-real
(qui est sur votre disque dur standard) est copié. À l'arrêt tout serait copié ( rsync 'd serait plus rapide) retour de ~/code
à ~/code-real
. Vous voudriez aussi probablement que ce script s'exécute périodiquement, donc vous n'avez pas perdu beaucoup de travail en cas de panne de courant, etc.
Je ne fais plus cela (je l'ai utilisé pour Opéra quand le 9.5 beta était lente, plus besoin).
je suis surpris du nombre de personnes qui suggèrent que L'OS peut faire un meilleur travail pour comprendre vos besoins de mise en cache que vous pouvez dans ce cas spécialisé. Bien que je ne l'ai pas fait pour compiler, 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 j'utiliserais un système moderne de contrôle des sources. A chaque Compilation, il vérifierait le code source (le long d'une branche expérimentale si nécessaire) automatiquement de sorte que chaque Compilation aboutirait à la sauvegarde des données.
pour lancer le développement, démarrer le disque RAM et tirer la ligne de base actuelle. Faire l'édition, compiler, éditer, compiler, etc. - pendant que les modifications sont sauvegardées pour vous.
Faire la vérification finale dans lorsque heureux, et vous n'avez même pas à impliquer votre disque dur.
mais il y a des synchroniseurs d'arrière-plan qui vont automatiser choses - le problème est qu'ils ne seront pas non plus optimisés pour la programmation et peuvent avoir besoin de faire des balayages complets des répertoires et des fichiers de temps en temps pour attraper les changements. Un système de contrôle de code source est conçu pour exactement ce but, donc il serait probablement plus faible overhead, même s'il existe dans votre configuration de construction.
Gardez à l'esprit qu'une tâche de synchronisation, dans le cas d'une panne de courant, n'est pas défini. Vous allez finir par avoir à comprendre ce qui a été sauvé et ce qui n'était pas enregistré si les choses ont mal tourné. 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 compiler. Utilisez un VCS et vous pouvez facilement le comparer au code précédent et voir quelles modifications vous avez déjà appliquées.
Voir excès de vitesse jusqu'à en sortir avec tmpfs ( Gentoo Linux wiki).
accélérer les compilations en utilisant des disques durs sous Gentoo a été le sujet d'un how-to écrit il y a de nombreuses éons. Il fournit un exemple concret de ce qui a été fait. L'essentiel est que tous les fichiers intermédiaires source et build sont redirigés vers un disque RAM pour la compilation, tandis que les binaires finaux sont dirigés vers le disque dur pour l'installation.
aussi, je recommande d'explorer la conservation de votre source sur le disque dur, mais git push
votre dernière source change en un clone respository qui réside sur le disque RAM. Compilez le clone. Utilisez votre script préféré pour copier les binaires créés.
j'espère que ça aidera.
votre système d'exploitation cache des choses en mémoire au fur et à mesure de leur fonctionnement. Un disque RAM peut sembler plus rapide, mais c'est parce que vous ne factorisez pas dans les temps "copier vers RAMDisk" et "copier depuis RAMDisk". Dédier une mémoire vive à un disque dur de taille fixe réduit la mémoire disponible pour la mise en cache. L'OS sait mieux ce qui doit être en RAM.
nous faisions cela il y a des années pour un macro-compilateur 4GL ; si vous mettez la macro-bibliothèque et les bibliothèques de soutien et votre code sur un disque RAM, compiler une application (sur un 80286) passerait de 20 minutes à 30 secondes.
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 de 3 Go pour la mémoire centrale, ce qui signifie que je ne peux pas utiliser trop de mémoire pour un disque RAM. 4 Go supplémentaires sur le 9010 vraiment rocks il. J'ai laissé mon IDE stocker toutes ses données temporaires sur le disque de RAM à l'état solide et aussi le dépôt Maven . Le disque RAM DRAM dispose d'une batterie de sauvegarde pour la carte flash. Cela ressemble à une publicité, mais il est vraiment une excellente configuration.
le disque DRAM a double SATA-300 ports et sort avec 0,0 ms moyenne chercher sur la plupart des tests;) quelque chose pour le stockage de Noël?
utiliser https://wiki.archlinux.org/index.php/Ramdisk pour faire le disque RAM.
puis j'ai écrit ces scripts pour déplacer les répertoires vers et depuis le disque RAM. La sauvegarde est effectuée dans un fichier tar avant de passer dans le disque RAM. L'avantage de le faire de cette façon est que le chemin reste le même, donc tous vos fichiers de configuration n'ont pas besoin de changer. Lorsque vous avez terminé, utilisez uramdir
pour ramener sur le disque.
Edit: code C Ajouté qui exécutera n'importe quelle commande qu'elle est donnée sur 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 vaut mieux que de faire une solution unique à quelque chose de très simple. KISS
assurez-vous de changer le chemin vers 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 ; /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 ; 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;
}
-
profil. assurez-vous que vous faites de bonnes mesures de chaque option. Vous pouvez même acheter des choses que vous avez déjà rejetées, les mesurer, et les rendre, de sorte que vous savez que vous travaillez à partir de bonnes données.
-
Obtenir beaucoup de RAM. DIMMs de 2 Go sont très bon marché; DIMMs de 4 Go sont un peu plus de US$100/ea, mais ce n'est pas encore beaucoup d'argent par rapport à ce que les pièces d'ordinateur coûtent seulement quelques il y a des années. Que vous vous retrouviez avec un disque RAM ou simplement en laissant le système d'exploitation faire son travail, cela vous aidera. Si vous utilisez Windows 32 bits, vous aurez besoin de passer à 64 bits pour faire usage de tout ce qui dépasse 3 Go ou plus.
-
Live Mesh peut se synchroniser à partir de votre disque RAM local vers le cloud ou un autre ordinateur, vous donnant une sauvegarde à jour.
-
Déplacer juste compilateur sorties. Gardez votre code source sur le vrai disque physique, mais direct .obj,.dll, et .fichiers exe à créer sur le disque RAM.
-
Considérer un DVCS . Clone du disque réel vers un nouveau dépôt sur le disque RAM. "repousse" souvent tes changements au parent, dis-le chaque fois que tous tes tests sont réussis.
j'ai eu la même idée et fait quelques recherches. J'ai trouvé les outils suivants qui font ce que vous cherchez:
cependant, le deuxième Je n'ai pas réussi à obtenir de travailler sur 64-bit Windows 7 à tous, et il ne semble pas être maintenu à l'heure actuelle.
le disque VSUITE RAM sur le les autres mains fonctionnent très bien. Malheureusement, je n'ai pas pu mesurer d'augmentation significative de performance par rapport au disque SSD en place.
oui, j'ai rencontré le même problème. Et après le googling inutile j'ai juste écrit un service de Windows pour la sauvegarde paresseuse de la commande de RAM (en fait - n'importe quel dossier, parce que la commande de RAM peut être montée dans, par exemple, le bureau).
http://bitbucket.org/xkip/transparentbackup Vous pouvez spécifier l'intervalle pour le balayage complet (par défaut 5 minutes). Et un intervalle pour numériser uniquement les fichiers notifiés (par défaut 30 secondes). Scan détecte les fichiers modifiés en utilisant le attribut "archive" (L'OS réinitialise celui-ci spécialement à des fins d'archivage). Seuls les fichiers modifiés sont sauvegardés.
le service laisse un fichier 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 marqueur, le service effectue une restauration automatique à partir de la sauvegarde. Ainsi, vous pouvez facilement détruire le lecteur de RAM et le créer à nouveau avec la restauration automatique des données. Il est préférable d'utiliser un lecteur RAM qui il est capable de créer une partition sur le démarrage du système pour le faire fonctionner de manière transparente.
une autre solution que j'ai récemment détectée est SuperSpeed SuperCache .
cette société a aussi un disque RAM, mais c'est un autre logiciel. SuperCache vous permet d'utiliser plus de RAM pour la mise en cache au niveau des blocs (c'est très différent de la mise en cache de fichiers), et une autre option-miroir que vous conduisez complètement en RAM. Dans n'importe quel scénario, vous pouvez spécifier à quelle fréquence déposez les blocs sales de nouveau au disque dur, faisant écrit comme sur le lecteur de RAM, mais le scénario de miroir fait aussi lit comme à partir du lecteur de RAM. Vous pouvez créer une petite partition, par exemple, 2 Go (en utilisant Windows) et mapper la partition entière en RAM.
une chose intéressante et très utile au sujet de cette solution - vous pouvez changer la mise en cache et les options de miroir à tout moment tout simplement instantanément avec deux clics. Par exemple, si vous voulez récupérer vos 2 Go pour gamimg ou machine virtuelle - vous pouvez arrêter de créer des miroirs instantanément et libérer la mémoire en arrière. Même les poignées de fichiers ouvertes ne cassent pas - la partition continue de fonctionner, mais comme un lecteur habituel.
EDIT: je vous recommande aussi fortement de déplacer le dossier TEMP à te RAM drive, parce que les compilateurs font généralement beaucoup de travail avec temp. Dans mon cas, il m'a donné un autre 30% de la vitesse de compilation.
je me demande si vous pourriez construire quelque chose comme un RAID logiciel 1 où vous avez un disque physique/une partition en tant que membre, et un morceau de RAM en tant que membre.
je parie qu'avec un peu de peaufinage et une configuration vraiment bizarre, on pourrait faire ça avec Linux. Je ne suis pas convaincu qu'il serait en vaut la peine si.
il y a beaucoup de RAMDrives autour, utilisez l'une d'elles. Désolé, ce serait irresponsable.
seulement si vous travaillez entièrement sur le disque RAM, ce qui est stupide..
Pseudo-ish script shell, 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
cela dit, le compilateur peut éventuellement le faire sans scripts supplémentaires.. Il suffit de changer l'emplacement de votre sortie de compilation sur un disque RAM, par exemple dans Xcode, c'est sous Préférences, Bâtiment de, "le Lieu de Construire des Produits dans:" et de "Lieu Intermédiaire Construire des Fichiers:".
ce qui peut être super bénéfique, même sur une machine à un seul noyau, c'est la fabrication parallèle. Disque I / O est un assez grand facteur dans le processus de construction. La reproduction de deux instances de compilation par noyau CPU peut en fait augmenter la performance. Comme une instance de compilateur bloque sur l'entrée/sortie, l'autre peut généralement sauter dans la partie intensive CPU de la compilation.
vous devez vous assurer que vous avez la RAM pour supporter cela (ne devrait pas être un problème sur un moderne workstation), sinon vous finirez par échanger et cela va à l'encontre du but.
Sur GNU vous pouvez utiliser -j[n]
où [n]
est le nombre de processus simultanés pour frayer. Assurez-vous que vous avez votre arbre de dépendances juste avant de l'essayer cependant ou les résultats peuvent être imprévisibles.
un autre outil qui est vraiment utile (dans la mode de fabrication parallèle) est distcc . Il fonctionne un régal avec GCC (si vous pouvez utiliser GCC ou quelque chose avec une interface de ligne de commande similaire). distcc casse en fait la tâche de compilation en prétendant être les tâches de compilation et de fraie sur les serveurs distants. Vous l'appelez de la même manière que vous appelleriez GCC, et vous profitez de l'option make-j[n] pour appeler de nombreux processus distcc.
à l'un de mes emplois précédents, nous avons eu une construction de système D'exploitation Linux assez intensive qui a été effectuée presque quotidiennement pendant un certain temps. L'ajout d'un couple de les machines dédiées à la construction et la mise en place de distcc sur quelques postes de travail pour accepter les travaux de compilation nous ont permis de réduire les temps de construction d'une demi-journée à moins de 60 minutes pour une construction complète de L'espace utilisateur OS+.
il existe beaucoup d'autres outils pour accélérer les compilations. Vous pourriez vouloir étudier plus que la création de disques RAM; quelque chose qui ressemble à cela aura très peu de gain puisque L'OS fait la mise en cache de disque avec la RAM. Les concepteurs D'OS passent beaucoup de temps à obtenir la mise en cache pour la plupart des charges de travail; ils sont (collectivement) plus intelligents que vous, donc je ne voudrais pas essayer de faire mieux qu'eux.
si vous mâchez de la RAM pour le disque RAM, L'OS a moins de RAM qui fonctionne pour mettre en cache les données et pour exécuter votre code -> vous finirez avec plus d'échange et des performances de disque pires qu'autrement (note: vous devriez profiler cette option avant de la jeter complètement).
cela ressemble à de la mise en cache de disque que votre système d'exploitation et / ou votre disque dur gérera automatiquement pour vous (à des degrés variables de performance, il est vrai).
mon conseil est, si vous n'aimez pas la vitesse de votre lecteur, acheter un lecteur à grande vitesse purement à des fins de compilation. Moins de travail de votre part et vous pourriez avoir la solution à votre compilation de malheurs.
depuis que cette question a été posée à l'origine, les disques durs tournants ont devenir des tortues misérables par rapport aux SSD. Ils sont très proches du disque RAM demandé à l'origine dans un SKU que vous pouvez acheter à Newegg ou Amazon.
Quelques idées sur le dessus de ma tête:
utilisez Sysinternals ' Process Monitor (pas Process Explorer ) pour vérifier ce qui se passe pendant une compilation - cela vous permettra de voir si %temp%
est utilisé, par exemple (gardez à l'esprit que les fichiers de réponse sont probablement créés avec FILE_ATTRIBUTE_TEMPORARY qui devrait empêcher l'écriture de disque si possible). J'ai déplacé mon %TEMP%
sur un disque RAM, et ça me donne peu d'importance. la vitesse en général.
obtenir un disque RAM qui prend en charge automatiquement le chargement/l'enregistrement des images de disque, de sorte que vous ne devez pas utiliser de scripts d'amorçage pour le faire. La lecture/écriture séquentielle d'une image disque est plus rapide que la synchronisation de beaucoup de petits fichiers.
placez vos fichiers d'en-tête souvent utilisés/de grande taille sur le disque RAM, et outrepassez les chemins standards de votre compilateur pour utiliser les copies du lecteur RAM. Il ne donnera probablement pas que beaucoup d'une amélioration après la première fois construit, cependant, comme L'OS cache les en-têtes standard.
Gardez vos fichiers source sur votre disque dur, et synchronisez - les sur le disque RAM - pas l'inverse . Découvrez MirrorFolder pour faire la synchronisation en temps réel entre les dossiers - elle y parvient par l'intermédiaire d'un pilote de filtre, de sorte synchronise uniquement ce qui est nécessaire (et seulement les changements - un 4 KB en écriture à 2 GO de fichier ne fera que provoquer un 4 KB en écriture à la cible dossier.) Comprendre comment faire votre IDE construire à partir du disque RAM bien que les fichiers source sont sur votre disque dur... et gardez à l'esprit que vous aurez besoin d'un grand RAM drive pour les grands projets.
le ralentissement de disque que vous encourez est principalement en écriture, et peut-être aussi en raison de scanners de virus. Il peut varier considérablement entre les os aussi.
avec l'idée que les Écritures sont les plus lentes, je serais tenté de configurer un build où les fichiers intermédiaires (par exemple, .o
) et les binaires obtiennent la sortie à un endroit différent tel qu'un lecteur RAM.
vous pouvez alors lier ce dossier bin / intermédiaire à des supports plus rapides (en utilisant un lien symbolique ) ou point de jonction NTFS ).
ma solution finale au problème est vmtouch: https://hoytech.com/vmtouch / Cet outil verrouille le dossier courant dans le cache (ram) et vmtouch daemonise 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 beaucoup de temps à écrire mon propre script ramdisk-rsync. Je suis sûr que j'aurais raté quelques cas de bordures, ce qui serait assez désagréable si important code était impliqué. Et je n'ai jamais aimé l'approche du scrutin.
Vmtouch semble être la solution parfaite. En outre, il ne gaspille pas la mémoire comme le fait un ramdisk de taille fixe. Je n'ai pas fait de benchmark, parce que 90% de mon dossier source+build 1Gig était déjà en cache, mais au moins il se sent plus rapide;)
comme le dit James Curran, le fait que la plupart des programmes suivent la loi de la localité des références, le code fréquent et le nombre de pages de données seront rétrécis au fil du temps à une taille gérable par le cache de disque OS.
Les disques RAMétaient utiles lorsque les systèmes d'exploitation étaient construits avec des limitations telles que des caches stupides (Win 3.x, Win 95, DOS). L'avantage du disque RAM est proche de zéro et si vous assignez beaucoup de RAM il sucera la mémoire disponible pour le gestionnaire de cache système, blessant les performances globales du système. La règle de base est: laissez votre noyau pour le faire. C'est la même chose que les programmes de "défragmentation de la mémoire" ou "optimiseurs": ils forcent effectivement les pages à sortir du cache (donc vous obtenez plus de RAM éventuellement), mais provoquent le système à faire beaucoup de page-défaut au fil du temps lorsque vos programmes chargés commencent à demander du code/données qui a été bipé.
donc pour plus de performance, obtenir un disque rapide I / O sous-système matériel, peut-être RAID, plus rapide CPU, meilleur chipset (Non VIA!), plus de RAM physique, etc.