Le ralentissement des performances des langages de programmation est-il vraiment une mauvaise chose? [fermé]

18

Voici comment je le vois.

Il y a du code machine et c'est tout ce dont les ordinateurs ont besoin pour exécuter quelque chose. Les ordinateurs ne se soucient pas des langages de programmation. Peu importe pour eux que le code machine provienne de Perl, Python ou PHP. Les langages de programmation ne servent pas les ordinateurs. Ils servent les programmeurs.

Certains langages de programmation fonctionnent plus lentement que d'autres, mais ce n'est pas nécessairement parce qu'il y a quelque chose qui ne va pas avec eux. Dans de nombreux cas, c'est parce qu'ils font plus de choses que les programmeurs auraient autrement à faire (c'est-à-dire la gestion de la mémoire) et en faisant ces choses, ils sont meilleurs dans ce qu'ils sont censés faire - servir les programmeurs.

Alors, les performances plus lentes des langages de programmation sont-elles vraiment une mauvaise chose?

Emanuil Rusev
la source
22
plus lent de quelle manière? temps de compilation, temps d'exécution, temps d'écriture, une autre métrique?
Matt Ellen
1
Je voudrais simplement souligner que les ordinateurs rapides et les compilateurs qui génèrent un langage machine efficace sont évidemment bons, sauf qu'ils permettent aux programmeurs d'être beaucoup plus paresseux. Lorsque les produits ont des problèmes de performances, c'est souvent parce qu'ils supposent que certaines choses sont "rapides", comme la gestion de la mémoire et les notifications.
Mike Dunlavey
5
@Mike: Alternativement, les programmes fonctionnent lentement en raison d'une attitude que Jeff a bien résumée récemment dans son blog: "Les algorithmes sont pour les gens qui ne savent pas comment acheter de la RAM". Si le programme fonctionne en temps cube plutôt qu'en temps O (N log n), la puissance de l'ordinateur n'a pas vraiment d'importance pour les gros problèmes.
David Thornley
2
@David: nous ne pouvons pas avoir plus de 512 Go de RAM sur notre serveur, nous devons donc écrire de meilleurs algorithmes maintenant.
JBRWilkinson
2
Dépend de l'endroit où se trouvent les goulots d'étranglement. Si le programme attend les E / S 99,9% du temps, peu importe si le programme lui-même est 10 fois plus lent que s'il était écrit en assembleur artisanal.

Réponses:

50

Je ne pense pas que ce soit automatiquement mauvais. Python est plus lent que C ++, mais lorsque les deux sont assez rapides , Python peut être le meilleur choix pour le problème à résoudre, même s'il est plus lent .

C'est toujours un compromis. Pour les petites tâches ponctuelles, il est beaucoup plus rapide d'écrire un script Python qu'une application C ++ qui fait de même (l'exemple typique pour moi serait une sorte de traitement de texte par lots ou de parcourir une arborescence de répertoires et de faire quelque chose dans les fichiers), et je me fiche de savoir si cela prend 10 ms ou 1000 ms, même si c'est 100 fois plus lent, car cela peut me prendre la moitié du temps pour écrire et tester.

Bien sûr, ce serait bien si Python était aussi rapide que C ++, donc en ce sens, je suis d'accord avec votre affirmation que "slow = bad". Mais ensuite, j'ai plutôt un langage puissant qui s'exécute aussi vite que je le souhaite en ne faisant pas certaines choses (disons, les limites des tableaux vérifient les tableaux bruts) tant qu'il me permet de décider quand faire ce compromis (par exemple, en utilisant std: :vecteur).

