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 .