Chiffres pour mieux comprendre les enjeux

Ouaaaiiis!! le java a la corbeille \o/ enfin!

Et puis bon, (ma devise personnelle), faire des choses inutilement complexes souligne toujours un manque de compétences.

Moi qui milite pour un limiteur de FPS réglable inclut dans DirectX ou dans les drivers Nvidia ou AMD.
30FPS ça suffit en général pour la plupart des jeux, tourner à 80FPS ça ne sert à rien et bouffe un courant pas possible.

Ce n'est pas forcément vrai, surtout quand il s'agit de faire ce que demandent tes clients Dans l'absolu j'aimerais être d'accord, mais par exemple va expliquer à des syndicats dans une grande entreprise que, gérer une carrière de salarié ça devrait être simple... et pas une usine à gaz! (c'est ce que je gère en développement en ce moment même, et c'est une horreur).

Sinon, concernant le développement "vert", c'est avant toute chose un débat déjà existant mais sous une autre forme: si l'on peut optimiser les temps de traitement, ainsi que la charge du ou des processeurs, cela libèrera d'autant plus tôt la machine. N'oublions pas que les grosses machines de compta (bull par exemple) passaient un job à la fois, et que les autres étaient en file d'attente, d'où l'obligation d'optimiser. En gros, ils faisaient un peu "d'écologie" mathématique quoi

Ce ne sont pas les développeurs qui décident du langage utilisé en général, mais les lecteurs de 01Net, les "décideurs informatique". Résultat, ils utilisent les dernières technos présentées par un journaliste ignare comme le dernier cri. Au final, les développeurs même doués doivent développer en un language choisi par des imbéciles conseillé par des ignares.

C'est une bonne idée, il y a déjà la VSync, mais ça ne suffit pas. il faudrait pouvoir spécifier le plafond de FPS à la main.

En termes techniques, avec la VSync, ça reviendrait à appeler 1..n fois SwapBuffers (en OpenGL), en sauvegardant/recopiant le contenu de l'image précédente (possible avec WGL_ARB_buffer_region).. Sous d3d, je connais pas encore assez mais ça doit être possible également..

Un grand merci à l'équipe de Présence PC (THFR ?) pour ce super dossier !

@Iksarfighter : +1000 ! C'est une excellente idée ! D'ailleurs ça remettrais peut être aussi en question la manière d'évaluer les cartes graphiques ...

Pour plus d'actus sur le Green IT, je vous recommande chaudement www.greenit.fr

Tu commences a réaliser que beaucoup de choses autour de nous sont mal gérées. Et pour les requêtes de clients qui changent en permanence, je connais ça, et c'est sur que ça n'aide pas a faire du code efficace.. a moins de tout réécrire a chaque demande... idéalement il ne faudrait que les demandes des clients soient claires dès le départ et qu'elles ne changent pas..

Je serais d'accord si je n'avais pas dix ans de métier En gros, tant le client que les utilisateurs sont tributaires d'énormément de choses indépendantes de leur volonté.

Tiens, par exemple : Bull ne supporte plus depuis belle lurette son bazar (GCOS), ce qui impose donc, tôt ou tard, de migrer l'usine à gaz comptable vers autre chose. Constats: d'une part il faut trouver un environnement "fiable", d'autre part développer la migration. De fait, le tout nécessite du temps, de l'argent, et dans l'entretemps les règles peuvent évoluer. La paie est quelque chose qui évolue sans cesse (nouvelles taxes, nouveaux contrats...) ce qui a pour conséquence que le client te balance "faut virer ce truc et le remplacer par ce machin". Toi, tu te dis "c'est débile", mais tu es tenu de le faire vu le besoin fonctionnel chez eux.

Ajoutons également la problématique de la réflexion. Lorsqu'un produit est imaginé, il répond (en principe) à un besoin non identifié au départ. Typiquement, plus tu as de services dans une société, plus tu as de chances qu'il y ait un besoin d'échanges entre eux, chose qui est rarement (pour ne pas dire jamais) imaginé. Alors d'un produit bien conçu, tu finis par aboutir à une grosse bouse, lourde, surchargée, parce que justement il y en a besoin... et que cela a été complété à la barbare.

Ceci étant, nombre de choses pourraient être revues avec efficacité, à la condition expresse de verrouiller les phases de réflexion afin de s'épargner les errances de bien des projets. A mon sens c'est même une des causes majeures de l'échec des projets de grande envergure.

Enfin, songeons aussi à la puissance disponible et sous exploitée, voire pas exploitée. On parle de l'usage des GPU pour les calculs (voir le calculateur basé sur du GeForce), on peut également raisonner sur l'abandon de solutions dites élégantes, mais finalement pas suffisamment efficaces. Les machines virtuelles comme .NET et Java en sont un exemple chronique: on dissocie (avec raison) les processus du système, cependant on augmente alors la consommation des machines hébergeant les dits "OS" virtuels. Résultat des courses: performances en baisse, efficacité à prouver, et globalement maintenance complexe et hasardeuse. A quand de vrais OS qui traitent nativement ces problématiques?

