Discussion :

[Invit�]

Bonjour,

Je r�cris actuellement un gros programme, en modifiant du code existant. J'utilise le m�me environnement et le m�me compilateur, mais je constate un accroissement rapide de la taille de mon exe. En gros, un programme qui faisait hier 3 Mo en fait aujourd'hui 9, alors que le nombre total de ligne de codes n'a pas chang� (il a en fait baiss�).

Actuellement, je soupconne fortement la STL. J'utilise pas mal de vector<> sur des types utilisateurs. Comme toute la STL est template, cela signifie beaucoup d'instanciation, mais quand m�me un triplement du code � fonctionnalit�s �gales?

Avez vous rencontr� ce genre de probl�me? la STL est elle r�ellement coupable? Comment peut on le r�soudre (je n'ai pas du tout envie de finir avec un exe de 20Mo, 5 c'est d�j� bien trop...)

Merci d'avance,
Francois

[JolyLoic]

Y a-t-il beaucoup de vecteurs sur des types vraiment diff�rents(1) ? En th�orie, �a pourrait expliquer, m�me si j'avoue avoir du mal � croire que �a pourrait �tre aussi impactant... Tu as essay� d'ajouter pour le plaisir un bout de code qui ne fait rien d'autre que d'instancier un vector sur une dizaine de types cr�es pour la circonstance, histoire de mesurer un delta ?

Un gros accroissement peut appara�tre la premi�re fois que l'on utilise les flux dans un programme, mais ce devrait �tre one shot.

Tu utilises quel compilateur ? Quelles options d'optimisation ?

(1) : Par vraiment diff�rent, je veux dire qu'une bonne impl�mentation n'aura pas de code bloat suppl�mentaire pour un vector<B*> si le programme contient d�j� un vector<A*>, et on peut esp�rer que dans le futur, ce soit aussi vrai avec les vector<shared_ptr<A>> et vector<unique_ptr<A>>.

[Invit�]

Y a-t-il beaucoup de vecteurs sur des types vraiment diff�rents(1) ?

Tout � fait... Il doit y avoir une petite centaine de structures distinctes, au total, et des vecteur sur presque chacune. Avec des structures arborescentes de vecteurs de vecteurs...

En th�orie, �a pourrait expliquer, m�me si j'avoue avoir du mal � croire que �a pourrait �tre aussi impactant... Tu as essay� d'ajouter pour le plaisir un bout de code qui ne fait rien d'autre que d'instancier un vector sur une dizaine de types cr�es pour la circonstance, histoire de mesurer un delta ?

Je vais effectivement essayer, et poster mes trouvailles sur ce fil, je pense que c'est utile... Pour l'instant, j'ai fait un essai sur un tout petit module (150 lignes de code). Le code �tait du calcul tr�s proche du C, mais � la fin, pour je ne sais quelle raison, j'avais mis un fill_n (donc un algorithme de la stl)... un seul...

Avec fill_n : code g�n�r� ds l'obj: 7k
Sans fill_n : code g�n�r� 2k

(cependant, enlever un fill_n par ci par la dans les autres modules repr�sente un petit gain, mais pas aussi spectaculaire, ce serait trop facile!)

Morale provisoire, il y a clairement un co�t d'entr�e de la STL au niveau du module. Je soupconne que l'un des effets indirects des templates est que le compilateur reinstancie tout ce dont il a besoin pour chaque module, et ca peut �tre un peu lourd...

Un gros accroissement peut appara�tre la premi�re fois que l'on utilise les flux dans un programme, mais ce devrait �tre one shot.

Des flux j'en avais avant, donc ca ne peut �tre cela.

Tu utilises quel compilateur ? Quelles options d'optimisation ?

Borland C++ Builder 6.0, options vitesse maxi (mais j'ai aussi teste l'option "debug", sans diff�rence notable), et une STLPort fournie avec le compilateur (donc optimis�, pourrait on croire)

