Haswell consommera 2,25 fois moins qu'Ivy Bridge à performance identique

Haswell consommera 2,25 fois moins qu’Ivy Bridge à performance identique

Chiche ?

Avatar de l'auteur
David Legrand

Publié dans

Sciences et espace

11/09/2012 2 minutes
82

Haswell consommera 2,25 fois moins qu'Ivy Bridge à performance identique

Lors de sa Keynote d'ouverture de l'IDF, sur laquelle nous reviendrons un peu plus tard, Dadi Perlmutter a effectué quelques annonces et démonstrations concernant Haswell. La prochaine génération de CPU du constructeur misera, comme annoncé, sur une consommation drastiquement revue à la baisse.

Car comme cela avait déjà été dit, Haswell a été conçue « avec la mobilité à l'esprit ». Ainsi, il a été confirmé que les puces afficheraient une consommation de moins de 10 watts, comme évoqué il y a un peu plus d'un an. Du côté de la dénomination officielle, il ne faudra pas s'attendre à quoi que ce soit de transcendant puisqu'il est question des processeurs Core de quatrième génération.

 

IDF Day 1 Keynote Haswell IDF Day 1 Keynote Haswell

 

Du côté des démonstrations, c'était assez pauvre puisque seul un kit de développement était présent. Intel promet sa miniaturisation assez rapidement, et a même montré un concept de machine dans lequel on pourra utiliser ces futurs produits. 

 

On a donc simplement eu droit à une séance d'Unigine Heaven afin de nous montrer qu'Haswell était plus performant qu'Ivy Bridge... mais sans aucun détail ni aucun chiffres. Par contre, un autre point a été mis en avant, qui était plus intéressant à noter : la consommation à performance identique.

 

IDF Day 1 Keynote Haswell IDF Day 1 Keynote Haswell

 

Ainsi, comparé à un modèle Ivy Bridge qui consommait 17 watts, Haswell tournait aux alentours de 7,5 watts, soit une réduction de 2,25x. Un point intéressant, notamment pour les Ultrabooks et autres machines compactes. Reste maintenant à voir ce qu'il en sera dans la pratique et dans les tests indépendants, et ce, avec l'ensemble des modèles qui seront proposés.

 

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Fermer

Commentaires (82)


Apres la gravure en finesse negative, voila que les puces vont produire de l’electricité quand on les utilise!



C’est beau le futur! <img data-src=" />


C’est quoi un kit de développement pour les processeurs? C’est une grosse machine qui simule le processeur?


Le 11/09/2012 à 17h 55







sioowan a écrit :



C’est quoi un kit de développement pour les processeurs? C’est une grosse machine qui simule le processeur?







C’est pas tout simplement ce qu’on appelait humblement un compilateur, dans le temps ? <img data-src=" />









pafLaXe a écrit :



C’est pas tout simplement ce qu’on appelait humblement un compilateur, dans le temps ? <img data-src=" />









donc une grosse machine qui simule le processeur dans un compilateur?<img data-src=" />



Bien bien tout ça, pour reussir à avoir un PC vraiment silencieux et performant.

Je vais bientôt lacher mon Core 2 Duo !! <img data-src=" />


Pas d’info sur le socket ?








scientifik_u a écrit :



Pas d’info sur le socket ?





Nouveau socket 1150 normalement.



Je vais attendre ce petit gars pour changer de pc-tablet moi <img data-src=" />



De toute façon, la débauche de puissance offerte augmente bien trop vite comparé aux besoins de 80% des utilisateurs.



Donc s’ils veulent avoir le moidnre espoir d’inciter à renouveler son matos, la consommation moindre doit être une des rares améliorations qui peut faire sens pour l’acheteur potentiel.



Et perso c’est pas pour me déplaire, moi qui rêve d’un 15 pouces totalement fanless, sans pour autant être une grosse brute de puissance ni un Atom anémique.








scientifik_u a écrit :



Pas d’info sur le socket ?





Pas encore, ce n’est pas le but de la Keynote d’ouverture hein. Après comme déjà dit 50x, on sait qu’il changera depuis un moment, besoin de savoir quoi de plus ? <img data-src=" />



Pour le kit de dév, c’est juste que ce sont des composants qui permettent de montrer ce que donneront la machine, mais qui ne sont pas encore assez miniaturisés pour rentrer dans un chassis de portable



Et sans valeur TDP biaisée cette fois-ci M. Intel?


Core 2 Duo e6550 qui commence à se faire vieux… attendons Haswell !



Dommage qu’AMD soit à la ramasse sur ce secteur, un peu de concurrence pourrait faire du bien au niveau des prix.








the_Grim_Reaper a écrit :



Nouveau socket 1150 normalement.







Okay





David_L a écrit :



Pas encore, ce n’est pas le but de la Keynote d’ouverture hein. Après comme déjà dit 50x, on sait qu’il changera depuis un moment, besoin de savoir quoi de plus ? <img data-src=" />





Sorry mais je scrute pas trop les news hardware <img data-src=" />



Le 11/09/2012 à 18h 26







David_L a écrit :



Pour le kit de dév, c’est juste que ce sont des composants qui permettent de montrer ce que donneront la machine, mais qui ne sont pas encore assez miniaturisés pour rentrer dans un chassis de portable







C’est donc bien une grosse machine. Voilà qui va faire plaisir à sioowan qui semblait nous faire un petit complexe à propos de taille de machine <img data-src=" />









Guiguiolive a écrit :



Apres la gravure en finesse negative, voila que les puces vont produire de l’electricité quand on les utilise!



C’est beau le futur! <img data-src=" />







Il me semble qu’une tablette se recharge par la pression des doigts sur celle-ci… on est plus très loin <img data-src=" />









brazomyna a écrit :



De toute façon, la débauche de puissance offerte augmente bien trop vite comparé aux besoins de 80% des utilisateurs.



Donc s’ils veulent avoir le moidnre espoir d’inciter à renouveler son matos, la consommation moindre doit être une des rares améliorations qui peut faire sens pour l’acheteur potentiel.







Et perso c’est pas pour me déplaire, moi qui rêve d’un 15 pouces totalement fanless, sans pour autant être une grosse brute de puissance ni un Atom anémique.





+1.

Ca, et aussi le prix peuvent être une de ces rares améliorations.









adrieng a écrit :



Il me semble qu’une tablette se recharge par la pression des doigts sur celle-ci… on est plus très loin <img data-src=" />







Ca me rappelle les montres automatiques cette affaire (et chapeaux si on y arrive)



Mon Core 2 Duo a prit une petite retraite bien tranquille dans une famille ou il sera bien traiter <img data-src=" /> .

Now je fais de misère au I7 si il fait le malin je le remplacerais par un Haswell <img data-src=" />


