Aujourd'hui je compile un projet de quelques milliers de lignes de code sur un ordinateur équipé d'un processeur Intel Core i7 16 cœurs qui met pourtant 15min !
Du coup je me demande ce que ça devait être dans le temps sur des vieux processeurs avec un seulement un cœur... Les programmeurs de l'ancien temps devaient passer leur journée à compiler !
EDIT : en fait après avoir compté le projet fait dans les 450 000 lignes de code de C/C++ ce qui explique peut-être le temps de compilation ^^'
Quelques milliers de lignes en 15 min, c'est lent. Il faudrait voir ton code (includes inutiles ? Pch ? Modules ?), comment tu compiles (-j16 ? Compilation incrémentale ? Libs ?), etc. J'ai des projets de plusieurs centaines de milliers de lignes et ça compile pas en plusieurs heures.
Et dans le passé, il avait juste des programmes plus simples (moins de lignes de code, moins de complexité, hardware cibles moins performants, beaucoup beaucoup moins de besoins utilisateur, etc), donc plus rapide a compiler.
Je me suis amusé à générer un petit programme C++ avec Python. Il a un peu plus de 100 000 lignes. Il compile en environ 10 secondes (pas minutes).
Et en environ 12 secondes (au pif) en -O3
Et il s'exécute sûrement en moins de 3 secondes (...) - print("#include <iostream>\n\ #include <vector>\n\ #include <array>\n\ #include <string>\n\ int dummy(int a, int b) {\n\ return a*a+b*b;\n\ }\n\ int main(void) {\n\ int v0 = 0;\n\ int v1 = 1;\n\ ") n=100000 for i in range(2, n+1): print(f" int v{i} = dummy(2*v{i-2}, v{i-1}+3);") print("}")
- Edité par PierrotLeFou 16 septembre 2022 à 2:02:29
Le Tout est souvent plus grand que la somme de ses parties.
C'est pas forcément pertinent de mesurer la compilation sur 1 seul fichier. 1 fichier de 100 000 lignes compilera plus vite que 1000 fichiers de 1000 lignes.
Alors je laisse Autechre le plaisir de le tester ... J'ai déjà travaillé sur des processeurs à 33 Mhz et ça ne prenait pas des heures non plus pour quelques milliers de lignes.
et 1000fois 1000 ça fait 1 000 000, pas 100 000 ...
le temps de chargement du compilateur n'est plus négligeable dans ce cas.
- Edité par PierrotLeFou 16 septembre 2022 à 3:32:25
Le Tout est souvent plus grand que la somme de ses parties.
A l'auteur, c'est en effet étrange que ton projet mette si longtemps à compiler.
Après, les compilateurs d'aujourd'hui font beaucoup plus de choses que leurs ancêtres. Ils essaient d'optimiser plein de trucs.
Les anciens compilos étaient assez brut.
Autre chose, je vois qu'on est en C++, toutes les bibliothèques standard modernes sont bourrés de template et de metaprogrammation : des calculs, des algos qui peuvent être faites à la compilation (pour optimiser, encore)
Tout cela prend donc du temps alors que leurs ancêtres se contentaient de passer tout droit.
Il y a des projets qui mettent une plombe à compiler et ne sont pourtant pas spécialement gros. WebKit par exemple, on est à plusieurs heures.
Aujourd'hui le C++ met du temps à compiler pour plusieurs raisons :
Les gens utilisent des bibliothèques header-only avec beaucoup d'over-engineering (boost, nlohmann::json (vous avez vu comme elle est bloat cette bibliothèque, pour parser du JSON ?)). Personnellement c'est ce qui m'agace le plus, le compilateur relit encore et encore le même code. C'est le gros problèmes de templates qui sont sur-abusés. Non les entête précompilés ne sont pas la solution, c'est déplacer le problème.
Les programmes sont plus gros (C'est du C, mais le code du noyau Linux décompressé fait 1,4Go au secours).
Les compilateurs sont plus lent. Moi je trouve ça indécent, j'ai beau avoir un MacBook et un ThinkPad surpuissants, ils compilent à peine plus vite que mon vieux HP ProBook (le HP ayant des vieilles versions de gcc/clang et moins de performance).
De toute façon, le développement c'était mieux avant. Oui je suis un boomer ET J'ASSUME. Sérieusement, les projets Rust ou NPM me donnent des boutons.
On est loin de l'époque où tout était clean, simple et propre mais heureusement il y a encore des projets qui s'en approchent.
- Edité par markand 16 septembre 2022 à 9:02:32
git is great because Linus did it, mercurial is better because he didn't.
De toute façon, le développement c'était mieux avant. Oui je suis un boomer ET J'ASSUME. Sérieusement, les projets Rust ou NPM me donnent des boutons.
On est loin de l'époque où tout était clean, simple et propre mais heureusement il y a encore des projets qui s'en approchent.
Voilà c'est exactement ça !! De nos jours tout est plus lent qu'avant car c'est over-engineeré, très complexe etc. Un programme ça devrait être juste un foutu exécutable qui se lance instantanément (comme dans cette vidéo que j'avais déjà linké https://www.youtube.com/watch?v=r9eQth4Q5jg)
Aujourd'hui avec les cmake et autre on se mange plein d'erreurs, ça met une éternité à compiler etc.
Pour éviter les longs temps de compilation il faut faire un unity build, donc avoir 1 seule translation unit (ou alors 1 par "gros morceau" du projet), du coup ça fait que tous les includes ne sont compilés qu'une seule fois
Franchement, je ne voit pas ou est le soucis (s'il doit y en avoir un).
Tout projet bien chiffré prendra en compte les temps de compilation. Et le temps de compilation par rapport au temps de développement, c'est peanuts.
Enfin, je préfère un truc qui prennent un peut plus de temps à compiler et soit bien optimisé pour mon système, qu'un truc compilé au moule à gaufres qui suce plus de ressources qu'il n'en devrait.
Franchement, je ne voit pas ou est le soucis (s'il doit y en avoir un).
Tout projet bien chiffré prendra en compte les temps de compilation. Et le temps de compilation par rapport au temps de développement, c'est peanuts.
Enfin, je préfère un truc qui prennent un peut plus de temps à compiler et soit bien optimisé pour mon système, qu'un truc compilé au moule à gaufres qui suce plus de ressources qu'il n'en devrait.
Pas d'accord. Sur une application dans un ancien emploi (environ 20M de lignes de code), je paniquais à l'idée de changer un entête car je savais que derrière j'allais avoir 10 à 15 minutes de compilation gratos.
Dans mon poste actuel en embarqué, le temps de compilation est faible car nos applications sont petites mais FreeRTOS prend quand même bien une petite minute à compiler en entier. Ensuite, tu rajoutes le temps de flashage de la carte (4-5 secondes environ) tu perds quand même beaucoup de temps pour rien. Heureusement que ninja est là pour améliorer le temps de compilation de manière considérable et que FreeRTOS ne se recompile pas au moindre changement parce qu'avec make c'est x4.
Ksass`Peuk a écrit:
markand a écrit:
On est loin de l'époque où tout était clean, simple et propre
Il a fallu que j'arrive ici pour comprendre le troll.
Pas sûr de voir de quel troll tu parles ou alors vis-tu dans une cave utopique. Sinon, n'hésite pas à me partager des projets opensource récents encore agréables à lire sans être bloat.
Tiens d'ailleurs une phrase de la chanson le généralise bien
« Tout est toujours plus puissant mais de plus en plus lent »
Si je suis le seul à être alarmé quand un système comme macOS a — après un démarrage à vide — déjà 4Go de RAM utilisé et plus de 540 processus alors oui, tout est propre.
- Edité par markand 16 septembre 2022 à 15:55:03
git is great because Linus did it, mercurial is better because he didn't.
je paniquais à l'idée de changer un entête car je savais que derrière j'allais avoir 10 à 15 minutes de compilation gratos.
C'est un peu l'idée des headers : c'est sensé être une interface stable et ne devrait pas être changé tout le temps.
Et un header n'est pas sensé non plus provoquer la recompilation en cascade de tout le projet.
Parce que je ne l'ai pas précisé, parce que ça me paraissait évident, mais quand on bosse sur des tâches de tous les jours, ça ne prend pas des dizaines de minutes pour compiler : ca prend quelques secondes, le temps de recompiler que ce qui a été modifié et les dépendances. Il n'y a que quelques headers qui risquent de provoquer des grosses recompilations, mais ces headers sont sensés être encore plus stables et ne pas être modifié très souvent.
Si c'est pas le cas, il faut voir s'il n'y a pas un gros problème d'architecture du projet.
markand a écrit:
Sinon, n'hésite pas à me partager des projets opensource récents encore agréables à lire sans être bloat.
Ca n'a pas de sens, on ne compare pas du tout des choses comparables. Du bloat code, c'est du code inutile et inutilement complexe pour réaliser une tâche. Quand tu as plus de fonctionnalités (même si tu ne les utilisent pas), c'est normal d'avoir plus de code et c'est pas du bloat code.
Ton Mac a peut être 540 processus qui tournent de plus qu'un Mac d'il y a 20 ans, mais il est capable de créer une connection avec un périphérique en quelques secondes, tu peux lui parler pour lancer des tâches, t'afficher de façon transparent un disque en ligne comme si c'était un disque local, etc.
Un ordinateur moderne n'est absolument pas plus compliqué et plus lent qu'un ancien ordinateur, c'est même l'inverse : beaucoup de tâches que l'on réalise maintenant en quelques secondes prenaient avant des minutes ou des heures pour être réalisées. Si tu voulais utiliser un ancien ordinateur de nos jours POUR REALISER LES MEMES TACHES QU"UN ORDINATEUR MODERNE, l'ancien ordinateur serait un veau.
C'est juste une forme de biais de selection, tu retiens les tâches que tu trouves lents de nos jours, en oubliant l'ensemble des tâches qui sont plus performantes de nos jours, en oubliant tout ce que l'ordi fait de façon transparente, et en comparant avec des domaines non comparables (embarqués).
je paniquais à l'idée de changer un entête car je savais que derrière j'allais avoir 10 à 15 minutes de compilation gratos.
C'est un peu l'idée des headers : c'est sensé être une interface stable et ne devrait pas être changé tout le temps.
Sauf que c'est précisément le problème des gens qui développent dans les entête (ou abusent des templates). Non un header ne doit pas tout recompiler mais il suffit que ce soit un entête un peu global contenant une constante ou une classe vraiment très utilisée et c'est le drame.
gbdivers a écrit:
Ca n'a pas de sens, on ne compare pas du tout des choses comparables. Du bloat code, c'est du code inutile et inutilement complexe pour réaliser une tâche. Quand tu as plus de fonctionnalités (même si tu ne les utilisent pas), c'est normal d'avoir plus de code et c'est pas du bloat code.
Et bien c'est précisément le cas de la bibliothèque de Niels, au début c'était un parseur JSON, maintenant ça fait :
du cbor
du bson
du MessagePack (sérieusement ?)
Pourquoi les gens continuent d'intégrer encore et encore des fonctionnalités ? Quand j'ai connu cette bibliothèque elle était chouette et simple. Maintenant c'est une usine à gaz du JSON. 17539 lignes de code pour gérer un format aussi simple que JSON, pour moi c'est insensé.
git is great because Linus did it, mercurial is better because he didn't.
Ton Mac a peut être 540 processus qui tournent de plus qu'un Mac d'il y a 20 ans, mais il est capable de créer une connection avec un périphérique en quelques secondes, tu peux lui parler pour lancer des tâches, t'afficher de façon transparent un disque en ligne comme si c'était un disque local, etc.
Il y a peut être plein de trucs en plus par rapport à avant, mais si c'est pour qu'au final on doive quand même attendre pour les taches basiques c'est un peu idiot, genre afficher les variables dans le debugger, aujourd'hui on ne peut pas spammer la touche "step" et voir les variables se mettre à jour direct alors qu'on pouvait le faire avec un pentium 4 d'il y a 20 ans https://www.youtube.com/watch?v=GC-0tCy4P1U&t=2188s
Il faut arrêter de croire que il y a plus de choses à faire aujourd'hui donc c'est plus lent, non les machines sont des millions de fois plus rapides qu'avant mais les logiciels sont codés n'importe comment et donc ça gache énormément de cycles CPU, c'est pas car il y a plus de choses à faire.
Et en parlant de JSON, tout le temps qu'on a perdu à attendre que ce p*** de GTA Online de m*** se lance, bah devinez quoi ? C'était gratuit, cadeau de Rockstar, il n'y avait AUCUNE raison technique d'attendre autant de temps, c'était juste codé n'importe comment https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/
Sauf que c'est précisément le problème des gens qui développent dans les entête (ou abusent des templates). Non un header ne doit pas tout recompiler mais il suffit que ce soit un entête un peu global contenant une constante ou une classe vraiment très utilisée et c'est le drame.
Ca arrive que l'on a pas le choix et que certaines tâches nécessitent de tout recompiler un projet plusieurs fois. Mais pour une tâche de tous les jours, si cella arrive, cela devrait être considéré (à mon avis) comme un bug dans l'architecture ou la gestion du projet.
Par exemple, un fichier qui contient de constantes, qui sont utilisées partout et qui sont modifiées souvent, il y a un problème. Peut être qu'il faut séparer les constantes dans plusieurs fichiers, peut être qu'il ne faut pas inclure le fichier de constantes dans les headers, peut être qu'il faudrait évaluer le gain d'avoir des constantes qui changent tout le temps comparé à l'augmentation du temps de compilation, etc. Je sais pas, il faut voir au cas par cas, mais il faut considérer ça comme un bug.
Un exemple concret que j'ai déjà rencontré, c'est un buildnum (numéro de build qui changeait tous les jours), qui était généré automatiquement tous les jours dans un header (et donc des recompilations). Le diagnostique a été simple : les avantages d'avoir un buildnum qui change tous les jours étaient moins important que le gain en temps de compilation POUR UN BUILD LOCAL. Le buildnum est devenu une constante (0) pour les builds locaux et seul le CI utilisait un buildnum qui change tous les jours (ce qui n'était pas impactant sur le CI, puisque de toute façon, c'était un clean build systématique).
Pour les templates, c'est pareil : même si tu as un code très templaté, tu n'es pas sensé tout recompiler le projet à chaque modification d'une ligne. Tu devrais bosser sur un template, recompiler (potentiellement plusieurs fois) uniquement les tests qui valident ce template. Et uniquement quand tu as fini de modifier le template et que c'est validé, tu recompiles tout le projet.
Et quand même, un template qui affecte tout un projet et qui est modifié régulièrement, il faut se poser des questions et considérer ça comme un bug. Imagine par exemple que tu as ta propre implémentation de vector, qui est utilisé partout dans ton projet. Ok, si tu modifies cette classe, ça va provoquer la recompilation complète du projet. Mais une implémentation de vector qui n'est pas stable et change tout le temps ??? Ca serait étrange et devrait être considéré comme le signe d'un problème d'architecture ou de gestion de projet.
Bref, ça peut arriver, mais ça doit être considéré comme un bug. Et souvent, il existe des solutions.
EDIT : j'ai oublié de répondre au second point. Mais ok, je peux comprendre que ça t'embête d'avoir une lib qui fait des choses que tu n'utilises pas et que le code qui en résulte te semblera inutilement complexe (pour ce que tu utilises).
Mais c'est pas du code bloat, puisque c'est du code utile pour les fonctionnalités qu'elle propose (même si tu n'utilise pas ces fonctionnalités). Et en termes de développement et de gestion de projets, cela a du sens de faire en sorte qu'un code soit générique et supporte plusieurs format, plutôt que de faire des copier-coller du meme code pour chaque format, ce qui pose des problèmes de maintenance.
C'est juste un choix logique (même si tu n'aimes pas ce que cela implique sur la taille du code)
Blah blah blah (un bon paquet de n'importe quoi au passage), Casey (non, sérieux, encore ?), blah blah blah...
- Edité par dragonjoker il y a environ 1 heure
J'aimerais bien savoir où sont les "n'importe quoi", pour moi ce qui est n'importe quoi c'est la lenteur qu'on se mange au quotidien alors qu'on a des pc puissants largement capables de faire tourner les logiciels.
Je vous donne 2 exemples de lenteur inutile : prendre en paramètre un unique_ptr au lieu de unique_ptr&& (ça oblige un move inutile), et à chaque fois qu'on a un unique_ptr dans le scope, il va quoi qu'il arrive se faire détruire, même si on lui a déjà sucé le sang comme vous dites, et donc le destructeur va au moins faire un check pour voir si y'a un truc à delete alors qu'on sait qu'il n'y a rien
Et flute pourquoi votre message est vide et "édité" ? J'ai pas eu le temps de le lire
Je vous donne 2 exemples de lenteur inutile : prendre en paramètre un unique_ptr au lieu de unique_ptr&& (ça oblige un move inutile)
Non.
JadeSalina a écrit:
et à chaque fois qu'on a un unique_ptr dans le scope, il va quoi qu'il arrive se faire détruire, même si on lui a déjà sucé le sang comme vous dites, et donc le destructeur va au moins faire un check pour voir si y'a un truc à delete alors qu'on sait qu'il n'y a rien
Non (bis).
(Il y aura une différence entre un raw ptr et un unique_ptr que si tu ne fais pas la même chose entre les 2, c'est a dire soit ne rien libérer avec un raw ptr - ce qui est une erreur - soit libérer libérer 2 fois avec unique_ptr. Dans les 2 cas, c'est idiot de faire ca)
Notez qu'ils recommandent de priviliégier la simplicité à la performance, et c'est exactement ça qui fait qu'on se retrouve avec des trucs plus lents qu'ils devraient. Alors ok ça prend 0.00001 micro seconde mais mis bout à bout ça fait des minutes à attendre pour rien
gbdivers a écrit:
JadeSalina a écrit:
et à chaque fois qu'on a un unique_ptr dans le scope, il va quoi qu'il arrive se faire détruire, même si on lui a déjà sucé le sang comme vous dites, et donc le destructeur va au moins faire un check pour voir si y'a un truc à delete alors qu'on sait qu'il n'y a rien
Non (bis).
Je ne connais pas bien les outils de profiling mais j'ai l'impression que le new/delete est quand même plus rapide que le unique_ptr, ils disent que "lower is faster" et j'ai l'impression que le rectangle du new/delete est plus bas que celui du unique_ptr mais c'est peut être mon écran qui bave sur les couleurs vives
Je ne connais pas bien les outils de profiling mais j'ai l'impression que le new/delete est quand même plus rapide que le unique_ptr, ils disent que "lower is faster" et j'ai l'impression que le rectangle du new/delete est plus bas que celui du unique_ptr mais c'est peut être mon écran qui bave sur les couleurs vives
Non significatif. Les outils de benchmarks font tourner le code des milliers ou des millions de fois, pour avoir des valeurs mesurables. Si on voit pas de différence, c'est que c'est pas pertinent. (Et oui, la valeur mesurée n'est pas exactement la même a 10 décimales près. Le contraire serait étonnant, meme en faisant tourner 2 fois le meme code).
Notez qu'ils recommandent de priviliégier la simplicité à la performance, et c'est exactement ça qui fait qu'on se retrouve avec des trucs plus lents qu'ils devraient. Alors ok ça prend 0.00001 micro seconde mais mis bout à bout ça fait des minutes à attendre pour rien
Toujours non. Le compilateur fait son boulot et il n'y a pas de différence, comme tu peux le voir sur les graphiques.
Et je sais bien que tu ne comprends rien au profiling. C'est pour ca que tu gobes pleins de conneries sur les performances de Casey, sans réussir a prendre du recul.
Pas sûr de voir de quel troll tu parles ou alors vis-tu dans une cave utopique. Sinon, n'hésite pas à me partager des projets opensource récents encore agréables à lire sans être bloat.
Et du coup c'est dans quelle cave utopique le vieux code qui est simple et propre ? Non parce que du vieux code, je bosse sur ça très souvent et s'il y a beaucoup de qualificatifs qui me viennent à l'esprit quand je le fais, "simple" et "propre", étrangement c'est pas dans la liste. On parlera même pas de 'testé" (et même quand on a "testé", "testé correctement" c'est mort).
- Edité par Ksass`Peuk 17 septembre 2022 à 8:31:43
Bon, depuis que j'ai créé le topic je me suis rendu compte que mon projet faisait plutôt dans les 450 000 lignes de code C/C++. Un facteur 10 par rapport à ce que j'avais indiqué à la base...
@gbdivers: Comme je l'ai indiqué, j'ai compilé du code de 100 K lignes en 10 secondes. Donc ça devrait faire 45 secondes pour 450 K lignes. Ce n'est pas aussi évident que je viens de le dire. Il faut compter le nombre de fichiers qui sont compilés séparément. Il faut ajouter les include qui en incluent d'autres. Est-ce qu'on prend le temps de choisir le bon fichier? Je donne un exemple avec C que je connais mieux. stdlib.h contient entre autres malloc.h, random.h, errno.h, etc. Il m'arrive de prendre le temps de choisir le fichier minimal requis. Mais est-ce que je le fais tout le temps? Non!
Et on ne parle pas de la complexité des programmes et du niveau d'optimisation.
- Edité par PierrotLeFou 18 septembre 2022 à 1:33:11
Le Tout est souvent plus grand que la somme de ses parties.
@Pierrot Désolé, je n'ai pas très bien compris ton propos. Tu réponds a quel message ?
45 secondes pour compiler un vrai projet d'un demi million de lignes de code, c'est pas habituel. Je pense que cela est du a la simplicité du code que tu génère.
Personnellement, 15 min pour 450k, ca me choque pas.
Je dois trouver des solutions pour accélérer le temps de compilation mais c’est pas simple. J’ai essayé d’activer l’option Unity Build de Cmake mais la compilation rate… Il y a probablement des conflits dans les noms…
J'avoue que mon code est d'une grande simplicité, même pas une boucle ... Quand on n'est pas dans le code d'un autre, on ne peut pas savoir. Mais il me semble qu'il est possible de compiler seulement une partie du code si c'est possible de le séparer en modules.
Le Tout est souvent plus grand que la somme de ses parties.
Discord NaN. Mon site.
Le Tout est souvent plus grand que la somme de ses parties.
Discord NaN. Mon site.
Le Tout est souvent plus grand que la somme de ses parties.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
git is great because Linus did it, mercurial is better because he didn't.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
git is great because Linus did it, mercurial is better because he didn't.
Discord NaN. Mon site.
git is great because Linus did it, mercurial is better because he didn't.
Discord NaN. Mon site.
Si vous ne trouvez plus rien, cherchez autre chose.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Discord NaN. Mon site.
Le Tout est souvent plus grand que la somme de ses parties.
Discord NaN. Mon site.
Discord NaN. Mon site.
Le Tout est souvent plus grand que la somme de ses parties.