Francois

[koala01]

Salut,

Fais attention au fait que BCB 6 revendiquait ne pas respecter le standard (et pas uniquement pour la VCL)...

Il n'est donc absolument pas impossible que la version STL port ne soit pas aussi bien optimis� que ce que tu ne semble croire

Il *semblerait* que les nouvelles versions de BCB tentent de mieux respecter la norme (mais je ne peux absolument pas donner de certitudes sur le sujet)

Ceci dit, il serait int�ressant de v�rifier sur plusieurs modules (inter) d�pendants du premier module sur lequel tu as test� les changements...

*Peut-�tre* auras tu la chance que seul le module test� ne pr�sente un tel accroissement de poids

Enfin, es-tu sur d'avoir utilis� les m�mes options de compilation

G�n�ralement, on observe effectivement un accroissement (parfois consid�rable) du poids de l'ex�cutable en mode d�bug, du fait de la pr�sence de toutes les informations n�cessaires au d�buggage, par rapport � la version release...

Mais certaines options de compilations ou certaines habitudes de programmation (comme l'inlining implicite ou explicite de fonction qui ne devraient pas l'�tre) peuvent �galement avoir un impact fort malsain sur le poids de l'ex�cutable ([EDIT]et force est d'avouer que l'utilisation de template de facto l'inlining des fonctions template [/EDIT])

[Invit�]

Fais attention au fait que BCB 6 revendiquait ne pas respecter le standard (et pas uniquement pour la VCL)...

Est ce un probl�me de standard? Il me semble que celui ci ne parle pas beaucoup de la taille des executables, laiss� au compilateur... Ce qui me travaille, c'est que BCB, que j'utilise depuis longtemps, produit en g�n�ral des exes pas trop gros, sauf dans certains cas pr�cis (appels OLE typiquement).

Ceci dit, il serait int�ressant de v�rifier sur plusieurs modules (inter) d�pendants du premier module sur lequel tu as test� les changements...

En fait, c'est apr�s avoir modifi� pas mal de choses que j'ai constat� ce triplement de taille. On avait un code de 3-4Mo environ (pour environ 35 000 lignes de code utilisateur, ie sans les librairies externes), r�partis dans 75 modules environ. Pour l'instant seuls les principaux modules ont �t� touch�s par la r�organisation, mais le code approche les 9Mo.

Je vais essayer de rajouter des modifs similaires � celles faites r�cemment, et voir l'augmentation...

Enfin, es-tu sur d'avoir utilis� les m�mes options de compilation

Oui, en fait, j'ai fait les calculs de comparaison en mode debug et en mode release, sur l'ancien et le nouveau source... Il peut bien sur y avoir une subtilit� qui m'�chappe, mais j'en doute un peu... (j'observe en fait la hausse lors de modification successives de mon code, sans changement des options)

G�n�ralement, on observe effectivement un accroissement (parfois consid�rable) du poids de l'ex�cutable en mode d�bug, du fait de la pr�sence de toutes les informations n�cessaires au d�buggage, par rapport � la version release...

Oui, mais chez borland, j'ai rep�r� que l'augmentation se traduisait au niveau des .obj (modules compil�s avant reliure), mais que le relieur avait le bon gout de supprimer ces �l�ments de l'exe pour les mettre dans un fichiers "annexe" (le tds) utilis� par le debuguer. Du coup, l'exe en mode d�bug n'est pas vraiment plus gros, voire l�g�rement plus petit que celui en mode release.

Je comprends que Microsoft suit une voie tr�s diff�rente.

Mais certaines options de compilations ou certaines habitudes de programmation (comme l'inlining implicite ou explicite de fonction qui ne devraient pas l'�tre) peuvent �galement avoir un impact fort malsain sur le poids de l'ex�cutable

C'est mon hypoth�se de travail. Je vais continuer � regarder, et essayer de raconter cela sur ce fil. Je soupconne que la situation est assez g�n�rique pour n'�tre pas qu'un pb borland...

En attendant, merci beaucoup pour ces r�ponses, �a m'aide pas mal.

Francois

[JolyLoic]

Oui, mais chez borland, j'ai rep�r� que l'augmentation se traduisait au niveau des .obj (modules compil�s avant reliure), mais que le relieur avait le bon gout de supprimer ces �l�ments de l'exe pour les mettre dans un fichiers "annexe" (le tds) utilis� par le debuguer. Du coup, l'exe en mode d�bug n'est pas vraiment plus gros, voire l�g�rement plus petit que celui en mode release.

Ce ne sont pas tant les informations de debug que le fait que l'inlining ne soit pas possible qui modifie le plus la taille des ex�cutable debug, surtout avec un style de programmation o� plein d'appels de fonctions s'imbriquent comme le template metaprogramming pousse � le faire. J'ai d�j� eu des explosions de stack en debug, alors qu'en release, j'en �tait tr�s loin, avec boost.serialization, par exemple.

[Silverstone]

Peut-�tre as-tu un l�ger probl�me de conception dans ton programme...

Moi j'utilise Visual c++ et j'ai toujours eu l'impression que les ex�cutables �taient particuli�rement optimis�s en taille (m�me avec l'option "vitesse maximale").