Gén ial on va pouvoir passer au socket 1154 ! <img data-src=" />


On notera qu’ils ont dit “Haswell consommera 2,25 fois moins qu’Ivy Bridge à performance identique”, pas “Haswell sera 2,25 fois plus puissant qu’Ivy Bridge à consommation identique”. Et pourtant Ivy Bridge est tout de même relativement économe.


Pas mal. C’est surement pour concurrencer ARM en consommation.



Et les supraconducteur s’en est où ? Ça fait plus de 10 ans qu’ils en parlent et je ne vois jamais rien. <img data-src=" />


Tiens, je pourrais me faire une salle de calcul scientifique avec ces CPU la <img data-src=" />


ça sort quand ça ?? (à peu près)



parce que la à ce niveau il est clair qu’il vaut mieux attendre pour acheter une tablette par exemple.


AMD sera définitivement dans les choux quand ils sortiront ces nouveaux procos.








Lafisk a écrit :



ça sort quand ça ?? (à peu près)



parce que la à ce niveau il est clair qu’il vaut mieux attendre pour acheter une tablette par exemple.





Fin Q1 début Q2 en 2013 normalment









David_L a écrit :



Fin Q1 début Q2 en 2013 normalment





ok merci, bon ben… je vais prendre mon mal en patience pour les tablette alors <img data-src=" />









ed a écrit :



AMD sera définitivement dans les choux quand ils sortiront ces nouveaux procos.





J’aime<img data-src=" />



Oui j’aime les trolls qui essaient de se convaincre qu’ils n’ont pas payé un proco hyper cher pour rien.



Ce titre attrape-mouche <img data-src=" />



Comme si une architecture APU (ou plutôt un ensemble de produits diverses regroupés sous une même appellation marketing) pouvait avoir une consommation propre…

Haswell, ce sont des processeurs à 2,4,6,8,10 cœurs, avec ou sans IGP à 8,20,40 unités, à des fréquences allant presque du simple au triple, et avec au moins quatre dies différents rien que pour les versions APU , dont un destiné aux ultrabook contenant le GT3 associé à une puce mémoire en sideport.



Ici l’on compare sans doute la consommation sous charge graphique d’un Ivy ULV GT2, avec ses 16 unités graphiques sous cadencées, et d’ un Haswell ULV GT3, avec ses 40 unités ultra under-clockées pour l’occasion.









kail a écrit :



J’aime<img data-src=" />



Oui j’aime les trolls qui essaient de se convaincre qu’ils n’ont pas payé un proco hyper cher pour rien.





Si tu comptes faire le relou dans les commentaires pendant toute la semaine, je peux te bloquer tout de suite hein ;)









David_L a écrit :



Si tu comptes faire le relou dans les commentaires pendant toute la semaine, je peux te bloquer tout de suite hein ;)





Yes you can !<img data-src=" />









brazomyna a écrit :



De toute façon, la débauche de puissance offerte augmente bien trop vite comparé aux besoins de 80% des utilisateurs.





En puissance pure, mon Core 2 Duo me va toujours.

C’est plus pour le chipset que j’ai envie de changer, histoire de rentrer dans la génération 3 de Sata et USB, maintenant que c’est bien mûre comme techno.





Ces ULV avec ces TDP si bas permettront ils théoriquement de faire des ultrabook/tablette sans ventilation ?

Quelqu’un saurait-il donner le TDP des procs ARM utilisés dans les plus puissants tablettes/téléphones ?


It’s a monster!

J’ai hâte de voir la bête a l’œuvre.

Sinon aucune confirmation sur l’ajout d’un dernier niveau de cache (off chip) comme certaines rumeurs le laissaient entendre.








cedric.pineau a écrit :



Quelqu’un saurait-il donner le TDP des procs ARM utilisés dans les plus puissants tablettes/téléphones ?





On y vient. Voilà ce que je veux entendre!









regis183 a écrit :



Ce titre attrape-mouche <img data-src=" />



Comme si une architecture APU (ou plutôt un ensemble de produits diverses regroupés sous une même appellation marketing) pouvait avoir une consommation propre…

Haswell, ce sont des processeurs à 2,4,6,8,10 cœurs, avec ou sans IGP à 8,20,40 unités, à des fréquences allant presque du simple au triple, et avec au moins quatre dies différents rien que pour les versions APU , dont un destiné aux ultrabook contenant le GT3 associé à une puce mémoire en sideport.



Ici l’on compare sans doute la consommation sous charge graphique d’un Ivy ULV GT2, avec ses 16 unités graphiques sous cadencées, et d’ un Haswell ULV GT3, avec ses 40 unités ultra under-clockées pour l’occasion.





Merci pour ce commentaire sensé. Je pense qu’il va y avoir des Inpactiens déçus, quand ils verront qu’à conso identique et hors IGP, Haswell ne met que 10% à tout casser à Ivy sur la gamme ‘normale’ de processeurs.









june a écrit :



Merci pour ce commentaire sensé. Je pense qu’il va y avoir des Inpactiens déçus, quand ils verront qu’à conso identique et hors IGP, Haswell ne met que 10% à tout casser à Ivy sur la gamme ‘normale’ de processeurs.







Intel va repasser les TDP à 65W et 95W pour pouvoir monter un peu les fréquences.

Ce qui est décevant, c’est leur conservatisme sur le design des unités de l’IGP.

On peut comprendre qu’ils n’ont pas envie de s’éparpiller au niveau drivers, m’enfin y’aurait vraiment matière à progresser.









metaphore54 a écrit :



Pas mal. C’est surement pour concurrencer ARM en consommation.



Et les supraconducteur s’en est où ? Ça fait plus de 10 ans qu’ils en parlent et je ne vois jamais rien. <img data-src=" />





Pour les supra conducteur c’est pas au point pour une utilisation domestique.

Il faut des températures extrêmement basse pour les faire fonctionner (la température de fonctionnement la plus haute connu pour un supraconducteur est de 133K)

Et au niveau manipulation de ces matériaux très particulier à l’échelle du nanomètre on ne sait pas encore faire.





Quelqu’un saurait-il donner le TDP des procs ARM utilisés dans les plus puissants tablettes/téléphones ?





Le cortex A9 de ARM a un TDP de 2W max. Sur les nouveaux A15 par contre la aucune idée.








Scorp14 a écrit :



Le cortex A9 de ARM a un TDP de 2W max. Sur les nouveaux A15 par contre la aucune idée.





Un coeur A9 c’est moins que ca. A 2w tu es plutot sur un SoC dual core avec un GPU moyen de gamme.



Pour entrer dans un telephone, les integrateurs demandent des CPU vers les 3-400 mW/MHz.



Ils parlent de 500mW pour le coeur et les 2w c’est pour Tegra2, donc dual core plus GPU, bref on est d’accord <img data-src=" />