ggambett
la source
Je n'ai pas dit que "lent = mauvais". Néanmoins, merci de partager vos pensées.
Emanuil Rusev
9
+1 «assez rapide» Lent est mauvais lorsqu'une implémentation est «trop lente / pas assez rapide». À tout autre moment, cela n'a pas d'importance.
Kirk Broadhurst
4
+1 «assez vite». Selon ce que vous faites, le temps du programmeur peut valoir BEAUCOUP plus que les économies potentielles en temps d'exécution.
Jonas
3
@Jonas: ce n'est presque jamais le cas, c'est juste que vous voyez le salaire du programmeur; vous ne voyez pas les utilisateurs pendre la tête de frustration alors que l'application rampe en criant "allez, quelle est la difficulté, vous empilez des logiciels de merde". S'ils publiaient le coût total de possession des logiciels lents contre les logiciels rapides - vous verriez vos priorités changer immédiatement votre service des ventes.
gbjbaanb
1
@mcmcc: Je ne parlais pas des langues là-bas, mais de l'expérience utilisateur. Lorsque vous cliquez sur un bouton, quelque chose doit se produire immédiatement. Lorsque vous lancez un calcul, c'est bien si cela prend un certain temps, tant qu'il existe un indicateur de progression utile.
Jonas
18

Assez simple - être lent est une mauvaise chose

lorsque le programme nécessite un certain niveau de performance

car sans cette performance, vous ne remplissez pas les exigences.

Il peut s'agir d'une application métier qui doit traiter des requêtes dans un laps de temps acceptable jusqu'à un jeu qui doit afficher de nombreuses informations à l'écran à tout moment. Si le programme n'est pas assez rapide, il ne fonctionne tout simplement pas .

Kirk Broadhurst
la source
2
..et souvent les exigences ne sont pas écrites dans une sorte de "plus de X secondes pour aller chercher une page oblige l'utilisateur moyen du site Web à se déplacer vers un autre site"
JBRWilkinson
1
@JBRWilkinson oui, ou si le système est trop lent, de nouvelles exigences de performances apparaîtront soudainement;)
Kirk Broadhurst
12

Regardez-le de cette façon: les ordinateurs sont stupides . Ils suivent péniblement les instructions que tout crétin avec une table trig pourrait suivre. Ils insistent obstinément pour faire ce que vous avez dit au lieu de ce que vous vouliez dire. Pas une once d'auto-direction ou d'intuition. C'est horrible.

La seule chose qu'un ordinateur a pour elle est, c'est rapide. Vraiment! Un knucklehead avec un classeur pourrait faire le même travail qu'une base de données. Un gars qui lance une presse à imprimer pourrait faire ce qu'Apache fait. Sérieusement! Et ils l'ont fait, pendant des centaines et des centaines d'années, en fait. Pourquoi un ordinateur est bon pour TOUT est sa vitesse.