[Silverstone]

Visual c++ est de loin le meilleur compilateur pour Windows (d'apr�s ce que j'ai pu constater).

Cela sens le mauvais compilo -- maintenant BCB est un ancien ...

Je pense qu'il a fait son temps, qu'il repose en paix � pr�sent...

[Invit�]

D'apr�s tous les benchmarks que j'ai pu lire, le meilleur compilateur pour Windows, en termes de vitesse du code produit, c'est celui d'Intel (qui utilise, il est vrai, Visual comme front end).

Pour le reste, la notion de "meilleur" est tr�s subjective. En ce qui me concerne, il sera nettement plus facile de l�cher la STL (que j'utilise plus souvent pour "faire moderne" que parce que j'en ai r�ellement besoin) que BCB (autour duquel s'organise mon interface...) Et BCB6, tout vieillot qu'il soit reste "mon meilleur" compilateur, parce que c'est celui sous lequel je d�veloppe le plus efficacement (NB j'ai �galement Visual et GCC, et je les utilise de temps en temps)

Francois

[Invit�]

Je me rends compte que je n'ai pas remerci� les testeurs b�n�voles... Merci beaucoup � vous. A charge de revanche !

Francois

[Arzar]

Oui mais je suppose qu'il ne marche que pour les processeurs Intel, ce qui rend la chose plus facile .

?
Le code compil� par ICC tourne sur n'importe quel processeur x86. �a serait un peu b�te d'obtenir des programmes qui se limiteraient � la moiti� des pc du march�, non ? Par contre, bien sur, ICC produit du code particuli�rement optimis� pour les processeurs intels.

D'apr�s tous les benchmarks que j'ai pu lire, le meilleur compilateur pour Windows, en termes de vitesse du code produit, c'est celui d'Intel (qui utilise, il est vrai, Visual comme front end).

Je viens justement de tester la d�mo de la derni�re version d'ICC 11.1.
Il est en effet tout aussi bon.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
 
C:\Documents and Settings\Thomas Petit\My Documents\Visual Studio 2008\Projects\Benchmark\Release\Benchmark.exe
 
test                            description   absolute   operations   ratio with
number                                        time       per second   test0
 
 0                 "double pointer verify2"   0.95 sec   3147.95 M     1.00
 1                 "double vector iterator"   0.95 sec   3147.95 M     1.00
 2                 "double pointer reverse"   1.55 sec   1939.24 M     1.62
 3         "double vector reverse_iterator"   1.58 sec   1901.14 M     1.66
 4         "double vector iterator reverse"   1.63 sec   1846.15 M     1.71
 5         "double pointer reverse reverse"   0.95 sec   3147.95 M     1.00
 6 "double vector reverse_iterator reverse"   0.95 sec   3147.95 M     1.00
 7 "double vector iterator reverse reverse"   0.97 sec   3095.98 M     1.02
 