Mais si Haswell a ce genre de perfs, ça ne risque pas de venir tailler des croupières aux procs ARM ? Je veux dire par là qu’avec la sortie de Windows 8, Intel a là une possibilité quasi-inespérée de reprendre la main sur l’univers de la mobilité. En effet, si on peut imaginer un plantage de Win8RT because non compatible avec les applis actuelles, alors des tablettes sous proc x86 devraient mieux se vendre puisque plus de compatibilité, non ? En gros : WinRT fait un bide, Win8 devient la norme sous tablettes Intel, et les procs ARM se retrouvent progressivement marginalisés comme ce fut le cas avec AMD. C’est possible ça ????


comparer le TDP un SoC ARM mobile avec un CPU Haswell c’est comme comparer la consommation d’un véhicule écoshell part rapport à un diesel 2 temps Wärtsilä. <img data-src=" />








-DTL- a écrit :



comparer le TDP un SoC ARM mobile avec un CPU Haswell c’est comme comparer la consommation d’un véhicule écoshell part rapport à un diesel 2 temps Wärtsilä. <img data-src=" />







OK, mais en clair ? Suis loin d’être un spé de la techno sur les procs, j’essaie simplement d’envisager les conséquences stratégiques sur le marché de ce genre de nouveau proc. Si le TDP est plus en faveur de ARM, OK, mais je lis partout que les ARM sont loin derrière les Intel en puissance. Si Intel trouve un bon compromis, ça ne sera pas la 1ère fois que le mieux-donnant techno sortira vainqueur, non ?









-DTL- a écrit :



Pour les supra conducteur c’est pas au point pour une utilisation domestique.

Il faut des températures extrêmement basse pour les faire fonctionner (la température de fonctionnement la plus haute connu pour un supraconducteur est de 133K)

Et au niveau manipulation de ces matériaux très particulier à l’échelle du nanomètre on ne sait pas encore faire.







Merci pour le renseignement. Au moins maintenant, je sais que je peux encore attendre. <img data-src=" />









june a écrit :



Merci pour ce commentaire sensé. Je pense qu’il va y avoir des Inpactiens déçus, quand ils verront qu’à conso identique et hors IGP, Haswell ne met que 10% à tout casser à Ivy sur la gamme ‘normale’ de processeurs.





Pour rappel, on parle ici de consommation à niveau de performances identiques. Pour ce qui est de la perf pure, c’est une autre question ;) Mais un changement d’archi ne permet jamais de grimper de 50% sauf sur une instruction ou une application bien précise, et en général parce qu’une implémentation hardware spécifique a été mise en place.









ffvsdoom a écrit :



OK, mais en clair ? Suis loin d’être un spé de la techno sur les procs, j’essaie simplement d’envisager les conséquences stratégiques sur le marché de ce genre de nouveau proc. Si le TDP est plus en faveur de ARM, OK, mais je lis partout que les ARM sont loin derrière les Intel en puissance. Si Intel trouve un bon compromis, ça ne sera pas la 1ère fois que le mieux-donnant techno sortira vainqueur, non ?





A l’heure actuel ARM produit des designs qui conviennent bien aux fabriquant de téléphone mobile.

Haswell même à 10w lui n’a aucune chance de terminer dans un smartphone.

Au mieux il pourrait finir dans une “grosse tablette”

Mais là on compare des CPU qui ne sont pas conçu pour le même usage et sont sur des marchés très distinct.



Une comparaison entre un atom et un ARM serait déjà plus pertinent.









-DTL- a écrit :



A l’heure actuel ARM produit des designs qui conviennent bien aux fabriquant de téléphone mobile.

Haswell même à 10w lui n’a aucune chance de terminer dans un smartphone.

Au mieux il pourrait finir dans une “grosse tablette”

Mais là on compare des CPU qui ne sont pas conçu pour le même usage et sont sur des marchés très distinct.



Une comparaison entre un atom et un ARM serait déjà plus pertinent.







OK, merci :-)

Mais justement, je parlais bien des tablettes, et non des smartphones (j’avais cru comprendre que les procs Intel avaient des soucis pour les smarphones). Mais en revanche, dans une tablette du type Surface, c’est pas possible de l’envisager ? On voit actuellement des tablettes (certes un peu plus grosses que l’ipad ou les tabs Android) sortir avec les procs Intel sous W7 (donc tout sauf optimal…). Avec une archi du type Haswell, ces tablettes ne pourraient pas, sous W8, faire mal à ARM sur le marché des tablettes, en facilitant la compatibilité avec l’univers PC plus classique ?

Sinon, je vois bien l’intérêt de comparer les Atom avec les ARM. Et dans ce cas, même question <img data-src=" />









ffvsdoom a écrit :



OK, merci :-)

Mais justement, je parlais bien des tablettes, et non des smartphones (j’avais cru comprendre que les procs Intel avaient des soucis pour les smarphones). Mais en revanche, dans une tablette du type Surface, c’est pas possible de l’envisager ? On voit actuellement des tablettes (certes un peu plus grosses que l’ipad ou les tabs Android) sortir avec les procs Intel sous W7 (donc tout sauf optimal…). Avec une archi du type Haswell, ces tablettes ne pourraient pas, sous W8, faire mal à ARM sur le marché des tablettes, en facilitant la compatibilité avec l’univers PC plus classique ?

Sinon, je vois bien l’intérêt de comparer les Atom avec les ARM. Et dans ce cas, même question <img data-src=" />







Oui bien sur, si Intel arrive a trouver le bon compromis entre conso et puissante (et surtout grace a l’argument de la compatibilité avec les progs x86) ils vont prendre une grosse part de marché et relégué l’ARM a des proco de seconde zone ^^ Intel l’a meme tres bien compris vu que les atoms sont leur proco qui vont le plus rapidement profiter des finesse de gravure les plus perfectionner avec des changements tout les ans (contrairement a tous les 2 ans chez les proc type core i..)



Apres comme dit mon prof d’elec : certes les processeurs ne cessent de diminuer mais les ventilateur ne cessent de grossir .. Parce que malheureusement l’un des problèmes de la réduction des finesses de gravure est la dissipation thermique … Et sur ceux point a conso égal l’ARM est mieux mais moins puissant (tout est un problème de compromis)









David_L a écrit :



Pas encore, ce n’est pas le but de la Keynote d’ouverture hein. Après comme déjà dit 50x, on sait qu’il changera depuis un moment, besoin de savoir quoi de plus ? <img data-src=" />



Pour le kit de dév, c’est juste que ce sont des composants qui permettent de montrer ce que donneront la machine, mais qui ne sont pas encore assez miniaturisés pour rentrer dans un chassis de portable









Je voudrais bien voir à quoi ça ressemble.









brazomyna a écrit :



