Bonjour,

Je suis à la recherche d'un compilateur, en fait, je ne recherche pas n'importequel compilateur, mais celui qui fourni un code binaire optimal. En terme de temps d'execution.

Dans le cadre d'un projet de cours, nous devons utiliser JNI et des codes C... Le but du projet est l'optimisation, et nous serons noté sur le temps d'execution de ce programme.

Ainsi, si certains d'entre vous ont testé plusieurs compilateur, j'aimerais connaitre celui qui produit le code binaire le plus rapide à executer (optimisation).

A ce que j'ai lu le compilateur de visual C++ toolkit est le meilleur. Néanmoins, je suis dans l'impossibilité de le tester dans la semaine...

Merci.

En fait,ils doivent être à peu près égaux. (Léger avantage de Visual)
Ce qui compte,c'est la manière de programmer et les algorithmes.
Si tu veux pousser à fond la vitesse,il faut faire de l'asssembleur (5 fois plus rapide mais c'était sur un compilateur très vieux et c'était du Pascal).

Salut,

Tout dépend de l'OS à mon avis.
Sous Linux, je dirait sans hésiter GCC.
Sous Windows, je ne sais pas quel compilateur offre de "meilleur performance", entre mingw32 et le compilo de visual.
J'imagine que Microsoft sont les mieux placés pour développer un compilateur pour leur propre OS, mais n'ayant jamais testé visual, et utilisant peu mingw32, je n'ai aucun argument.

Voilà de mon point de vue. (assé petit)

Salut,

comme l'a dit un membre avant, cela dépend surtout de la qualité de ton code !

Merci pour vos réponses.

Je suis actuellement en train de dl Visual C++ express, hier j'ai dl lcc ainsi que devc++. Mais je ne les ai pas testé.

De toute façon, je testerais les 3 compilateurs pour la partie à optimiser (je vais mettre en C 4 fonctions dont une recursive et mettre en inline les 3 autres qui sont appelées à chaque appel de la fonction récursive).

Citation : Pole

En fait,ils doivent être à peu près égaux. (Léger avantage de Visual)

Oui, ils sont surement être à peu près égaux, mais s'il existe différent compilateur c'est surement parcequ'ils ont des différences, sinon on en utiliserait qu'un seul. De plus, si microsoft sort un compilateur, on peut supposer qu'ils connaissent mieux leur OS que les autres editeurs... (néanmoins, si des solutions alternatives existent c'est qu'il y a une raison).

J'ai lu que visual c++ 7.1 (en 2002) respectait la norme ISO C++ à 98%, et visual C++ express est sorti en 2005 (donc...).