Total absolute time for Vector accumulate: 9.53 sec
 
Vector accumulate Penalty: 1.25
 
 
test                                           description   absolute   operations   ratio with
number                                                       time       per second   test0
 
 0                 "insertion_sort double pointer verify2"   1.51 sec    1.98 M     1.00
 1                 "insertion_sort double vector iterator"   1.33 sec    2.26 M     0.88
 2                 "insertion_sort double pointer reverse"   1.91 sec    1.57 M     1.26
 3         "insertion_sort double vector reverse_iterator"   1.30 sec    2.31 M     0.86
 4         "insertion_sort double vector iterator reverse"   1.30 sec    2.31 M     0.86
 5         "insertion_sort double pointer reverse reverse"   1.31 sec    2.29 M     0.87
 6 "insertion_sort double vector reverse_iterator reverse"   1.30 sec    2.31 M     0.86
 7 "insertion_sort double vector iterator reverse reverse"   1.31 sec    2.29 M     0.87
 
Total absolute time for Vector Insertion Sort: 11.27 sec
 
Vector Insertion Sort Penalty: 0.91
 
 
test                                      description   absolute   operations   ratio with
number                                                  time       per second   test0
 
 0                 "quicksort double pointer verify2"   1.95 sec   12.28 M     1.00
 1                 "quicksort double vector iterator"   2.16 sec   11.13 M     1.10
 2                 "quicksort double pointer reverse"   2.20 sec   10.89 M     1.13
 3         "quicksort double vector reverse_iterator"   2.13 sec   11.29 M     1.09
 4         "quicksort double vector iterator reverse"   2.13 sec   11.29 M     1.09
 5         "quicksort double pointer reverse reverse"   2.09 sec   11.46 M     1.07
 6 "quicksort double vector reverse_iterator reverse"   2.16 sec   11.13 M     1.10
 7 "quicksort double vector iterator reverse reverse"   2.14 sec   11.21 M     1.10
 
Total absolute time for Vector Quicksort: 16.95 sec
 
Vector Quicksort Penalty: 1.10
 
 
test                                      description   absolute   operations   ratio with
number                                                  time       per second   test0
 
 0                 "heap_sort double pointer verify2"   1.97 sec   12.20 M     1.00
 1                 "heap_sort double vector iterator"   2.20 sec   10.89 M     1.12
 2                 "heap_sort double pointer reverse"   2.23 sec   10.74 M     1.14
 3         "heap_sort double vector reverse_iterator"   2.00 sec   12.00 M     1.02
 4         "heap_sort double vector iterator reverse"   2.00 sec   12.00 M     1.02
 5         "heap_sort double pointer reverse reverse"   2.25 sec   10.67 M     1.14
 6 "heap_sort double vector reverse_iterator reverse"   2.28 sec   10.52 M     1.16
 7 "heap_sort double vector iterator reverse reverse"   2.30 sec   10.45 M     1.17
 
Total absolute time for Vector Heap Sort: 17.23 sec
 
Vector Heap Sort Penalty: 1.11

Il est quand m�me un peu moins "stable" que MSVC sur la p�nalit� d'abstraction. Alors que MSVC aligne les 1.0 imperturbablement, ICC d�rape de temps en temps.

Deux petites particularit�s int�ressantes :
1) Il �clate compl�tement MSVC 10 sur le premier test "Vector accumulate". Sur mon pc, on passe de 30 secondes � 10 secondes et de 796.60 M � 3147.95 M d'op�rations par secondes ! Le timing des autres tests est par contre � peu pr�s identique... Bizarre...

