Quelqu'un fait-il des tests de performances matérielles sur la compilation de code? [fermé]

21

J'ai vu un tas de sites qui comparent le nouveau matériel aux performances de jeu, à la fermeture éclair de certains fichiers, à l'encodage d'un film, etc. Existe-t-il des tests de l'impact du nouveau matériel (comme les SSD, les nouveaux processeurs, les vitesses de RAM, etc.) sur les vitesses de compilation et de liaison, Linux ou Windows?

Ce serait vraiment bien de savoir ce qui comptait le plus pour la vitesse de compilation et de pouvoir se concentrer sur cela, au lieu de simplement extrapoler à partir d'autres références.

benchmarking Colen
la source
Je pense que cela appartient à SuperUser.
Mahmoud Hossam
2
@Mahmoud Hossam: Sorte de sujet mixte, la compilation est une activité intensivement réservée aux programmeurs, tandis que les benchmarks matériels sont définitivement un territoire différent.
Orbling
@Orble bien, il ne demande pas s'il doit compiler X ou Y, il demande si les gens utilisent la compilation en général pour faire des benchmarks.
Mahmoud Hossam
1
j'ai fait quelques kokizzu.blogspot.co.id/2015/02/…
Kokizzu
1
Il y a un benchmark CPU basé sur les temps de compilation du noyau Linux ici: openbenchmarking.org/showdown/pts/build-linux-kernel
sjakobi

Réponses:

4

Je l'ai fait pendant un certain temps - voir ici et ici .

À l'époque, je travaillais sur des hacks GTK + et X11 pour une distribution de téléphone portable Linux, et chaque fois que je touchais quelque chose à un niveau aussi bas, cela déclenchait la reconstruction de toutes sortes de choses. Un de mes collègues n'a jamais terminé les builds car, sur l'ordinateur fourni par l'entreprise avec les options de compilation standard, cela a pris cinq heures.

J'avais toutes sortes de matériel fou à la maison, alors j'ai exécuté des tests de performance sur certaines machines pendant que je codais sur d'autres, et vous pouvez voir les résultats sur les liens.

Pour ce que nous faisions sur Ubuntu, une fois que j'ai optimisé l'utilisation du processeur - ce que vous pouvez faire très facilement avec l'argument -j à faire - le goulot d'étranglement semblait être le disque.

Mais ensuite, l'entreprise a fait de grosses mises à pied, alors j'étais dehors, et je n'ai pas fini de délimiter tout cela. J'avais beaucoup de données et d'interprétations que je n'ai pas publiées sur ce blog aussi.

Bob Murphy
la source
Dommage de le construire avec deux posts détaillés et les arrêter. Avez-vous encore toutes ces données? Dans tous les cas, il serait très intéressant de voir certains articles / réponses de blog avec quelques conclusions de ce que vous avez trouvé.
Hugo
@Hugo: Non, j'ai bien peur que non - les données brutes ont disparu depuis longtemps. Mais en gros, ce que j'ai trouvé, c'est que pour les systèmes (1-8 cœurs de processeur) et le code source (le noyau Linux) que je testais, les temps de construction les plus rapides étaient lorsque l'option -j était à 1,5 fois le nombre de cœurs, avec -j = 2 étant le meilleur pour un noyau. En dessous, les systèmes étaient liés au CPU et au-dessus, ils étaient liés aux E / S. C'est une question intéressante - je devrais peut-être la reprendre un jour.
Bob Murphy
0

Le premier sur ma liste de souhaits est un disque SSD. Cela n'aura pas un impact énorme sur le temps de compilation, mais l'ouverture des applications devient considérablement plus rapide (IDE, PhotoShop, ETC). http://joelonsoftware.com/items/2009/03/27.html

Le plus grand facteur de temps de compilation sera le CPU. Vous êtes assez sûr de l'utiliser pour la référence http://www.cpubenchmark.net/ .

Evan
la source
1
Là encore, beaucoup dépend de votre chaîne de construction. Si votre chaîne de génération utilise uniquement un seul thread pour la compilation sur un processeur multi-CPU, multi-core ou même multi-thread, vous perdez une opportunité de gains massifs. Un benchmark CPU simple ne le montrera pas, et un benchmark de compilation ne serait bon que pour une chaîne d'outils donnée.
asoundmove
2
En fait, j'ai découvert par expérience qu'une fois que vous faites une compilation parallèle, c'est votre disque qui est le goulot d'étranglement. Dans la limite du raisonnable, vous feriez mieux avec un processeur plus lent et un disque plus rapide que l'inverse.
Bob Murphy