Existe-t-il une étude comparative de la consommation mémoire des runtimes des langages de programmation, en corrélation avec l'expressivité et les ratios de bugs de production? [fermé]

10

Il existe de nombreuses études comparatives et disponibles en ligne en ce qui concerne les performances d'exécution des applications créées dans une langue ou une autre. Certains sont dirigés par des sociétés, d'autres universitaires, d'autres simplement des rapports d'expériences personnelles.

Nous obtenons également une part décente d'études comparatives sur les effets secondaires d'un langage de programmation et de ses outils, comme:

  • temps de construction,
  • probabilité de détection de bogues en post-production,
  • puissance expressive,
  • etc...

Cependant, j'ai récemment été de plus en plus bouleversé par la consommation de mémoire de mes programmes plus que toute autre chose. Cela peut provenir du fait que, bien que la loi de Moore soit de notre côté pour les performances brutes, nous avons réalisé que d'autres goulots d'étranglement importent plus. Cela, et je n'ai pas tendance à mettre à jour mon matériel de temps en temps, et j'ai quelques "vieux" (lire Pentium 4 3,6 GHz 2005-2006 avec 4 Go de RAM) qui de nos jours ont du mal à être utilisables pour de grandes applications sans m'obligeant à me donner beaucoup de mal pour en extraire chaque bit de jus (choix de l'OS, de l'interface utilisateur, peaufinage des services et des démons, choix des applications à utiliser pour une tâche ou une autre ...). Honnêtement, parfois je déclenche topou procexppleure à la vue de la mémoire utilisée par les programmes les plus innocents.

Je peux résoudre ce problème en continuant à pousser dans la direction indiquée ci-dessus, et en essayant essentiellement de me limiter et de limiter les programmes que j'utilise (j'aime beaucoup les programmes cli pour cette raison, je suppose), mais je ne peux pas m'empêcher de penser que peut-être nous le faisons mal.

Des outils modernes pour les besoins modernes

Bien sûr, les langues de niveau supérieur sont sans doute meilleures et justifient leur valeur de poids mort. Certains choix de conception ont été faits pour de bonnes raisons (ou prétendument bien intentionnées) à l'époque, dans de nombreuses chaînes d'outils. Bibliothèques partagées, modèles de mémoire, pré-processeurs, systèmes de type, etc ... Mais certains pourraient être plus viables que d'autres avec notre matériel moderne, et je serais curieux de lire quelques études sérieuses sur la question.

Donc, ma question est, y a-t-il un pendant au jeu de référence et à d'autres qui se concentrent sur une comparaison de la consommation de mémoire d'exécution de base des langues?

Et même plus loin, y a-t-il des études qui recoupent cela avec d'autres paramètres (similaires à ce que cet article a fait, par exemple, pour d'autres critères, également basés sur le jeu de référence )?

haylem
la source
3
Pourquoi le jeu de benchmarks est-il insuffisant? C'est probablement la meilleure ressource qui existe, et elle couvre déjà la consommation de mémoire en détail.
Robert Harvey
@RobertHarvey: Il fournit des informations sur la mémoire, mais ce n'est pas pour le runtime "de base". De plus, je trouve que l'extraction d'informations du jeu de référence est plutôt mystérieuse (d'autant plus que cet article fait un travail incroyable avec ses données, bien que ce ne soit pas celui que je recherche).
haylem
1
Cela pourrait aider les personnes qui tentent de répondre à votre question si vous fournissez des informations sur le problème que vous essayez de résoudre, avec des détails tels que votre environnement d'exécution et votre consommation de mémoire souhaitée. La réponse va différer si vous écrivez un logiciel pour un environnement embarqué (où la quantité de mémoire utilisée est importante) par rapport à une machine de bureau de pointe (où la consommation de mémoire est essentiellement sans conséquence, sauf si le système logiciel est extrêmement large).
Robert Harvey
2
How much memory consumption makes you weep?30 Mo pour un onglet Chrome inactif sans extensions, 100 Mo pour CCC d'ATI, même 11 Mo pour un plugin googletalk inactif, ou 23 Mo pour un pilote d'imprimante inactif. Ces choses, et bien d'autres. L'exemple de chrome est un peu hors du parc car c'est un exemple plus complexe, mais les autres me surprennent déjà un peu.
haylem

Réponses:

7

