Discussion :

[skip78]

Salut les gens, je savais pas trop ou poster ca, mais votre débat me fait penser à ce qui m'arrive en ce moment :

J'ai developpé un petit logiciel de traitement d'image, en C.
Le traitement était trés long, mais le taux de réussite d'environ 80%

Je l'ai passé en Cpp (sans changer mes fonctions C) pour des raisons externes, et cela à eu pour conséquence tout à fait innatendue de rendre mon traitement 4 fois plus rapide environ, mais avec un taux de réussite moindre ! (environ 50%)

Alors bon première réaction = "l'informatique est définitivement pas une science exacte", mais deuxième réaction = "Bah ouais définitivement ca me dégoute "

Avez vous deja connu ce genre de situation ?

(Vraiment, fonctions en tout point similaires, je n'ai fait que passer mes .c en .cpp, à quelques warnings prés)

[millie]

Un taux de réussite à 50%, il y a forcement des bugs dans ton application...

[skip78]

Non.
L'objectif du traitement est de détecter dans un deuxieme temps quelque chose de précis sur l'image (je ne peux pas en parler plus précisément désolé), et c'est de ce taux de réussite la que je parle (sachant que la banque de données d'image dont je dispose possede les cas les plus difficiles, 80% est un trés bon résultat).

La n'est pas le sujet de toute facon.

Je suis vraiment intrigué par cet écart impressionant entre les deux versions, et bon, c'est pas la première fois que l'informatique est non détérministe, donc j'aimerais savoir si quelqu'un à déjà connu ca.

[Jean-Marc.Bourguet]

J'ai beaucoup de mal a croire que le langage soit un facteur significatif dans ton histoire: tu as vraisemblablement change d'algo en meme temps et c'est ca qui explique ta chute dans le taux de reussite.

[souviron34]

J'ai beaucoup de mal a croire que le langage soit un facteur significatif dans ton histoire: tu as vraisemblablement change d'algo en meme temps et c'est ca qui explique ta chute dans le taux de reussite.

et dans l'augmentation de la vitesse..

Il est impossible (même avec des traitements de chaînes de caractères) de diminuer un temps de calcul de 75% en passant de C à C++....

@skip78 :

soit tu n'as pas fait que "Vraiment, fonctions en tout point similaires, je n'ai fait que passer mes .c en .cpp, à quelques warnings prés", soit tu avais des structures et constructions aberrantes en C... (je soupçonne une "simili-construction C++" en C..., ou plus précisément un programme C fait par quelqu'un qui ne possède que les paradigmes objets, ou alors qui est débutant)

[Jean-Marc.Bourguet]

et dans l'augmentation de la vitesse.

Il est vraisemblable qu'elle soit due a cela aussi.

Il est impossible (même avec des traitements de chaînes de caractères) de diminuer un temps de calcul de 75% en passant de C à C++....

Je n'utiliserais pas le mot "impossible". J'imagine assez bien un tel rapport pour des operations particulieres, suite a de l'inlining autorise par une implementation a base de template plutot que l'utilisation de pointeurs sur fonctions (genre un tri avec une fonction de comparaison sur un type de base, avec qsort() fait une indirection a chaque comparaison, std::sort() peut inliner facilement). Mais les cas doivent etre relativement rares.

[skip78]

J'ai beaucoup de mal a croire que le langage soit un facteur significatif dans ton histoire: tu as vraisemblablement change d'algo en meme temps et c'est ca qui explique ta chute dans le taux de reussite.

Moi aussi j'ai beaucoup, mais alors vraiment BEAUCOUP de mal à y croire, et c'est pour ca que je me permet de poster ceci ici, je savais que j'aurais pas mal de réactions, et je suis maintenant servi

soit tu n'as pas fait que "Vraiment, fonctions en tout point similaires, je n'ai fait que passer mes .c en .cpp, à quelques warnings prés", soit tu avais des structures et constructions aberrantes en C... (je soupçonne une "simili-construction C++" en C..., ou plus précisément un programme C fait par quelqu'un qui ne possède que les paradigmes objets, ou alors qui est débutant)

Bah j'ai pas grand interet à mentir n'est ce pas
J'ai absolument rien changé.
Pour ce qui est des structures et constructions aberrantes en C, mdr
je vois pas comment je pourrais être aberrant à ce point, mais ca proviens peut être de là :

Mon interface graphique utilise GTK+, et pour retrouver tous mes arguments au fil des callbacks, et éviter les statics, j'ai tout foutu dans une structure globale.

C'est plutot commun en GTK, mais bon peut être que ca peut venir de la ?

De plus le GTK+ utilise une "pseudo structure objet", comme tu dis, mais bon c'est cencé fonctionner en C++.


Je tiens tout de même à préciser que le programme fonctionne à la perfection malgrès les écarts de résultats.

C'est ce qui me fait penser que mon code d'origine est pas si mauvais ...

Mais si quelqu'un peut m'affirmer à 100% que la différence de vitesse ne peut PAS être due au changement de language, c'est que c'est du au fait que mon passage en Cpp est mauvais non ?

Pourtant je vous le répète, je n'ai pas changé une ligne de code, j'ai juste un programme en C dans des fonctions .cpp
Cela ayant pour but d'inclure une lib en cpp.

Enfin voilou de mon coté je tente de repasser tout ca en C malgrès tout, dans l'hypothèse ou c'est effectivement la conception de mon programme qui est foireuse.

[Mat.M]

(Vraiment, fonctions en tout point similaires, je n'ai fait que passer mes .c en .cpp, à quelques warnings prés)

Est-ce que tes routines de traitement d'images appellent des fonctions mathématiques ?( je suppose évidemment que oui surtout si c'est du traitement d'image )
Cela dépend de la manière dont sont implémentées ces fonctions selon le langage en C ou en C++ l'implémentation au niveau bibliothèque de code.
Si tu veux plus t'en rendre compte je te conseille de t'initier à l'assembleur et de tracer en assembleur pour voir comment le code a été compilé selon la version..
il se peut que dans un cas les bibliothèques fassent appellent à une émulation logicielle des fonctions mathématiques ( sin,cos....) et dans l'autre par des calculs avec des instructions assembleur implicites i386/i387.
Pour faire plus clair dans une version le compilo il voit sin( telle_valeur) il fait l'édition des liens avec une routine de code qui émule sin().
Dans l'autre cas il compile directement en code assembleur l'instruction i386 correspondante..
Tout cela tu le verras si tu traces directement dans le code assembleur..
Il y aussi les astuces de mise sur le registre de pile avec des push et pop assembleur comment le compilateur fait cela.


une suggestion de lecture que je ressorts à chaque fois
http://msdn.microsoft.com/en-us/libr...69(VS.60).aspx

[souviron34]

...
il se peut que dans un cas les bibliothèques fassent appellent à une émulation logicielle des fonctions mathématiques ( sin,cos....) et dans l'autre par des calculs avec des instructions assembleur implicites i386/i387.
...

M'étonnerais fortement (ou alors par volonté délibérée de privilégier un langage) que les bibliothèques de maths soit si différentes que ça... avec le même compilo, la même machine, le même OS, le même IDE...


M'enfin, rien n'est hors de portée de M$ en ce qui concerne les coups tordus..