Donc, un langage de programmation qui (par rapport à d'autres langages) ne parvient pas à exploiter qui manque le SEUL avantage d'utiliser des ordinateurs.

Dan Ray
la source
13
Vous manquez un élément important: les ordinateurs sont stupides, rapides et prévisibles , alors que erratum humanum est. Et dans de nombreux cas, cette prévisibilité est beaucoup plus importante qu'une vitesse pure.
SK-logic
5
Tout langage de programmation exploite la vitesse de l'ordinateur. Python sur l'un des ordinateurs OLPC d'origine fait les choses beaucoup plus rapidement que je ne le peux à la main. Gardez à l'esprit que mon ordinateur portable actuel (acheté il y a deux ans, et qui n'est pas haut de gamme à l'époque) est à peu près cent mille à un million de fois plus puissant que mon premier ordinateur domestique à bien des égards.
David Thornley
4
Sans oublier qu'un ordinateur consomme beaucoup d'énergie à utiliser (en particulier les serveurs), et qu'il y a une inquiétude perçue avec la consommation d'énergie (la technologie verte), et qu'un programme plus rapide fait généralement plus avec la même quantité d'énergie qu'un programme plus lent, donc ça compte (surtout sur les serveurs, qui consomment beaucoup)
Coyote21
4
@ SK-logic La prévisibilité informatique est surestimée. Comme l'a très bien souligné Joseph Weizenbaum, les grands systèmes ont tendance à devenir si compliqués qu'ils ne sont en aucun cas prévisibles et personne n'est en mesure de PRÉDIRE le résultat d'une certaine exécution. Cela devient une question de foi ou d'espérance. Vous ne pouvez pas prouver formellement qu'un programme fera toujours ce que vous vouliez (il n'est donc pas prévisible).
Omar Kohl
2
Pourtant, si la vitesse (d'exécution) est l'objectif ultime, pourquoi n'écrivons-nous pas tous nos programmes en code machine?
Emanuil Rusev,
5

Un langage de programmation peut être de très haut niveau, "faire beaucoup", tout de même être très rapide. OCaml est un langage de niveau supérieur à PHP, mais il produit un code presque aussi rapide que C. Javascript est aussi dynamique que PHP, mais il peut être exécuté très rapidement. Donc, c'est principalement un problème avec une implémentation de langage, pas une conception. Les langages dynamiques sont plus difficiles à implémenter efficacement, mais pas impossible.

SK-logic
la source
Pensez-vous que les langages considérés comme lents (en termes de fonctionnement), tels que PHP, peuvent être implémentés pour s'exécuter plus rapidement?
Emanuil Rusev
1
Zend Optimizer quelqu'un?
user281377
Permettez-moi de demander ceci d'une autre manière - qu'est-ce qui, dans l'implémentation de PHP, le ralentit?
Emanuil Rusev
6
Oui, il peut être mieux implémenté. Cela demandera beaucoup d'efforts - une interprétation abstraite pour spécialiser les types dynamiques, par exemple, est une chose assez délicate et pas encore bien étudiée. Un langage statique est beaucoup plus facile à traduire en un code très efficace. Donc, PHP est lent principalement parce qu'il est dynamique. Et, à l'origine, il avait une implémentation très pauvre et non professionnelle, ainsi que de nombreux autres langages de script.
SK-logic
Le compilateur HipHop, lancé par Facebook, peut traduire PHP en code C ++, donc c'est vraiment rapide.
JBRWilkinson
3

La vitesse peut être mesurée en termes d'exécution, de temps de développement initial et de maintenance (temps nécessaire pour résoudre les problèmes / bogues et produire un nouveau code et le déployer).

Les langages de script ont généralement un temps d'exécution plus lent mais un temps de maintenance plus rapide car vous pouvez souvent effectuer une modification et un déploiement rapides sans avoir à reconstruire un système entier, et parfois sans même avoir à arrêter et redémarrer.

Par conséquent, beaucoup dépend de la vitesse dont vous avez besoin.

Le contexte est également important. Charger votre configuration initiale en prenant 0,5 seconde au lieu de 0,1 seconde n'est pas un problème, mais au moment de l'exécution, prendre 0,5 seconde pour exécuter une requête au lieu de 0,1 seconde peut être un gros problème s'il doit gérer 100 requêtes, ce qui prend 50 secondes au lieu de dix.

Vache à lait
la source
100 ms est effectivement instantané dans la perception de l'utilisateur. 500 ms est assez perceptible. Si l'utilisateur effectue des requêtes, c'est une différence notable dans le flux de travail.
David Thornley
3

Simple - les clients aiment les logiciels rapides. En fait, le but des ordinateurs est de calculer rapidement.

Nemanja Trifunovic
la source
11
mal, en fait. Les clients adorent les logiciels qui répondent aux exigences et au budget. Ils ne se soucient pas moins si un écran prend 19 millisecondes à construire plutôt que 15, car ils ne s'en rendent jamais compte (si cela prend 15 secondes à construire, c'est autre chose). Ils se moquent également de savoir si vous utilisez un "langage rapide", ils veulent juste quelque chose qui fonctionne selon les spécifications et dans les limites du budget.
jwenting
4
19 ms contre 15 ms peuvent ne pas faire de différence, mais 500 ms vs 300 ms le font définitivement et cela peut faire la différence entre un produit réussi et un échec.
Nemanja Trifunovic
2
+1 "Les clients adorent les logiciels qui répondent aux exigences et respectent le budget." En revanche, certains utilisateurs finaux, qui ne paient pas directement le logiciel, comme les employés d'une grande entreprise, ne se soucient pas vraiment des coûts de développement. Bien sûr, en tant que fournisseur de logiciels, votre tâche la plus importante est de garder ces gens heureux, qui vous paient réellement.
Zsolt Török
@Zsolt: Cela dépend vraiment du type de logiciel que vous développez. Je travaille généralement sur des produits où les utilisateurs finaux paient directement les produits ou influencent les décisions d'achat - ils ne nous donnent pas de spécifications et ne se soucient pas de notre budget. J'aurais peut-être dû utiliser le terme «utilisateurs» plutôt que «clients».
Nemanja Trifunovic
4
Parlant en tant qu'utilisateur (plutôt qu'en tant que développeur), je peux dire que la réactivité générale (note: différente de la vitesse) est un facteur majeur dans ma décision de choisir un programme plutôt qu'un autre. C'est une des raisons pour lesquelles j'utilise peu d'applications Java par exemple; le temps de démarrage sur la JVM seule entraîne des applications qui commencent avec -5000 points dans cette zone;). Sérieusement, la réactivité peut (souvent) faire la différence entre l'interface utilisateur de votre produit qui est maladroite ou efficace, et cela peut parfois être difficile à réaliser si la langue que vous utilisez induit des bégaiements ou de longues E / S de disque attend.
Billy ONeal
3

