Lecteur de RAM pour la compilation – y a-t-il une telle chose?

Une réponse (voir ci-dessous) à l’une des questions ici sur Stack Overflow m’a donné une idée pour un petit logiciel génial qui pourrait être inestimable pour les codeurs du monde entier.

J’imagine un logiciel d’entraînement de RAM, mais avec une différence cruciale – il refléterait 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, toute construction serait presque instantanée (ou au moins deux ordres de grandeur plus rapides). Le lecteur RAM synchroniserait son contenu avec le 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 faire pour Google. Peut-être que quelqu’un connaît un tel logiciel? De préférence gratuit, mais des frais raisonnables peuvent convenir.

Ajoutée: Certaines solutions ont été suggérées et mises au rebut au tout début. Ils seraient (sans ordre particulier):

  • Achetez un disque dur plus rapide ( SSD peut-être ou 10 000 tr / min). Je ne veux pas de solution matérielle. Non seulement les logiciels peuvent être meilleur marché (freeware, tout le monde?), Mais ils peuvent également être utilisés dans des environnements où les modifications matérielles seraient indésirables, voire impossibles, par exemple au bureau.
  • Laissez OS / HDD faire la mise en cache – il sait mieux utiliser votre RAM libre. Le système d’exploitation / disque dur dispose d’algorithmes de cache génériques qui mettent tout en cache et tentent 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 soaps tous très bien, ils ne le cachent pas vraiment de toute façon. 😉
  • Il y a beaucoup de lecteurs de RAM autour; utilisez un de ceux-ci. Désolé, ce serait téméraire. J’ai besoin de synchroniser mes données sur le disque dur chaque fois qu’il y a un peu de temps libre. En cas de panne de courant, je risque de perdre les cinq dernières minutes de travail, mais pas tout depuis ma dernière visite.

Ajout de 2: Une idée qui est venue – utilisez un lecteur de RAM normal plus un synchroniseur de dossiers en arrière-plan (mais je veux dire en arrièreplan ). Y at-il une telle chose?

Ajout de 3: Intéressant. Je viens d’essayer un simple lecteur de RAM au travail. Le temps de reconstruction passe de ~ 14 secondes à ~ 7 secondes (pas mal), mais la génération incrémentielle est toujours à environ 5 secondes – comme sur le disque dur. Des idées pourquoi? Il utilise aspnet_comstackr 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. 🙂

L’une des principales raisons de cette idée n’est pas le logiciel mentionné ci-dessus (14 secondes), mais un autre auquel je n’avais pas access à l’époque. Cette autre application dispose d’une base de code de 100 Mo et sa version complète prend environ 5 minutes. Ah oui, c’est dans Delphi 5 , donc le compilateur n’est pas trop avancé. 🙂 La source sur un lecteur de RAM a entraîné une différence BIG. Je pense que je l’ai eu en dessous 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 éléments, je ne suis pas du même avis.

Question connexe:

Disque RAM pour accélérer l’IDE

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 Dmisorting Nesteruk à laquelle j’ai lié était:

Je comstack presque instantanément. En partie à cause de la petite taille de mes projets, due en partie à l’utilisation de disques RAM.

Sous Linux (vous n’avez jamais mentionné le système d’exploitation sur lequel vous vous trouvez, cela pourrait être pertinent), vous pouvez créer des périphériques de bloc à partir de la RAM et les monter comme tout autre périphérique de bloc (c’est-à-dire un disque dur).

Vous pouvez ensuite créer des scripts qui copient vers et depuis 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 de RAM est monté au ~/code au démarrage, puis tout ce qui vient de ~/code-real (qui se trouve sur votre disque dur standard) est copié. A la fermeture, tout serait copié ( rsync serait plus rapide) de ~/code à ~/code-real . Vous voudrez probablement aussi que ce script soit exécuté périodiquement, vous n’avez donc pas perdu beaucoup de travail en cas de panne de courant, etc.

Je ne le fais plus (je l’ai utilisé pour Opera lorsque la version bêta 9.5 était lente, plus nécessaire).

Voici comment créer un disque RAM sous Linux.

Je suis surpris par le nombre de personnes qui suggèrent que le système d’exploitation peut faire un meilleur travail pour déterminer vos besoins de mise en cache que vous ne le pouvez dans ce cas spécialisé. 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 j’irais avec un système de contrôle de source moderne. A chaque compilation, il vérifierait automatiquement le code source (le long d’une twig expérimentale si nécessaire) pour que chaque compilation entraîne la sauvegarde des données.

Pour démarrer le développement, démarrez le disque RAM et extrayez la ligne de base actuelle. Effectuez l’édition, la compilation, la modification, la compilation, etc. – pendant que les modifications sont enregistrées pour vous.