J'ai trouvé des informations partielles, je vais donc commencer à compiler mes résultats dans ma propre réponse. S'il vous plaît ne laissez pas cela vous empêcher de fournir vos propres réponses (ou de modifier celle-ci).

Littérature existante:

  • Une comparaison empirique de 7 langages de programmation - Prechelt (2000) [ PDF ]

    Un peu daté, mais couvre une partie du matériel qui m'intéresse et donne une vue de l'utilisation et de l'expressivité de la mémoire d'exécution. Les résultats peuvent différer considérablement maintenant, mais c'est un début intéressant.

  • Vitesse, taille et fiabilité des langages de programmation - Marceau (2009) [ blog ]

  • Code utilisé, formes de temps utilisées dans le jeu de références [ u32 , u32q , u64 , u64q ]

    Bien qu'il ne couvre pas la consommation de mémoire d'exécution, le travail de Marceau est plus ou moins le genre de référence ou d'étude empirique que je serais prêt à trouver pour ce critère, en termes de contenu et de qualité. Un bon exemple de ce que je recherche, juste pour différentes mesures. Le deuxième article est une suite trouvée sur le site Benchmarks Game et qui a été publié peu de temps après (et qui fait référence) au travail de Marceau, avec des écrans plus récents et plus de langues, mais toujours sans détails de mémoire d'exécution. Chaque graphique sur ces pages puis conduit à la comparaison à la langue langue font fournir des informations de la mémoire de haut niveau bien.

haylem
la source
Le travail de Marceau est un exercice de narration d'histoires, et certaines histoires n'ont pas de sens - "L'introduction de fonctionnalités fonctionnelles tue-t-elle les performances?" ignore le simple fait que certains de ces programmes de "langage fonctionnel" peuvent ne pas utiliser de fonctionnalités fonctionnelles. Les données ont été tirées d'une incarnation précédente du jeu de repères; et a été initialement utilisé sans compréhension, il y a donc eu plusieurs cycles de correction après publication (voir les commentaires).
igouy
Pour votre «consommation de mémoire d'exécution de base», une simple comparaison des programmes «hello world» peut être aussi bonne que vous en avez besoin.
igouy
@igouy: oui. Pas de doute là-dessus, mais j'espérais ne pas avoir à expérimenter et documenter / maintenir cela moi-même :) En fait, encore moins qu'un monde bonjour serait OK, car dans certains, vous ne seriez même pas obligé de vous connecter à (ou charge) des routines d'impression, par exemple. (la désactivation des optimisations du compilateur et d'autres choses peut également être recommandée)
haylem
@igouy: concernant le travail de Marceau, je sais, j'ai lu la page, les commentaires, les pages mises à jour du jeu de référence, et j'ai été en contact avec lui. L'article est toujours une bonne référence à mon avis. Le fait qu'il soit imparfait ne lui enlève pas sa valeur et c'est toujours dans le sens de ce que j'aimerais trouver (ou me recréer).
haylem
"mais j'espérais ne pas avoir à expérimenter et documenter / maintenir cela moi-même" - regardez les mesures dans InternetArchive . Malheureusement pour vous, j'ai décidé que les mesures de mémoire pour Hello World étaient totalement trompeuses et j'ai cessé de les afficher après 2005.
igouy
1

Cela ne répond pas à la question, mais change peut-être un peu la perspective. Je garde à l'esprit la transcription du chat, pour donner le ton de cette réponse-commentaire qui fera certainement l'objet de nombreux votes négatifs.

Il y a des gens, des fournisseurs de matériel, des fournisseurs d'outils et des programmeurs soucieux de l'efficacité. Pour le moment, ce sera une préoccupation croissante pour eux et pour nous tous. Ces préoccupations sont ancrées dans les appareils mobiles, en particulier les monstres à haute puissance et engloutissant la batterie avec les plus grands écrans et les radios les plus puissantes.

Pour prendre un peu plus de recul, une partie de la raison pour laquelle nous nous trouvons dans la situation dans laquelle nous nous trouvons aujourd'hui, avec des cadres relativement massifs et un léger mépris pour l'efficacité générale, au-delà des améliorations matérielles, est hérité. La compatibilité avec les anciens systèmes nous garantit une compatibilité en plus de la compatibilité. Ce n'est pas tant la faute des temps d'exécution de haut niveau, car ce sont essentiellement les mêmes temps d'exécution qui agissent de manière assez efficace et performante lorsqu'ils sont utilisés dans un environnement d'exploitation différent (par exemple Xbox, windows mobile pre 7/8 / surface, java micro framework , etc).

