Meilleure vitesse d'exécution : Fortran vs C++ ?

Version imprimable

05/03/2009, 14h29
Kaluza

Meilleure vitesse d'exécution : Fortran vs C++ ?

:salut: Tout d'abord bonjour tout le monde, je suis nouveau venu ici.

Je débute en programmation (C/C++ que je suis en train de voir en école d'ingé) et j'ai un projet en tête et je voudrai quelques conseils. Mon but est de créer un simulateur de gravité à N corps en temps NlogN (algorithme de Barnes-Hut) par une méthode de Runge-Kutta d'ordre 4.

Mon but est que l'algorithme soit le plus rapide possible. J'ai commencé à regarder les langages des applis scientifiques et beaucoup reposent sur du Fortran. Quels sont ses avantages vis à vis du C++. Pour mon projet, le Fortran donnera-t-il un programme plus rapide à l'éxécution ? Pour mon projet (programme surtout pour Windows, si c'est multiplateforme c'est mieux), quel serait le langage le plus "rapide" ?

Et d'ailleurs comme je suis débutant, quels sont les facteurs déterminants pour la vitesse d'exécution ? Le langage (Fortran vs C++) ? Le compilateur ?

Enfin, je ne suis pas sur de bien comprendre le contenu de ce site : http://www.polyhedron.com/pb05-win32-f90bench_p40html
Le même code compilé avec le compilateur d'Intel et ftn95 prend 3 fois plus de temps à l'exécution s'il a été compilé avec ftn95 ?

Merci beaucoup ;)
06/03/2009, 16h14
Mat.M

Citation:

Envoyé par Kaluza

Pour mon projet (programme surtout pour Windows, si c'est multiplateforme c'est mieux), quel serait le langage le plus "rapide" ?

Et d'ailleurs comme je suis débutant, quels sont les facteurs déterminants pour la vitesse d'exécution ? Le langage (Fortran vs C++) ? Le compilateur ?

Pour la rapidité de projet tout dépend quel type de projet c'est s'il est avec une interface utilisateur
Un programme en mode console programmé en Java sera aussi sinon plus rapide qu'un programme en C++ nativement.
Mais pour peu que tu fasses un projet avec une fenêtre utilisateur et des boutons le C++ risque d'être plus rapide.
Sauf si tu lances des threads spécifiques de calcul en tache de fond.
La différence entre Fortran et C++ c'est que les bibliothéques de code pour le calcul doivent être particulièrement optimisées et plus performantes qu'en C++
Par contre peut-être que C++ sera plus performant en calcul parallèle je précise que c'est une éventualité.
Tout dépend ce que l'on veut faire ; il est clair qu'un compilateur C++ ( genre VC++ 2008 ) + biblios d'Intel sera très performant notamment pour le calcul parallèle le multithreading...parce qu'évidemment les biblios d'Intel "colleront" plus au mode de fonctionnement du CPU.
En d'autres termes comme les CPU sont majoritairement fabriqués par Intel , c'est plus logique d'utiliser ce qui est fait maison
tu pourras utiliser de manière optimales les cpu à double , 4 coeurs etc...

Une astuce qu'il ne faut pas perdre de vue : tu peux compiler des fichiers objets en Fortran qui sont particulièrement optimisés et faire une édition de liens avec des fichiers .obj initialement en C++.
C'est une technique particulièrement intéressante du C++ et toc c'est un argument de plus dans le débat Java vs C++ :mouarf:

Citation:

Envoyé par Kaluza

Le même code compilé avec le compilateur d'Intel et ftn95 prend 3 fois plus de temps à l'exécution s'il a été compilé avec ftn95 ?
Merci beaucoup ;)

Eh oui y'a pas photo les compilateurs d'Intel semblent être performants peut-être que le Fortran c'est dépassé comme langage parce que il ne prend pas en compte les innovations technologiques récentes comme les architectures parallèles , les CPU à n coeurs etc...
Fortran c'est un langage qui a quelques années comme le C++ seulement il n'a pas évolué parce que trop limité aux calculs scientifiques ; contrairement à C+
06/03/2009, 17h25
souviron34

Citation:

Envoyé par Mat.M

Eh oui y'a pas photo les compilateurs d'Intel semblent être performants peut-être que le Fortran c'est dépassé comme langage parce que il ne prend pas en compte les innovations technologiques récentes comme les architectures parallèles , les CPU à n coeurs etc...
Fortran c'est un langage qui a quelques années comme le C++ seulement il n'a pas évolué parce que trop limité aux calculs scientifiques ; contrairement à C+