Lent est relatif. Si j'ai besoin de lire un port 10 fois par seconde, un langage qui ne peut pas créer un binaire qui peut le faire est trop lent. Si otoh j'écris une application Web où la séquence de demande / réponse entre le serveur et le navigateur / client est mesurée en secondes et l'utilisateur est susceptible de passer des minutes sur un écran avant de cliquer sur un bouton, un langage de programmation qui peut gérer le traitement des demandes en 1 seconde est probablement assez rapide (la plupart sont bien sûr beaucoup plus rapides).

Bien sûr, le langage de programmation peut être un facteur déterminant la vitesse d'exécution, mais ce ne sera pas le langage lui-même mais les compilateurs et / ou les runtimes qui l'accompagnent. Cela est évident vu le développement de Java, où les performances des machines virtuelles Java (même sur des environnements matériels identiques) ont considérablement augmenté au fil des ans. Et bien sûr, il est toujours possible d'écrire du code terriblement lent dans l'environnement de votre choix. De telles affirmations comme «C ++ est dix fois plus rapide que Java» sont automatiquement fausses à moins qu'elles ne soient qualifiées et quantifiées quant aux conditions exactes qui ont été testées et comment. Il est également possible de créer un test où Java est plus rapide que C ++, tout dépend de ce que vous utilisez comme code de test et de la façon dont vous l'exécutez.

jwenting
la source
3

Parce que les langages de programmation n'existent pas pour servir les programmeurs, ils existent pour créer des programmes pour servir les utilisateurs.

Si vous avez juste besoin d'un simple petit outil personnel pour faire quelque chose une fois, cela peut être aussi lent que vous le souhaitez. Mais une fois que vous commencez à déployer vers les utilisateurs, ils se soucient de la vitesse et de la mise à l'échelle, surtout s'ils vont l'utiliser à plusieurs reprises. (Par exemple, un programme d'installation peut être lent; le programme qu'il installe vaut mieux ne pas l'être.) Et ce n'est pas seulement la langue; c'est le programme dans son ensemble. Si votre programme est lent, les utilisateurs ne l'aimeront pas. Et si vous avez de la concurrence, les utilisateurs qui n'aiment pas votre programme sont une très mauvaise chose. Donc, un langage qui contribue à ce que les utilisateurs n'aiment pas votre programme (en le ralentissant) est mauvais.

Je fais partie d'une équipe qui écrit des logiciels de contrôle pour les médias audiovisuels. Il y a de fortes chances que votre station de radio ou de télévision préférée fonctionne dessus si vous êtes aux États-Unis. La performance est l'une des choses dont nous entendons le plus souvent parler les clients. Il a été initialement écrit pour de petites opérations à une seule station, mais maintenant nous signons des réseaux de diffusion et de câblodistribution majeurs avec des centaines de chaînes, et l'échelle commence à devenir un problème. Si nous ne pouvons pas faire avancer les choses rapidement pour eux, ils remettront leurs contrats de plusieurs millions de dollars à des gens qui le peuvent, et nous nous retrouverons sans emploi. C'est pourquoi nous utilisons un langage rapide et compilé et optimisons le diable de nos bases de données.

Mason Wheeler
la source
3

Parce que plus vite c'est mieux. Le temps, c'est de l'argent. Si vous écrivez un logiciel serveur et que vous utilisez un langage de programmation plus lent, vous achetez plus de serveurs. Si vous écrivez un logiciel sous film rétractable, vous perdez des clients face à des concurrents plus rapides.

Pour tout type de logiciel durable utilisé par les gens, nous le voulons généralement le plus rapidement possible. Au niveau de l'assemblage, le délai de mise sur le marché augmente trop et n'est pas rentable. Ce sont tous des compromis. D'un point de vue commercial, il pourrait être plus rentable de laisser les pauvres programmeurs déboguer les erreurs de mémoire en C ++, le faisant pendant plusieurs mois supplémentaires, si cela signifie que le produit est plus rapide que vos concurrents.

La vitesse est donc réellement importante dans de nombreux logiciels. Les langages lents sont considérés comme "mauvais" de nos jours parce qu'ils sont vraiment trop lents (Python peut facilement être 50x - 100x plus lent, et c'est trop)

