search

cgogn / CGoGN_2

n-dimensional Meshes with Combinatorial Maps
https://cgogn.github.io
GNU Lesser General Public License v2.1
20 stars 19 forks source link

Comparison #287

Closed etienneschmitt closed 7 years ago

etienneschmitt commented 7 years ago

Ajout de benchs permettant de comparer cgogn à d'autres libs : -cgogn1 -cgal LCC -OpenMesh -SurfaceMesh

Ce sont des tests qui proviennent du package LCC de CGAL. Je ne sais pas s'ils sont tous pertinents, j'attends vos retours. Je pense qu'on devrait y ajouter ceux développés de notre côté. Ces benchmarks ne couvrent pour l'instant que les 2-cartes. Le reste suivra dans un second temps.

untereiner commented 7 years ago

Ne serait-il pas judicieux de mettre tous ces bench dans un dépôt à côté de celui du code de la lib ? Sinon, j'ai donné mes benchs à Guillaume Damiand, qui les a mis dans cgal, j'ai les mêmes pour les volumes.

etienneschmitt commented 7 years ago

Je dirais que le dossier benchmark fait très bien l'affaire pour l'instant. OK pour les benchs, donc il y a de fortes chances que tu ais écrit les benchs que j'ai rajoutés dans cette PR ;-)

etienneschmitt commented 7 years ago

J'ai aussi vu ceux pour les volumes, je m'y attaquerai quand j'aurai un peu de temps.

untereiner commented 7 years ago

SI tu veux y rajouter des comparaisons avec d'autres libs et donc des dépendances à ces libs, je considère que ce dossier n'a plus sa place dans le projet "code d'un noyau de modeleur" mais que c'est un projet à part entier dont cgogn2 est une dépendance au même titre que les autres libs

etienneschmitt commented 7 years ago

Voilà j'ai un peu cherché et je pense avoir reglé le problème d'une façon plus maline.

etienneschmitt commented 7 years ago

Concernant les dépendances tu as dû mal regarder, il n'y en a aucune.

etienneschmitt commented 7 years ago

En regardant de plus près @untereiner , tu verras les find_package que j'ai mis n'ont pas le mot clef REQUIRED. Les benchs compilent très bien avec juste cgogn2. Bien sûr dans ce cas la comparaison sera limitée. Ensuite concernant l'idée de mettre ces benchs ailleurs, je réponds que non, ils sont à leur place ici. Cordialement.

untereiner commented 7 years ago

Oui, c'est une dépendance, optionnelle, mais une dépendance quand même. Tout ceci sans autre argument que "ils sont à leur place ici". Soit, je m'incline.

pierrekraemer commented 7 years ago

C'est quoi le fichier "comparison.patch" ?

etienneschmitt commented 7 years ago

Un fichier qui n'a rien à faire ici. Je fais un dernier commit en essayant de nettoyer les nombreuses coquilles de cette PR et ce sera bon de mon côté.

pierrekraemer commented 7 years ago

Bon, si on a fini avec la correction des problèmes de gestion d'attributs de marquage, je donne mon avis sur l'autre discussion qui anime cette PR. On a depuis longtemps un dossier "benchmarks" dans lequel il y a du code pour mesurer des temps d'exécution. Qu'il y ait là dedans du code qui permette de mesurer des temps d'exécution pour des algos communs sur des libs autre que cgogn dans le cas où ces dernières sont disponibles sur la machine, cela ne me dérange pas plus que ça. Si on ne veut que le code du coeur de la lib sur ce dépôt, alors on peut supprimer complètement le dossier "benchmarks", et en poussant un peu dans ce sens, on pourrait aussi déplacer les "tests" et les "examples" dans un autre dépôt. Cela ne me semble pas souhaitable. En revanche, la compilation des benchs peut, si l'utilisateur le souhaite, ne pas être faite du tout. A ce sujet, je serais d'avis que dans le CMakeLists racine, les options CGOGN_BUILD_BENCHS, CGOGN_BUILD_EXAMPLES et CGOGN_BUILD_TESTS soient à OFF. Ainsi, par défaut, on ne compile que la lib. En tant que développeur, on souhaitera certainement compiler au moins les tests (et aussi probablement les exemples), mais cela reste facile à configurer.

etienneschmitt commented 7 years ago

D'accord avec tout ça. J'ai rajouté un commit pour l'appliquer et j'ai mis l'intégration continue à jour pour qu'elle active tout le temps les tests et les examples.

untereiner commented 7 years ago

Et pourtant, ce découpage c'est la bonne pratique employée par une bonne partie des projets ici ou ailleurs. Je peux ajouter un paquet de liens pour le démontrer si nécessaire. Maintenant, si la majorité ici ne souhaite pas sortir des années 2000 sans autre argument que "c'est plus pratique pour nous" je m'incline. Mes contributions étant désormais assez limitées je ne voudrais pas imposer ma vision. 🙈

pierrekraemer commented 7 years ago

Disons que pour le moment, ça me semble effectivement plus pratique comme ça. Comme tu l'avais justement fait remarquer toi-même, CGoGN n'a pas actuellement une base de développeurs / utilisateurs particulièrement importante.. Et je ne pense pas que cela soit dû au problème dont on est en train de parler. Quoi qu'il en soit, si on a un jour de nombreux utilisateurs qui souhaitent ce changement, cela ne sera pas difficile à réaliser.

untereiner commented 7 years ago

Je ne vois pas de corrélation directe entre le nombre de développeurs/utilisateurs et le recentrage de l'objectif de ce dépôt de code. Par contre, ce dont je suis convaincu c'est que ce changement sera encore plus difficile à effectuer s'il y a plus de personnes impliquées (j'ai le cas sous les yeux avec sofa). T'es le boss, on peut donc clore le sujet et accepter toutes ces modifications.

etienneschmitt commented 7 years ago

Moi c'est vraiment sur le fond que je ne suis pas d'accord. Le projet "CGoGN_2" intègre non seulement la librairie, mais des petites applications (qui ont valeur d'exemples), des tests, et des benchmarks. Qu'y trouves-tu de choquant ? Quelle "bonne pratique" dont tu parles violons-nous ? Est-ce que tu as protesté quand on a décidé de faire des modules avec à chaque fois un dossier "tests" et "examples" ? Je trouve que tu fais beaucoup de zèle pour ce qui me semble être un point de détail. Pour le cas des benchmark, le tout est dans un dossier "benchmark", à côté du dossier "cgogn". Tout le monde comprend sa raison d'être ici: permettre de mesurer les performances de cgogn (seul ou face à d'autres libs). Ce genre d'outil est directement lié au projet ce qui justifie sa présence sur le dépôt. De ton côté tu as beaucoup critiqué mais dans aucun de tes messages je ne vois la moindre justification de ton point de vue. Tu parles de bonnes pratiques sans les décrire et d'innombrables projets sans en citer un seul...

untereiner commented 7 years ago

😆 Toujours la même histoire, même après ton départ de mimesis. Pour les libs, et juste pour rester dans la communauté, au choix: cgal (doc) / sofa (doc) / libigl (doc/tests/examples). J'étais contre les dossiers tests et examples mais je n'ai malheureusement pas d'enregistrement 💩 .... Nous ne serons jamais d'accord donc pour ma part ça s'arrête ici.