Non, c'est parce que Fortran et ses compilateurs/utilisateurs n'ont en général jamais été sur des PCs,mais des minis, gros, voire super calculateurs..

Le portage de Fortran sur PC est assez récent (voir ftn95), et je ne sais pas du tout quelle est l'optimisation incluse.

De plus, par rapport à ce que tu disais, les CPU à n coeurs et les machines parallèles sont intégrés depuis longtemps avec la bibliothèque MPI.

Enfin tes exemples sont faux..

Tout langage multi-purpose (IHM et code) sera par définition plus lent qu'un langage mono-purpose.

Et Fortran, comme C, ne sera pas abandonné de sitôt, simplement parce que d'une part son but est spécifiquement le calcul scientifique, et d'autre part parce que la quantité de bibliothèques disponibles, débuggées, testées, et exhaustives est tout simplement sans pareil.

Après encore une fois cela dépend des compilateurs.

Après, il est possible que sur Intel personne n'ai vraiment fait l'effort de faire un compilateur Fortran performant... MAis en général tout le monde s'en fiche, car c'est rarement sous W$ que les applis scentifiques tournent...
07/03/2009, 07h10
Kaluza

Fortran vs C++

Merci bcp de vos remarques.

En fait, après y avoir réfléchi un peu, je penchais pour un "solver" (mode console) codé en fortran et un "gui" en C++. Si jamais je code en fortran de toutes façons ce sera avec le compilateur et biblio d'Intel : http://www.intel.com/cd/software/pro...ers/278834.htm avec la MKL (Math Kernel Library).

Mon programme sera évidemment fait pour être divisé en plusieurs threads pour tirer parti des processeurs multicores et éventuellement faire un solver "réseau local". Selon ce que vous me dites, le C++ serait donc plus rapide que le Fortran.

Le problème c'est que pour moi le codage ne sera pas le même car je le rappelle, je débute seulement donc si je code en C++, le code risque de ne pas être optimisé au maximum tandis qu'en fortran, comme vous le dites, je m'appuierai sur des biblio éprouvées et très optimisées.

Alors selon vous : [programme complet en C++] ou [solver fortran + gui C++] ?

Merci beaucoup. ;)

EDIT : ah je n'avais pas vu mais la MKL Intel est aussi dispo en C++, ce qui change un peu ma réflexion
08/03/2009, 01h58
Garulfo

Citation:

Envoyé par Mat.M

[...]
Fortran c'est un langage qui a quelques années comme le C++ seulement il n'a pas évolué parce que trop limité aux calculs scientifiques ; contrairement à C+

Je pense que tu t'égares. Les compilateurs FORTRAN sont encore sous le scalpel des développeurs. C'est quand même le langage le plus utilisé dans le domaine des calculs scientifiques. Et c'est justement pour ça qu'il y en a beaucoup qui continue à voir le jour. C'est pourquoi aussi les multi-coeurs et le parallélisme y est intégré depuis longtemps comme le souligne Souviron : dans le domaine du calcul scientifique, on a réellement besoin de puissance de calcul, bien plus que dans n'importe quel autre domaine. C'est les physiciens, les géomaticiens, les chimistes qui demandent de la puissance de calcul. D'ailleurs je me demande, mais n'en suis pas certain, si ce n'est pas FORTRAN qui a bénéficié en premier de toutes les améliorations qu'on a maintenant dans la majorité des compilateurs pour ce qui concerne ce genre d'optimisation (liée au parallélisme par exemple).

Pour répondre un peu plus à la question initiale, la force du FORTRAN c'est avant tout ses bibliothèques. Elles ont été validés par l'expérience ! Tant d'années d'utilisation ont aidé à obtenir du code qu'on estime « très probablement » valide.
08/03/2009, 02h00
Garulfo

Citation:

Envoyé par Kaluza

[...]je débute seulement donc si je code en C++[...]