De toute façon, la débauche de puissance offerte augmente bien trop vite comparé aux besoins de 80% des utilisateurs. anémique.





Raaah, non, non, et non ! Les utilisateurs ont besoin de plus de puissance pour deux choses :

* Permettre aux développeurs d’écrire leur code dans des langages de haut niveau qui offrent plus de productivité et de sécurité, pour des applis moins chères, plus riches, plus évolutives, nécessitant de plus petites équipes, contenant moins de bogues et sans risques de sécurité.

* Pour toutes ces choses que l’on ne peut pas encore faire aujourd’hui, à commencer par des IA vraiment bluffantes, pour les assistants personnels type Siri jusqu’aux jeux vidéos, en passant par tous les webservices intelligents que nous aurons un jour.



Le coup de la montée en puissance pour palier les langages de plus haut niveau… lol. Le delta de perf pour le comparer au delta d’une generation de cpu. Ca fait très longtemps que ce surcout est négligeable comparé à la puissance disponible.

Pour les webservices, je rigole bien aussi puisque la notion de webservice implique justement un traitement largement déporté du côté des serveurs, or là on parlait du marché ‘grand public’.



Après il ne faut pas me faire dire ce que je n’ai pas dit: l’évolution de l’it doit effectivement s’accompagner d’une evolution de la puissance des cpu. Je dis juste qu’en ce moment on est en plein dans le creux de la vague des besoins cpu pour tout le matos qui se retrouve entre les mains du consommateur final.








kail a écrit :



Et sans valeur TDP biaisée cette fois-ci M. Intel?





Gnié <img data-src=" />









HarmattanBlow a écrit :



Raaah, non, non, et non ! Les utilisateurs ont besoin de plus de puissance pour deux choses :

* Permettre aux développeurs d’écrire leur code dans des langages de haut niveau qui offrent plus de productivité et de sécurité, pour des applis moins chères, plus riches, plus évolutives, nécessitant de plus petites équipes, contenant moins de bogues et sans risques de sécurité.

* Pour toutes ces choses que l’on ne peut pas encore faire aujourd’hui, à commencer par des IA vraiment bluffantes, pour les assistants personnels type Siri jusqu’aux jeux vidéos, en passant par tous les webservices intelligents que nous aurons un jour.







J’ai l’impression que CPU est largement sous utilisé par les programmes et jeux, même récent, pourtant j’ai un CPU qui commence à être ancien (I7 en 1366.) Donc l’évolution des programmes et jeux, je ne la voit pas.









brazomyna a écrit :



Le coup de la montée en puissance pour palier les langages de plus haut niveau… lol. Le delta de perf pour le comparer au delta d’une generation de cpu. Ca fait très longtemps que ce surcout est négligeable comparé à la puissance disponible.





Il n’y a pas de delta, il y a un facteur multiplicatif. Quand tu écris un code en dotnet aujourd’hui, tu as la puissance qu’avaient les développeurs C il y a quelques années. Quand tu écris un code en php aujourd’hui, tu as la puissance qu’avaient les développeurs dotnet il y a quelques années. Et ce facteur est loin d’être négligeable.









brazomyna a écrit :



Le coup de la montée en puissance pour palier les langages de plus haut niveau… lol. Le delta de perf pour le comparer au delta d’une generation de cpu. Ca fait très longtemps que ce surcout est négligeable comparé à la puissance disponible.





Il faut tout de même reconnaitre qu’avant personne n’aurait eu l’idée d’écrire des applications en JS/HTML5 pour faire 2-3 effets kikoolol sur le bureau en local…

Donc pour ça on lance une VM javascript et un moteur de rendu.

Bref niveau perf on a jamais fait aussi mauvais… juste sous prétexte qu’il y a de la puissance disponible…



Et ça se retrouve même dans les commentaires PCI.

Combien de fois j’ai pu lire à propos d’une nouvelle version de Firefox censée mieux gérer la ram “mais on s’en fout, qui n’a plus 8go de ram aujourd’hui, lolilol” <img data-src=" />



Autant du côté développement, je peux comprendre qu’une boite préfère économiser en misant sur la puissance pour compenser (c’est pas toujours la faute du développeur si le code est pas optimisé).

Autant côté utilisateur j’ai du mal à comprendre qu’on puisse cautionner la démarche sous prétexte que les machines sont de plus en plus puissantes …



Sauf que mon ancêtre avec son go de ram, il était sur les genoux … c’est quand même con d’en arriver à racheter un multi coeur juste pour aller sur le net <img data-src=" />








arno53 a écrit :



Apres comme dit mon prof d’elec : certes les processeurs ne cessent de diminuer mais les ventilateur ne cessent de grossir ..





Il disait ça dans quel sens ? Parce que c’est plus le fait de rajouter des core (du fait de la place gagner par la finesse de gravure) qui pose problème, mais la finesse en elle même permet de diminuer la dissipation, non ?









-DTL- a écrit :



comparer le TDP un SoC ARM mobile avec un CPU Haswell c’est comme comparer la consommation d’un véhicule écoshell part rapport à un diesel 2 temps Wärtsilä. <img data-src=" />





Non, pas tout à fait.



Il faut comparer les deux plate-formes mobiles complètes.



Dans une plate-forme ARM, l’écran consomme entre 25 et 75% de l’énergie (75%, c’est par exemple sur de grosses tablettes ou des portable format classique ou Netbook).



Si Intel place des processeurs qui consomment 2 fois plus d’énergie que les ARM, l’autonomie baissera, mais pas forcément de façon drastique.



Par ailleurs, si le processeur Intel met 4 fois moins de temps à faire le boulot de l’ARM, il sera plus souvent en idle, en mode basse consommation.



Donc sur un ordi complet, ça commence à vraiment s’approcher.



Par exemple: Intel a déjà fait des démo cette année d’un ordi en 17” tenant 6-7h avec une batterie de 50Wh (de mémoire…). Ca m’a choqué, car l’Ipad 3 a une batterie de 40Wh et tient 8-9h avec une diagonale de moitié. En fait, la conso semble quasiment comparable en excluant l’effet rétina.









brice.wernet a écrit :



Non, pas tout à fait.



Il faut comparer les deux plate-formes mobiles complètes.



Dans une plate-forme ARM, l’écran consomme entre 25 et 75% de l’énergie (75%, c’est par exemple sur de grosses tablettes ou des portable format classique ou Netbook).



Si Intel place des processeurs qui consomment 2 fois plus d’énergie que les ARM, l’autonomie baissera, mais pas forcément de façon drastique.



Par ailleurs, si le processeur Intel met 4 fois moins de temps à faire le boulot de l’ARM, il sera plus souvent en idle, en mode basse consommation.



Donc sur un ordi complet, ça commence à vraiment s’approcher.



