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)

[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

[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.

[souviron34]

Je n'utiliserais pas le mot "impossible".

admettons, je ne me battrais pas là-dessus

[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..

[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.

[souviron34]

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 ?

ben ça c'est classique... et à priori ça ne viendrait pas de là..

Et utilises-tu GTK+ dans les 2 langages ?

Sinon, pourquoi transformer tout un programme pour utiliser une biblothèque ?? une API spécifique aurait suffi...

[skip78]

Oui Gtk+ dans les deux.

Je viens de faire une série de tests, c'est vraiment étrange.

Pour certains panels d'image j'ai de meilleurs résultats en C, pour d'autres de meilleurs résultats en Cpp.

Bon sans trop pouvoir rentrer dans les détails, je ne travaille pas seul, et je reçois plusieurs librairies à tester. Au départ j'ai fait mon programme en C pour qu'il soit le plus portable possible, mais la plupart des libs sont en Cpp, donc bon vu que le C est supposé fonctionner en C++, je me suis dis pourquoi ne pas faire un copier collé tout con.

Et la les ennuis ont commencés.

P.S. J'ai besoin d'aller chercher des variables et manipuler les fonctions des libs à tester, donc je suis obligé de les intégrer convenablement.

Cela étant dit c'est peut être la librairie sur laquelle je travaille actuellement qui à mal été transcrite du Cpp vers le C.
Même si l'opération semblait simplissime, y'avait du extern C un peu partout si je me souviens bien, donc c'est pas dit que y'ai une couille dans le potage.

Bref je sais toujours pas à quoi c'est du, et surtout je ne sais que choisir entre la version plus stable mais plus lente de C ou la version rapide et parfois plus précise C++.

Etant donné mes difficultés à comprendre la situation, je pense revenir en C, mais bon c'est tout de même bien dommage ...

En tout cas bonne soirée à tous, et bon courage si vous taffez

[gl]

Bon sans trop pouvoir rentrer dans les détails, je ne travaille pas seul, et je reçois plusieurs librairies à tester. Au départ j'ai fait mon programme en C pour qu'il soit le plus portable possible, mais la plupart des libs sont en Cpp, donc bon vu que le C est supposé fonctionner en C++, je me suis dis pourquoi ne pas faire un copier collé tout con.

Déjà cette supposition là est fausse. C et C++ partage une ensemble commun important qui couvre en fait une grande partie du C. Mais C n'est pas intégralement inclus dans le C++. De fait, même du code syntaxiquement correct dans les deux langages peut avoir un comportement légèrement différent entre les deux langages.

Maintenant est ce la source de la différence observé ? Difficile à dire à priori, mais cela me semble assez peu probable.

[Mat.M]

Oui Gtk+ dans les deux.

Je viens de faire une série de tests, c'est vraiment étrange.

Pour certains panels d'image j'ai de meilleurs résultats en C, pour d'autres de meilleurs résultats en Cpp.

Cela change tout !! Tu n'avais précisé que tu utilisais Gtk+ !
En général les frameworks utilisent des threads internes une sorte de scheduler.
Si tu prends les sources de MFC donc une bibliothèque semblable à Gtk+ à l'initialisation du framework tu as des threads ou des events qui sont lancés ce qui fait que MFC peut-être parfois plus lent qu'un programme directement fait en win32.
Mais là n'est pas la seule explication ; si tu as un framework comme Gtk+ eh bien...tu as la gestion des exceptions par derrière ce qui risque de nuire aux performances du programme ( un peu comme le Garbage Collector en Java mais il y a déjà 50 pages de fil de discussion à ce sujet )
Alors comment peut s'expliquer une telle différence entre C et C++ ? Eh bien c'est qu'à l'édition des liens, lier Gtk+ peut se faire différemment... selon le langage.
Il ne faut pas perdre de vue que la compilation en C++ demande plus de mémoire que le C..

Je te conseillerais pour de meilleurs performances d'isoler les traitements et calculs de la gestion de l'interface utilisateur.
En d'autres termes si par exemple tu est sous Windows de faire une dll qu'importe que cela soit en C ou C++ pourvu que les classes soient simples pour les calculs et l'interface utilisateur avec Gtk

[Mat.M]

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.

Oui mais l'édition des liens est radicalement différentes entre sources C et sources CPP !
En c++ c'est infiniment plus complexe pour le compilateur cela va de soi qu'en C.
Le compilateur à partir du C++ pour faire des fichiers objets doit obéir à bien plus de règles qu'à partir du C.

Si tu as des différences de performances alors que tu n'as fait que des copier-coller des explications possibles seraient
-en C++ il y a un mécanisme de gestion des exceptions supplémentaires qui se met en route
en C il n'y a rien cela donne un beau "violation access"
-en C++ il y aussi des trucs comme le Run-time Type Information ( RTTI )
On peut le paramêtrer ou non...

Etant donné mes difficultés à comprendre la situation, je pense revenir en C, mais bon c'est tout de même bien dommage ...
En tout cas bonne soirée à tous, et bon courage si vous taffez

Tout dépend si tu veux avoir recours à la programmation objet c'est évident..
si tu sents le besoin d'avoir du code modulable et réutilisable vaut mieux faire du code C++.
Mais encore une fois je conseille vivement de séparer le code pour les calculs et le traitement de l'image pur du reste du projet et notamment de l'interface utilisateur.
Sinon tu devrais avoir recours à des techniques plus avancées comme la programmation multithreading.
Mais pour ce qui est des performances pures je suis sceptique je ne pense pas qu'il y en ait autant entre un code en C et un code en C++ c'est kif kif

[Cheps]

Je veux bien comprendre des grosses différences de performances, par contre des résultats différents c'est étonnant. Utilises-tu un algorithme probabiliste?

[skip78]

Il ne faut pas perdre de vue que la compilation en C++ demande plus de mémoire que le C..

C'est ce que je me disais avant cet incident
Mais là c'est le C++ qui est 4 fois plus rapide que le C


Pour ce qui est de séparer l'interface Graphique du reste, c'est compliqué, voir impossible, car le rôle principal de mon apli (le rôle secondaire étant d'afficher les résultats) est d'aller chercher l'info dans la lib de traitement d'image étudiée et de changer les widgets en conséquence (affichage texte/graphique, gestion des filtres ...)

L'idée est donc bonne, mais je pense pas que ca soit jouable.



Sinon ca me fait plaisir de lire des commentaires tels que "Je suis quand même vraiment sceptique ..."

Vous savez je n'y crois toujours pas à ce truc, c'est juste dingue, mais c'est pourtant vrai.



Bon et puis j'ai tout repassé en C pour voir, c'est définitivement plus stable, mais biiiiiiiiien plus lent

Sick'

P.S. non pas d'algo probabiliste juste des calculs de moyenne, de diférentielles, de dérivées directionelles...

[white_tentacle]

Je pense que tu appelles certaines fonctions sans respecter leur préconditions, et que donc, les comportements "à la marge" sont différents entre C et C++. Voire, tu as assumé que certaines équivalences C/C++ étaient vraies, alors qu'elles ne le sont pas tout à fait (code de retour différents, comportements différents).

C++ quatre fois plus rapide que C, ça veut dire que le code C était mauvais (ie, qu'on peut beaucoup l'optimiser), ou que le code C++ ne fait plus un traitement que le code C faisait.

Tu parles de "tout repasser en C", mais si tu compiles ton code C avec g++, il devrait compiler et tu devrais avoir le même comportement qu'avec gcc.

Je me doute que tu ne peux pas poster les deux codes ici, mais néanmoins, pourrais-tu détailler un peu plus ce que tu entends par "passer de C à C++" (par exemple, remplacer les tableaux par des vector, etc...)

L'informatique, c'est en général déterministe, et quand ça ne l'est pas, c'est souvent un bug.

[befalimpertinent]

J'ai peut être sauté un post mais il me semble que tu n'a pas précisé le compilateur que tu as utilisé pour le C et le C++. Et les options que tu as activé pour l'un puis pour l'autre.

[souviron34]

P.S. J'ai besoin d'aller chercher des variables et manipuler les fonctions des libs à tester, donc je suis obligé de les intégrer convenablement.

ça, c'est uniquement un problème de commnication entre appels, et ça se fait via des API ... (du style jni pour Java). Pas besoin de tout réécrire...

Je te conseillerais pour de meilleurs performances d'isoler les traitements et calculs de la gestion de l'interface utilisateur.

+1000

si tu sents le besoin d'avoir du code modulable et réutilisable vaut mieux faire du code C++.

beeeppp !!!!

Biais éhonté...

Il n'y a aucune raison que ce ne soit pas en C...

Bon et puis j'ai tout repassé en C pour voir, c'est définitivement plus stable, mais biiiiiiiiien plus lent

Définitivement un bug....

C++ quatre fois plus rapide que C, ça veut dire que le code C était mauvais (ie, qu'on peut beaucoup l'optimiser), ou que le code C++ ne fait plus un traitement que le code C faisait.
...
L'informatique, c'est en général déterministe, et quand ça ne l'est pas, c'est souvent un bug.