Le projet est très sympa, mais il y a quand même des trucs qui m'interpellent au niveau du vécu, n'y voyez rien de méchant, plutôt une critique constructive...
Hier soir j'ai compilé G'MIC sur mon Core i7 flambant neuf (oui tout cette histoire n'est qu'un alibi pour me la péter avec ma machine de bourrin).
Une fois le configure exécuter, je me dis que ça sera compilé en deux temps trois mouvement grace à un vigoureux "make -j 16", qui lancera la compilation de 16 objets en parallèle (c'est le paramétrage que j'utilise pour compiler des kernels et ça se passe très bien).
Quel ne fut pas ma déception en me rendant compte que tout le projet se trouve dans 2 fichiers CPP, ce qui fait que make n'a pu lancer que 2 compilations en parallèle, compilations qui du coup ont pris une plombe.
De plus, gcc monopolisait une quantité invraisemblable de RAM...
En y regardant de plus près, tous le projet tiens en deux fichiers CPP de respectivement 1000 et 3000 lignes ainsi que d'une poignée de headers, dont le pantagruélique CImg.h qui fait tout de même plus de 36000 lignes...
Alors sans compter le fait qu'on m'a inculqué à l'école de segmenter mes projets en un maximum de petits fichiers pour des raisons d'organisation, le fait est que les outils de compilation aussi préfèrent s'attaquer à une multitude de petit fichier (je suis certain qu'en segmentant Cimg.h, on mangerait beaucoup moins de ram, et en segmentant les fichiers CPP, on pourrait exploiter plusieurs processeurs à la compilation).
Je n'ai que survolé le code (j'ai vu qu'il y avait pleins de choses dans Cimg.h qui ( d'après ce qu'on m'a appris toujours ) n'ont rien faire dans un .h mais devrait être dans un .cpp...), et sans doute y a-t-il une raison technique qui a imposé cette organisation atypique. Je serais positivement ravis qu'un des développeur de ce projet nous l'explique (ceci n'est PAS, je répète, PAS de l'ironie) si c'est le cas...
# PA-RA-LLELE!
Posté par case42 . En réponse à la dépêche Traitement d'images : Quand G'MIC 1.3.0 s'invite dans GIMP. Évalué à 5.
Hier soir j'ai compilé G'MIC sur mon Core i7 flambant neuf (oui tout cette histoire n'est qu'un alibi pour me la péter avec ma machine de bourrin).
Une fois le configure exécuter, je me dis que ça sera compilé en deux temps trois mouvement grace à un vigoureux "make -j 16", qui lancera la compilation de 16 objets en parallèle (c'est le paramétrage que j'utilise pour compiler des kernels et ça se passe très bien).
Quel ne fut pas ma déception en me rendant compte que tout le projet se trouve dans 2 fichiers CPP, ce qui fait que make n'a pu lancer que 2 compilations en parallèle, compilations qui du coup ont pris une plombe.
De plus, gcc monopolisait une quantité invraisemblable de RAM...
En y regardant de plus près, tous le projet tiens en deux fichiers CPP de respectivement 1000 et 3000 lignes ainsi que d'une poignée de headers, dont le pantagruélique CImg.h qui fait tout de même plus de 36000 lignes...
Alors sans compter le fait qu'on m'a inculqué à l'école de segmenter mes projets en un maximum de petits fichiers pour des raisons d'organisation, le fait est que les outils de compilation aussi préfèrent s'attaquer à une multitude de petit fichier (je suis certain qu'en segmentant Cimg.h, on mangerait beaucoup moins de ram, et en segmentant les fichiers CPP, on pourrait exploiter plusieurs processeurs à la compilation).
Je n'ai que survolé le code (j'ai vu qu'il y avait pleins de choses dans Cimg.h qui ( d'après ce qu'on m'a appris toujours ) n'ont rien faire dans un .h mais devrait être dans un .cpp...), et sans doute y a-t-il une raison technique qui a imposé cette organisation atypique. Je serais positivement ravis qu'un des développeur de ce projet nous l'explique (ceci n'est PAS, je répète, PAS de l'ironie) si c'est le cas...