Par exemple: Intel a déjà fait des démo cette année d’un ordi en 17” tenant 6-7h avec une batterie de 50Wh (de mémoire…). Ca m’a choqué, car l’Ipad 3 a une batterie de 40Wh et tient 8-9h avec une diagonale de moitié. En fait, la conso semble quasiment comparable en excluant l’effet rétina.





Tu parles d’autonomie “réelle” soit d’un temps quand on parle de TDP qui est une puissance.

Bref on ne parle pas du tout de la même chose d’un point de vu physique. <img data-src=" />



Ce que j’essaie de faire comprendre avec mon analogie c’est que l’on compare des puissances (maximales) sauf que les usages des 2 moteurs n’est absolument pas les mêmes.

L’un est optimisé avant tout pour la consommation quand on demande à l’autre d’être le plus puissant possible.



D’un cote tu dis que l’ecran est gros consommateur, de l’autre tu exclus l’ecran retina, ca manque de coherence, non ? <img data-src=" />



Je voudrais bien voir une vraie etude poussee (et non sponsorisee par Intel ou un fabricant ARM) de la consommation des differents elements d’un telephone et d’une tablette, ca permettrait d’y voir un peu plus clair.



Il y a un truc qu’il ne faut pas oublier : le “form factor” joue enormement. Sur les telephones et les tablettes, tu ne veux pas avoir de refroidissement actif et tu n’as pas beaucoup de place pour dissiper la chaleur degagee. Dans ces conditions meme 10W c’est beaucoup, et je ne suis pas certain qu’on sache faire une tablette sans refroidissement actif utilisant un tel CPU. Perso, je ne veux pas d’une tablette avec ventilo…



En tout cas chapeau bas a Intel <img data-src=" />








ldesnogu a écrit :



Perso, je ne veux pas d’une tablette avec ventilo…





L’Ipad a pas un mini ventilo de quelque millimètre ?









HarmattanBlow a écrit :



Il n’y a pas de delta, il y a un facteur multiplicatif. Quand tu écris un code en dotnet aujourd’hui, tu as la puissance qu’avaient les développeurs C il y a quelques années. Quand tu écris un code en php aujourd’hui, tu as la puissance qu’avaient les développeurs dotnet il y a quelques années. Et ce facteur est loin d’être négligeable.





Pour du langage style Java/.net, la différence de perf est de l’ordre de 1% à 5% au pire, hors cas extrêmement spécifiques. Autant dire rien.



Ce n’est pas parce qu’une génération entière de troll est passée par là à propos à l’époque du Java que ça reste vrai aujourd’hui. Mais ça évidemment il faut avoir un certain recul et une certaine pratique pour le comprendre, ce qui est le plus souvent incompatible avec les “je sais tout sur tout mais j’ai jamais rien fait de concret” qui traînent le plus souvent sur les espaces de discussion ‘mainstream’ du net.







-DTL- a écrit :



Il faut tout de même reconnaitre qu’avant personne n’aurait eu l’idée d’écrire des applications en JS/HTML5 pour faire 2-3 effets kikoolol sur le bureau en local





Tu parles d’un cas isolé et extrême pour en faire une généralité. Exactement comme quand certains avancent que Flash c’est de la merde parce que certains s’en servent à mauvais escient. Ou si je dis que les couteaux il faut les interdire parce que certains s’en servent pour tuer.










Lafisk a écrit :



L’Ipad a pas un mini ventilo de quelque millimètre ?





Non, aucun des 3 modeles n’en a et encore heureux, j’aurais fait un lancer d’iPad sinon <img data-src=" />









brazomyna a écrit :



Pour du langage style Java/.net, la différence de perf est de l’ordre de 1% à 5% au pire, hors cas extrêmement spécifiques. Autant dire rien.



Ce n’est pas parce qu’une génération entière de troll est passée par là à propos à l’époque du Java que ça reste vrai aujourd’hui. Mais ça évidemment il faut avoir un certain recul et une certaine pratique pour le comprendre, ce qui est le plus souvent incompatible avec les “je sais tout sur tout mais j’ai jamais rien fait de concret” qui traînent le plus souvent sur les espaces de discussion ‘mainstream’ du net.





Mouai mais quand tu veux on fait une comparaison de vitesse entre C et Java/.net.



Java et les bidules .net sont surement plus safe et on developpe bien plus rapidement avec eux. Mais dire que la difference de perf est de 1% a 5% la c’est n’importe quoi sauf cas particulier <img data-src=" />



Le principal probleme est que l’immense majorite des developpeurs n’ont strictement plus aucune notion d’architecture CPU et ne savent meme plus ce qu’est un cache ou un pipeline. Du coup ils font n’importe quoi et ce quel que soit le langage.



Y’a quelques annees j’ai fait un cours d’archi CPU a des maitrises d’infos, et la plupart ne comprenait pas l’interet de ce que j’enseignais. J’avais fait un cours similaire quelques annes auparavant et la c’etait la majorite qui voyait l’interet. Java et les weberies etaient passes par la.









brazomyna a écrit :



Pour du langage style Java/.net, la différence de perf est de l’ordre de 1% à 5% au pire, hors cas extrêmement spécifiques. Autant dire rien.



Ce n’est pas parce qu’une génération entière de troll est passée par là à propos à l’époque du Java que ça reste vrai aujourd’hui. Mais ça évidemment il faut avoir un certain recul et une certaine pratique pour le comprendre, ce qui est le plus souvent incompatible avec les “je sais tout sur tout mais j’ai jamais rien fait de concret” qui traînent le plus souvent sur les espaces de discussion ‘mainstream’ du net.



Tu parles d’un cas isolé et extrême pour en faire une généralité. Exactement comme quand certains avancent que Flash c’est de la merde parce que certains s’en servent à mauvais escient. Ou si je dis que les couteaux il faut les interdire parce que certains s’en servent pour tuer.





J’aime bien tes chiffres sortie de nul part…

Moi quand je regarde des comparatifs comme : http://shootout.alioth.debian.org/

Je vois quoi ?

Par exemple pour le test binary-trees N=20 (x86 Ubuntu™ Intel® Q6600® one core)

C GNU CPU : 12.22s Elapsed : 12.24s Memory : 99,448 KB

Java 7 CPU : 15.47s Elapsed : 15.50s Memory : 505,588 KB

Delta CPU : +26,60% Delta Elapsed : +26,63% Delta Memory : +408,39%



Bref Java est un quart plus lent mais surtout consomme presque 5 fois plus de mémoire…



Et pour mon cas “isolé” c’est pourtant ce qu’essaye de populariser (entre autre) microsoft avec “Metro”…









ldesnogu a écrit :



Mouai mais quand tu veux on fait une comparaison de vitesse entre C et Java/.net.