Faites le check-in final lorsque vous êtes heureux, et vous n’avez même pas besoin d’impliquer votre disque dur habituel.

Mais il existe des synchroniseurs d’arrière-plan qui automatisent les choses – le problème est qu’ils ne seront pas optimisés pour la programmation non plus et qu’ils devront parfois effectuer des parsings complètes de répertoires et de fichiers pour détecter les modifications. Un système de contrôle de code source est conçu exactement à cette fin, il est donc probable qu’il soit moins lourd même s’il existe dans votre configuration de construction.

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 finiriez par devoir comprendre ce qui a été enregistré et ce qui n’a pas été sauvé si les choses tournaient mal. Avec un sharepoint 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 comstackr. 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 Accélérer l’émergence avec tmpfs (wiki Gentoo Linux ).

Accélérer les compilations à l’aide de lecteurs de RAM sous Gentoo a fait l’object d’un tutoriel écrit il ya de nombreuses années. Il fournit un exemple concret de ce qui a été fait. L’essentiel est que tous les fichiers intermédiaires source et de compilation sont redirigés vers un disque RAM pour la compilation, tandis que les fichiers binarys finaux sont dirigés vers le disque dur pour l’installation.

Aussi, je vous recommande d’explorer la maintenance de votre source sur le disque dur, mais git push vos dernières modifications de source vers un référentiel de clone qui réside sur le disque RAM. Comstackz le clone. Utilisez votre script favori pour copier les fichiers binarys créés.

J’espère que ça aide.

Votre système d’exploitation mettra en cache les éléments en mémoire pendant qu’il fonctionne. Un disque RAM peut sembler plus rapide, mais c’est parce que vous ne tenez pas compte des temps “copier dans RAMDisk” et “copier de RAMDisk”. Dédier de la RAM à un disque virtuel de taille fixe réduit simplement la mémoire disponible pour la mise en cache. Le système d’exploitation sait mieux ce qui doit être dans la mémoire vive.

Je n’ai pas exactement ce que vous cherchez, mais j’utilise maintenant une combinaison de disque virtuel Ramdisk et DRAM . Comme il s’agit de Windows, j’ai une limite 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 de plus sur le 9010, ça le bouscule vraiment. Je laisse mon IDE stocker tous ses trucs temporaires sur le disque RAM à l’état solide ainsi que dans le référentiel 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 deux ports SATA-300 et sort avec une moyenne de 0,0 ms 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 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 manière est que le chemin rest le même, donc tous vos fichiers de configuration n’ont pas besoin de changer. Lorsque vous avez terminé, utilisez uramdir pour restaurer le disque.

Edit: Code C ajouté qui exécutera n’importe quelle commande, il est donné sur un intervalle en arrière-plan. Je l’envoie tar avec --update pour mettre à jour l’archive en cas de changement.

Je pense que cette solution à usage général est une solution unique pour une solution très simple. BAISER