Si tu ne fais que débuter (moins de quelques années d'expérience) en C++ et que tu sais bien faire du FORTRAN, la question ne se pose même pas : FORTRAN est ton grand gagnant.
08/03/2009, 10h08
Kaluza

Petite précision : en fait je suis débutant en programmation tout court. Par débutant j'entends "pas beaucoup d'expérience". Je ne connais pas le fortran, j'ai un peu programmé en C, et là je bosse sur mon premier vrai projet C++ dans le cadre d'un projet d'info pour l'école. Donc niveau algorithmique ça va bien, par contre je ne connais pas les "astuces" des langages que l'on apprend au fur et à mesure en pratiquant.

En fait le projet dont je parle dans ce topic c'est pour m'occuper tout l'été. J'ai jeté un coup d'oeil à des extraits de programmes en fortran et ça m'a pas l'air super galère à apprendre comme je connais le C++.

En tous les cas merci de vos réponses ;).
09/03/2009, 09h42
millie

Si c'est pour un projet d'école, je pense que le temps de calcul que tu pourrais gagner en choisissant l'un ou l'autre langage n'est pas vraiment important.

Après, les benchmarks, on peut le faire faire dire tout et n'importe quoi (surtout n'importe quoi).

Pour le problème des n corps, ce qui est surtout important, c'est l'algorithme (on peut résoudre le problème de manière naîve, ce qui est lent, ou en utilisant des quadtree, ou encore l'algorithme que tu cites, et c'est là qu'il y a un réel gain).
09/03/2009, 14h31
Mat.M

Citation:

Envoyé par souviron34

Enfin tes exemples sont faux..

euh pardon je ne comprends pas à quoi tu fais allusion.
J'ai écrit: Eh oui y'a pas photo les compilateurs d'Intel semblent
être performants

Citation:

Tout langage multi-purpose (IHM et code) sera par définition plus lent qu'un langage mono-purpose.

Ah bon parce que la plupart des projets informatiques sont en mode console et mono-purpose comme tu écris ?
09/03/2009, 14h37
Mat.M

Citation:

Envoyé par Garulfo

C'est pourquoi aussi les multi-coeurs et le parallélisme y est intégré depuis longtemps comme le souligne Souviron

je me suis mal exprimé je voulais parler explicitement des CPU multi-coeurs d'Intel en particulier .
C'est certain qu'il y a des calculateurs et des systèmes tournant sous Unix par exemple qui possèdent des processeurs plus performants qu'Intel.
Mais ce genre de machine n'est pas à la portée de tout le monde ce que Mr Souviron semble perdre de vue ( et toc ! ).
09/03/2009, 21h31
Garulfo

Citation:

Envoyé par Mat.M

je me suis mal exprimé je voulais parler explicitement des CPU multi-coeurs d'Intel en particulier .[...]

Ah ok. Perso, moi et les PC ont a pas une grande histoire d'amour ^_^ Je te crois donc sur parole.
09/03/2009, 23h42
souviron34

Citation:

Envoyé par Mat.M

euh pardon je ne comprends pas à quoi tu fais allusion.
J'ai écrit: Eh oui y'a pas photo les compilateurs d'Intel semblent
être performants

Ok autant pour moi :oops:

Citation:

Envoyé par Mat.M

Ah bon parce que la plupart des projets informatiques sont en mode console et mono-purpose comme tu écris ?

Quand on parle d'un programe scientifique, en général il est mono-purpose.

Ensuite, et seulement ensuite, il y a en général une IHM pour présenter les résultats.. (très souvent stockés dans des fichiers) Il est extrêmement rare en sciences d'avoir à faire une présentation dynamique temps réel de résultats calculés au vol, et qui plus est dans la même application..

(modèles numériques, etc etc).

Citation:

Envoyé par Mat.M

je me suis mal exprimé je voulais parler explicitement des CPU multi-coeurs d'Intel en particulier .
C'est certain qu'il y a des calculateurs et des systèmes tournant sous Unix par exemple qui possèdent des processeurs plus performants qu'Intel.
Mais ce genre de machine n'est pas à la portée de tout le monde ce que Mr Souviron semble perdre de vue ( et toc ! ).

Euh 8O

Un bon serveur multi-coeurs Lunix est aussi accessible qu'une machine multi-coeurs Intel...

Nous ne reviendrons pas sur la "mode" M$, mais par exemple en général encore une fois quand on fait un code suffisamment scientifique pour se poser des questions de perfomances, c'est qu'on est dans un labo ou une équipe qui a un tant soit peu les moyens, la différence de prix étant relativement négligeable ...

:P

Mais là nous sommes HS....
17/03/2009, 20h57
bretus

Bonjour,

J'ai toucher un peu aux deux langages et j'ai eu à réaliser un projet en Fortran (simulation 3D de circulation) avec un collègue en école d'ingé.

Je t'avoue que j'ai été fort surpris par la rapidité du programme en Fortran, notamment sur les tableaux (on s'est retrouvé avec une fluidité que l'on espérait pas). Le hic a été au niveau des bibliothèques (graphiques, IHM, images...) qui ne sont pas autant à jour et développées que ce que l'on trouve en C/C++.

Fortran est plus strict et plus propre que le C (notamment pour le passage de paramètres et la gestion des tableaux).

Pour ce qui est du multi-thread, c'est un problème au niveau de l'OS et non au niveau du langage (il est tout à fait possible de créer un processus en fortran, que ça soit sous windows, ou sous linux)

Ensuite, si tu utilises Fortran, il existe différents Fortran. Je te conseille le 90/95, pour du calcul, tu auras ce dont tu as besoin.

Enfin, je pense que si vraiment tu veux jouer avec du multi-threading abordable pour du calcul, tu peux regarder plutôt du coté des cartes graphiques et la programmation GPU en C (CUDA chez NVIDIA par exemple). Inutile de lancer 150 processus sur un pauvre processeur quatre coeurs, il passera son temps à swapper entre les processus et a se faire interrompre par les frappes clavier...

En espérant que ça t'aide,
Bon courage
18/03/2009, 08h47
gorgonite

Citation:

Envoyé par bretus

Ensuite, si tu utilises Fortran, il existe différents Fortran. Je te conseille le 90/95, pour du calcul, tu auras ce dont tu as besoin.

justement, je conseillerais plutot de rester au 77 le plus longtemps possible, et de basculer vers 2003 si vraiment ça ne suffit pas... mais en évitant soigneusement 90/95
je connais plein de personnes qui préfèrent rester sur 77, car les performances sur le code qu'ils utilisent sont meilleures qu'en 90 par exemple ;)