Commence par me déterminer ce que doit être ton test et de définir un usage ‘moyen’ d’un utilisateur ‘moyen’ et on en reparle. Parce que si c’est pour me comparer un superPI en Javascript vs. assembleur, c’est juste ridicule.



Le fait est que contrairement à ce que disait HarmattanBlow avant, le surcoût n’est par une facteur, mais est proche d’une valeur absolue, qui fait que la proportion diminue au fur et à mesure que les perfs d’un CPU moyen augmente.





Java et les bidules .net sont surement plus safe et on developpe bien plus rapidement avec eux



Ce sont deux réalités indéniables (il y en a d’autres: portabilité, …), et dans le domaine pro une barette de RAM ou un serveur supplémentaire est très souvent beaucoup plus rentable que quelques hommes.jour passés à optimiser où à être moins productif avec un langage moins ‘efficient’.





Mais dire que la difference de perf est de 1% a 5% la c’est n’importe quoi sauf cas particulier <img data-src=" />



Depuis l’avènement de la compilation ‘just in time’ (qui date pas d’hier), la différence de perf est pourtant très faible (bien sûr quand on parle d’un langage fortement typé, sinon on compare des choux et des carottes).





Le principal probleme est que l’immense majorite des developpeurs n’ont strictement plus aucune notion d’architecture CPU et ne savent meme plus ce qu’est un cache ou un pipeline. Du coup ils font n’importe quoi et ce quel que soit le langage.



Et on reparle du couteau mal utilisé. <img data-src=" />









-DTL- a écrit :



Par exemple pour le test binary-trees





Et donc ce test est représentatif de ce que fait un ordi en moyenne dans une journée ?



Ou alors, on prend un autre, basé sur les switch de thread (sûrement déjà plus proche de ce qu’un OS moderne fait à longueur de journée):

F# Mono 2.99

C++ GNU g++ 15.63

C GNU gcc 121.65





Et même à ce train là, on a pour le même test des cas d’archi où la version Java est plus rapide que la version C++ et l’inverse sur une autre archi.












brazomyna a écrit :



Commence par me déterminer ce que doit être ton test et de définir un usage ‘moyen’ d’un utilisateur ‘moyen’ et on en reparle. Parce que si c’est pour me comparer un superPI en Javascript vs. assembleur, c’est juste ridicule.





Je suis en partie d’accord avec toi. Je te laisse choisir un truc qui te semble raisonnable et plutot calculatoire bien sur. Un codec ? <img data-src=" />





Le fait est que contrairement à ce que disait HarmattanBlow avant, le surcoût n’est par une facteur, mais est proche d’une valeur absolue, qui fait que la proportion diminue au fur et à mesure que les perfs d’un CPU moyen augmente.



Je ne suis pas d’accord ! Chaque langage impose des contraintes qui font que certaines choses ne pourront jamais etre efficaces et donc le surcout deviendra un facteur, pas un cout fixe. L’absence de pointeurs peut etre un tel obstacle.





Ce sont deux réalités indéniables (il y en a d’autres: portabilité, …), et dans le domaine pro une barette de RAM ou un serveur supplémentaire est très souvent beaucoup plus rentable que quelques hommes.jour passés à optimiser où à être moins productif avec un langage moins ‘efficient’.



Completement d’accord. Mais a un moment il va falloir se poser la question de l’efficacite energetique qui est liee a l’efficacite d’execution.





Depuis l’avènement de la compilation ‘just in time’ (qui date pas d’hier), la différence de perf est pourtant très faible (bien sûr quand on parle d’un langage fortement typé, sinon on compare des choux et des carottes).



D’accord la aussi. On peut meme voir des cas ou grace au JIT un programme Java est plus rapide qu’un programme C++ ecrit a la va-vite. Apres C/C++ etant ce qu’ils sont rien n’empeche de generer du code a la volee, ca va juste prendre un temps enorme en dev <img data-src=" />





Et on reparle du couteau mal utilisé. <img data-src=" />



C’est helas une realite.









brazomyna a écrit :



Et donc ce test est représentatif de ce que fait un ordi en moyenne dans une journée ?





Je suis d’accord que le shootout ne montre pas grand-chose, mais de la a dire qu’il n’y a pas de structures de donnees plus ou moins complexes dans les softs que tu utilises tous les jours, la tu t’egares <img data-src=" /> Regarde un peu la complexite des briques de base necessaires a un browser…









ldesnogu a écrit :



Je suis en partie d’accord avec toi. Je te laisse choisir un truc qui te semble raisonnable et plutot calculatoire bien sur. Un codec ? <img data-src=" />





Parce que ton ordi à la maison passe ses journées à faire du super PI ?

Parce que 95% des besoins en développement, c’est pour implémenter des codecs ?

<img data-src=" />





Je ne suis pas d’accord ! Chaque langage impose des contraintes qui font que certaines choses ne pourront jamais etre efficaces et donc le surcout deviendra un facteur, pas un cout fixe. L’absence de pointeurs peut etre un tel obstacle.



La plupart des langages (même le VB.Net) ont la notion double de passage par valeur ou par référence, ce qui n’est rien d’autre qu’un pointeur derrière ; la vraie différence se situe essentiellement dans la gestion de la mémoire et la notion de GC.

Et tu confonds ‘ne pourra jamais être plus efficace’ d’un côté (ce qui est vrai) et ‘la différence d’efficacité s’estompe en proportion de la puissance disponible’





Completement d’accord. Mais a un moment il va falloir se poser la question de l’efficacite energetique qui est liee a l’efficacite d’execution.



Elle évolue comme la puissance dispo: en augmentant petit à petit, ce qui rend un surcoût fixe de moins en moins énergivore.









ldesnogu a écrit :



Je suis d’accord que le shootout ne montre pas grand-chose, mais de la a dire qu’il n’y a pas de structures de donnees plus ou moins complexes dans les softs que tu utilises tous les jours, la tu t’egares <img data-src=" />





J’ai jamais dit ça. <img data-src=" />





Regarde un peu la complexite des briques de base necessaires a un browser…



Même raisonnement que pour les codecs ou d’autres trucs à calculs très intensifs : que certains besoins spécifiques ne se satisfassent pas de ce type de techno est un évidence sauf pour le kikoolol de 15 ans qui croit que tout est ‘tout noir’ ou ‘tout blanc’ et qu’une solution unique peut se présenter comme la Saint graal pour couvrir tous les besoins.



ça n’en fait pas une généralité pour autant. C’est justement le contraire: ce type de besoin est ultra minoritaire dans la globalité du code qui est écrit chaque jour dans le monde.










brazomyna a écrit :



Pour du langage style Java/.net, la différence de perf est de l’ordre de 1% à 5% au pire, hors cas extrêmement spécifiques. Autant dire rien.