ça me rappel le logiciel fournit avec ma tuner TNT !
C'est d'une lourdeur pas croyable !
Je démare plus vite crysis que ce logiciel lol!

C'est simplement inadmissible !
A quois bon avoir du matériel performant si les logiciels ne sont pas optimisé !

Quand je voit les étudiants de ma fac, je me demande comment il pourront faire un programme qui ressemble a quelque chose plus tard !

Ca c'est aussi une problématique de logique comptable: "sortez le soft le plus vite possible, quitte à filer des patchs par la suite"...

Sur cet aspect, il est essentiel de rester prudent. L'école est supposée t'apprendre les bonnes pratiques, ce qui est malheureusement différent des "pratiques pro". je m'explique: l'étudiant va apprendre à se prendre la tête sur des détails qui lui sembleront sur le coup essentiels, mais qui en entreprise seront traités comme du superflu. De là, le problème devient double: les professeurs ont ils encore une visibilité sur la façon de procéder dans le monde pro, et d'autre part sont ils capable de la transmettre à leurs étudiants?

Le cursus professionnel (quelque soit la profession) ne prépare pas à la technique (ou si peu), il est supposé préparer à la rigueur que nécessité une prise de poste dans la vie active. De là, il est hélas dramatique de constater que d'une part les étudiants ne sont que rarement autonomes sur leur premier poste, et qu'en plus on leur a enfoncé dans le crâne qu'ils savent tout faire... et surtout très bien. C'est d'ailleurs tragi comique de les voir se casser les dents sur des gens expérimentés qui les remettent en place avec des remarques du genre "ah oui ton truc ça a de la gueule... mais ça sert à quoi concrètement?"

Espérons que les écoles sauront progresser sur ces aspects et former leurs élèves aux priorités réelles du monde pro dans l'informatique... et pourquoi pas d'aborder les notions d'écologie qui peuvent, à terme, devenir une véritable marque de fabrique. On pourrait rêver d'OS et de programmes portant le label "eco friendly"

A propos de l'économie d'énergie par rapport à l'écran, quand est-ce que votre site passe en fond noir ?

Ajoute aussi Flash, Silverlight, C# (qui fonctionne grâce à un runtime, beurk)...


Pour en revenir à l'article c'est fort intéressant et bien écrit. "Loïc Duval" c'est l'ancien d'Atari France ou un homonyme ?

Le fond du problème c'est qu'il est plus économique de produire un code non optimisé que de se souvenir de l'époque ou il fallait se battre pour économiser quelques octets afin que son soft s'exécute sur les 512 ko de mémoire du système. Aujourd'hui le raisonnement des éditeurs c'est plutôt : si c'est trop lourd il n'y a qu'à changer de processeur, de carte graphique et ajouter quelques Go de RAM.
Peut-être qu'avec des arguments écologiques les éditeurs reviendront à plus de raison et recommenceront à faire leur travail d'optimisation. C'est comme si en automobile on sous faisais des pneus carrés sous prétexte que c'est moins cher à produire, et qu'on nous expliquait que pour avoir des performances identiques aux précédents il suffit de mettre un moteur de 500 cv.
Au delà de l'aspect écologique cette pratique dégrade tout simplement la fameuse "expérience utilisateur". Un soft qui répond tout de suite c'est quand même plus agréable que d'admirer un sablier.

Pour l'annonce eBay c'est surement 30 Wh et pas 30W/h... sinon ca fait beaucoup...

jay_rom -> bonne idée pour les possesseurs de CRT mais les écrans en dalle TN consomment moins dans le blanc (très peu mais moins), laissons le choix

surtout que 30W/h ça ne veut rien dire ici car ça représente une variation de consommation ...

Quand à l'avenir de la formation des futurs programmeurs, j'ai bien peur que ça migre de plus en plus vers des langages où parler d'optimisation est une vaste blague. En effet la "mode" est au haut niveau dans lequel on n'a plus aucune notion du matériel, d'ailleurs ça tombe bien puisqu'on parle de moins en moins de matériel dans les formations.

+1 pidz

Grave erreur dans cette article de laisser croire que tous les écrans consomment moins en fond noir ...
La plupart des écran LCD pour PC (surtout les PC portable) sont en dalle TN donc consomment moins dans les blanc.
Inversement pour les LCD TV, dalle MVA ou IPS , ça consomment moins dans les noir.
tout est là :
http://www.lesnumeriques.com/article-438.html

Je programme sur des jeux qui ne demandent pas beaucoup de puissance, et du coup qui peuvent tourner à 1500-2000 fps sur une machine récente.
Comme cela sert à rien d'avoir un tel framerate, je limite celui-ci à 100 fps (ce qui est déjà énorme).
Avec un appareil qui calcule la consommation à la prise de courant, j'ai constaté sur ma machine (E8400 + 8800GT) une baisse de 30W dans la consommation.
C'est pas si mal et la modification m'a demandé juste 30 minutes de travail.