kizzx2
la source
2

Les langages de programmation existent pour servir les programmeurs.

Je ne sais pas comment vous en êtes arrivé à cette conclusion. Je dirais: les ingénieurs logiciels utilisent des langages de programmation pour leurs besoins.

Certains langages de programmation sont plus lents que d'autres, mais ce n'est pas parce qu'ils ont quelque chose de mal.

Ceci est également une déclaration floconneuse. Définissez ce que vous voulez dire en utilisant le mot «plus lent» ici. Plus lent pourrait signifier:

  1. Les programmes finaux, qui réalisent la même chose, fonctionnent «plus lentement» dans une langue par rapport à une autre.
  2. Le temps nécessaire pour créer le programme final peut être plus long (par conséquent, certains le qualifieraient de «plus lent»).

Ces deux problèmes qui me viennent à l'esprit sont également liés lorsqu'il y a une sorte de compromis entre le temps consacré au développement et aux performances.

JK
la source
3
Vous avez raison de dire que "les ingénieurs logiciels utilisent des langages de programmation pour leurs besoins". Cela ne prend en charge que la déclaration que «les langages de programmation existent pour servir les programmeurs».
Emanuil Rusev
1
Je dirais: les ingénieurs logiciels utilisent des langages de programmation pour résoudre des problèmes (qui ne sont généralement pas les leurs, mais ceux de leurs clients).
Péter Török
@Emanuil: Je ne dirais pas "un marteau sert à un bricoleur / humain", mais qu'un marteau est utilisé pour accomplir une tâche (par exemple, marteler un clou, frapper quelqu'un que vous n'aimez pas, etc.). @ Péter: Je me demande combien de personnes écrivent simplement '@Peter'. Mais si vous pouvez inventer le terme «problème» pour tout , je pense que nos déclarations sont effectivement synonymes.
JK
1

Comme tout logiciel, être lent peut être le signe de problèmes sous-jacents / d'une mauvaise conception. Le design est certes un peu zeitgeist, mais cela n'enlève rien à ce fait, les principes de conception sur lesquels il est désormais basé sont obsolètes et considérés comme `` mauvais ''.

Prenez par exemple ASP classique et ASP.net.

À M
la source
1

Quelqu'un a déclaré que «les clients adorent les logiciels qui répondent aux exigences et au budget». Eh bien, c'est vrai - mais cela a tout à fait une incidence sur les logiciels lents, et cela, presque par définition, signifie des langages de programmation (et des cadres) et des algorithmes, et une configuration plus lents. Un langage de programmation lent est probablement la partie la plus importante de tout ce qui précède simplement parce que c'est une base à partir de laquelle vous aurez du mal à changer. Si vous utilisez une base de données Oracle et avez besoin de plus de performances, vous pouvez optimiser les tables / index / etc. Facile. Si vous avez un mauvais algorithme dans votre code, vous pouvez écrire un code différent. Si votre framework est lent, vous pouvez le remplacer - ce n'est pas si facile mais c'est faisable sans tout réécrire. Si votre langue est trop lente, vous devez pratiquement recommencer.

Voir Facebook pour les tracas dans lesquels ils se sont rendus pour faire fonctionner PHP assez rapidement quand ils avaient besoin d'évoluer.