Non, pas du tout, et de loin. Je parle là en ma qualité de développeur qui bosse essentiellement sur dotnet, une plateforme que j’aime beaucoup et que je connais en détail, et qui a utilisé ce dernier pour des applis très gourmandes, dont des réécritures de codes en asm/C/C++, et passé beaucoup de temps sous des profileurs. Qui plus est, ton affirmation me laisse à croire que tu n’as absolument aucune notion sur l’architecture matérielle, l’assembleur x86 et plus généralement ce qui se au niveau CPU et mémoire pour un même algorithme écrit en dotnet et en C, sans quoi tu comprendrais l’absurdité de ton affirmation.





Ce n’est pas parce qu’une génération entière de troll est passée par là à propos à l’époque du Java que ça reste vrai aujourd’hui. Mais ça évidemment il faut avoir un certain recul et une certaine pratique pour le comprendre, ce qui est le plus souvent incompatible avec les “je sais tout sur tout mais j’ai jamais rien fait de concret” qui traînent le plus souvent sur les espaces de discussion ‘mainstream’ du net.



Oui, un certain recul et une certaine pratique, en effet.



brazomyna a écrit :



Commence par me déterminer ce que doit être ton test et de définir un usage ‘moyen’ d’un utilisateur ‘moyen’ et on en reparle. Parce que si c’est pour me comparer un superPI en Javascript vs. assembleur, c’est juste ridicule.



[quote]Le fait est que contrairement à ce que disait HarmattanBlow avant, le surcoût n’est par une facteur, mais est proche d’une valeur absolue, qui fait que la proportion diminue au fur et à mesure que les perfs d’un CPU moyen augmente.





Ton affirmation me fait penser que tu es de ceux qui croient qu’une fois le compilateur JIT passé par là le résultat est le même que celui produit par un code C, ce qui est on ne peut plus faux.



En revanche il est légitime de comparer un code dotnet avec un code C++ moderne utilisant intensivement Boost ou la STL pour implémenter une gestion non-déterministe de la mémoire et autres patterns coûteux. L’écart dans un tel cas est bien sûr plus faible mais toujours pas fixe.









HarmattanBlow a écrit :



Non, pas du tout, et de loin. Je parle là en ma qualité de développeur qui bosse essentiellement sur dotnet […] Ton affirmation me fait penser que tu es de ceux qui croient qu’une fois le compilateur JIT passé par là le résultat est le même que celui produit par un code C





Bref tu sais tout sur moi et ça te donne un bel argument … d’autorité <img data-src=" />



Ben je ne peux que te laisser à tes certitudes alors <img data-src=" />









brazomyna a écrit :



Bref tu sais tout sur moi et ça te donne un bel argument … d’autorité <img data-src=" />





C’est toi qui a commencé par me prendre de haut si tu relis le passage que j’ai précédemment cité. Maintenant, tout ce que je sais de toi c’est que visiblement tu ne comprends rien au sujet dont tu parles. Commence par étudier un peu d’asm puis demande-toi ensuite comme tu implémenterais par exemple la gestion automatisée de la mémoire, la vérification des accès aux tableaux, ou la gestion des exceptions. Puis renseigne-toi sur la façon dont la mémoire est gérée et quelques uns des impacts sur les performances, et comment l’utilisation de références (pointeur vers un pointeur), d’un ramasse-miettes ou la présence d’un header de 12 octets interfèrent avec ça.







brazomyna a écrit :



Ou alors, on prend un autre, basé sur les switch de thread (sûrement déjà plus proche de ce qu’un OS moderne fait à longueur de journée):





La vitesse des changements de contexte ne dépend pas du langage utilisé. <img data-src=" />









HarmattanBlow a écrit :



Maintenant, tout ce que je sais de toi c’est que visiblement tu ne comprends rien au sujet dont tu parles. Commence par étudier un peu d’asm





Je faisais déjà de l’asm sur moto 68k il y a 20 ans de ça, et je bosse dans un domaine parmi les plus contraints (IT, finance, le genre de domaine où on adôôôre perdre des montagnes de pognon en ayant des outils inadaptés aux contraintes lourdes du business et où quand on paie un consultant 1.2k€.jour c’est parce qu’il est notoirement incompétent).



Une paille, vu que tu vas m’apprendre la vie en étant bien persuadé que tu sais tout mieux que tout le monde <img data-src=" />

Ce sera tout pour moi. Il n’y a rien à retirer de ce genre de non-discussion.









brazomyna a écrit :



Et donc ce test est représentatif de ce que fait un ordi en moyenne dans une journée ?



Ou alors, on prend un autre, basé sur les switch de thread (sûrement déjà plus proche de ce qu’un OS moderne fait à longueur de journée):



Et même à ce train là, on a pour le même test des cas d’archi où la version Java est plus rapide que la version C++ et l’inverse sur une autre archi.



Un arbre binaire c’est une structure de donné courante… des tests sur ce genre de structure est donc relativement représentatif de ce que peut faire un programme.



C’est bien de me sortir le test thread ring sauf que sans surprise les 3 premiers sont des langages de programmation concurrente… soit le test taillé sur mesure pour eux.

Et oui le C++ ou le C sont à la “ramasse” dans ce test mais c’est normal ils utilisent des appels système via pthread qui est très couteux.

Alors que Haskell, F# et Erlang peuvent utiliser des threads en userland qui sont très performant pour le test en question. Soit exactement pourquoi ils ont été conçu. Sauf que dans tous les autres tests ils sont à la masse…



Et non Java ne peut pas être plus rapide que du C/C++ car sa VM est basé dessus. Au mieux il peut battre dans un test spécifique une implémentation en C/C++ mais rien de plus. Cela ne sera pas forcément le cas dans face à une autre implémentation.









-DTL- a écrit :



Un arbre binaire c’est une structure de donné courante… des tests sur ce genre de structure est donc relativement représentatif de ce que peut faire un programme.





Non, il est représentatif de ce que fait un programme quand il passe son temps à instancier un arbre à la fois énorme et de la façon la plus brute possible. Ce qui n’est pas représentatif d’un programme moyen et au-delà des tâches les plus courantes demandées à un système global.





C’est bien de me sortir le test thread ring sauf que sans surprise les 3 premiers sont des langages de programmation concurrente… soit le test taillé sur mesure pour eux.



Exact, mais mon contre exemple n’avait d’autre but que de montrer que se baser sur un test unique et spécifique est un non sens.





Et non Java ne peut pas être plus rapide que du C/C++ car sa VM est basé dessus



Et à nouveau tu me fais dire des trucs que je n’ai pas dit. <img data-src=" />





Cela ne sera pas forcément le cas dans face à une autre implémentation.



