A propos des codes de calcul
Répondre à la discussion
Affichage des résultats 1 à 20 sur 20

A propos des codes de calcul



  1. #1
    invite31b5cbad

    A propos des codes de calcul


    ------

    Bonsoir à tous,

    Ce sujet est à la limite entre la Physique et l'Informatique, je ne savais pas trop où poster, désolé pour la gêne éventuelle.

    Je me pose un certain nombre de questions au sujet des codes de calcul scientifique.

    Je suis un grand utilisateur de Matlab, c'est un outil que j'aime beaucoup. On m'a dit qu'il s'agissait d'un langage "interprété"... Qu'est-ce que cela signifie?

    Je constate que le Fortran est extrêmement utilisé dans les logiciels de simulation numérique (Fluent, Star-CD, etc.). La raison en est, je crois, qu'il s'agissait d'un langage assez fulgurant à l'époque. Il est encore pas mal aujourd'hui, mais on m'a dit qu'il y avait mieux (le C?). Apparemment le Fortran est encore là en raison du nombre incalculable de routines qui on été développées avec ce langage. Sa pérennité serait dûe à la "fainéantise", tant il serait long, coûteux et pénible de tout réécrire dans un nouveau langage.

    Quelle est la différence entre Matlab et le Fortran?

    Existe t-il des codes de calcul en Assembleur?

    Merci!

    -----

  2. #2
    mamono666

    Re : A propos des codes de calcul

    Ca serait plutôt limite entre mathématiques et informatique.

    Je ne peux pas t'aider, mais je te conseil vivement ces liens:

    http://fr.wikipedia.org/wiki/MATLAB

    http://fr.wikipedia.org/wiki/Fortran
    Out! Out! You, Demons Of Stupidity!!

  3. #3
    obi76

    Re : A propos des codes de calcul

    Matlab est un langage interprété dans le sens ou ce que tu écris n'est pas compilé (comme le visual basic sous windaube. un "éxécutable" est en fait une suite de commandes en basic interprétées par un programme. C'est pour ça qu'un programme "compilé" necessite un runtime à coté.
    D'om le langage interprété.

    Le fortran c'est vrai que c'est par fénéantise, et puis ça marche très bien alors pourquoi changer...

    Matlab et fortran ça a rien à voir. L'un est interprété, l'autre quand il est compilé est en assembleur.

    Cordialement

  4. #4
    inviteb836950d

    Re : A propos des codes de calcul

    Bonsoir

    Je ne peux te donner que quelques éléments de réponse : un programme écrit dans un langage compilé sera totalement traduit en langage machine avant son exécution. Un langage interprété sera traduit "à la volée" instruction par instruction au cours de son exécution.

    La pérennité du Fortran est surement due aux millions et millions de lignes de codes qui sont déjà écrit. Pourquoi les réécrire ? surtout que le code compilé à partir du Fortran est de très bonne qualité (depuis le temps, les compilateurs Fortran sont au top ...)

    edit : croisement avec obi76
    (au fait quand c'est compilé, c'est en langage machine, pas en assembleur...)

  5. A voir en vidéo sur Futura
  6. #5
    obi76

    Re : A propos des codes de calcul

    Le langage machine c'est simplement la conversion de l'assembleur en hexadécimal, pas besoin de compilation....

  7. #6
    mamono666

    Re : A propos des codes de calcul

    Dans l'absolue cela n'a pas rien à voir. Comme nous le rappel wikipédia:

    Le nom MATLAB est la contraction du terme anglais matrix laboratory. Le langage MATLAB a été conçu par Cleve Moler à la fin des années 70 à partir des bibliothèques Fortran, LINPACK et EISPACK
    Out! Out! You, Demons Of Stupidity!!

  8. #7
    invitee394e3b8

    Re : A propos des codes de calcul

    La pérénité du Fortran et surtout la raison de son ampleur est justement qu'il est tres bien compilé. C'est à dire que la facon dont il traduit ce que tu ecris en matrices de 1 et de 0 est tres efficace et en fait encore aujourd'hui le langage le plus rapide pour le calcul scientifique.
    Mais aujourd'hui le peu de différence que cela fait n'est plus aussi importante que l'utilisation qu'il permet. Autrement dit, c'est peut être le meilleur pour te résoudre une équation mais au delà ... Il est alors en train, petit à petit (l'inertie du poids des lignes de calcul écrites certainement) de ceder la place à d'autres codes. Surtout pour l'orientation objet naturelle dans le fortran. Mais qui sera l'heureux remplacant ? le C++ ? j'en suis pas sur ...

  9. #8
    obi76

    Re : A propos des codes de calcul

    DocDav, je suis pas si sur que ça que le fortran soit en vue d'être remplacé...

  10. #9
    inviteb836950d

    Re : A propos des codes de calcul

    Citation Envoyé par obi76 Voir le message
    Le langage machine c'est simplement la conversion de l'assembleur en hexadécimal, pas besoin de compilation....
    Non, tu te trompes, le langage d'assemblage est un code en soi. C'est un langage de bas niveau mais il faut le compiler et éditer les liens pour en faire un vrai exécutable.

  11. #10
    invitee394e3b8

    Re : A propos des codes de calcul

    Citation Envoyé par obi76 Voir le message
    DocDav, je suis pas si sur que ça que le fortran soit en vue d'être remplacé...
    Seul l'avenir nous le dira... En tous cas, chez nous, après 20 ans d'utilisation du Fortran, on est parti pour tout refaire (en mieux biensur ) en C++.

  12. #11
    obi76

    Re : A propos des codes de calcul

    ben pas chez nous

  13. #12
    invite5cf37a3e

    Re : A propos des codes de calcul

    Bonsoir Koranten,

    Un langage interprété s'oppose à un langage compilé/"linké"

    Ce qu'on appelle un langage compilé est un langage naturel lisible (pour un informaticien!!!) qui sera traduit une fois pour toute en langage machine (des 0 et des 1) directement assimilable par le processeur (je simplifie un peu pour la clarté de l'expo).
    Cette traduction s'apelle la compilation.

    Ensuite on "link" (on dit en français éditer les liens) l'objet obtenu.
    Ce qui veut dire qu'on rattache tous les appels aux fonctions de bases déjà compilées dans le passé (ex. print() pour écrire à l'écran) et dont on aurait besoin pour, par exemple, accéder aux diverses ressources de la machine (pas la peine de tout réécrire à chaque fois: on écrit des fonctions spécialisées, on les compile et on les place dans une bibliothèque de fonction qu'on appelle ensuite. Souvent on peut acheter des bibliothèques de fonctions particulières. Les compilateurs sont livrés avec les bibliothèques de base)


    Un langage interprété est tout autre. On écrit aussi en un langage lisible par l'homme, mais cette fois on ne le traduit pas en langage machine. Il reste en l'état.
    Lorsque l'on veut l'exécuter, il faut un autre programme, l'interpréteur ou runtime, qui va traduire au fur et à mesure de l'exécution (là aussi, je simplifie) le programme en instruction compréhensible par la machine.

    A l'exécussion on perd du temps par rapport à un langage compilé puisqu'il faut en plus interpréter le langage.

    Il y a des inconvénients et des avantages aux deux techniques. Tout dépends de l'utilisation finale.

    Ensuite, il existe aussi le langage assemblé (on l'appelle Assembleur). C'est un langage qui dépend directement du processeur. En effet, on écrit alors des instructions de processeur comme lire l'adresse, ou décaler tout les bit d'un registre vers la gauche... Ce langage est lisible par des informaticiens spécialisés, il colle au processeur dans la mesure où chaque instruction est une instruction du processeur alors que chaque instruction des autres types de langage est déjà un programme (la multiplication ou la fonction print n'existe pas dans le jeu d'instruction du processeur)
    Il faut aussi le traduire en langage machine, toujours des 0 et des 1, c'est ce qu'on appelle l'assemblage.


    Enfin, le Fortran (FORmula TRANslating) est un des premiers langages compilés (si ce n'est le premier) développé à l'origine pour simplifier la programmation. En effet l'assembleur est lourd à utiliser et il faut presque toujours tout réécrire les fonctions de base, ce qui oblige à savoir, par exemple, comment programmer une multiplication avant de s'en servir ou encore savoir comment la machine doit envoyer des 0 et des 1 sur l'imprimante pour voir mes photos de vacances (par où, comment gérer les retours comme la fin de papier...) Avec un langage compilé j'écris
    print(mes photos, mon imprimante) ou quelqeu chose de trés proches.

    FORTRAN a été un fabuleux langage pour la traduction de formule mathématique (pour l'époque) et a été beaucoup utilisé dans les universités.

    Si on l'utilise encore aujourd'hui (presque plus) ce n'est pas par fénéantise mais comme beaucoup de langages anciens qu'on n'ose pas abandonner, pour un souci économique: si un programme existe, qu'il remplit son office et que son remplacement serait particulièrement coûteux, pourquoi le remplacerais-je? D'autre langage trés célèbre suive cette logique comme le COBOL par exemple, spécialisé dans les applications de gestion.
    Leur mort est régulièrement annoncée, mais ils sont régulièrement modernisés.

    Revenons rapidement à l'Assembleur: comme il reflète les instructions du processeur, il permet de faire tout ce qu'on peut faire avec un ordinateur, sauf qu'il faut tout écrire.
    Lorsque l'on passe par un langage plus évolué, voir spécialisé comme Matlab, on écrit plus vite des programmes utiles (y a pas photos!) mais on ne peut pas tout faire. Je suis à peu près sûr que Matlab ne sait pas faire tourner un tour ou une fraiseuse à commande numérique! En assembleur, on peut toujours (si l'interface existe, bien sûr)
    Donc un langage sera plus ou moins spécialisé et j'en viens au C qui est un langage compilé et qui est peut-être le plus proche de l'assembleur.
    C'est une sorte de compromis entre un langage comme FORTRAN et l' Assembleur. Il est plus compliqué que le Fortran mais moins que l'assembleur. il est plus généraliste que le Fortran et trés proche de l'assembleur. D'ailleurs, la plupart des compilateurs C admette qu'on leur parle en assembleur, ce que l'on fera pour des fonctions précises.

    Aujourd'hui le choix de langage de programmation est immense. En voici quelques-uns anciens ou récents:
    Assembleur (en générale plusieurs par processeur), Basic, Fortran, Cobol, Pascal, C, C++, Visual Basic, Java, Html, Xml, Lisp, Delphi, Corba...


    Désolé, c'est un peu long, mais il avait plusieurs questions dans le post.

    Cordialement

  14. #13
    invite31b5cbad

    Re : A propos des codes de calcul

    Merci beaucoup tkiteasy

    Tu peux me dire quel est l'intérêt de l'interprété (Matlab par exemple) par rapport au compilé (Fortran?). C'est beaucoup plus simple à programmer de ce que j'en ai vu, mais est-ce vraiment la différence?

    Et puis pourquoi Matlab ne pourrait pas être compilé, plutôt que d'être interprété? Ca irait plus vite, non? Il n'existe pas de moyen de traduire un code Matlab en code Fortran? Ce serait génial... (doux rêve )

    Donc, si on résume:

    Matlab = spécialisé = facile mais lent
    Assembleur = grosse brutasse en 'natif' = super balèze mais over rapide

    Et entre les deux, le C et le Fortran?

    Quid du C++?

    Si j'ai bien compris, le C est plus "puissant" que le Fortran et pourrait, à terme, le remplacer?

    Mes profs me disent qu'on a encore pour 40 ans de Fortran.

    Je comprends bien que lorsqu'un langage marche aussi bien, pourquoi se grouiller de passer à autre chose? D'où la longévité du Fortran.

    En même temps, j'étudie en ce moment la simulation numérique de la mécanique des fluides et les problèmes liés à la turbulence. C'est encore aujourd'hui insurmontable en simulation numérique directe (SND ou DNS en anglais), d'où le recours à tout un tas de modèles simplificateurs (RANS, LES, etc.). Les meilleurs codes de DNS sont optimisés jusqu'à la racine et ne gèrent pas encore les cas industriels réels, loin de là. Quand je vois les efforts faits sur le stockage, le solveur, le parallélisme, etc, je m'étonne que plus d'efforts ne soient pas faits sur le langage. Quoique, c'est peut-être le cas, je ne sais pas. Mais la turbulence est un problème encore ouvert, non résolu, et il y a tellement à gagner à la résoudre que je me demande...

    Merci en tous cas

  15. #14
    invite5cf37a3e

    Re : A propos des codes de calcul

    Koranten,

    Le C est quasiment aussi vieux que le Fortran.
    L'un ne remplace pas vraiment l'autre. On choisit l'un ou l'autre en fonction de ce que l'on veut faire.
    C peut paraitre plus puissant, mais il induit aussi beaucoup d'erreurs de programmation. Il demande plus de discipline. C'est souvent qu'à la mise au point, on plante la machine. C'est plus rare en Fortran.
    Si je dois écrire des interfaces techniques ( j'ai eu à programmer la réception de cours de bourse depuis une parabole satellite, par exemple) le C est plus approprié. Mais s'il s'agit de programme scientifique, le Pascal ou le Fortran seront mieux adaptés.


    On peut trés bien envisager de compiler un langage interprété. C'est le cas du Basic.
    Lorsque je programmais en Basic, il y a 20 ans, je mettais mes programmes au point en mode interprété et lorsque j'étais satisfait, je le compilais.

    Un des avantages d'un langage interprété est d'y avoir facilement accés.

    Si tu achètes un programme interprété, tu auras systèmatiquement le source.
    Mais c'est exceptionnel: on te vendra plus facilement des programmes compilés pour que tu n'ailles pas pirater (en tout cas moins facilement) les programmes.

    C'est un raccourcis: ce n'est pas la seule raison, ni la raison essentielle.


    Pour ce qui est de transcrire un programme d'un langage en un autre, c'est tout à fait possible.
    Tu peux tout à fait imaginer mettre au point une fonction dans un langage conviviale puis la réécrire dans un autre langage, plus rapide. Mais en général, on écrit directement dans le langage cible.
    Je faisais cela par exemple en mettant au point un calcul mathématique un peu complexe sous Excel puis je le transcris en C une fois OK!


    Maintenant, s'agissant de la meca flu, c'est une autre histoire.
    Certe, il vaut mieux avoir un langage rapide et optimisé s'il y a bcp de calcul. Peut-être utiliser l'Assembleur dans des fonctions ciblées trés répétitives.
    Mais, comme tu le dis, il y aura aussi bcp à gagner sur les méthodes numériques.
    Mais aussi sur la connaissance des turbulences, qui, à mon humble avis, ne se laisseront pas détordre de sitôt: on est dans un domaine de calcul non linèaire et j'ai peine à croire qu'on arrivera un jour à dompter la bête. Sauf peut-être dans des cas précis, bien délimités, souvent éloignés du cas industriel réel.
    Quoique!

  16. #15
    invite5cf37a3e

    Re : A propos des codes de calcul

    Le C++, c'est encore un stade au-dessus.
    C'est de la programmation objet (à ne pas confondre avec la conception objet)

    Avant la programmation objet, les programmes étaient linéaires.
    instruction 1
    puis instruction 2
    puis arbre de décision vers instruction 3 ou 4
    etc...

    L'objet c'est autre chose. Je programme un élément sorti de son contexte en lui accordant des caratéristiques et des actions et réactions.
    Quand c'est bien fait, je n'ai plus trop à m'occuper comment est programmé l'objet mais plutôt à comment il réagit quand je lui envoie une action. Quand je remonte ma montre, je n'ai pas besoin de savoir ce qu'il y a dans le boitier et ce que font les engrenages; il m'importe surtout de savoir qu'il faut la remonter pour qu'elle continue à me donner l'heure.
    (oui, je sais, il n'y a plus bcp de montre mécanique, mais la mienne l'est)

    De plus un objet peut être constitué de plusieurs objets, comme ma montre qui a plusieurs engrenages, des ressorts, des aiguilles...
    L'intéret est de pouvoir réutiliser les objets sans avoir à les reprogrammer à chaque fois. D'où un gain en temps de programmation (enfin normalement!) et un gain à chaque nouveau projet utilisant les mêmes objets.

    Ceci dit, on ne gagne pas en temps d'exécution, bien au contraire. Il faut bien choisir son compilateur.

  17. #16
    invitec336fcef

    Re : A propos des codes de calcul

    Citation Envoyé par tkiteasy
    Le C++, c'est encore un stade au-dessus.
    C'est de la programmation objet (à ne pas confondre avec la conception objet)
    Pas forcément, la P.O.O est une facette du C++, mais ce n'est pas forcément utilisable dans un code de calcul. Le FORTRAN ne sera pas remplacé, en tout cas, moi qui suis au CEA, les codes de calcul sont presque tous codés en FORTRAn bien que les nouvelles applications sont maintenant généralement codées en C++. En tout cas, cela couteraît trop cher.

    Cordialement.

  18. #17
    obi76

    Re : A propos des codes de calcul

    Si t'es au CEA on aurai pu se croiser, ils ont proposé des stages de numérique dans le labo ou je fais mes études

  19. #18
    invite31b5cbad

    Re : A propos des codes de calcul

    Bah tiens c'est marrant, je vais faire mon stage de fin d'études au CEA (Tours, Le Ripault)

  20. #19
    invite5cf37a3e

    Re : A propos des codes de calcul

    Au CEA, j'y suis passé en 1987!

  21. #20
    invite835105c9

    Re : A propos des codes de calcul

    Salut,

    juste pour mettre mon grain de sel.
    L'oriente objet n'est pas franchement bien adapte "aux calculs".
    Je veux dire (comme tu le dis) qu'il faut bien choisir son compilo et repenser une bonne partie de l'architecture (objet) du programme.

    Par exemple un des grands trucs de la simulation atomistique c'est d'utiliser des potentiels a deux-corps. En programmant bien on peut reduire par un facteur deux les calculs (quand on a une dizaine de milliers d'atomes ca devient non negligeable). Par contre si on considere un code objet dans lequel les atomes deviennent des "objets" (au sens informatique) alors chacun a sa methode propre et hop on peut facilement perdre son facteur 2 voir pire avec les copies et autres jolies inventions informatiques !

    Donc pour resumer C++ (C#, java et consort) c'est bien mais faut reflechir longtemps avant et reflechir sans les equations de la physique (enfin sans se baser dessus uniquement).

    J'ai travaille il y a quelque temps sur un (tres) gros projet d'une (tres tres) grosse boite d'informatique et le C++ etait reserve a l'interface humaine, le reste le coeur du code du bon vieux C (le language de haut niveau le plus pres de la machine finalement !!!). Parce que finalement un langage invente en 70 peut encore tourner en 2007. D'ailleurs Linux est ecrit en C et meme les compilos... Marrant non ?

Discussions similaires

  1. a propos des casque des astronautes...
    Par invite483d8df8 dans le forum Astronautique
    Réponses: 2
    Dernier message: 10/11/2006, 06h41
  2. Réponses: 1
    Dernier message: 09/10/2005, 22h40
  3. Allumage des codes
    Par laramasse dans le forum Environnement, développement durable et écologie
    Réponses: 246
    Dernier message: 19/02/2005, 17h13