7 Jun
2004
7 Jun
'04
10:05 a.m.
Niels van Vliet wrote:
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
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...
sûrement, il faudrait donc en parler
Thierry GERAUD wrote:
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)
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. 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 ? 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. 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.
vrai
Cf. mon autre post à propos de bêtes fonctions mathématiques ; on a tout
à y gagner en passant à SCOOP
<< d'ailleurs SCOOP ne marche
pas>>
SCOOP n'est pas utilisé systématiquement dans Olena (par exemple
la hierarchie des window est mauvaise). 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. 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 ?