c'est bien mais si c'est pour remettre(refourguer ) des batteries qui n'ont que le nom, ca sert a rien. sinon ca en en desktop son succes dependra du prix de l'ulta (+/-)value..

C'est là qu'on se dit que la concurrence n'a pas forcément que du bon... 15w voire 22w c'est le niveau auquel on devrait être pour des CPU normaux, comme à l'époque des P54c et leurs 17w. Pour préciser ma pensée, ça fait des années que le soft est très loin de suivre le hard, d'ailleurs avec le multi-cores on touche vraiment le fond puisque les outils sont devenus tout simplement médiocres (framework .NET et les compilateurs associés en tête, ou comment renre un exe 4x plus gros que nécessaire et plus lent en mono-core qu'un vrai code vaguement optimisé mais pas pour autant plus rapide en multi-cores)

tfpsly

J'aurais plutôt cité Java en exemple, ou comment utiliser un CPU récent pour avoir des perfs de 486...

C'est quand même un peu dépassé ce genre d'arguments contre Java... Java a énormément progressé sur le plan des perfs, et aujourd'hui, lors du portage d'applications métier C/C++ vers Java, il n'est pas rare de perdre seulement 5-10% de perfs au départ, ce qui n'est vraiment pas mal si tu considères que les versions Java sont "neuves" alors que les versions C/C++ ont des années d'optimisation derrière elles... Et encore, là c'est les pertes qu'on a en faisant une compilation en bytecode, mais il est aussi possible de faire une compilation native (mais on perd alors la portabilité du binaire), qui réduit encore cet écart. Et cette petite perte de perfs est compensée par le gain financier sur le temps de développement, la maintenabilité, la portabilité, etc... J'ai par exemple connu un cas où le portage d'une appli métier en Java a fait économiser sur le coût des licences et du support OS : tant que le métier était en C, le fournisseur OS se disait "il pourront pas changer d'OS, donc je peux les faire payer plein pot", mais une fois que c'est passé en Java, il a été mis en concurrence et les prix ont fondu... Même pour du HPC ou des applications à haute disponibilité et qui doivent répondre vite, le Java est souvent un bon choix. Par exemple, quand tu vas faire un test d'éligibilité ADSL sur n'importe quel site français, derrière c'est deux applis Java chez FT qui répondent (plus de 2M de requêtes par jour), avec des temps de réponse de l'ordre de 200ms, en travaillant sur des bases de données de plusieurs dizaines de Go). Il n'y a quasiment que pour la 3D et le multimédia que le Java est encore à la peine, mais ça viendra probablement un jour...

Ctrl-Alt-Suppr.

Au final il ne reste à .NET qu'une pseudo-portabilité, car en pratique tout le framework "client" doit être lui-même porté sur l'OS/CPU cible, et à ce niveau autant réécrire des compilateurs... (surtout que bon, C#/C++, la différence n'est pas extraordinaire côté langage, et qui n'a pas au moins un compilateur C, lui-même déjà pas mal avancé, pour son CPU?

Pour porter du C++, il faut aussi que toutes les librairies qu'on utilise existent pour la plateforme vers laquelle on veut porter, et ça c'est loin d'être le cas à 100%. Un exemple tout bête : DirectX. Une appli en C++ qui utilise DirectX, pour la porter sous Linux, une simple recompilation ne suffira pas, il faudra tout adapter pour remplacer les appels à des API DirectX par des appels à des API équivalentes sous Linux. Avec le C# par contre, tu peux faire une appli 3D qui, sans recompilation, s'exécutera en DirectX avec le framework .NET Microsoft sous Windows et en OpenGL sous Linux avec le framework Mono. De toute façon, il n'existe aucun langage qui puisse être porté d'un OS à un autre sans recompiler au minimum des outils (VM, interpréteur...). Mais si ce n'est que les outils qu'il faut recompiler, l'appli est bel et bien portable (quelqu'un qui a l'appli sans son code source PEUT la faire passer d'une plateforme à l'autre), alors que dès qu'il faut recompiler des bouts de l'appli, c'est mort pour la portabilité, on est obligé de fournir plusieurs binaires si on veut pas livrer le code source.

SartMatt

Mais si ce n'est que les outils qu'il faut recompiler, l'appli est bel et bien portable (quelqu'un qui a l'appli sans son code source PEUT la faire passer d'une plateforme à l'autre), alors que dès qu'il faut recompiler des bouts de l'appli, c'est mort pour la portabilité, on est obligé de fournir plusieurs binaires si on veut pas livrer le code source.

Ce qui serait également vrai pour le C++ si toutes les plateformes respectaient Posix et utilisaient des API portables pour le reste.