pourrais-tu détailler ton choix du 90/95 ?
18/03/2009, 11h41
bretus

Bonjour,

En fait, je t'avoue que n'ayant pas testé les deux et que je ne connais pas toutes les différences, je ne peux pas faire de comparaison précise. C'était une consigne, un conseil du prof, avant tout. Si j'ai bien compris le 77 est en forme fixe obligatoirement non? (honnêtement, le coup des cartes perforées, j'aurais eu du mal ;))

Voilà, après libre à chacun de faire ses choix, mais pour 2003, je doute que d'ajouter de la P.O.O. au langage le rendra plus rapide à l'exécution...

Bye
18/03/2009, 11h42
millie

Citation:

Envoyé par bretus

Pour ce qui est du multi-thread, c'est un problème au niveau de l'OS et non au niveau du langage (il est tout à fait possible de créer un processus en fortran, que ça soit sous windows, ou sous linux)

Par hasard, tu es conscient que thread (ou fil d'exécution) et processus, ce n'est pas la même chose ?
18/03/2009, 11h53
souviron34

oui, mais MPI s'intègre parfaitement au Fortran...
18/03/2009, 22h40
bretus

Citation:

Envoyé par millie

Par hasard, tu es conscient que thread (ou fil d'exécution) et processus, ce n'est pas la même chose ?

J'avoue ne pas avoir compris directement ce que tu voulais dire parceque je ne pensais pas le thread aussi limité... Dis moi si j'ai bien compris maintenant stp :

Le processus est ordonnancé par l'OS, les threads sont ordonnancés par le processus qui les créés. Donc le thread n'est pas une affaire d'OS, c'est juste un mécanisme mis à disposition pour simuler le parallélisme au sein d'un même processus? Je disais donc une grosse connerie?

(merci pour la remarque en tout cas, pardon pour la connerie)
18/03/2009, 22h47
millie

Sur tous les systèmes que je connais, c'est l'OS qui ordonnance les threads.

D'ailleurs, chaque changement de threads nécessite une mise à jour du contexte d'exécution (notamment pour la pile), et seul l'OS sait le faire.

On choisit souvent du faire du multithread au lieu du multiprocessus car :
- le temps de création est plus rapide
- le changement de contexte est plus rapide
- il n'y a qu'un tas en mémoire
- on peut partager des données entre les threads (on veut synchroniser des traitements etc.) (il y a des solutions avec du multi processus avec des shmalloc est compagnie, mais la gestion des mutex, et d'après mes souvenirs plus délicates)

EDIT : @souviron : Tu t'adressais à moi avec RMI (aaah, non, t'as dit MPI, je connais pas :aie:) ?
18/03/2009, 23h03
bretus

Ok, merci pour ces précisions, ça m'évitera surement de faire une connerie de conception un jour...

bye
19/03/2009, 00h52
souviron34

Citation:

Envoyé par millie

EDIT : @souviron : Tu t'adressais à moi avec RMI (aaah, non, t'as dit MPI, je connais pas :aie:) ?

oui..

Message Passing Interface

ce qui est utilisé pour le traitement parallèle...

http://www.mcs.anl.gov/research/projects/mpi/

:D

C'est ce qui est utilisé mondialement pour le parallèlisme dans la plupart des programmes scientifiques, et cela s'intégre parfaitement au Fortran (ou à d'autres, bien sûr, mais la biblothèque d'origine est en Fortran).
19/03/2009, 01h05
deadalnix

Citation:

Envoyé par souviron34

Un bon serveur multi-coeurs Lunix est aussi accessible qu'une machine multi-coeurs Intel...

Trop gros, passera pas.
19/03/2009, 01h18
souviron34

Citation:

Envoyé par deadalnix

Trop gros, passera pas.

8O

La machine peut être la même... Et Linux est gratuit...

:koi:
20/03/2009, 09h56
Jatukam

Bonjour,
Voici l'origine du mot Fortran : "The IBM Mathematical Formula Translating System"....
Pour les threads, aucun problème, d'ailleurs, OpenMP est disponible et sa première version était pour le Fortran...
10/04/2010, 20h10
msnbcorp

Bonjour a tous, bon je remonte un sujet qui date d'un an, mille pardon et tout ça.

Bon je souhaite savoir si le contexte a évolué depuis que l'auteur du topic a posté.

Je m'explique : je vais travailler sur un supercalculateur , et actuellement on fait tourner un algorithme en Fortran dessus , avec un main en C pour la parallélisation (bibliothèque Mpi).

Mais bon , l'algo a étais écris il y a déjà une vingtaine d'années, et le Fortran n'a guerre évolué.

Le C++ lui au contraire continue a évoluer énormément, et si la parallélisation était bien peu développé en C++ il y a 20 an, aujourd'hui c'est devenu le fer de lance des principales innovations dans ce langage.

D'où ma question : aujourd'hui, vaudrait il mieux réécrire le langage en C++ pour gagner en temps de calculs, ou garder l'algo dans un langage qui commence à dater un peu .

Je précise que les avis du genre "je suis scientifique je programme toujours en Fortran donc le Fortran c'est bien" ou autres avis non constructif basé sur une opinion personnel ne me servent pas à grand chose...

(ha oui et pardon pour les fautes d'orthographe et tout ça.)
13/04/2010, 19h03
souviron34

une remarque en passant :

MPI ne fait pas que de la parallèlisation mono-machine mais multi-machines et multi-réseaux..

Si tu préfères te retaper (éternel débat, mais dont on voit tous les jours le bienfondé) de ré-écrire tout le code (ce qui n'est pas forcément le plus compliqué), mais surtout de tout re-tester pour atteindre le même niveau de confiance et si tes boss sont OK, allez-y.

Mais cette étape-là est de très très très loin la plus importante.. Un logiciel qui a plus de 20 ans a par conséquent plus de 20 ans de tests et débuggages..

Surtout ne pas oublier ça dans l'équation.

Quant à la parallèlisation, comme dit plus haut MPI (qui visiblement est déjà intégré) gère tout ça bien mieux (voir ls arguments ci-dessus). Il te faudrait donc de toutes façons le ré-implanter dedans..

Quelle serait donc la raison te poussant à vouloir réécrire en C++ ?

PS: si le langage n'a guère évolué en 20 ans, ce n'est pas que personne ne s'en sert, c'est surtout qu'il avait déjà intégré la plupart des évolutions nécessaires pour le calcul (multiplication matricielle, etc) :P Et d'ailleurs le cycle d'évolution de la norme est 20 ans : dans une révision de la norme (par exemple Fortran 90) on déclare que telle fonction DEVIENDRA obsolète à la prochaine révision (qui est dans 10 ans). A cette révision, ce qui a été mentionné précedemment va se faire affubler de l'épithète "obsolète", mais ne disparaitra totalement qu'à la révision SUIVANTE.. Soit un cycle de 20 ans pour se retourner et modifer.. ;) donc 20 ans est tout à fait un age normal pour un programme...