Et donc on arrive à la façon d’utiliser le couteau qui devient plus importante dans la vraie vie que les caractéristiques du couteau en lui-même (qui ont certes une influence, mais toute relative, hors cas extrêmes ou spécifiques).



C’est bien, on avance <img data-src=" />



Bon brazomyna, visiblement tu ne veux lire que ce que tu as envie pour taper sur les gens on dirait. Je vais quand meme repondre.









brazomyna a écrit :



Parce que ton ordi à la maison passe ses journées à faire du super PI ?

Parce que 95% des besoins en développement, c’est pour implémenter des codecs ?

<img data-src=" />





Alors que je repondais a :



Commence par me déterminer ce que doit être ton test et de définir un usage ‘moyen’ d’un utilisateur ‘moyen’ et on en reparle. Parce que si c’est pour me comparer un superPI en Javascript vs. assembleur, c’est juste ridicule.



Donc oui desole on se tape du temps passe par les dev, ce qui compte c’est ce que les utilisateurs utilisent, ben ouai ca fait ridicule en l’ecrivant hein ? Et OMG les utilisateurs utilisent des CODEC. Dingue hein ? <img data-src=" />



Ensuite tu reponds :





brazomyna a écrit :



J’ai jamais dit ça. <img data-src=" />





dans un contexte ou tu disais qu’une difference de temps d’execution sur un algo d’arbre binaire n’etait pas representatif. Oui j’extrapole, mais des arbres binaires, y’en a partout.



Et ensuite tu embrayes en disant :



C’est justement le contraire: ce type de besoin est ultra minoritaire dans la globalité du code qui est écrit chaque jour dans le monde.



C’est la que tu passes du mode temps de CPU effectue dans le monde a temps de dev, ce qui AMHA n’est pas le sujet de la discussion.



Maintenant ce que tu dis sur la finance m’interpelle. Vous utilisez vraiment du Java en salle de marche ? Je pensais qu’il y avait des contraintes tres fortes de temps reel la-dedans. Java et .net sont bons en temps reel ?









brazomyna a écrit :



Je faisais déjà de l’asm sur moto 68k il y a 20 ans de ça, et je bosse dans un domaine parmi les plus contraints (IT, finance, le genre de domaine où on adôôôre perdre des montagnes de pognon en ayant des outils inadaptés aux contraintes lourdes du business et où quand on paie un consultant 1.2k€.jour c’est parce qu’il est notoirement incompétent).



Une paille, vu que tu vas m’apprendre la vie en étant bien persuadé que tu sais tout mieux que tout le monde <img data-src=" />

Ce sera tout pour moi. Il n’y a rien à retirer de ce genre de non-discussion.





Sauf que même moi, qui pourtant ne suis pas un “vieux”, je sais qu’il a raison dans ces propos contrairement à ce que t’affirmes.









ldesnogu a écrit :



Donc oui desole on se tape du temps passe par les dev, ce qui compte c’est ce que les utilisateurs utilisent, ben ouai ca fait ridicule en l’ecrivant hein ?





Non, ce qui est ridicule, c’est de penser qu’on vit dans un monde infini, celui où les développeurs auront un temps infini pour faires toutes les optimisations possibles et ne s’arrêteront que lorsqu’ils seront sûrs d’avoir mis en oeuvre l’ensemblre des optimisations possibles et ne seront plus limités que par la nature du langage choisi qui ne leur permettra plus d’aller plus loin.





Et OMG les utilisateurs utilisent des CODEC. Dingue hein ? <img data-src=" />



Et pour ça, un lange bas niveau est PARFAIT pour ça. Et (sauf ton postulat dichotomique qui t’amène à croire que si j’argumente en faveur des langages plus haut niveau, je suis forcément contre le bas niveau partout) je n’ai jamais remis en question cet état de fait.

Et OMG, combien de développeurs développent des codecs ? 1% ?





Oui j’extrapole, mais des arbres binaires, y’en a partout.



Comme plein d’autres concepts où pour certains la différence sera nettement moins flagrante





C’est la que tu passes du mode temps de CPU effectue dans le monde a temps de dev



Je ne passe par rien du tout, je dis juste que les perfs intrinsèques dépendent très souvent moins de la qualité de l’implémentation que du langage utilisé, que ça se réduit encore comme peau de chagrin avec le temps et qu’à partir de là, dire que le managé est une connerie universelle est un non sens ridicule.





Maintenant ce que tu dis sur la finance m’interpelle. Vous utilisez vraiment du Java en salle de marche ? Je pensais qu’il y avait des contraintes tres fortes de temps reel la-dedans. Java et .net sont bons en temps reel ?



On a même du VB6 <img data-src=" /> (mais pas pour tout, heureusement <img data-src=" />). Mais d’une façon un peu plus sérieuse, le .net managé est très représenté dans l’IT orientée finance









brazomyna a écrit :



Non, ce qui est ridicule, c’est de penser qu’on vit dans un monde infini, celui où les développeurs auront un temps infini pour faires toutes les optimisations possibles et ne s’arrêteront que lorsqu’ils seront sûrs d’avoir mis en oeuvre l’ensemblre des optimisations possibles et ne seront plus limités que par la nature du langage choisi qui ne leur permettra plus d’aller plus loin.





Et pour ça, un lange bas niveau est PARFAIT pour ça. Et (sauf ton postulat dichotomique qui t’amène à croire que si j’argumente en faveur des langages plus haut niveau, je suis forcément contre le bas niveau partout) je n’ai jamais remis en question cet état de fait.

Et OMG, combien de développeurs développent des codecs ? 1% ?





Comme plein d’autres concepts où pour certains la différence sera nettement moins flagrante





Je ne passe par rien du tout, je dis juste que les perfs intrinsèques dépendent très souvent moins de la qualité de l’implémentation que du langage utilisé, que ça se réduit encore comme peau de chagrin avec le temps et qu’à partir de là, dire que le managé est une connerie universelle est un non sens ridicule.





On est d’accord sur quasiment tout alors <img data-src=" /> Tout ce qui compte a l’arrivee c’est le bon langage avec le bon developpeur pour un truc particulier.



Le point de depart quand meme etait ton affirmation laminaire :





brazomyna a écrit :



Pour du langage style Java/.net, la différence de perf est de l’ordre de 1% à 5% au pire, hors cas extrêmement spécifiques.





Et la tu pourras tourner autant que tu veux autour du pot, c’est juste faux dit comme tu l’as ecrit <img data-src=" />





On a même du VB6 <img data-src=" /> (mais pas pour tout, heureusement <img data-src=" />). Mais d’une façon un peu plus sérieuse, le .net managé est très représenté dans l’IT orientée finance



Ca reste hors salle de marche, j’imagine ? Je pense a tous ces ecrans avec plein de courbes, aux transactions effectuees avec une garantie de 10ms (ou un truc du genre).



EDIT : pfff