C’est un vrai problème : avec la croissance continue des usages numériques, les applications représentent une part importante de la consommation énergétique. Au-delà de leur nombre et de leurs usages, la question de leur conception préoccupe un nombre croissant d’observateurs… et de chercheurs. Au CNRS, une équipe travaille à les rendre plus sobre. Y compris dans le cloud.
Le sujet n’est pas nouveau, mais il prend de l'ampleur. Nous l’avons abordé à plusieurs reprises, notamment quand nous nous étions penchés sur le poids des applications. Certes le poids élevé d’une application engendre des transferts plus longs et demande un plus gros espace de stockage, mais la question qui se posait était surtout de savoir ce qui nécessitait tant de place.
Dans notre article, les applications de Facebook étaient très représentatives du problème soulevé : l’utilisation intensive des cadriciels (frameworks) externes aboutissant non seulement à ce que le Journal du CNRS nomme « obésiciels », mais également à un manque flagrant d’optimisation, donc à une consommation élevée d’énergie.
Comme l’indique Romain Rouvoy, chercheur en génie logiciel au Centre de recherche en informatique, signal et automatique de Lille (CRIStAL), la prise de conscience est récente : « En 2010, alors que nous travaillions dans le cadre d’un projet baptisé EcoHome, qui visait à mieux comprendre la consommation des box internet domestiques afin de mieux la maîtriser, nous avons observé que les logiciels étaient grandement responsables de la consommation énergétique globale des systèmes informatiques ».
Avec son équipe, il travaille donc sur cette problématique.
Mesurer et recommander
Le chercheur cite le paradoxe de Jevons (aussi appelé « effet de rebond »), « selon lequel le développement de technologies plus efficaces, permettant en théorie de faire des économies d’énergie, augmente paradoxalement la quantité d’énergie consommée ». Pourquoi ? Essentiellement parce que cette efficacité est contrebalancée par l’explosion des usages ou gommée par de mauvaises habitudes dans le développement.
C’est précisément le cas pour les applications. L’augmentation continue de la puissance des appareils et les débits sans cesse plus importants apaisent les craintes liées à l’attente. Pour une partie des entreprises, c’est un raccourci et un gain de temps : plus besoin de travailler autant sur l’efficacité du code. Il n’y a pas de hasard : la puissance des batteries a beau augmenter, la fréquence des recharges n’a que peu évolué.
« La première étape pour relever un tel défi est d’estimer la consommation énergétique des programmes actuels et d’identifier les portions de code informatique particulièrement consommatrices. C’est la pierre angulaire dans la conception de systèmes plus efficients », a indiqué le chercheur. Il a même développé, dès 2012, une API pour mesurer la consommation des programmes afin d’estimer en temps réel la quantité d’énergie nécessaire au fonctionnement d’une machine.
Il estime cependant qu’il faut des outils beaucoup plus puissants pour intégrer de nouvelles habitudes. La question du langage est par exemple centrale : « […] pour une même fonctionnalité, la consommation peut varier d’un facteur 100, selon le langage informatique choisi (Java, Python, JavaScript, etc.) ». On pourrait alors recommander un langage plus qu’un autre selon les cas, avec toujours cette question : comment parvenir au résultat souhaité en consommant le moins d’énergie possible ?
À ce sujet, le CERN expliquait récemment que, sur son réseau mondial, « les moindres gains d'efficacité dans un code très utilisé peuvent avoir un grand impact » sur les ressources utilisées. Le contraire est aussi vrai : un programme peu ou mal optimisé peut décupler la consommation.
Le cloud, l’autre gros morceau de l’équation
La prise en compte d’une consommation globale ne peut se faire sans aborder les serveurs qui accompagnent souvent une application. Beaucoup d’entre elles fournissent en effet un service qui réclame des calculs basés sur des données hébergées et, bien sûr, des communications dans les deux sens.
La consommation des centres de données est une problématique connue. Les grandes entreprises américaines – Google, Apple, Facebook, Amazon, Microsoft… - ont pris l’habitude depuis des années de concevoir les nouveaux accompagnés d’un mélange de sources en énergies, certaines renouvelables, d’autres compensées, etc.
Dans ce domaine, la marge d’amélioration semble conséquente, notamment sur la manière dont un centre est géré, plus précisément comment les ressources sont réparties en fonction des logiciels. Le CNRS se penche sur le sujet depuis longtemps et l’avait d’ailleurs abordé il y a quelques mois, dans l’optique de « verdir les centres de données ».
Les travaux de Romain Rouvoy sont cependant axés sur le logiciel. En 2017 par exemple, il avait participé au développement d’un ordonnanceur (scheduler) ayant abouti à une baisse moyenne de 23 % de la consommation d’un centre de données, en gardant les mêmes performances. Depuis le début de l’année, il travaille surtout à « l’élaboration de recommandations précises sur les programmes informatiques et les configurations les plus adaptés pour diminuer la consommation énergétique des logiciels du cloud ». Ce programme, nommé Distiller, est financé par l’Agence nationale de la recherche à hauteur de 664 580 euros.
Une émulation sur la problématique
Anne-Cécile Orgerie, de l’Institut de recherche en informatique et systèmes aléatoires (Irisa) de Rennes, travaille de son côté sur une utilisation plus intelligente des énergies renouvelables. « Un de nos buts majeurs est de déterminer s’il est possible de développer des codes permettant de faire en sorte que l’exécution des applications de smartphones sollicitant les serveurs d’un centre de données, et ne nécessitant pas d’être réalisées rapidement (comme les sauvegardes), soit retardée et effectuée seulement quand il y a production de l’énergie renouvelable (la journée, par exemple, pour le solaire) », explique-t-elle.
Le CNRS pointe en effet que l’écoconception logicielle crée une véritable émulation un peu partout. Les équipes à s’y pencher sont de plus en plus nombreuses, et l’IA pourrait d’ailleurs jouer un rôle important. « Grâce à différents algorithmes d'intelligence artificielle, nous pourrons étudier l'ensemble des couches logicielles d’une application cloud, et raisonner plus globalement pour proposer des configurations optimisées de bout en bout », ajoute ainsi Romain Rouvoy.
Comme toujours cependant, les progrès réalisés en amont n’auront de réel impact que s’ils deviennent de nouvelles habitudes pour les développeurs et que les outils utilisés s’adaptent en conséquence. Au-delà du choix du langage, il n’y aurait rien d’étrange à ce qu’un environnement de développement intégré recommande un langage spécifique en fonction du type de projet choisi, comme il existe déjà de nombreuses recommandations, notamment pour la sécurité. Libre à chacun d’en tenir compte ou non.
Commentaires (43)
#1
Sur mon portable pro, quand j’ouvre le navigateur Edge, je me retrouve sur un page “personnalisée” avec de jolie fond d’écran et parfois des fonds d’écran animés (type vidéo de cascade d’eau ou autre).
Sa sert à rien mis à part faire tourner le ventilo du portable au taquet…
Sur la nouvelle appli mobile de la SNCF, je dois faire 3 fois la même recherche sur des écrans consécutifs avant d’avoir l’affichage de TGV correspondant à mes critères…
ergonomie 0, efficience 0 et je dois mettre 2 fois plus longtemps à réserver un train par rapport à l’application précédente !
Et niveau pro, a chaque nouvelle application remplaçant une vieillissante, même constant : je fait les chose en bcp plus de clic et de temps…. A en regretter les interfaces design année 2000 qui piquent les yeux…
Pour ce qui est du stockage informatique, c’est tellement simple d’accumuler : on ne voit pas la montagne de papier grossir et envahir tout le bureau !
Tient une idée à creuser pour les entreprises: un truc connecté en USB qui augmente de volume proportionnellement à la consommation de stockage de l’utilisateur : un genre de wall of shame pour les collègues !!!
(Genre un gros ballon de baudruche calibré pour exploser à 3 Go d’espace consommé, avec un bruit d’explosion capable de réveiller un open space de 120 personnes !)
#2
J’ai du mal à avoir l’innovation ici et j’ai l’impression qu’on ouvre des portes .. déjà ouvertes. J’ai plus l’impression d’un rappel des principes logiques et de bases de l’informatique quand elle était encore aux mains “d’artistes” pour qui l’optimisation, l’efficacité d’un code était vu comme positives et non une entrée négative sur le tableur Excel.
Mais ça demande du temps et des compétences. Et même le CNRS ne les valorisent pas en interne, alors en dehors…
Quand au cloud, je pense que ça limitation est au contraire un moyen d’économiser de l’énergie. Car en plus des raisons cités dans l’article, à ton vraiment besoin de stocker l’intégralité de nos photos sur un cloud ? En sachant qu’elles seront utilisés pour faire du profilage marketing ou entraîner des réseaux de neurones énergivores. Alors oui, ça fait stratégie backup 3-2-1 mais est-il nécessaire de forcément les mettre dans un cloud qui va les scanner et les utiliser à nos insu ?
Pour l’IA, je suis vraiment déçu de voir cette argument sorti comme une solution technologique à nos problèmes. L’IA n’est pas la panacée, ce n’est pas l’IA qui résoudra les problèmes qu’on a crée.
Leur méthode d’analyse vont être énergivores pour arriver à la même conclusion qu’un humain simplement en regardant le code.
L’écoconception (en dehors de bullshit de l’IA [on demande des financement Dr. Orgerie ?
Pas de panique, je sais très bien ce que vous traversez.]) ne sera vraiment utile que quand elle sera considérait comme “positive” en terme financier, et ça passe soit par du greenwashing soit par de vrais mesures juridiquement contraignantes (Vous le sentez le bullshit ?). Mais encore une fois rien de novateur sous le Soleil.
Si le CNRS veut se faire une verte vertue qu’il commence par donner l’exemple. Pour avoir bossé chez eux, voici les pistes de réflexions que je propose (si jamais Petit passe dans le coin) : Rénover les passoires thermiques (15 °C dans les bureaux en hiver, chauffage H24 pour éviter de geler ou des benchmark de openssl pour forcer les PC à nous tenir les doigts au chaud. 40 °C en été, les PC en PLS tout comme nos cerveaux), virer cette chiasse de Windows qui passent son temps à faire du profilage et de l’espionnages car moins de cycles CPU, plus de C-States du CPU. Arrêter de confier son parc informatique à des fournisseurs digne de marchands de tapis (tu sais le i9 pour faire de la bureautique
) tout comme de tout sous-traiter avec SSII pour des choses qui peuvent se faire en interne en changeant le code du travail pour conserver les bons éléments.
A la lecture de l’article, j’ai l’impression que le CNRS essaye de trouver des rustines pour maintenir encore vivant un dinosaure en soin palliatif plutôt que de chercher à innover pour proposer un modèle différent de consommation
.
#3
Plusieurs choses pour expliquer cela à mon sens :
Sans même parler d’optimisation, simplement savoir programmer (pas juste être capable d’aligner 2 lignes de code mais bien de connaître le métier) permettrait déjà de résoudre nombres de problèmes.
Car là où je rejoins l’article, c’est qu’avant, les ressources étaient limités (CPU, RAM, disque dur). Il fallait donc faire avec et une personne sachant bidouiller du code se retrouvait vite limitée par son propre manque de connaissance. Aujourd’hui, cette barrière n’existe malheureusement plus…
Pour donner quelques exemples de mon expérience professionnel :
Je ne dis pas que le choix du langage n’est pas sans conséquence sur les performances d’un programme. Je pense seulement qu’aujourd’hui, le problème n’est pas tant le langage utilisé, que les compétences de ceux qui développent. Si la personne derrière ne sait pas ce qu’elle fait, elle peut toujours changer de langage, cela ne changera absolument pas le problème de performance…
#3.1
gros +1 de manière générale
si je me suis pas planté, un traitement (insertion en base, on me fourni un csv de ~ 100mo) dont on m’a dit qu’il prenait 4 à 6h (je sais pas d’où provenaient les données, ni la durée de génération du csv actuel), mais il parait qu’il y avait des timeout d’autres traitements à cause de celui-là, je l’ai ramené à 20 minutes (et c’est encore optimisable, là j’ai fait le bourrin en écrasant des valeurs … même si elles changent pas) et les appels à la base font au max quelques secondes histoire de pas bloquer à cause d’une requête monolithique qui tourne pendant des plombes
#3.2
Globalement, les ESN/ grosses boites d’expert, c’est d’la merde parce que 90% de leurs experts ne savent pas ce qu’ils font. Résultat : des applications anti-optimisé. Parfois on pourrait croire de manière volontaire tellement c’est gros. Et une fois que c’est livré, le commercial va refuser de piocher dans son
bonusbudget pour faire des passes d’optimisation par des gens compétents même si le client se plaints.+1 sauf pour les “effets de mode”. Le problème, ce sont les commerciaux qui utilisent ces termes comme des cons sans penser aux implications techniques (ni aux capacités de leurs équipes).
Le cloud, dans le sens très large Azure/Aws/Google cloud ou tout autre petit fournisseur, permet de faire bien plus écoresponsable/green/sobre qu’un système “classique” ou tu as des serveurs physiques à toi. Le concept de microservice et dérivées (serverless & toute autre folie) permet surtout de tirer encore plus parti de ce que le cloud t’offre comme flexibilité.
Et le NoSql à de vrais intérêts s’ils sont bien utilisés pour le cas d’usage qui leur correspond.
Marrant, ayant été quelques fois du côté “Expert”, je me suis retrouvé à travailler avec des machines sous-dimensionné vendu par les commerciaux, plutôt que l’inverse
Une fois, on nous a donné un budget de 30 cpu et 60go de ram. Dessus, on devait installer la “code factory” (comprendre gitlab on-premise, jenkins sonar & co), ainsi que 4 environnements d’intégration pour les différentes étapes de validation (testing, QA, pre-prod et je sait plus quoi). Dans chaque environnement, c’était entre 4 à 8 serveurs applicatifs.
Bien entendu, le restant pourra être laissé au devs qui en auraient besoins.
#4
Tout à fait d’accord avec ces 3 points, plus:
J’ai du mal à voir la plus-value des applis web actuelles face à des applis en VT100 souvent. Peu d’applis web arrivent aux même fonctionnalités que celles qu’on trouvait sous Word sous DOS, Multiplan ou dbase - y compris en comptant Excel online auquel il manque encore des fonctionnalités.
Et les fonctionnalités sont atteintes au prix d’une consommation de ressources exceptionnelles.
Exemple habituel: comment se fait-il qu’il faille utiliser des dizaines de Mo de RAM (voire des centaines) pour afficher des SMS ou des mails? L’affichage d’une page de SMS consomme 10Mo d’un coup, pour m’afficher 66 caractères…
Où sont passés les développeurs qui savaient scanner et manipuler une page A4 (190Mo) sur 4Mo de RAM?
#5
Comment rendre une application moins énergivore:
Vous allez voir, virer les apps de merde ça économise incroyablement la batterie.
La technologie n’a pas vraiment de problème en soit. Le problème ce sont les entreprises et les développeurs.
edit: pompé sauvagement à seb
#6
Ils existent toujours, mais ils sont moins mis en lumière et sont plus sur des niches.
#7
Pour en rajouter une couche, si le métier de dev était un minimum valorisé, on n’en serait pas là.
) car être scrum master, 1/ c’est valorisé et moins stressant, n’ayant pas un petit chef hargneux sur le dos 2/ c’est mieux payé. La faute aux trop nombreuses entreprises qui d’un côté se plaignent d’une pénurie de bons devs, et de l’autre qui font tout pour ne pas garder leurs devs, et refusent de les former. La plupart des projets sont donc montés par des équipes “expertes avec 1 ou 2 ans d’xp”, et on s’étonne que ça foire. Parfois on leur colle un lidl-dev, pardon un lead-dev, mais il ne peut pas faire grand chose à lui seul et, étant “garant de l’excellente de l’équipe” (entendu mainte fois), on le décapite en place publique au premier soucis.
Aujourd’hui, tout est fait (en France) pour pousser les devs vers d’autres métiers, à savoir chef de projet, manager, scrum master, etc. Les devs débutent leur carrière en se disant “passionnés”, et quittent le métier 2~3 ans plus tard (bah, et ta passion ?
Fort heureusement tous les pays n’ont pas cette culture, mais pour le cas de la France, on (enfin vous ^^) est vraiment mal barrés.
#7.1
Assez d’accord, surtout sur le fait que monter = arrêter de dev, et faire du mamagement, on ne sait que valoriser une personne de cette manière en France, au détriment de la technique…, donc, on se retrouve qu’avec des jeunes dev sortis des écoles, qui codent majoritairement avec stackoverflow…
#8
garant de l’ *excellente -> excellence, bien évidemment
#9
Quand on voit les préco des prestataires pour les VM… C’est souvent 4x le besoin voire plus. Sans compter que non, les composants ne peuvent pas fonctionner sur la même machine, il faut plusieurs serveurs…
La supervision, le diagnostic et la projection sont souvent des domaines totalement inconnus des ‘experts’ qu’on paye une blinde.
J’ai rarement vu un ‘expert’ qui trouve la cause d’un problème de perfs, que ce soit sur du réseau, du san, du sharepoint ou du sql. C’est toujours moi qui trouve (mais j’y passe du temps et je lis)
#10
Venant du dev embarque du début des années 2000, je connais extrêmement bien cette problématique et j’ai toujours refusé de céder à la facilité contrairement aux étudiants que je retrouve dans mes TDs, c’est consternant d’entendre encore et toujours :
De nombreux reconvertis sont également une plaie et font bien plus de mal que de bien au métier.
Coté poids des apps, ce n’est quand même pas compliqué de faire quelque chose de sérieux, certes il va falloir y passer plus de temps, coder des choses soit même pour éviter d’utiliser une lib de 10Mo pour un truc qui ne ferait que 500 lignes de codes nécessaires. On y gagne en rapidité et généralement en stabilité. J’ai des apps qui tournent depuis 12 ans et + sans que j’y retouche et elles fonctionnent toujours. Je mentirais si je disais que je n’ai jamais utilisé de librairies annexes, mais j’essais toujours de les réduire au maximum.
J’essaie également d’expliquer le codage objet en couches hiérarchiques mais c’est compliqué, c’est peut être trop abstrait pour ces nouveaux à l’égo chargé par des écoles qui font de la masse. Ces loulous savent tout juste utiliser quelques outils et se pensent expert dev !
J’ai découvert avec stupeur qu’à l’école 42, ils ne font que se corriger les uns les autres, il n’y a pas de référant technique sénior ou autre, j’espère que ça a/va changer.
Ça c’est un vrai problème et c’est une demande des mes étudiants, malheureusement, le programme (edu nat) n’a jamais pu évoluer dans ce sens dans l’université dans laquelle j’interviens. Donc sur ce point ce n’est pas vraiment de leur faute, mais ils ne font pas vraiment d’effort non plus pour se former eux même.
Tu parles de langage de dev ici ? Si oui, il m’arrive de faire du front et du back avec le même langage pourtant :) mais surement pas Node.Js je te rassures !!
Quand tu dev pour un appareil avec 15Mo de mémoire partagé stockage/ram, tu prends de bonnes habitudes.
C’est en effet pas bien compliqué de stocker certaines infos qui ne changent pas ou trop peu pour éviter de multiplier les appels fichiers/web, mais encore un fois c’est une habitude que les nouveaux n’ont pas. Ils pensent tous que tout le monde dispose d’une machine de guerre et/ou de la fibre. Il faudrait déjà commencer par réussir à comprendre que l’utilisateur n’utilise pas qu’une seule appli à la fois, une app bourrin + une autre + une autre, etc, ça sature vite.
Je me sent vieux d’un coup !
#11
Java + les bricoleurs.
Topic résolu.
#12
Pourquoi nodejs n’aurait jamais dû exister ? (C’est juste pour savoir)
#13
15 Mo ? Mais c’est Byzance !
je retourne à mes mcu avec 256k de flash et 32k de ram… (c’est le luxe, on a abandonné les 8 bits).
Pour l’article, c’est effectivement dommage qu’il fasse complètement l’impasse sur la question du coût écologique du tracking dans les apps.
#13.1
Je ne suis pas si vieux en fait
Je suis arrivé tard dans le domaine mais assez tôt pour prendre les bonnes habitudes. Ici on parle de terminaux type lecture optique à écran graphique arrivés dans les années 90. Aujourd’hui ça ne choque pas grand monde d’avoir une app de news qui fait 80-100Mo pour une empreinte ram de plusieurs centaines de Mo et autant sur le disque
#14
Je ne pense pas que ce soit lié directement : les contraintes sont similaires en interne / externe: faire au plus vite, faire pour pas cher (dans l’immédiat car à long terme il vaut mieux faire bon du premier coup)
Malheureusement un gros +1 sur l’ensemble du topic : il n’y a quasi plus de formation logiciel théorique (ex : complexité des algo de parcours d’arbre…) les “dev” utilisent des frameworks et des librairies et font du collage de briques toute prête sans rien comprendre.
Je discutais hier avec un collègue (jeune ingénieur) de l’intérêt des Maths dans l’info. J’ai eu une fois à utiliser une loi de Poisson pour un algo de réappro de boutiques pour un client (sous SAP)
Sa réponse m’a scotché :
Un jeune aurait googler le cahier des charges en espérant trouver un code à copier/coller depuis stackoverflow…
#15
Pour plein de raisons :
#15.1
Merci
#16
J’ai Slack d’ouvert. Une fenêtre, 3 zones :
Consommation RAM : 300Mo.
#17
#18
Je suis le premier à critiquer, mais je vais tempérer un peu: la consommation RAM n’est pas facile à évaluer réellement (notamment sous Windows et Linux - android il gère pas la RAM en fait)
On peut avoir l’impression que la RAM est prise, mais elle est souvent libérée en cas de pression RAM.
C’était le syndrôme Vista: Vista chargeait beaucoup au démarrage, la RAM était notée utilisée, mais elle était libérée en lançant n’importe quel outil.
A l’inverse, sous Linux on a eu une belle période où on se voyait montrer comment des DE consommaient peu de ressources: c’était vrai, mais dès qu’on lançait une appli GTK ou Qt, tout l’environnement correspondant démarrait, et là ça consommait plus que Gnome ou KDE. Pire si on lançait une appli GTK et une appli Qt.
Par contre, j’ai bossé des années sur un VAX (100MHz, 72Mo de RAM, quelques go de disque, 60 utilisateurs connectés simultanés): franchement quand dans les années 2000-2015 tu vois ce genre de machine faire tourner la logistique d’une boite qui fait 400M€ de CA, tu ne peux que respecter :) (même si ça rame, ça ne plante jamais - tu peux tout lancer en aveugle et attendre que ça sorte avec une confiance tout aussi aveugle)
Bon, on avait des Alpha déportés quand même (1GHz, 1Go de RAM). Niveau de qualité de service offert >>> n’importe quelle appli Windows qu’on a pu tester pendant cette période…
#19
Les jeux vidéo rentrent ans le cadre des applis ?
#20
Je ne vais pas m’amuser à défendre nodejs bec et ongles, mais sur ce point, Javascript n’a le monopole ni de l’héritage par prototype, ni du fonctionnement asynchrone ; j’estime que les résultats catastrophiques sont plutôt dus à un manque de formation/connaissances de la part des développeurs.
Je pense également, contrairement à JM Jancovici, qu’on ne peut pas utiliser des langages “rapides” © partout : il est tout à fait possible d’écrire un backend en assembleur plutôt qu’en Python par exemple, mais ce qui est gagné en performances énergétiques sera contrebalancé par le coût de maintenance du logiciel (exemple capilotracté, entendons-nous bien
)
#21
Je suis d’accord. Le paradigme de gestion de la RAM a changé, notamment avec les langages à base de ramasse-miettes, où on exploite la mémoire tant qu’il y en a et on la libère si elle est demandée. Mais entre la théorie et la pratique…
Exemple : sur ma machine de dev, il m’arrive de ne pas pouvoir lancer une machine virtuelle, faute de mémoire vive disponible (car oui, la machine virtuelle a le bon gout de ne pas vouloir utiliser le swap pour éviter les problèmes de performance, en tout cas au démarrage !).
Dans ces cas là, je regarde les applications que j’ai d’ouvertes et celles qui consomme le plus. A chaque fois, c’est :
Dans les applications, toutes utilisent le moteur V8 (V8 est issue de Chrome, Visual Studio Code et Slack sont des applications basées sur Electron (donc utilisent V8) et Visual Studio a je ne sais combien de process nodejs en cours d’exécution (donc du V8 également).
Je ferme Slack et Visual Studio Code (souvent ça suffit). Je peux allumer ma machine virtuelle. Je peux ensuite relancer les applications. Et tout fonctionne. Elles consomment souvent moins qu’avant, car la mémoire est plus vite saturée (je tourne à 95% de mémoire utilisée) sans pour autant swaper.
Donc oui, la consommation de RAM n’est pas évidente à évaluer, et la consommation relevée via l’OS n’indique qu’une consommation, pas ce qui est effectivement nécessaire. Dans la pratique, la libération théorique de la RAM n’a pas du tout l’effet escompté, et plomber une machine avec 16Go de RAM avec 4 applications reste, selon moi, problématique.
#22
Je n’ai jamais dis que javascript avait ce monopole :) Je dis juste que beaucoup de dev ont effectivement du mal avec ces notions (j’ai presque envie de dire normal, puisque ce qui est enseigné c’est souvent de la programmation synchrone et de l’héritage polymorphique).
Quand un dev passe du front au back, sans formation adéquat, le résultat est encore pire…
Tiens, un vieux poste que j’avais déjà vu et commenté en plus :) Je n’étais déjà pas d’accord avec son analyse sur le moment. Et je ne le suis toujours pas aujourd’hui. Je mettais déjà en cause l’algorithmie et l’architecture dans les problèmes de performances plus que le problème de langage.
#23
Non pas tant que ça. De base un processeur de sait que faire des additions et des soustractions.
Du coup, quand, en assembleur, ta as écrit de quoi faire une division, bein tu t’arrange pour en faire une fonction (ou lib, question de sémantique) :)
#24
Et pourtant c’est une logique qui te vaudrait d’être qualifié de vieux
Je me plaignais déjà de mon temps des clients e-mail qui pompaient des 100 Mo pour afficher un vulgaire texte au point d’avoir même payé 20 € pour acheter un client e-mail inconnu mais peu gourmand
Mais n’oublions pas le CPU : Corsair iCue dont je me plaignais ici me pompait 10 % du CPU pour que je puisse utiliser les touches macro du clavier. J’ai donc désinstallé.
Les dévs incompétents justifient la consommation par la grande puissance disponible comme tu le dis, mais ils oublient qu’ils ne sont pas seuls. J’aimerai tant leur demander s’ils adoreraient si Discord pompait 8 Go de RAM et 50 % du CPU au point que Fortnite ou autres jeux vidéos finissent par ramer. Parce que bon… Discord est devenu limite obligatoire de nos jours.
Mais ces derniers temps je suis inquiet de la puissance gâchée par le tracking obligatoire et aussi par les « besoins artificiels ». Par exemple, il faut un compte HP pour scanner avec l’application HP Smart, alors que l’imprimante est à 1 mètre de l’ordinateur. Ou encore j’ai découvert aujourd’hui que sur les smartphones Xiaomi, n’espèrez pas pouvoir lire un PDF avec le lecteur intégré si vous n’avez pas de connexion réseau (j’étais chez un client en zone blanche, aïe…), au point de devoir réessayer de multiples fois jusqu’à ce que ça affiche enfin, alors que le PDF est stocké localement.
Juste… pourquoi ? Si c’est pour traquer, ils pouvaient faire cela plus sournoisement et sans aller jusqu’à un tel extrème. Je n’arrive pas à percevoir l’intêret de la manoeuvre.
En attendant, je perçois toutes les requêtes vers l’extérieur qui ne devraient même pas exister, donc de l’énergie électrique gâché.
#25
Ça fait longtemps que nos cpu, même dans l’embarqué, ont la multiplication (et même la division) en hard. Pas avoir de fpu, oui. Mais pas de multiplication entière, j’ai pas vu ça de nos jours. Ça doit peut-être encore concerner quelques vieux machins 8 bits fabriqués depuis 30 ans et que plus grand monde n’utilise, et encore…
#25.1
Effectivement de mémoire c’était sur un 8080 ou un 68705.
En binaire, facile de faire de l’addition et de la soustraction (algèbre de boule je crois).
Pour le reste il fallait coder.
#25.2
multiplication et division très faciles aussi, tant que tu te limites aux puissances de 2
#26
Je n’ai pas encore lu l’article en intégralité, mais je suis juste passé sur le mot “cadriciel” qui ne semble pas faire partie du dictionnaire de l’Académie française.
Autant, je soutiens la francisation des anglicismes (voire de néo-preudo-anglicismes, créés par des nuls en anglais de 30 ans qui veulent “faire classe”) qui pullulent, notamment dans les domaines technologique & d’entreprise (alors imaginez un peu le cauchemar dans les entreprises technologiques…), autant, je ne vois pas forcément l’intérêt d’aller changer un vocabulaire déjà existant en français.
Pour quoi ne pas utiliser “cadre d’applications” ? Le Grand Dictionnaire Terminologique québécois renvoie d’ailleurs vers ces termes lorsque “cadriciel” (qui y est connu) est recherché.
#27
Allez dire ça à MS et son Teams sous Android qui me suce ma batterie…10% par heure…
#28
Ouaip, Electron. C’est littéralement un navigateur Chromium dédié à une app JS single page. C’est la même avec Spotify, Skype, Discord…
L’intérêt étant d’avoir quasi la même base de code sur le site web que sur l’app desktop et de pas avoir à se prendre la tête à dev pour Windows, Mac et Linux.
Le soucis c’est que forcément si tu embarques tout un navigateur à chaque fois ça bouffe des ressources pour rien, y compris dès le téléchargement de l’app.
L’équivalent (ou l’un d’eux ?) en mobile est React Native.
D’ailleurs, je ne sais pas si ça a été corrigé mais hier Windows Defender spammait de faux positifs dès qu’on avait une app Electron ouverte.
#29
Le département RSE de MS pourrait aussi se pencher sur “compattelrunner high cpu usage”. Toujours pas compris à quoi servait ce truc (Compatibility Telemetry) si ce n’est bouffer des MW.
#30
Le 8051 savait multiplier et diviser mais en bits seulement et quelques cycles machine mais c’était le seul 8 bits à le faire.
On en revient à l’algorithmie quand on voit que la majorité des dev réalisaient la conversion binaire vers bcd ou décimal codé ascii avec des division successives par 1000 au lieu d’utiliser tout simplement l’addition avec ajustement décimal ( facteur 1000 sur la vitesse sur un 8051).
Curieusement, L’ajustement décimal qui extiste dans tous les assembleurs que j’ai pu étudier n’a strictement aucun équivalent dans aucun language compilé ou interprété. C’est pourtant indispensable pour les calculs en décimal en virgule fixe donc sans erreurs de conversion et les conversions binaire en décimal. Je ne vois que le SQL qui puisse s’en servir pour le type decimal.
Pour l’annecdote, le 68000 réalisait les multiplications et divisions séquentiellement en réalisant une addition ou soustraction conditionnelle par cycle d’horloge. 34 cycles en comptant le fetch et le décodage, c’était long.
#31
Que je suis ému de lire cela!!
Perso, j’y aurait ajouté JAVA pour l’escrcroquerie intellectuelle qu’il représente par rapport au c++
Pour le coup des libs, j’ai tenté de compiler une sorte de hello word avec la bibliothèque rocket en rust: 2 Gio de dépendance et un exe de 30 Mio pour un début d’api avec deux points d’arrivée ! Plus gros que nginx et ses libs, c’est une blague ?
Grosse déception pour moi alors qu’une api web, c’est pas la mort en ressource normalement.
#31.1
Perso j’espère que l’économie de ressources et l’écologie favorise un “retour en grâce” des langages bas niveau.
#32
Pour le coup, je ne dirais pas escroquerie, car Java a de réels atouts intellectuellement parlant :
Bon, maintenant, je vais me flagéler, car en tant que C-Sharpiste, je viens d’évangéliser java…
#33
dans les trucs qui n’auraient jamais du exister : flash et son action script, qui permet de mettre du code n’importe où, absolument génial pour debugger, faut rechercher partout si y’a pas un bout de code qui traîne, il peut y en avoir sur le moindre objet graphique manipulé …
#34
La spécification de la taille est en effet bien pratique mais, dans les fait, la plus part des programmeurs C et C++ (en embarqué comme sur PC), on fait des alias pour avoir les u8 s8 u16 s16 …. à la place des unsigned char et compagnie. Ce n’est donc pas bloquant en C/C++
A ce titre, j’adore les types rust.
Le ramasse miette de JAVA est une horreur incontrôlable qui s’enclenche aux pires moments et rend impossible la maîtrise des temps d’exécution. C’est une mauvaise réponse à un vrai problème.
Là dessus, rust apporte une solution qui me parrait correcte et d’autres languages comme le perl s’en tirent bien mieux depuis l’antiquité de l’informatique.
Vu que de plus en plus de services tournent dans des conteneurs lancés dans des VM, c’est juste inutile. En fait, je pense que cette caractéristique est une conséquence et non une qualité recherchée. Du coup, je ne parierais pas sur la solidité de cette protection.
J’y vois, mais je me trompe peut-être, le même niveau de protection qu’un NAT en IPv4.
Cela passe par l’émulation d’un processeur R3000 (si j’ai bien compris), donc performances de merde assurées.
Côté bonheur, j’ai pu avoir à faire avec des softs en java dans le passé et il y avait constamment des problèmes de version. Finalement, c’est un langage interprété qui ne veut pas s’assumer comme tel.
Sinon, a la base, la compilation en code intermédiaire, c’est le fonctionnement même de la majorité des langages interprétés. Cela existe depuis certains basics comme le GFA basic dans les années 80.
La seule nouveauté à l’époque était de conserver le code intermédiaire pour ne pas avoir à le flash compiler comme le font python ou perl.
Maintenant , il y a le web assembly qui fait la même chose il me semble mais de manière plus ouverte.
Il me semble qu’en C#, il y a aussi une compilation en byte code soit l’équivalent du java compilé.
Les coups et les douleurs, cela ne se discute pas
#35
Certes, mais beaucoup utilisent encore les int, long, short sans spécification de taille. C’est là qu’est le danger ;)
La gestion de la mémoire proposée par java et par rust n’ont absolument rien à voir. Java reste simple. Pour rust, il faut comprendre des notions comme la possession, la durée de vie, etc…
Il n’y a pas spécialement une approche qui est meilleure qu’une autre. Juste deux approches totalement différentes.
Le côté non prédictif du ramasse miette de java, hormis pour des questions de temps réel, n’est pas vraiment un souci.
Absolument pas inutile. C’est une vision très serveur que vous avez, et je devrais même dire très orchestrateur. Il y a encore beaucoup de VPS où toutes les applications ou services sont installées directement, sans cloisement, ou de client lourd sur les postes clients (le côté portable !).
Quand on sait que les exploits par buffer overflow/underflow représentent de 50 à 70% des failles de sécurités, c’est d’un grand intérêt que de s’en prémunir ! Les chiffres varient selon les études. Microsoft avait relevé jusqu’à 70% dans une étude en 2019
Cela fait bien longtemps que ce n’est plus le cas, et qu’avec les compilateurs JIT voir AOT les performances sont très respectables, d’autant plus pour des programmes comme des services qui sont censés tourner en permanence.
Oui, C# et webassembly repose exactement sur le même principe.