La construction de tous de Boost en quelques minutes

Quelqu'un peut-il expliquer pourquoi en suivant ces instructions:

http://www.boost.org/doc/libs/1_59_0/more/getting_started/unix-variants.html#easy-build-and-install

... il prend mon décent machine à 5 heures pour construire tous les de Boost, tandis que certaines personnes rapport à faire de même dans seulement 3 minutes ?

Est-il une autre façon de construire le coup de pouce que celui mentionné ci-dessus que, de fait, va très vite (par rapport à plusieurs heures, en tout cas).

Je suis en utilisant le compilateur Clang sur Darwin (Mac) de l'option. Pas sûr de savoir comment il est pertinent mais j'ai 16 GO de RAM et un SSD récents. L'horloge de 2,3 Ghz.

Edit: je suis heureux de vous communiquer, sur la base des commentaires et des réponses, que l'utilisation de la ./b2 -j4 -d0 options, j'ai eu mon moment de la compilation que 13 minutes. Aussi la -jN option n'est pas répertorié dans l'ensemble des options disponibles avec la valeur par défaut --help, vous devez appeler plutôt --help-options pour voir ces autres plus techniques "avancées".

  • le compilateur et de la plate-forme?
  • Vous avez mentionné dans le lien que vous avez un quad core, 3 ans macbook. Vous devriez être en mesure de réduire de 5 heures à un peu plus d'une demi-heure en utilisant make -j8; voir iSanych de réponse.
  • Ne -d0 vraiment d'incidence sur le coup de pouce construire la vitesse?