Bravo pour avoir osé un tel sujet.
Et merci pour les chiffres donnés, ça donne une bonne idée de l'ampleur du désastre...
Et puis après un tel article on se sent soudain plus motivé à regarder de près ce qu'on fait dans son code.

Le haut niveau n'est pas forcement synonyme de baisse de performances et d'optimisation difficile (je dirait presque que c'est le contraire). C'est le désintérêt général des programmeurs qui s'exprime mieux avec des langages de haut niveau. Ils ne réfléchissent pas plus loin que ce que le langage leur offre : ''tiens, lire le contenu entier du fichier pour l'ouvrir, c'est plus simple. mince, ça marche moins bien avec des gros fichiers ...''

et la désinfo continue

En effet; mes machines de développement sont des Pentium 300 MHz : malgré la lenteur de mes machines, mes applications ont des temps de réponse corrects, les applications ont une belle apparence, et mes clients sont très satisfaits. (Il faut bien sûr rechercher une programmation performante, une présentation "suffisante").

Mes prochaines machines ? à base de processeurs Via pico-Itx : elles consomment 15W.

Je pensais au faite que beaucoup se moque un peu de l'optimisation malgré que l'on nous apprenne la notion de complexité et que l'on l'on montre avec des programme de trie par exemple, que certain sont vraiment beaucoup plus efficace que d'autre. Après il y a aussi l'optimisation des testes, de l'occupation mémoire, etc...

Quand a java, sur PC c'est sur c'est pas le top.
Mais peut être utils dans certain cas je pense; comme sur les mobiles, programmer en C un programme compatible pour tout les téléphones ...

Mon dieu, cette page est à majorité sur fond blanc et je ne peux pas désactiver les publicités en flash qui font tourner inutilement mon PC.
Peut-être vaut-il mieux que j'imprime cet article et que je coupe mon moniteur ?

Moi j'aurai plutôt envie de dire :

Et vraiment, l'enseignement du développement est vraiment à revoir. Les étudiants ne se rendent déjà pas compte du fait que ce qui développent ne servent pas que pour eux.

Ouh là, il faudrait prendre garde à ne pas tout mélanger et à éviter les raccourcis rapides!

Cela fait bien longtemps que les compilateurs JIT existent et réduisent pratiquement à néant la surconsommation CPU de programmes compilés en "bytecode" comme Java par rapport à leur équivalent en C++.
Dans un autre domaine, il suffit de voir les perf obtenues en Perl sur certaines tâches.

J'ai prouvé à plusieurs reprises à des développeurs C++ que leur code (vite et mal écrit) était bien moins performant qu'un équivalent Java (écrit proprement et optimisé).

Le seul point noir de Java reste effectivement sa consommation mémoire, dont l'optimisation reste une affaire de spécialiste, mais on paie le prix d'un garbage collecting automatique qui a été mis en place pour pallier les déficiences du développeurs moyen incapable de gérer correctement ses allocations mémoires (ou de faire du développements parallèle), élément primordial dans de la programmation Objet.

Effectivement on peut se poser la question de l'intérêt (initial) d'une machine virtuelle .Net ou Silverlight, dédiée à un unique OS... Il ne faut pas oublier que le slogan originel de Java était "write once, run anywhere" ! Faire du bytecode pour du bytecode n'a effectivement aucun intérêt !

Pour en revenir à l'article, il pointe du doigt 2 choses importantes, que la plupart des développeurs actuels "oublient" :

- optimiser les morceaux de code les plus utilisés (métrologie logicielle de base),
- écrire du code propre/lisible qui pourra être optimisé correctement par le compilateur (et non pas du code abscons incompréhensible, "inmaintenable" et impossible à optimiser par le compilateur comme on le voit trop souvent).


En 30 ans l'informatique est passé d'un métier d'artisans, maîtrisant leur technique sur le bout des doigts et leur production de A à Z, à un métier de travail à la chaîne où on ne fournit plus aux développeurs la moindre vision d'ensemble.
Il n'est pas étonnant de constater que les logiciels les plus efficaces sortent de petites structures et que les usines à gaz sortent des SSII ou autres poids lourds du domaine...

On paie aussi la conséquence de la course aux performances côté hardware : à quoi bon optimiser son code quand on sait que la performance des serveurs aura doublé au moment où le code sera entré en production.

On arrive cependant enfin à la fin de cette course aux "armements" : la loi de Moore a été simplement rattrapé par les considérations énergétiques et les coûts associés. Remplacer un serveur tous les 3 ans ne coute que quelques milliers d'euros, qu'on arrive à amortir, mais quand il faut revoir de fond en comble l'infrastructure énergétique d'un centre d'hébergement, la facture passe à 6 zéros et on se découvre rapidement une conscience écologique à ce moment là !

Ouah, ca faisait longtemps que je n'avais pas été autant captivé par un article de tom's ! Merci pour cet article !