Pour le reste d'entre nous, les «exigences de performances non fonctionnelles» sont souvent inscrites dans les spécifications, en particulier pour les applications Web évolutives. Si vous ne remplissez pas la "page, l'utilisateur doit l'afficher dans les 2 secondes suivant la demande" et vous perdez le contrat (ou payez des pénalités). (vous ne vous souciez peut-être pas du temps que les utilisateurs passent à regarder le sablier, mais le client le sait, c'est un coût énorme).

Par exemple, dans un grand centre d'appels, on m'a dit qu'ils avaient déterminé que pour chaque seconde que vous pouviez économiser sur le processus de prise d'appel, 1 appelant pouvait être «réduit». C'est de l'argent réel tout à coup, et une incitation énorme pour les patrons à obtenir des logiciels plus rapides, efficaces et plus utilisables.

Il y a beaucoup de temps à s'inquiéter du fait que les programmeurs produisent du code aussi rapidement que possible (puis testent et refactorisent en permanence, lol). J'ai trouvé que ce n'était pas autant un facteur que les gens le pensent - si vous êtes un expert dans votre langue, vous pouvez le coder beaucoup plus rapidement que si vous êtes inexpérimenté. Ainsi, un développeur C ++ expert peut écrire du code plus rapidement et plus précisément qu'un développeur PHP novice. Je pense donc que devenir un expert est plus important que de choisir une langue `` facile '' et c'est pourquoi je n'aime pas le culte de la `` réécriture dans le cool, de nouvelles choses '' qui semble être partout aujourd'hui.

gbjbaanb
la source
1

Je soulignerai que la plupart des problèmes de performances existent parce que le programmeur a fait un mauvais travail, pas parce que le langage était trop lent. Vraiment, il y a beaucoup plus de choses pertinentes à se soucier de la performance que la langue que vous choisissez. Ce serait environ le numéro 1 203 407 e sur ma liste.

HLGEM
la source
0

Alors, les performances plus lentes des langages de programmation sont-elles vraiment une mauvaise chose?

Toutes choses étant égales par ailleurs, aller plus vite est une bonne chose. Après tout, personne ne veut vraiment attendre plus longtemps pour certains résultats, et une fois ce résultat obtenu, il peut libérer des ressources pour d'autres choses.

Mais tout le reste n'est pas égal. Pour commencer, il est également important de produire le bon résultat, ou du moins suffisamment. (Si des résultats complètement incorrects sont autorisés, vous pouvez en effet les produire très rapidement et ils auront une valeur exactement nulle pour quiconque.) grand compromis. Les langues de niveau supérieur ont ici un avantage sur les langues de niveau inférieur, car leur ensemble plus riche de modèles facilite généralement l'expression d'un problème complexe sans trop de détails explicites.

Il est également généralement important de gérer le coût de production du logiciel en premier lieu, d'ajouter de nouvelles fonctionnalités comme vous le souhaitez et de le faire fonctionner au fur et à mesure que les systèmes sous-jacents changent. Les langages de niveau supérieur permettent généralement un délai de programmation plus rapide, et il est très utile de maintenir les coûts de programmation dans les limites du budget. En effet, le maintien des coûts à ce niveau permet de réaliser plus de choses différentes dans l'ensemble, ce qui est généralement une bonne chose.

Le dernier point clé à noter est qu'il n'est pas nécessaire d'utiliser un seul langage et que de nombreux systèmes logiciels ont une majorité de leurs composants qui ne sont pas critiques en termes de performances. L'utilisation d'un langage de bas niveau pour produire des composants hautes performances pour les bits critiques est judicieuse, tout en laissant les parties les moins critiques à un langage de haut niveau (afin de minimiser le coût de leur production) est éminemment sensé. De plus, les fonctionnalités qui font un bon langage de bas niveau (la capacité de contrôler précisément ce que fait la machine) ne sont pas les fonctionnalités qui font un bon langage de haut niveau (la capacité d'inférer les détails à partir de descriptions beaucoup plus petites): elles sont diamétralement opposés, donc pouvoir les coupler ensemble et les utiliser pour leurs forces et éviter leurs faiblesses, c'est vraiment une bonne chose.

Quels composants devraient recevoir le traitement haute performance? L'optimisation? Mesurez- les. Profilez- les. Trouvez la vérité plutôt que de deviner. Concentrez vos efforts là où cela fait le plus de bien.

Associés Donal
la source