Contexte
J'ai revisité un ancien (mais excellent) site auquel je n'avais pas été depuis longtemps: le Alioth Language Shootout ( http://benchmarksgame.alioth.debian.org/ ).
J'ai commencé à programmer en C / C ++ il y a plusieurs années, mais depuis lors, je travaille presque exclusivement en Java en raison de contraintes de langage dans les projets auxquels j'ai participé. Ne me souvenant pas des chiffres, je voulais voir, en gros, à quel point Java fait face à C / C ++ en termes d'utilisation des ressources.
Les temps d’exécution étaient encore relativement bons, avec au pire Java une performance 4x plus lente que C / C ++, mais en moyenne environ (ou inférieure) à 2x. En raison de la nature de l’implémentation de Java, ce n’était pas une surprise et son temps de performance était en réalité inférieur à ce que j’attendais.
La vraie brique était l' allocation de mémoire - au pire, Java alloué:
- 52 fois plus de mémoire que C
- et 25 fois plus que C ++.
52x la mémoire ... Absolument méchant, non? ... ou est-ce? La mémoire est relativement bon marché maintenant.
Question:
Si nous ne parlons pas en termes de plates-formes cibles avec des limites strictes en termes de mémoire de travail (systèmes intégrés, etc.), l' utilisation de la mémoire devrait-elle être une préoccupation lors de la sélection d'un langage à usage général aujourd'hui?
Je demande en partie parce que je considère migrer vers Scala comme langue principale. J'aime beaucoup les aspects fonctionnels, mais d'après ce que je peux voir, cela coûte encore plus cher en mémoire que Java. Cependant, puisque la mémoire semble devenir plus rapide, moins chère et plus abondante d’année en année (il semble de plus en plus difficile de trouver un ordinateur portable grand public sans au moins 4 Go de mémoire vive DDR3), on ne pourrait pas affirmer que la gestion des ressources devient de plus en plus complexe. non pertinentes par rapport aux fonctionnalités de langage de haut niveau (ce qui peut s'avérer coûteux en termes de mise en œuvre) permettant une construction plus rapide de solutions plus lisibles?
Réponses:
La gestion de la mémoire est tout à fait pertinente dans la mesure où elle régit la rapidité d'affichage d'un élément, même s'il contient beaucoup de mémoire. Le meilleur et le plus canonique des exemples sont les jeux de titres AAA comme Call of Duty ou Bioshock. Ce sont effectivement des applications en temps réel qui nécessitent des quantités énormes de contrôle en termes d'optimisation et d'utilisation. Ce n'est pas l'utilisation en soi qui est le problème mais plutôt la gestion.
Cela se résume à deux mots: Garbage Collection. Les algorithmes de récupération de place peuvent entraîner de légers problèmes de performances, voire même bloquer l'application pendant une ou deux secondes. Généralement inoffensif dans une application de comptabilité, mais potentiellement ruineux en termes d'expérience utilisateur dans un jeu de Call of Duty. Ainsi, dans les applications où le temps compte, les langages collectés avec ordures peuvent être extrêmement problématiques. C'est l'un des objectifs de Squirrel, par exemple, qui vise à remédier au problème rencontré par Lua avec son GC en utilisant plutôt le comptage de références.
Est-ce plus un mal de tête? Bien sûr, mais si vous avez besoin d'un contrôle précis, vous l'acceptez.
la source
Tu comprends les chiffres que vous basez votre question sur?
Lorsqu'il y a une grande disparité entre ces programmes Java et C, c'est principalement l' allocation de mémoire JVM par défaut rapport aux besoins de la libc:
Programme Java 13,996 Ko :: programme C 320 Ko :: Free Pascal 8 Ko
Regardez les tâches qui nécessitent de la mémoire l’allocation de (ou utilisez des tampons supplémentaires pour accumuler les résultats des programmes multicœurs):
mandelbrot
programme Java 67 , 880KB :: programme C 30 , 880 Ko , 444 Ko
k-nucléotides
programme Java 494 , programme 040KB :: C 153 , 452 Ko
programme Java à complément inverse 511 , 484 Ko :: programme C 248 , 632 Ko
programme Java regex-dna 557 , 080 Ko :: programme C 289 , 088 Ko
programme binaire-arbres
Java 506 , 592 Ko :: programme C 99 , 448 Ko
Cela dépend si l' utilisation spécifique , pour votre approche spécifique à la résolution des problèmes spécifiques que vous devez résoudre, sera contrainte par les limites spécifiques de la mémoire disponible sur la plate-forme spécifique qui sera utilisée.
la source
Comme pour toutes choses, c'est un compromis.
Si vous construisez une application qui s'exécutera sur un poste de travail composé d'un seul utilisateur et dont on peut raisonnablement s'attendre à ce qu'elle contrôle une grande partie de la RAM sur cette machine, il peut être intéressant de sacrifier l'utilisation de la mémoire pour la vitesse d'implémentation. Si vous ciblez le même ordinateur, mais que vous construisez un petit utilitaire qui va concurrencer de nombreuses applications gourmandes en mémoire qui s'exécutent simultanément, vous voudrez peut-être être plus prudent à propos de ce compromis. Un utilisateur peut très bien utiliser un jeu qui utilise toute sa mémoire lorsqu'il s'exécute (bien que, comme le souligne World Engineer, Vous êtes inquiet si le ramasse-miettes décide de suspendre l'action périodiquement pour effectuer un balayage); interfère avec leur capacité à travailler. Si vous construisez une application Web, la mémoire utilisée sur les serveurs limite votre capacité d'évolutivité, ce qui vous oblige à dépenser plus d'argent sur davantage de serveurs d'applications pour prendre en charge le même groupe d'utilisateurs. Cela peut avoir un impact majeur sur la situation économique de l'entreprise. Vous devrez donc être très prudent avant de faire ce compromis. La mémoire que vous utilisez sur les serveurs limite votre capacité d'évolutivité, ce qui vous oblige à dépenser plus d'argent sur davantage de serveurs d'applications pour prendre en charge le même ensemble d'utilisateurs. Cela peut avoir un impact majeur sur la situation économique de l'entreprise. Vous devrez donc être très prudent avant de faire ce compromis. La mémoire que vous utilisez sur les serveurs limite votre capacité d'évolutivité, ce qui vous oblige à dépenser plus d'argent sur davantage de serveurs d'applications pour prendre en charge le même ensemble d'utilisateurs. Cela peut avoir un impact majeur sur la situation économique de l'entreprise. Vous devrez donc être très prudent avant de faire ce compromis.
la source
Cela dépend d'un certain nombre de facteurs, notamment de l'échelle à laquelle vous travaillez.
Juste pour les besoins de l’argumentation, supposons une différence de mémoire entre 30 x et d’utilisation par 2 du processeur.
Si vous utilisez un programme interactif qui prend 10 mégaoctets de mémoire et 1 milliseconde de processeur s'il est écrit en C, cela n'a aucune importance: 300 mégaoctets de mémoire et 2 millisecondes d'exécution sont normalement totalement inutiles sur un poste de travail typique, et peu susceptible de dire beaucoup même sur un téléphone ou une tablette.
La différence entre avoir besoin d'environ la moitié des ressources d'un serveur et de 15 serveurs représente toutefois une étape beaucoup plus importante, d' autant plus que la mise à l'échelle vers 15 serveurs nécessitera probablement beaucoup de travail supplémentaire au lieu de la réduire. En ce qui concerne l'expansion future, les mêmes facteurs que ceux que vous avez mentionnés tendent à suggérer qu'à moins que votre clientèle ne subisse des pertes massives. croissance , que s'il fonctionne maintenant sur un serveur, il y a de fortes chances que vous deveniez trop grand pour ce serveur. capable de remplacer cela avec un serveur plus récent sans aucun problème.
L'autre facteur à prendre en compte est le degré de différence de coût de développement que vous rencontrerez pour votre tâche particulière. À l'heure actuelle, vous regardez essentiellement un côté d'une équation. Pour avoir une bonne idée des coûts par rapport aux avantages, vous devez (évidemment suffisamment) examiner les coûts et les avantages, et non pas un seul. La vraie question est fondamentalement: "est-ce que x est plus grand que y?" - mais vous ne pouvez pas déterminer cela en ne regardant que x. Vous devez clairement y regarder aussi.
la source
La gestion de la mémoire est absolument pertinente dans le monde d'aujourd'hui. Cependant, pas de la façon dont vous pourriez vous attendre. Même dans les langues à ordures ménagères, vous devez vous assurer de ne pas avoir de fuite de référence
Vous faites quelque chose de mal si c'est votre code:
La collecte des ordures ne peut pas magiquement savoir que vous n'utiliserez plus jamais de référence à moins que vous ne la fassiez de sorte que vous ne puissiez plus l' utiliser, c.-à-d.
Cache=nullà-d. y accéder plus. Faites ce que vous voulez avec "C'est plus compliqué que cela, mais les fuites de références sont tout aussi nocives, sinon plus, que les fuites de mémoire traditionnelles.
Il y a aussi des endroits où vous ne pouvez pas installer de ramasse-miettes. Par exemple, ATTiny84 est un microcontrôleur avec 512 octets de code ROM et 32 octets de RAM. Bonne chance! C'est une extrême et ne serait probablement pas programmé autrement qu'en montage, mais quand même. Dans d'autres cas, vous pourriez avoir 1 M de mémoire. Bien sûr, vous pouvez installer un ramasse-miettes, mais si le processeur est très lent (soit par limitation, soit pour préserver la batterie), vous ne voudrez plus utiliser de ramasse-miettes car il est trop coûteux de suivre ce qu'un programmeur pourrait savoir .
Il devient également beaucoup plus difficile d'utiliser la récupération de place lorsque vous avez besoin de temps de réponse garantis. Par exemple, si vous avez un moniteur cardiaque ou quelque chose comme ça et quand il reçoit un
1port sur un port, vous devez vous assurer que vous pouvez y répondre avec un bon signal ou quelque chose dans les 10 ms. Si, au milieu de votre routine de réponse, le ramasse-miettes doit effectuer une passe et qu'il faut 100 ms pour répondre, il peut s'agir d'une personne morte. Le ramassage des ordures ménagères est très difficile, voire impossible, à utiliser lorsque les contraintes de temps doivent être garanties.Et bien sûr, même sur du matériel moderne, il existe des cas où vous avez besoin de 2% de performances supplémentaires sans vous soucier des frais généraux d'un ramasse-miettes.
la source
Comme Donald Knuth l'a dit, l'optimisation prématurée est la racine de tout mal. À moins que vous n'ayez une raison de croire que la mémoire sera le goulot d'étranglement, ne vous inquiétez pas. Et étant donné que la loi de Moore offre toujours une capacité de mémoire accrue (même si nous n’obtenons pas de code mono-threadé plus rapide), il y a tout lieu de croire que nous aurons encore moins de mémoire à l’avenir. sont aujourd'hui.
Cela dit, si l'optimisation n'est pas prématurée, faites-le. Je travaille personnellement sur un projet en ce moment où je comprends très bien l'utilisation de ma mémoire, j'ai besoin d'un contrôle précis, et un balayage des ordures me tuerait. Je fais donc ce projet en C ++. Mais ce choix semble être un événement tous les plusieurs années pour moi. (J'espère que dans quelques semaines, je ne toucherai plus au C ++ avant quelques années.)
la source
Pour les personnes confrontées à un "big data", la gestion de la mémoire reste un problème majeur. Les programmes d’astronomie, de physique, de bioinformatique, d’apprentissage automatique, etc. doivent tous traiter des jeux de données de plusieurs gigaoctets. Ils sont beaucoup plus rapides si les parties pertinentes peuvent être conservées en mémoire. Même fonctionner sur une machine avec 128 Go de RAM ne résout pas le problème.
Il y a aussi la question de tirer parti du GPU, bien que vous classeriez peut-être cela comme un système embarqué. L’essentiel de la réflexion sur l’utilisation de CUDA ou OpenCL se résume à des problèmes de gestion de la mémoire lors du transfert de données de la mémoire principale vers la mémoire du processeur graphique.
la source
Pour être honnête, beaucoup de Java s’exprime dans des schémas d’explosions de classe véritablement et inutilement qui assassinent juste la performance et la mémoire de porc, mais je me demande combien de cette mémoire est juste la JVM qui, en théorie (heu), vous dirigez le même application dans plusieurs environnements sans avoir à en réécrire complètement de nouveaux. Par conséquent, la question du compromis en matière de conception est la suivante: "Quelle est la valeur de la mémoire de vos utilisateurs pour un tel avantage en termes de développement?"
Ceci est, IMO un compromis parfaitement utile et raisonnable à considérer. Ce qui me fait chier, c’est que les PC modernes sont si puissants et la mémoire si peu chère que nous pouvons complètement ignorer ces inquiétudes, ces fonctionnalités et ce code démesurés, et être paresseux en matière de choix au point de donner l’impression de beaucoup de choses. Je fais sur un PC Windows maintenant, prend tout aussi longtemps que dans Windows 95. Sérieusement, Word? Combien de nouvelles conneries dont 80% des utilisateurs ont-elles réellement besoin auraient-elles éventuellement pu ajouter d'ici 18 ans? Nous sommes presque sûrs que nous avions des correcteurs orthographiques, non? Mais nous parlions de mémoire qui n’est pas forcément rapide si vous en avez beaucoup, alors je m'éloigne du sujet.
Mais bien sûr, si vous pouvez obtenir l'application réalisée en 2 semaines au prix de peut-être quelques mégaoctets supplémentaires au lieu de 2 ans pour obtenir la version à besoins quelques-uns seulement-K, il vaut la peine de se comparer à quelques méga-octets ( Je devine) 4-12 concerts sur la machine des utilisateurs moyens avant de se moquer à l'idée d'être si bâclée.
Mais qu'est-ce que cela a à voir avec Scala au-delà de la question des compromis? Le simple fait de ramasser les ordures ne signifie pas que vous ne devriez pas toujours essayer de penser au flux de données en termes de contenu dans les portées et les fermetures, et de savoir si elles doivent être laissées en place ou utilisées de manière à ce qu'elles le soient. désalloué par GC lorsqu'il n'est plus nécessaire. C’est quelque chose que même les développeurs Web de l’UI JavaScript ont dû prendre en compte et qui, espérons-le, continueront à se répandre dans d’autres domaines problématiques tels que le cancer à haute performance (que vous auriez tous dû tuer avec Flash ou Applets ou quelque chose lorsque vous en avez eu la chance). que nous sommes.
la source
La gestion de la mémoire (ou contrôle) est en fait la principale raison pour laquelle j'utilise C et C ++.
Pas de mémoire rapide. Nous examinons encore un petit nombre de registres, par exemple un cache de données de 32 Ko pour L1 sur i7, 256 Ko pour L2 et 2 Mo pour L3 / cœur. Cela dit:
Utilisation de la mémoire à un niveau général, peut-être pas. Je suis un peu peu pratique dans la mesure où je n'aime pas l'idée d'un bloc-notes prenant, par exemple, 50 mégaoctets de DRAM et des centaines de mégaoctets d'espace sur le disque dur, même si j'ai encore beaucoup à faire. Cela fait longtemps que je suis dans le coin et cela me semble bizarre et assez dégoûtant de voir une application aussi simple prendre relativement autant de mémoire pour ce qui devrait être faisable avec des kilo-octets. Cela dit, je pourrais peut-être vivre avec moi-même si je rencontrais une telle chose si elle était toujours agréable et réactive.
La raison pour laquelle la gestion de la mémoire est importante pour moi dans mon domaine n’est pas pour autant réduire l’utilisation de la mémoire en général. L'utilisation de centaines de mégaoctets de mémoire ne ralentira pas nécessairement l'application de manière non triviale si aucune de ces mémoires n'est fréquemment utilisée (par exemple: uniquement en cliquant sur un bouton ou sous une autre forme de saisie utilisateur, ce qui est extrêmement rare, à moins que vous ne le fassiez. parlent de joueurs coréens de Starcraft qui pourraient cliquer sur un bouton un million de fois par seconde).
La raison pour laquelle il est important dans mon domaine est de garder la mémoire serrée et rapprochée (par exemple, une boucle sur chaque image) dans ces chemins critiques. Nous ne voulons pas avoir une mémoire cache manquée chaque fois que nous accédons à un élément sur un million seulement qui doit être accessible en boucle à chaque image. Lorsque nous déplaçons de grandes quantités de mémoire dans la hiérarchie, disons des lignes de cache de 64 octets, il est vraiment utile que ces 64 octets contiennent tous des données pertinentes, si nous pouvons adapter plusieurs éléments de données à ces 64 octets, et si nos modes d'accès sont tels que nous les utilisons tous avant l'expulsion des données.
Les données fréquemment consultées pour le million d’éléments pourraient ne couvrir que 20 mégaoctets, même si nous avons des giga-octets. Il y a toujours un monde de différences dans les taux de trame qui se superposent à chaque donnée tracée si la mémoire est serrée et rapprochée pour minimiser les erreurs de cache, et c’est là que la gestion / le contrôle de la mémoire est si utile. Exemple visuel simple sur une sphère de quelques millions de sommets:
Ce qui précède est en réalité plus lent que ma version mutable car il teste une représentation de structure de données persistante d’un maillage, mais mis à part cela, j’avais du mal à atteindre de telles vitesses de trame même avec la moitié de ces données (certes, le matériel est devenu plus rapide depuis mes difficultés ) parce que je n’ai pas eu l’impression de minimiser les erreurs de cache et l’utilisation de la mémoire pour les données de maillage. Les maillages font partie des structures de données les plus délicates que j'ai traitées à cet égard, car elles stockent une grande quantité de données interdépendantes devant rester synchronisées telles que des polygones, des arêtes, des sommets, autant de cartes de texture que l'utilisateur souhaite attacher, des poids, etc. cartes de couleurs, jeux de sélection, cibles de morphing, poids des arêtes, matériaux polygonaux, etc. etc. etc.
J'ai conçu et mis en œuvre un certain nombre de systèmes de maillage au cours des deux dernières décennies et leur vitesse était souvent très proportionnelle à leur utilisation en mémoire. Même si je travaille avec tellement, beaucoup plus de mémoire que lorsque j'ai commencé, mes nouveaux systèmes de maillage sont 10 fois plus rapides que ma première conception (il y a presque 20 ans) et dans une large mesure car ils utilisent environ 1 / 10ème des années précédentes. la mémoire. La version la plus récente utilise même la compression indexée pour stocker le plus de données possible. Malgré la surcharge de traitement liée à la décompression, la compression a réellement amélioré les performances car, encore une fois, nous avons si peu de mémoire rapide précieuse. Je peux maintenant adapter un million de polygones avec des coordonnées de texture, des plis de bords, des affectations de matériaux, etc., ainsi qu'un index spatial correspondant d'environ 30 mégaoctets.
Voici le prototype modifiable avec plus de 8 millions de quadrangles et un schéma de subdivision multires sur un i3 avec un GF 8400 (datant d’il ya quelques années). C'est plus rapide que ma version immuable mais je ne l'utilise pas en production car j'ai trouvé la version immuable tellement plus facile à maintenir et les performances ne sont pas si mauvaises. Notez que le cadre filaire n'indique pas les facettes, mais les patchs (les fils sont en fait des courbes, sinon tout le maillage serait noir), bien que tous les points d'une facette soient modifiés par le pinceau.
Donc de toute façon, je voulais juste montrer une partie de ce qui précède pour montrer des exemples concrets et des domaines dans lesquels la gestion de la mémoire est si utile et aussi, espérons-le, afin que les gens ne pensent pas que je parle juste de mes fesses. J'ai tendance à être un peu irrité lorsque les gens disent que la mémoire est tellement abondante et bon marché, parce que cela parle de mémoire lente comme la mémoire DRAM et les disques durs. Il est encore si petit et si précieux quand on parle de mémoire rapide, et la performance pour des chemins véritablement critiques (c'est-à-dire, cas commun, pas pour tout) est liée au fait de jouer avec cette petite quantité de mémoire rapide et de l'utiliser aussi efficacement que possible. .
Pour ce genre de choses, il est vraiment utile de travailler avec un langage qui vous permet de concevoir des objets de haut niveau comme le C ++, par exemple, tout en pouvant stocker ces objets dans un ou plusieurs tableaux contigus avec la garantie que la mémoire de tous ces objets seront représentés de manière contiguë et sans surcharge de mémoire inutile par objet (ex: tous les objets ne nécessitent pas de réflexion ou d'envoi virtuel). Lorsque vous vous déplacez dans ces domaines critiques en termes de performances, il devient réellement plus productif de disposer d'un tel contrôle de la mémoire, par exemple en manipulant des pools d'objets et en utilisant des types de données primitifs pour éviter les frais généraux d'objet, les coûts de GC, et de conserver un accès fréquent à la mémoire. ensemble contigu.
Ainsi, la gestion / le contrôle de la mémoire (ou son absence) est en fait une raison dominante dans mon cas pour choisir la langue qui me permet le plus efficacement de résoudre les problèmes. J'écris définitivement ma part de code qui n'est pas critique en termes de performances, et pour cela, j'ai tendance à utiliser Lua, qui est assez facile à intégrer depuis C.
la source