Question

On dit que Blitz ++ offre une performance proche de Fortran .

Fortran at-il tendance à être plus rapide que le C ++ classique pour des tâches équivalentes?

Qu'en est-il des autres langages HL offrant des performances d'exécution exceptionnelles? J'ai entendu parler de quelques langages qui surpassent le C ++ pour certaines tâches ... Objective Caml, Java, D ...

Je suppose que le GC peut rendre beaucoup de code plus rapide , car il supprime la nécessité d'une copie excessive autour de la pile? (en supposant que le code est pas écrit pour la performance)

Je demande par curiosité - j'ai toujours supposé que C ++ était quasiment imbattable, à l'exception du codage ASM expert.

Était-ce utile?

La solution

Fortran est plus rapide et presque toujours meilleur que C ++ pour le code purement numérique. Fortran est plus rapide pour plusieurs raisons. C'est le plus ancien langage compilé (beaucoup de connaissances en optimisation des compilateurs). C’est toujours LE langage utilisé pour les calculs numériques, de nombreux vendeurs de compilateurs vivent donc de la vente de compilateurs optimisés. Il existe également d'autres raisons plus techniques. Fortran (du moins Fortran77) n'a pas de pointeur et n'a donc pas les problèmes de repliement qui affectent les langages C / C ++ dans ce domaine. De nombreuses bibliothèques haute performance sont toujours codées en Fortran, avec une longue histoire (> 30 ans). Ni C, ni C ++ n’ont de bonnes constructions de tableaux (C est de niveau trop bas, C ++ a autant de bibliothèques de tableaux que de compilateurs sur la planète, qui sont incompatibles les unes avec les autres, empêchant ainsi un pool de code rapide bien testé).

Autres conseils

Que fortran soit plus rapide que c ++ est un sujet de discussion. Certains disent oui, certains disent non. Je n'entrerai pas dans ça. Cela dépend du compilateur, de l'architecture sur laquelle vous l'exécutez, de la mise en oeuvre de l'algorithme, etc.

.