InformationsquelleAutor johnbakers | 2015-11-06
  1. 15

    J'ai juste couru quelques tests avec un peu différents de configs.

    Matériel: 2012 MacBook Pro (2.3 Ghz Ivy Bridge i7 [i7-3615QM]), l'usine de SSD et 16GO de ram.

    Logiciel: Mac OS X 10.11.1 avec Xcode 7 (Apple LLVM version 7.0.0 clang-700.1.76). Nouvelle copie de Boost 1.59.0 à partir du site web.

    J'ai testé la génération suivante commandes:

    De Génération Par Défaut:

    ./bootstrap.sh && ./b2 -j N

    Construire forcer la liaison de la libc++

    ./bootstrap.sh && ./b2 toolset=clang cxxflags="-stdlib=libc++" linkflags="-stdlib=libc++" -j N

    Pour chaque j'ai essayé trois différentes valeurs de N: 1 (un seul thread), 4 (correspondant cœurs physiques), et 8 (correspondant à hyperthread cœurs).

    Par défaut de la liaison:

    • Avec 8 de la durée de la construction était de 6:45 minutes
    • Avec 4 le délai de construction est de 7:22 minutes
    • Avec 1 le temps de construction a été de 22:58 minutes

    Reliant la libc++:

    • Avec 8 le délai de construction est de 4:35 minutes
    • Avec 4 le temps de construction a été de 5:45 minutes
    • Avec 1 le délai de construction est de 17:15 minutes

    Conclusion: Boost ne devriez pas avoir à prendre toute la journée pour construire sur un système multi-core avec un SSD, même si elle n'est pas neuve. Bâtiment avec la valeur par défaut (distingué fil) prend beaucoup plus de temps que d'une génération en parallèle. Le coup de pouce de construire avec clang sur OS X ne bénéficient légèrement de l'hyperthreading. Le lien avec la libc++ semble un peu plus vite.

    • Merci beaucoup pour l'aide. Votre 1 de base peut très bien prendre un certain temps, je pense que, si c'est quelque chose comme le mien.
    • Êtes-vous également de ces centaines de milliers de construire journal des sorties avec le Boost ./b2 ?
    • Bâtiment avec clang produit beaucoup de répété les avertissements du compilateur que Linux/gcc ne s'appuie pas. Je vais prendre un compte exact lorsque ce build est fait, mais en général, oui. Les configs au-dessus de produire beaucoup de sortie.
    • peut-être que l'enregistrement de la sortie est de ralentir les choses pour moi
    • décompte final pour la version complète avec clang, comme décrit ci-dessus, a été 318116 lignes de sortie. Final le temps de construction sur ce matériel pour un seul thread était d'environ 17 minutes. Pas génial, mais pas 5 heures. Il y a probablement quelque chose d'autre se passe avec votre machine.
    • Le mien serait tombé sous votre Défaut puisque je n'ai pas passer des options à tous, n'était pas obliger toute la liaison. Je me réjouis de ce que ce test montre dans votre cas.
    • Est -j1 construire encore en cours?
    • J'ai mis à jour ma question la grand les résultats de vos suggestions, merci.
    • ils sont tous fait maintenant. La plus longue j1 construire a pris 23 minutes sur ce matériel. Semble comme -j mise à l'échelle est presque linéaire avec le nombre de cœurs et de l'hyperthreading ajoute 10 à 20% pour coup de pouce supplémentaire.
    • merci pour l'exécution de ces tests. Je crois qu'une grande partie du temps a été en sortie du compilateur. Tout en parallèle de la construction a certainement contribué beaucoup, j'estime qu'au moins 30 minutes de temps de compilation a été induite juste à cause de l'enregistrement détaillé de sortie, dans mon cas.
    • En plus d'être surpris que clang génère tellement de sortie (comme zaphoyd vérifié), je vous suggère de définir un bas de ligne taille de la mémoire tampon de votre terminal. Je ne pense pas que vous aurez jamais vraiment besoin un demi-million de lignes de l'histoire, et il semble significative de vous ralentir.
    • bon point, qui était sans doute une grande partie du problème pour moi. c'était juste une emacs shell de la mémoire tampon, ce qui maintient tout

    InformationsquelleAutor zaphoyd
  2. 5

    Je suppose que vous n'êtes pas en utilisant en parallèle option de compilation -jN (où N certain nombre de processus, pourrait être un peu plus élevé que le nombre de cœurs sur votre machine). Aussi 3 min le son comme seule configuration de la machine avec un ssd ou un disque ram, et de 5 heures comme toute configuration avec un seul processus et lent disque dur.

    • Je n'ai pas spécifier toutes les options, juste utilisé le coup de pouce défaut comme prévu dans le lien, donc je suppose que je ne suis pas la construction en parallèle. Aurais-je vraiment voir une augmentation d'au moins 10x au moment de la construction en allant parallèle (comme suggéré dans l'un des commentaires à ma question)?
    • Utilisation ./b2 -jn avec n égal au nombre de cœurs que vous avez. Vous verrez une réduction du temps de construction du rond-point x/n (comme cela devrait être prévu). Pour comparaison, j'ai juste fait une time ./b2 -j12 sur ma station de développement (double hexacore Xeon @ 3.3 GHz), et est venu avec 2:05 min temps réel, 22:54 min temps de l'utilisateur.
    • Votre 22:54 de temps pour l'utilisateur est encore loin de mes 300 minutes. Aussi, ma sortie de la construction (les journaux ./b2 crée) est de plus d'un demi-million de lignes selon les emacs shell tampon. Est-ce que ça normal? Peut-être que l'enregistrement a été ralentir les choses (mais pas sûr qu'il est possible de désactiver la journalisation de toute façon).
    • Si vous avez 8 Core CPU, de suffisamment de mémoire et de disque pourrait garder vous pourriez obtenir au moins 8 fois plus rapide avec -j10. Vous pouvez également envisager de quoi avez-vous besoin: debug/release/les deux, statique/shared/deux - seule variante est beaucoup plus rapide que tous les varaints
    • Il se peut que votre Mac par défaut diffère de la mienne (Linux). Peut-être que vous êtes la construction de multiples variantes, comme ISanych fait allusion à l'. Comme pour l'enregistrement, je reçois 2131 lignes, et tant comme il va à la borne (par opposition à disque, il ne devrait pas être un problème. Il y a un beaucoup de la lecture/écriture de la circulation passe de toute façon. Donc... je ne suis pas sûr pourquoi, votre version est si lent.
    • Vous allez voir une certaine amélioration par la spécification de plus que le nombre de noyaux, en supposant que les noyaux sont des dual cores (qu'ils soient sur un 2012 MacBook Pro).
    • Je suis en cours d'exécution un autre test maintenant avec ./b2 -j4 -d0 pour voir ce qui se passe....
    • J'ai mis à jour ma question la grand les résultats de vos suggestions, merci.
    • Je dis "carottes" dans le sens de "cœurs" - 2 pour les dual core, 4 quad-core, etc.

    InformationsquelleAutor ISanych
  3. 0

    Plus de boost sont des paquets d'en-tête uniquement. Si vous avez seulement besoin de ceux-ci, l'installation est simple copie de fichiers. En fonction du nombre de paquets construits que vous faites le temps peut varier de plusieurs ordres de grandeur. Plus oui, compilation parallèle, différents de la machine (Raspberry Pi vs 32 PROCESSEUR IvyBridge de la Lame), etc. Des bâtiments à partir de et vers /dev/shm, vous pouvez obtenir en accélération significative.

    • Comment fonctionne le répertoire de construction elle-même une incidence sur la vitesse?
    • /dev/shm est soutenu par la mémoire (c'est à dire un disque ram) plutôt que de freiner SSD ou HDD.
    • Pour être juste à l'OP, beaucoup de ceux de l'onu-construit libs sont assez fonctionnalités de base pour l'utilisation de Boost en premier lieu.
    InformationsquelleAutor bobah