2) Pour le deuxi�me test, ICC donne des "p�nalit�s" d'abstraction de 1.00, 0.88, 1.26, 0.86, 0.86, 0.87, 0.86, 0.87 pour un total de .... 0.91 !
C'est un myst�re complet pour moi. Je ne comprends pas du tout comment un compilateur peut faire une meilleure optimisation avec un it�rateur qu'avec un pointeur, m�me dans les cas les plus tordus, car sous Visual Studio ICC utilise la STL de microsoft, qui d�finit un it�rateur de vecteur peu ou prou comme ceci :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
 
template <typename T>
class Vector_Iterator
{
public:
// plein de fonction.... operator *, operator ++, operator --,  etc
 
private:
   T* _Ptr;
}

[Invit�]

?
1) Il �clate compl�tement MSVC 10 sur le premier test "Vector accumulate". Sur mon pc, on passe de 30 secondes � 10 secondes et de 796.60 M � 3147.95 M d'op�rations par secondes ! Le timing des autres tests est par contre � peu pr�s identique... Bizarre...

Accumulate est une fonction assez particuli�re, dans le sens o� (� la difference des autres tests, fond�s sur des tris) elle parcourt le tableau de proche en proche, et l'ordre de parcours est connu � l'avance. Donc, ni saut ni indirection. Je soup�onne que c'est typiquement ce qu'un compilateur "d�di�" comme ICC sait parfaitement exploiter. Je suis juste un peu surpris que cela ne se retrouve pas dans quicksort, parce que la boucle internet de quicksort (recherche de pivot) ca repose exactement sur le m�me principe. Sans doute � cause des tests...

2) Pour le deuxi�me test, ICC donne des "p�nalit�s" d'abstraction de 1.00, 0.88, 1.26, 0.86, 0.86, 0.87, 0.86, 0.87 pour un total de .... 0.91 !
C'est un myst�re complet pour moi. Je ne comprends pas du tout comment un compilateur peut faire une meilleure optimisation avec un it�rateur qu'avec un pointeur, m�me dans les cas les plus tordus,

Ma th�orie personnelle, l� dessus, c'est que dans le cas o� il travaille sur des it�rateurs, ICC n'effectue pas les optimisations de code dans le m�me sens que pour des types natifs. En gros, sur des types natifs, il va privil�gier des optimisations "bas niveau" alors que pour des types utilisateur il commence par simplifier le code "haut niveau".

Pour insert sort, dont la boucle de plus haut niveau est assez simple, je pense qu'il arrive � appliquer (pour les it�rateurs) la m�me ruse que celle qui fait des merveilles avec accumulate. En revanche, quand il a des pointeurs, il commence par une optimisation malencontreuse de bas niveau...

Ceci dit, hors STL, la diff�rence de vitesse entre Visual et ICC est assez document�e. Au fil des ann�es Visual se rapproche, mais ICC a encore pas mal d'avance.

Francois

[Silverstone]

D'apr�s tous les benchmarks que j'ai pu lire, le meilleur compilateur pour Windows, en termes de vitesse du code produit, c'est celui d'Intel (qui utilise, il est vrai, Visual comme front end).

Oui mais je suppose qu'il ne marche que pour les processeurs Intel, ce qui rend la chose plus facile .

[Goten]

Oui mais je suppose qu'il ne marche que pour les processeurs Intel, ce qui rend la chose plus facile .

Non non.. le code produit marche aussi sur amd. Apr�s pour autre chose que le x86 je sais pas du tout.

[Silverstone]

Par contre, bien sur, ICC produit du code particuli�rement optimis� pour les processeurs intels.

Oui donc �a n'est valable que pour les processeurs Intel . En tout cas en ce qui concerne les optimisations (ce qui rend la chose plus facile)...

Alors que MSVC aligne les 1.0 imperturbablement, ICC d�rape de temps en temps.

Il �tait sur une patinoire ? Ca pourrait expliquer .