Discussion :

[hsazerty]

salut à tous !

- Lorsque je compile un code en C (c++builder 5), et un code équivalent en pascal, la taille de l'exécutable écrit en C et SUPERIEURE à celle de l'exécutable écrit en pascal ? Alors pourquoi dit-on souvent que le C est plus rapide que le pascal ?

- Est-ce que la vitesse d'exécution d'un programme est liée à la taille de son exécutable ?

Merci !!

[henderson]

Salut !

Oui, mais pas dans le sens où un programme plus petit serait plus rapide qu'un programme plus grand !

On le démontre assez facilement en comparant le temps pris par un traitement dans une boucle (n * 1) et le temps pris par une succession de n traitements !

A plus !

[Crayon]

Plus un langage est de haut niveau, plus il sera lent. Et normalement si prend on un langage comme l'Assembleur (le plus bas niveau possible) il va falloir beaucoup plus de ligne de code pour faire exactement la même chose qu'en C ou C++. Pourtant l'assembleur est plus rapide. Tout dépand aussi du genre de code et l'optimisation du compilateur

[Interruption13h]

Salut !

A mon avis, la taille de l'exécutable peut affecter la vitesse de l'exécution, puisque par exemple si ce fichier contient des images de grandes taille dans ces ressource, et doivent être chargées...etc. alors que le même programme qui contiendrai moins de ressources, sera sûrement fonctionnel de façon plus rapide.

D'autre part, c'est sûr que le compilateur choisi a un impact direct sur l'exécutable, et chaque compilateur a sa propre grammaire, génération et l'optimisation du code binaire.

Reste le travail du programmeur, puisque lui aussi jouera un rôle très important pour l'optimisation de son code, puisque le compilateur n'est pas intelligent, et malgré ça fait de son mieux selon des règles pour optimiser le tout !
je prend un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
x=x*2;
x=x*4;

Le compilateur va générer normalement un code assembleur (ici avec les mnémoniques) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
mul [Emplacement_X],2
mul [Emplacement_X],4

Une optimisation sera peut être fait en se basant sur :
- Une multiplication et beaucoup plus lent qu'une addition
- Une addition est plus lente qu'un décalage


on aura ainsi un truc comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
Shl [Emplacement_X],1  //SHL veut dire décalage à gauche; 2 décalage de 2 bits
shl [Emplacement_X],2

mais je crois pas du tout que le code sera réduit par le compilateur en :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
shl [Emplacement_X], 3

Et y a une très grande différence entre C++ Builder et le C++ tout court, puisque il faut voir aussi si la VCL par exemple à bien été optimisé pour ce qui concerne le temps et mémoire








J’espère vous avoir apporté une aide sur quelque chose



A+

[rtg57]

Et n'oubliez pas l'importance de la mémoire cache.

Si la partie la plus utilisée de votre programme est suffisamment petite pour pouvoir entrer dans la mémoire cache de votre processeur, la vitesse explose. Quoique de nos jours avec des mémoire cache de 2 Moctets, en s'en fout un peu. Mais à l'époque du pentium 1, avec 8 kOctets de cache programme, et 8 kOctets de cache de données, il fallait jouer serré.

Il vaut mieux faire un petit programme avec des tests et des branchements conditionnels, qu'un long programme linéaire. Une fois les tables de prédictions de branchement bien réglées, les échecs de branchements diminuent et la vitesse augmente car les boucles s'effectuent depuis la mémoire cache.

C'est tout un art...