Où fortran a un gros avantage sur C, c’est le temps qu’il vous faut pour mettre en œuvre ces algorithmes. Et cela le rend extrêmement bien adapté à tout type d'informatique numérique. J'énoncerai quelques avantages évidents par rapport à C:

  • Indexation de tableaux basée sur 1 (extrêmement utile lors de la mise en oeuvre de modèles plus volumineux, vous n’aurez pas à y penser, mais simplement FORmula TRANslate
  • a un opérateur électrique ( ** ) ( Dieu, qui était persuadé qu'une fonction électrique ferait l'affaire? Au lieu d'un opérateur?! )
  • oui, je dirais le meilleur support pour les tableaux multidimensionnels de toutes les langues du marché actuel (et il ne semble pas que cela va changer si tôt) - A (1,2) juste comme en maths
  • sans oublier d'éviter les boucles - A = B * C multiplie les tableaux (presque comme la syntaxe matlab avec la vitesse compilée )
  • il a des fonctionnalités de parallélisme intégrées dans le langage (vérifiez le nouveau standard sur celui-ci)
  • très facilement connectable avec des langages tels que C, python, afin que vous puissiez effectuer vos calculs les plus difficiles en fortran, tandis que .. que que ce soit ... dans la langue de votre choix, si vous vous sentez si enclin
  • entièrement compatible avec les versions antérieures (puisque l'ensemble du F77 est un sous-ensemble de F90), vous disposez donc d'un siècle complet de codage
  • très très portable (cela pourrait ne pas fonctionner avec certaines extensions du compilateur, mais en général cela fonctionne comme un charme)
  • communauté de résolution de problèmes (puisque les utilisateurs de fortran ne sont généralement pas cs, mais maths, phy, ingénieurs ... des personnes sans programmation, mais plutôt dans la résolution de problèmes dont la connaissance de votre problème peut être très utile)

Je ne peux penser à rien d’autre que cela m’arrive à présent, alors cela devra être fait.

Ce contre quoi Blitz ++ est en compétition n’est pas tant la langue Fortranaise que les siècles de travail consacrés aux bibliothèques de mathématiques Fortran. Dans une certaine mesure, le langage est utile: un langage ancien a eu beaucoup plus de temps pour optimiser les compilateurs (et, avouons-le, le C ++ est l’un des langages les plus complexes). D'autre part, des bibliothèques C ++ de haut niveau, telles que Blitz ++ et uBLAS vous permet d’énoncer vos intentions plus clairement que le code Fortran relativement bas, et permet de nouvelles classes d'optimisations à la compilation.

Cependant, pour pouvoir utiliser efficacement une bibliothèque, les développeurs doivent bien connaître le langage, la bibliothèque et les mathématiques. Vous pouvez généralement obtenir un code plus rapide en améliorant l’un des trois ...

FORTAN est généralement plus rapide que C ++ pour le traitement de tableaux en raison des différentes manières dont les langages implémentent les tableaux - FORTRAN n'autorise pas la création d'alias d'éléments de tableau, contrairement à C ++. Cela facilite le travail des compilateurs FORTRAN. En outre, FORTRAN possède de nombreuses bibliothèques mathématiques très abouties sur lesquelles on travaille depuis près de 50 ans - le C ++ n’a pas été aussi long!

Cela dépendra beaucoup du compilateur, des programmeurs, qu’il ait ou non gc et peut varier trop. S'il est compilé directement en code machine, attendez-vous à de meilleures performances que celles interprétées la plupart du temps, mais une optimisation limitée est possible avant que vous n'ayez quand même une vitesse asm.

Si quelqu'un disait que fortran était un peu plus rapide, coderiez-vous un nouveau projet dans ce cas?

Le problème avec c ++ est qu’il est très proche du niveau matériel. En fait, vous pouvez programmer au niveau du matériel (via des blocs d’assemblage). En général, les compilateurs c ++ font un bon travail d'optimisation (pour une accélération considérable de la vitesse, activez "Génération de code de lien de lien" pour autoriser l'inline de fonctions entre différents fichiers cpp), mais si vous connaissez le matériel et avez le comment, vous pouvez écrire quelques fonctions dans l'assemblage qui fonctionnent encore plus rapidement (même si, parfois, vous ne pouvez pas battre le compilateur).

Vous pouvez également implémenter vos propres gestionnaires de mémoire (ce que beaucoup d'autres langages de haut niveau n'autorisent pas), afin de les personnaliser pour votre tâche spécifique (peut-être que la plupart des allocations seront de 32 octets ou moins, alors vous pouvez simplement avoir une liste géante de tampons de 32 octets que vous pouvez allouer / désallouer en temps O (1). Je crois que c ++ PEUT battre n'importe quel autre langage, tant que vous comprenez parfaitement le compilateur et le matériel que vous utilisez. La majorité dépend des algorithmes que vous utilisez plus que toute autre chose.

Vous devez utiliser un étrange analyseur XML géré pour charger cette page. :)

Nous profilons continuellement le code et le gain est constant (et ce n’est pas du C ++ naïf, c’est juste du C ++ moderne avec boos). Il ouvre systématiquement toute implémentation CLR d’au moins deux fois et souvent de cinq fois ou plus. Un peu mieux que les jours Java où il était environ 20 fois plus rapide, mais vous pouvez toujours trouver de bonnes instances et simplement éliminer tout le ballonnement de System.Object et le battre à fond.

Une chose que les développeurs gérés ne comprennent pas, c’est que l’architecture matérielle est opposée à toute mise à l’échelle de la machine virtuelle et aux approches de la racine de l’objet. Vous devez le voir pour le croire, accrochez-vous, lancez un navigateur et accédez à une VM 'mince' comme Silverlight. Vous serez choqué par la lenteur et le besoin en ressources processeur.

Deux, lancement d’une application de base de données pour n’importe quelle performance, oui géré vs base de données native.

J'ai écrit ceci il y a quelques minutes:

Gestion de la mémoire en chaîne C ++

C'est généralement l'algorithme et non le langage qui détermine le stade de performance dans lequel vous vous retrouverez.

Au sein de ce stade, l'optimisation des compilateurs peut généralement produire un meilleur code que la plupart des codeurs d'assemblage.

L'optimisation prématurée est la racine de tous les maux

Ceci peut être la "connaissance commune" que tout le monde peut perroquet, mais je soutiens que c'est probablement parce que c'est correct. J'attends des preuves concrètes du contraire.

D peut parfois être plus rapide que C ++ dans les applications pratiques, en grande partie parce que la présence du garbage collection permet d’éviter les surcoûts de RAII et le comptage des références lors de l’utilisation de pointeurs intelligents. Pour les programmes qui allouent de grandes quantités de petits objets avec des cycles de vie non triviaux, la récupération de place peut être plus rapide que la gestion de la mémoire de style C ++. De plus, les tableaux intégrés de D permettent au compilateur d'effectuer dans certains cas de meilleures optimisations que le vecteur STL C ++, que le compilateur ne comprend pas. De plus, D2 prend en charge les annotations de données immuables et de fonctions pures, sur lesquelles les versions récentes de DMD2 optimisent. Walter Bright, le créateur de D, a écrit un interpréteur JavaScript en D et en C ++ et, selon lui, la version D est plus rapide.

Tout dépend du compilateur, prenons par exemple le compilateur Stalin Scheme, il bat presque toutes les langues de la suite de tests de performance de Debian, mais mentionne-t-il quelque chose à propos des temps de compilation?

Non, je soupçonne (je n'ai jamais utilisé Staline auparavant) de compiler des points de repère (toutes les optimisations à des niveaux d'effort maximum) prend beaucoup de temps pour tout, sauf les plus petits morceaux de code.

si le code n'est pas écrit pour la performance , alors C # est plus rapide que C ++ .

Avertissement obligatoire: tous les points de repère sont diaboliques.

Voici les points de repère qui en faveur de C ++ .

Les deux liens ci-dessus montrent que nous pouvons trouver des cas où C ++ est plus rapide que C # et inversement.

La performance d’un langage compilé est un concept inutile: l’important est la qualité du compilateur, c’est-à-dire les optimisations qu’il peut appliquer. Par exemple, le compilateur Intel C ++ produit souvent - mais pas toujours - un code plus performant que g ++. Alors, comment mesurez-vous les performances de C ++?

Là où la sémantique de la langue entre, c’est à quel point il est facile pour le programmeur d’obtenir du compilateur la création d’une sortie optimale. Par exemple, il est souvent plus facile de paralléliser le code Fortran que le code C. C’est pourquoi Fortran est toujours très utilisé pour les calculs hautes performances (par exemple, les simulations climatiques).

Comme la question et certaines des réponses le mentionnent: assembleur: la même chose est vraie ici, c’est juste un autre langage compilé et donc pas intrinsèquement 'plus rapide'. La différence entre assembleur et les autres langages réside dans le fait que le programmeur - qui possède idéalement une connaissance absolue du programme - est responsable de toutes les optimisations au lieu de déléguer certaines d'entre elles au compilateur "stupide".

Par exemple, les appels de fonction dans l'assembleur peuvent utiliser des registres pour passer des arguments et n'ont pas besoin de créer de trames de pile inutiles, mais un bon compilateur peut également le faire (pensez à l'inline ou à un appel rapide). L’inconvénient de l’utilisation d’Assembler est que les algorithmes les plus performants sont plus difficiles à mettre en œuvre (pensez à la recherche linéaire par rapport à la recherche binaire, à la table de hachage, ...).

Faire beaucoup mieux que le C ++ va surtout amener le compilateur à comprendre ce que veut dire le programmeur. Un exemple de ceci pourrait être un exemple où un compilateur de n'importe quel langage déduit qu'une région de code est indépendante de ses entrées et ne fait que calculer la valeur du résultat au moment de la compilation.

Un autre exemple est la manière dont C # produit du code très performant simplement parce que le compilateur sait ce que signifie "incantations" et peut utiliser intelligemment l'implémentation qui produit les performances les plus élevées, ce qui entraîne une translittération du même programme en C ++. cycles d’allocation / suppression inutiles (masqués par des modèles) car le compilateur traite le cas général au lieu du cas particulier donné par ce morceau de code.

Un dernier exemple pourrait être les adaptations Brook / Cuda de C conçues pour du matériel exotique qui n’est plus si exotique. Le langage prend en charge les primitives exactes (fonctions du noyau) mappées sur le matériel non-von-neuman compilé.

Est-ce la raison pour laquelle vous utilisez un navigateur géré? Parce que c'est plus rapide. Ou OS géré parce que c'est plus rapide. Non, accrochez-vous, il s'agit de la base de données SQL .. Attendez, ce doit être le jeu auquel vous jouez. Stop, il doit y avoir un morceau de code numérique Java et Csharp qui sont franchement inutiles. En passant, vous devez vérifier ce que votre VM a écrit pour sceller la langue racine et dire qu’elle est lente.

Quelle idée fausse, mais bon, montrez-moi une application rapide et gérée afin que nous puissions tous rire. CONTRE? Bureau ouvert?

C # est beaucoup plus rapide que C ++ - en C #, je peux écrire un analyseur syntaxique XML et un processeur de données en dix fois le temps nécessaire pour l'écrire en C ++.

Oh, vouliez-vous dire vitesse d'exécution?

Même dans ce cas, si vous prenez le temps de la première ligne de code écrite à la fin de la première exécution du code, C # est probablement encore plus rapide que C ++.

Il s'agit d'un article très intéressant sur la conversion d'un programme C ++ en C # et sur les efforts nécessaires pour rendre le C ++ plus rapide que le C #.

Donc, si vous prenez en compte la vitesse de développement, presque tout le monde bat le C ++.

OK, pour répondre à l'exigence de performance d'exécution de l'OP uniquement: Ce n'est pas la langue, mais l'implémentation du langage qui détermine les performances d'exécution. Je pourrais écrire un compilateur C ++ qui produit le code le plus lent imaginable, mais cela reste du C ++. Il est également théoriquement possible d’écrire un compilateur pour Java qui cible les instructions IA32 plutôt que les codes d’octets Java VM, ce qui accélère la vitesse d’exécution.

Les performances de votre code dépendront de l’adéquation entre les points forts du langage et les exigences du code. Par exemple, un programme qui alloue beaucoup d'allocation / désallocation mémoire ne fonctionnera pas correctement dans un programme C ++ naïf (c'est-à-dire utilise l'allocateur mémoire par défaut) car la stratégie d'allocation mémoire C ++ est trop généralisée, alors que l'allocateur basé sur le GC de C # peut être plus performant (comme le lien ci-dessus montre). La manipulation des chaînes est lente en C ++ mais rapide dans des langages comme php, perl, etc.

Ahh ... La bonne vieille question - quel compilateur fabrique du code plus rapide?

  1. Cela ne concerne que le code qui passe beaucoup de temps au bas de la pile d'appels, c'est-à-dire les points chauds qui ne contiennent pas d'appels de fonction, tels que l'inversion de matrice, etc.

  2. (Impliqué par 1) Cela importe uniquement dans le code que le compilateur voit réellement. Si votre compteur de programme passe tout son temps dans des bibliothèques tierces que vous ne construisez pas, cela n'a pas d'importance.

  3. Dans le code où cela compte, tout dépend du compilateur qui produit un meilleur ASM, et cela dépend en grande partie de la façon intelligente ou stupide d'écrire le code source.

Avec toutes ces variables, il est difficile de distinguer les bons compilateurs.

Cependant, comme cela a été dit, si vous avez beaucoup de code Fortran à compiler, ne le réécrivez pas.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top