Deux Athlon Low Voltage chez AMD

Publié le 05 septembre 2008 , par Tanguy Andrillon - mis à jour le 05 juillet 2009 à 19h - dans Hardware

Courant novembre, AMD devrait dévoiler deux nouveaux processeurs basse consommation, l'Athlon 2650E et l'Athlon X2 3250E.

>> Retour à l'article <<

Réactions


lesnikov - le 06/09/08 à 02:51
au moins avec ces deux la on est sûr de ne pas avoir un i945 comme chipset lol
loxmab - le 06/09/08 à 09:34
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..
alexko - le 06/09/08 à 09:43
Je pense que c'est plutôt destiné au marché desktop, en effet...
[Ctrl][Alt][Suppr.] - le 06/09/08 à 10:42
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 - le 06/09/08 à 12:54
Ce n'est pas au compilateur de multithreader ton appli ; un tel choix a trop de conséquences sur l'architecture d'un soft pour que ça puisse être automatisé. Avoir une appli C# utilisant plusieurs cores est tout à fait possible. Par contre +1 sur la lourdeur de certains langages. J'aurais plutôt cité Java en exemple, ou comment utiliser un CPU récent pour avoir des perfs de 486...
SartMatt - le 06/09/08 à 13:16
tfpslyJ'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.] - le 06/09/08 à 13:34
tfpslyCe n'est pas au compilateur de multithreader ton appli ; un tel choix a trop de conséquences sur l'architecture d'un soft pour que ça puisse être automatisé. Avoir une appli C# utilisant plusieurs cores est tout à fait possible.
C'est pourtant un des objectifs de .NET d'améliorer la découverte de parallélisme, mais de ce que j'en ai vu jusqu'à présent, un Visual C# pond des exe horriblement lourds car remplis de symboles, y compris en release... pour le coup VC++6 pondait du code machine nettement plus condensé et donc à la fois moins gourmand en mémoire (RAM comme stockage, un comble quand on sait que pas mal d'applis PPC sont réalisées via .NET) et beaucoup plus prédictible car le contrôle de parallélisme était 100% fait par du code écrit. 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?
SartMatt - le 06/09/08 à 13:49
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.
tfpsly - le 06/09/08 à 14:45
SartMattC'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
Non. Dans tout ce qui est très exigeant en calcul, Java peut encore être environ 8 fois plus lent. Java s'est beaucoup installé en SSII/informatique "générale" grâce à ses libs assez fournies et sa verbosité/rigidité (que je déteste d'ailleurs) ; et les gains financiers en terme de dév enj effet (mais qui s'explique aussi par la difficulté de trouver des bons dévs C++). Je n'ai volontairement pas parlé de C# dans mon précédent message car il est un bon cran au dessus en performances. C'est d'ailleurs le langage qui commence à monter dans le JV : code propre et basé sur des design patterns, support D3D "natif"...
SartMattJava 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).
Désolais, ce n'est pas ce que j'appelle du rapide wink
SartMattUne 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
Wine y arrive pourtant bien, sans émulation ni recompilation : c'est vraiment un remplacement des appels systèmes.
CtrlAltSuppr.C'est pourtant un des objectifs de .NET d'améliorer la découverte de parallélisme, mais de ce que j'en ai vu jusqu'à présent, un Visual C# pond des exe horriblement lourds car remplis de symboles, y compris en release... pour le coup VC++6 pondait du code machine nettement plus condensé et donc à la fois moins gourmand en mémoire (RAM comme stockage, un comble quand on sait que pas mal d'applis PPC sont réalisées via .NET) et beaucoup plus prédictible car le contrôle de parallélisme était 100% fait par du code écrit.
C# fournit des outils de base pour gérer plusieurs threads, ainsi que des "façon de faire" pour éviter des dead-locks par exemple. Par contre oui pour le moment, rien n'arrive proche de code compilé par un bon compilo. A moins d'avoir à attendre des données externes (DB, réseau...), aucun langage interprété ou JIT ne peut suivre en terme de performances aujourd'hui. Un simple exemple : un Celeron peut être presque aussi rapide qu'une TNT en faisant du rendu software utilisant le SSE à fond. Voir SoftWire de Nicolas "Nick" Capens et Pixomatic : http://www.flipcode.com/archives/11-12-2002.shtml http://www.radgametools.com/pixomain.htm
CtrlAltSuppr.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
C'est également vrai pour Java qui y arrive bien wink
SartMattAvec 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.
Il me semble que Momo n'a toujours pas un framework .Net complet. Mais je peux me tromper sur ce point. En termes de perfs, Momo a aussi du retard sur la plateforme .Net Windows.
tfpsly - le 06/09/08 à 14:46
SartMattMais 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.
Les commentaires sur ce document sont clos.
  • Tout
  • Hi-Tech
  • Matériel
  • Mac
  • Jeux