Ben c'est très relatif : ça dépend de l'OS, de l'architecture, du processeur lui-même (vitesse du bus, instructions spéciales,...), du niveau d'optimisation utilisé(d'ailleurs ça détermine aussi la lenteur ),...

Par exemple, le compilateur d'Intel utilisera tous les trucs spécifiques pour accélérer le programme sur les Pentium. mais il risque d'être légèrement plus lent sur les AMD. Et puis... on va pas s'énerver pour 5 microchiures de secondes sur un calcul qui prend 3 jours... C'est beaucoup plus intéressant de chercher à utiliser de meilleurs algorithme et ça te sera beaoucp plus utile.

Citation : Borny

Le but du projet est l'optimisation, et nous serons noté sur le temps d'execution de ce programme.

Dans ce cas, prends n'importe quel compilateur, mais optimise tes algorithmes. S'ils ne le sont pas, aucun compilateur ne le fera à ta place. Si l'optimisation a autant d'importance, tu peux aussi optimiser le code assembleur obtenu avant d'en faire un exécutable.

Dans tous les cas, le compilateur n'y est pas pour grand chose...

Citation : remram44

tu peux aussi optimiser le code assembleur obtenu avant d'en faire un exécutable.

Ah ? oO
Je savais pas, quelle est la pratique ?

Citation : Yno

Citation : remram44

tu peux aussi optimiser le code assembleur obtenu avant d'en faire un exécutable.

Ah ? oO
Je savais pas, quelle est la pratique ?

Citation : Borny

Citation : Pole

En fait,ils doivent être à peu près égaux. (Léger avantage de Visual)

Oui, ils sont surement être à peu près égaux, mais s'il existe différent compilateur c'est surement parcequ'ils ont des différences, sinon on en utiliserait qu'un seul.

Super argument. Tu l'as lu sur un emballage de Caram'bar ?

Il y a plusieurs compilateurs parce que l'empire Soviétique a échoué dans sa tentative d'imposer une économie dirigée au monde entier (même les Chinois les plus communistes savent ça) et que c'est la loi du marché régulé (plus ou moins) qui a gagné.

Il y a donc de la place pour les projets privés avec les grands(Intel, Microsoft, Borland, Sun, IBM, Mentor Graphics etc.), les petits (lcc, Digital Mars, Comeau etc.), les libres (GNU OSF etc.) et pour les projets universitaires, personnels etc. Bref, il y a le choix, et c'est une Bonne Chose. L'économie monopolistique, c'est le Diable !

Citation : Pas de titre

De plus, si microsoft sort un compilateur, on peut supposer qu'ils connaissent mieux leur OS que les autres editeurs... (néanmoins, si des solutions alternatives existent c'est qu'il y a une raison).

Certes, y compris les fonctions non documentées qui font que les autres sont par nature à la traine. Mais ça ne concerne pas le code généré.

Si tu veux de la performance au niveau binaire, voit plutôt les compilateurs Intels. Redoutables !

Citation : Pas de titre

J'ai lu que visual c++ 7.1 (en 2002) respectait la norme ISO C++ à 98%, et visual C++ express est sorti en 2005 (donc...).

Arf ! ISO-C, oui, mais ... 1990 ! Pour ce qui est de ISO-C 1999 (C99), c'est 0%. (gcc 4.x, c'est environ 85%).

Les compilateurs gcc sont surtout réputés pour leur grande portabilité. En effet, ils existent pour quasiment toutes les plateformes connues ou à venir, vu que le projet est bien découpé et que le back-end (le générateur de code binaire) est bien séparé du front-end (analyse du code commun à toutes les versions). On dit qu'il faut moin d'un mois à un spécialiste de l'assembleur concerné pour écrire un portage pour un nouveau processeur.

Mais ça ne suffit pas. Il faut un environnement cohérent ou faire de la compilation croisée.

En terme de performance, ca dépend de la cible. Sans être foudroyants, ils sont généralement corrects, et permettent d'écrire des applications opérationnelles. De plus, ils disposent de plusieurs niveaux d'optimisation dont certains ont été fortement améliorés ces dernières années, notamment grâce à la prise en compte des processeurs modernes mettant en oeuvre les caches et les pipelines.

Citation : ddx39

>gcc -S source.c -o source.asm

Ca fait marteau pour écraser une mouche ça
Il est possible d'intégrer de l'assembleur dans du C, mais il me semble que c'est dépendant du compilateur et que la syntaxe n'est pas imposée par la norme.
Pour gcc ça peut donner :

Mais la syntaxe de l'assembleur inline de gcc est loin d'être évidente.

De plus, c'est rarement utile, le compilateur fera de toute façon du meilleur assembleur que vous(sauf dans certains cas très rares), donc bon

Citation : asmanur

Citation : ddx39

>gcc -S source.c -o source.asm

Ca fait marteau pour écraser une mouche ça
Il est possible d'intégrer de l'assembleur dans du C, mais il me semble que c'est dépendant du compilateur et que la syntaxe n'est pas imposée par la norme.
Pour gcc ça peut donner :

asm("movl %eax, %ebx");
asm("pushl %%eax" :: "a"(variable));
/* etc ...*/

Mais la syntaxe de l'assembleur inline de gcc est loin d'être évidente.

De plus, c'est rarement utile, le compilateur fera de toute façon du meilleur assembleur que vous(sauf dans certains cas très rares), donc bon

He bien, merci à vous deux

Pour moi, le meilleur compilateur reste et restera sans aucun doute -> GCC !

Je confirme, si tu es sur un processeur Intel et que tu as le choix du compilateur, utilise celui d'Intel . Mais la complexité de tes algorithmes, c'est ça le plus important.