Niels van Vliet wrote:
Thierry GERAUD wrote:
suite à une discussion rapide hier soir, il semble que le fait que je n'utilise pas la dernière version d'olena pour la prestation SWT ait un effet (psychologique) négatif sur le labo.
L'utilisation de olena (toute version) a en tout cas un effet psychologique positif pour les developpeurs :)
- comme j'effectue bcp de couple compilation/test, le temps de compilation est critique pour mon avancement
Oui, et tu n'es pas le seul à souligner ce problème.
L'algo qui classifie présenté lors du séminaire prend 2 minutes pour compiler sur nostromo, et... se fait killer sur mon pauvre PC.
Il existe des moyens pour diminuer le temps de compile. Doit-on travailler la dessus ? Est-ce une priorité ? Je pense que oui.
ce n'est pas à moi de répondre ; je peux seulement donner mon avis (qui est : je ne pense pas que c'est une des priorités majeures)
olena-0.5 exécution 1,15s 1,08s
olena-0.10 3.3.3 (3.3.3 opt) exécution 1,91s
(2a) << olena, c'est lent >>
Par rapport a la version 0.5, Olena est environ 2 fois plus lent (1.08 vs 1.91). Est-ce important ?
je ne le pense pas pour deux raisons : 1. les temps d'exécution ne peuvent qu'être améliorés (ils le seront dans un avenir qu'il faudrait fixer) 2. le fait de disposer dans olena d'algorithmes performants (au sens des fast::morpho, des filtrages récursifs, de l'union-find de Tarjan) au lieu des versions naïves est bcp plus important
Doit-on travailler dessus ? Doit-on attendre que les compilateurs s'améliorent ?
ce n'est pas à moi de prendre des décisions sur ces points
(2b) << en voulant être générique et rapide, on n'est ni l'un ni l'autre ; >>
Ce qu'a oublié la personne qui a dit ça, c'est que 'générique' et 'rapide' doivent être compris relativement. Il est clair que Olena 0.10 est moins rapide que Olena 0.5 pour les compilateurs actuels. Mais Olena est rapide par rapport à Mathlab, par rapport à de nombreuses autres bibliothèques.
Cf. ce que je disais précédent : il faut dorénavant éviter ce type d'assertions ! quelqu'un a comparé les temps d'exécution avec matlab, avec d'autres bibliothèques ? il faudrait peut-être le faire...
En ce qui concerne la génénéricité, on peut difficilement dire qu'Olena n'est pas génénérique. Mais on peut encore gagner en généricité, en travaillant par exemple sur les images à base de pixels non rectangulaires, ou bien les images Nd.
<< d'ailleurs SCOOP ne marche pas>>
SCOOP n'est pas utilisé systématiquement dans Olena (par exemple la hierarchie des window est mauvaise).
vrai Cf. mon autre post à propos de bêtes fonctions mathématiques ; on a tout à y gagner en passant à SCOOP
Il y a également des modifictions à apporter pour éviter des problèmes de typages dans les morphers. Ceci dit SCOOP marche car Olena 0.10 marche. SCOOP n'est pas finalisé et appliqué partout et c'est pourquoi la version d'Olena n'est pas Olena 1.0. Ceci dit encore une fois il faut fixer les priorités.
oui
(2) que les personnes qui ont dit ça en parlent ouvertement et non pas dans mon dos, qu'elles donnent des chiffres, des arguments (pas des impressions)
On en a déjà parlé lors du pot de la Release Olena-Vaucanson-Transformer. Je pense qu'un certain nombre d'arguments ont été mal interprétés.
sûrement, il faudrait donc en parler
Ceci dit je pense qu'il ne faut pas demander aux personnes mécontentes des preuves, mais faire avancer Olena. Je propose une réunion Olena
tu interprètes mal mes propos : je dis qu'il n'est pas normal de critiquer dans mon dos et, Cf. plus haut, je dis qu'une critique doit être fondée (et, pour ça, il faut _effectivement_ avancer des *faits*)
mercredi matin pour savoir où on veut aller (image Nd, Scoop, compile++, stable?).
très bonne initiative un responsable fait un ordre du jour ?