Comparez l'étendue de la compatibilité d'un ordinateur de bureau avec son logiciel hérité à l'étendue de la compatibilité d'un appareil mobile.

Avec les appareils mobiles, les fabricants d'appareils s'efforcent d'assurer une certaine compatibilité, mais ils n'ont pas fait de la compatibilité un élément fondamental. Lorsque le choix est entre continuer à assurer la compatibilité et faire avancer la conception du système mobile, le système mobile avance.

Pour les ordinateurs de bureau, l'inverse semble vrai. Si un changement de rupture significatif frappe à tort les spécialistes du marketing ou les premiers utilisateurs, il pousse à plusieurs reprises les fonctionnalités nécessaires et la refonte nécessaire dans l'arrière-boutique. À un moment donné, je me souviens de rumeurs selon lesquelles, en tant qu'utilisateurs Windows, nous trouverions un système de fichiers complètement et radicalement nouveau avec Windows XP, puis dans Vista, plus tard le même pour Seven, et enfin à nouveau dans Eight, mais non, juste amélioré progressivement depuis nous l'avons vu pour la première fois sur Windows 2000? Le nouveau système de fichiers est resté longtemps assis, a été abandonné, et cependant les rumeurs décident de l'histoire après cela, je ne peux pas le dire. C'est probablement le plus gros cas connu, mais je suis certain que ce n'est pas le seul gros cas.

Même avec les tablettes et les systèmes d'exploitation mobiles les plus récents, Microsoft, qui a jadis façonné le marché, est désormais mêlé à un match à mort avec non seulement les consommateurs, mais une ombre de lui-même du département des ordinateurs de bureau. La tablette devait avoir une interopérabilité significative avec son homologue de bureau. Non, il ne pouvait pas jouer parfaitement avec lui, en raison des différences d'architecture, mais aussi en raison de la nature archaïque des fondations de bureau, il a fait des sacrifices importants.

Maintenant, Windows est certainement la cible facile de toute sorte de critique pour cette situation, mais d'autres plates-formes sont loin d'être «sans péché». Il y a beaucoup de reliques cachées dans l'écosystème Linux qui, j'en suis sûr, provoquent une grande consternation pour une amélioration systématique.

L'économie joue un grand rôle dans cette équation; la façon dont nous finançons nos calculs et nos applications sur l'un et comment ils sont financés sur l'autre suivent des schémas étonnamment différents. Là où Wintel a autrefois fortement influencé l'obsolescence, Apple et Google l'ont transformé en un calendrier presque strict. C'est plus loin que je ne le pensais, alors je vais laisser comme ça et laisser les lecteurs le prendre à partir de là.

Si et lorsque les grands fournisseurs changent d'obsolescence et de modèles de tarification, ils peuvent commencer à aller de l'avant avec des changements à plus grande échelle à un rythme plus uniforme. Ces cadres de haut niveau qui sont pilotés par les langages de plus haut ordre se rétréciront en quelque sorte, car ils seront en mesure d'accomplir leur tâche de haut niveau avec une efficacité de niveau plus bas, car la compatibilité intermédiaire inefficace et les couches de bas niveau être considérablement réduit, sinon éliminé.

JustinC
la source
Ne répond pas vraiment en effet, c'est plus comme des pensées de forme libre s'ajoutant au fond de la question :) Merci et +1 pour la perspicacité, cependant. (En outre, je tiens à préciser que je n'ai jamais eu l'intention de distinguer les systèmes Microsoft parmi les coupables. Tout système d'exploitation comme le même problème, si le modèle de mémoire du système et le format exécutable le permettent).
haylem
Ce n'est certainement pas mon intention de pousser Microsoft, mais ce sont les cas les plus faciles à voir à cet égard. Autre grand nom, les fournisseurs traditionnels sont dans le même bateau, même s'ils sont peut-être légèrement différents (bases de données de qualité industrielle et équipements de mise en réseau par exemple; combien de compromis portent-ils qui entravent autrement une amélioration significative de l'innovation et de la valeur de leurs produits sous-jacents) . Encore plus près de chez nous sur les produits que chacun de nous soutient, nous portons cette croix proverbiale à un degré ou à un autre.
JustinC