Assurez-vous de changer de 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 $1; /bin/pwd`; somedirparent=`dirname $somedir` # Backup directory /bin/tar cf $somedir.tar $somedir # Copy, sortinged 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; } 

Nous avions l’habitude de le faire il y a des années pour un macro-compilateur 4GL ; Si vous mettez 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) passe de 20 minutes à 30 secondes.

  1. Profil. Assurez-vous de bien mesurer chaque option. Vous pouvez même acheter des choses que vous avez déjà rejetées, les mesurer et les retourner pour que vous sachiez que vous travaillez avec de bonnes données.

  2. Obtenez beaucoup de RAM. Les modules DIMM de 2 Go sont très bon marché; Les modules DIMM de 4 Go coûtent un peu plus de 100 $ US / ch, mais ce n’est pas beaucoup d’argent par rapport à ce qu’ont coûté les pièces d’ordinateur il ya quelques années. Que vous vous retrouviez avec un disque RAM ou simplement que le système d’exploitation fasse son travail, cela vous aidera. Si vous exécutez Windows 32 bits, vous devrez passer à 64 bits pour utiliser plus de 3 Go ou plus.

  3. Live Mesh peut se synchroniser à partir de votre lecteur RAM local vers le cloud ou vers un autre ordinateur, vous offrant ainsi une sauvegarde à jour.

  4. Déplacer juste les sorties du compilateur. Conservez votre code source sur le disque physique réel, mais dirigez les fichiers .obj, .dll et .exe sur le lecteur RAM.

  5. Considérons un DVCS . Clone à partir du lecteur réel vers un nouveau référentiel sur le lecteur RAM. “repoussez” souvent vos changements au parent, dites à 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:

  • Disque RAM VSuite
  • DiskBoost

Cependant, le second, je n’ai pas réussi à travailler sur Windows 7 64 bits, et il ne semble pas être maintenu pour le moment.

Le disque virtuel VSuite des autres mains fonctionne très bien. Malheureusement, je n’ai pas pu mesurer une amélioration 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 d’écrire un service Windows pour la sauvegarde lente du lecteur de 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 l’intervalle d’parsing complète (5 minutes par défaut). Et un intervalle pour parsingr uniquement les fichiers notifiés (par défaut 30 secondes). Scan détecte les fichiers modifiés à l’aide de l’atsortingbut ‘archive’ (le système d’exploitation réinitialise celui-ci 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 de la sauvegarde. Ainsi, vous pouvez facilement détruire le lecteur de RAM et le recréer avec la restauration automatique des données. Il est préférable d’utiliser un lecteur de 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é dispose également d’un disque RAM, mais c’est un autre logiciel. SuperCache vous permet d’utiliser de la mémoire vive supplémentaire pour la mise en cache au niveau des blocs (elle est très différente de la mise en cache des fichiers), et une autre option – la mise en miroir complète de la mémoire vive. Dans tous les scénarios, vous pouvez spécifier à quelle fréquence déposer des blocs sales sur le disque dur, en effectuant des écritures comme sur le lecteur RAM, mais le scénario miroir permet également d’effectuer des lectures à partir du lecteur RAM. Vous pouvez créer une petite partition, par exemple 2 Go (à l’aide de Windows) et mapper l’intégralité de la partition sur 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 gamimg ou une machine virtuelle, vous pouvez simplement arrêter instantanément la mise en miroir et libérer de la mémoire. Même les descripteurs de fichiers ouverts ne se cassent pas – la partition continue à fonctionner, mais comme un lecteur habituel.

EDIT: Je recommande également fortement de déplacer le dossier TEMP vers le lecteur RAM, car les compilateurs font généralement beaucoup de travail avec temp. Dans mon cas, cela m’a donné 30% de la vitesse de compilation.

Je me demande si vous pourriez créer quelque chose comme un logiciel RAID 1 où vous avez un disque / une partition physique 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, Linux pourrait faire cela. Je ne suis pas convaincu que cela en vaudrait la peine.

Il y a beaucoup de RAMDrives, utilisez-en un. Désolé, ce serait téméraire.

Seulement si vous travaillez entièrement dans 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 

Cela dit, votre compilateur peut le faire sans scripts supplémentaires. Il vous suffit de modifier votre emplacement de sortie de génération en disque RAM, par exemple dans Xcode, sous Préférences, Génération, “Placer les produits dans” et “Placer les fichiers de construction intermédiaires dans:”.

Ce qui peut être super bénéfique même sur une machine à cœur unique est la fabrication parallèle. Les E / S sur disque sont un facteur important dans le processus de construction. La création de deux instances de compilateur par cœur de processeur peut en fait améliorer les performances. Comme une instance de compilateur se bloque sur les E / S, l’autre peut généralement sauter dans la partie intensive de la compilation de la CPU.

Vous devez vous assurer que vous disposez de la mémoire vive pour prendre en charge cette fonctionnalité (cela ne devrait pas être un problème sur une station de travail moderne), sinon vous finirez par échanger et cela va à l’encontre du but recherché.

Sur GNU make, vous pouvez simplement utiliser -j[n][n] est le nombre de processus simultanés à générer. Assurez-vous d’avoir votre arbre de dépendance juste avant de l’essayer ou que les résultats peuvent être imprévisibles.

Un autre outil vraiment utile (en parallèle, c’est la mode) est distcc . Cela fonctionne avec GCC (si vous pouvez utiliser GCC ou quelque chose avec une interface de ligne de commande similaire). distcc décompose effectivement la tâche de compilation en prétendant être les tâches de compilation et de création sur les 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 précédents travaux, nous avions un système d’exploitation Linux assez intensif qui était exécuté presque quotidiennement pendant un certain temps. L’ajout de deux machines de construction dédiées et la mise en place de distcc sur quelques stations de travail pour accepter des tâches de compilation nous ont permis de réduire les temps de construction de moins d’une demi-journée à moins de 60 minutes pour une construction complète de l’espace utilisateur.

Il existe beaucoup d’autres outils pour accélérer les compilations. Vous voudrez peut-être examiner plus que la création de disques RAM; quelque chose qui a l’air d’avoir très peu de gain puisque le système d’exploitation effectue la mise en cache des disques avec la RAM. Les concepteurs de systèmes d’exploitation consacrent beaucoup de temps à la mise en cache correcte 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 mangez de la RAM pour le disque RAM, le système d’exploitation dispose de moins de mémoire vive pour mettre en cache les données et exécuter votre code – vous finirez par avoir plus de swap et moins de performances (remarque: vous devez définir cette option avant de supprimer complètement il).

Cela ressemble à la mise en cache de disque que votre système d’exploitation et / ou votre disque dur prendront en charge automatiquement (à des degrés de performances variables, certes).

Mon conseil est, si vous n’aimez pas la vitesse de votre lecteur, d’acheter un lecteur à haute 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 en tête:

Utilisez Process Monitor de Sysinternals (pas Process Explorer ) pour vérifier ce qui se passe pendant une construction – cela vous permettra de voir si %temp% est utilisé, par exemple (gardez à l’esprit que les fichiers de réponses sont probablement créés avec FILE_ATTRIBUTE_TEMPORARY si possible, cependant). J’ai déplacé mon %TEMP% sur un disque RAM, ce qui me donne des accélérations mineures en général.

Procurez-vous un disque RAM prenant en charge automatiquement le chargement / l’enregistrement des images de disque. Vous n’avez donc pas à utiliser de scripts de démarrage pour ce faire. La lecture / écriture séquentielle d’une image disque unique est plus rapide que la synchronisation d’un grand nombre de petits fichiers.

Placez vos fichiers d’en-tête souvent utilisés / volumineux sur le disque RAM et remplacez les chemins d’access standard du compilateur pour utiliser les copies du lecteur RAM. Cependant, cela ne donnera probablement pas beaucoup d’amélioration après les premières versions, car le système d’exploitation met en cache les en-têtes standard.

Conservez vos fichiers sources sur votre disque dur et synchronisez-les sur le disque RAM – et non l’inverse . Découvrez MirrorFolder pour effectuer la synchronisation en temps réel entre les dossiers – cela se fait via un pilote de filtre, donc synchronise uniquement ce qui est nécessaire (et ne fait que les modifications – une écriture de 4 Ko sur un fichier de 2 Go entraînera uniquement une écriture de 4 Ko dans le dossier cible) ). Déterminez comment créer votre IDE à partir du lecteur RAM bien que les fichiers sources soient sur votre disque dur … et gardez à l’esprit que vous aurez besoin d’un grand lecteur de RAM pour les gros projets.

Le ralentissement du disque que vous subissez est principalement dû à l’écriture, et peut-être aussi aux scanners de virus. Il peut également varier considérablement entre les systèmes d’exploitation.

Avec l’idée que les écritures sont les plus lentes, je serais tenté de configurer une version intermédiaire (par exemple, les fichiers .o ) et les fichiers binarys générés à un emplacement différent, tel qu’un lecteur RAM.

Vous pouvez ensuite lier ce dossier bin / intermédiaire à un média plus rapide (en utilisant un lien symbolique ou un sharepoint jonction NTFS ).

La solution finale à ce problème est vmtouch: https://hoytech.com/vmtouch/ Cet outil verrouille le dossier en cours dans le cache (ram) et vmtouch en démon en arrière-plan.

 sudo vmtouch -d -L ./ 

Mettez ceci en shell rc pour un access rapide:

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

J’ai cherché un script prêt à l’emploi pendant un certain temps, car je ne voulais pas perdre beaucoup de temps à écrire mon propre script ramdisk-rsync. Je suis sûr que j’aurais raté des cas-types, ce qui serait très désagréable si un code important était impliqué. Et je n’ai jamais aimé l’approche de sondage.

Vmtouch semble être la solution parfaite. En outre, cela ne gaspille pas la mémoire comme le fait un disque virtuel de taille fixe. Je n’ai pas fait de benchmark, car 90% de mon dossier source + build 1Gig était déjà en cache, mais au moins, il se sent plus rapide;)

Tout comme James Curran le dit, le fait que la plupart des programmes respectent la loi de localité des références, le nombre fréquent de codes et de pages de données sera réduit au fil du temps à une taille gérable par le cache disque du système d’exploitation.

Les disques RAM étaient utiles lorsque les systèmes d’exploitation étaient construits avec des limitations telles que les caches stupides (Win 3.x, Win 95, DOS). L’avantage du disque RAM est proche de zéro et si vous affectez beaucoup de mémoire vive, la mémoire disponible pour le gestionnaire de la mémoire cache du système diminuera, ce qui nuira aux performances globales du système. La règle de base est la suivante: laissez votre kernel faire cela. C’est la même chose que les programmes de “défragmentation de mémoire” ou “optimiseurs”: ils forcent les pages à sortir du cache (vous avez donc éventuellement plus de RAM), mais provoquent beaucoup de fautes de pages au fil du temps. commencer à demander le code / les données qui ont été retirés.

Donc, pour plus de performances, procurez-vous un sous-système matériel d’E / S disque rapide, peut-être RAID, processeur plus rapide, meilleur chipset (pas de VIA!), Plus de RAM physique, etc.