Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 13 sur 21 PremièrePremière ... 356789101112131415161718192021 DernièreDernière
Affichage des résultats 361 à 390 sur 613

Discussion: Intel Atom

  1. #361
    Citation Envoyé par Møgluglu Voir le message
    Même la division/sqrt? Ça peut effectivement avoir un intérêt pour la conso...
    Oui c'est fait en hard, mais pas pipeliné bien entendu.

    L'ARM (Architecture Reference Manual, ah ah) de l'ARMv5:
    http://infocenter.arm.com/help/index...00i/index.html
    Oulà c'est comme si tu parlais du P6 là Ca a bien évolué depuis, sauf que les docs... Un peu d'infos ici.

    Je m'y perd un peu entre NEON, VFP, les numéros de version des archi, des micro-archi, des implémentations, les extensions... C'est pire que les SSE, vos trucs.
    Ouai c'est le foutoir, mais franchement, pas plus tard qu'hier j'essayais de trouver quand certaines features x86 avaient été introduites... Et je n'y suis pas parvenu, bien que je sois loin d'être un handicapé en Googlerie.

  2. #362
    Citation Envoyé par newbie06 Voir le message
    Ouai c'est le foutoir, mais franchement, pas plus tard qu'hier j'essayais de trouver quand certaines features x86 avaient été introduites... Et je n'y suis pas parvenu, bien que je sois loin d'être un handicapé en Googlerie.
    Tu peux toujours demander ici
    fefe - Dillon Y'Bon

  3. #363
    En fait ce qui me gêne là-dedans c'est que depuis 20 ans (=PowerPC) la façon habituelle d'introduire de l'arithmétique flottante dans une archi est de partir d'un FMA, rajouter du contrôle, des chemins de bypass et autres bricoles autour (<10%) pour les autres instructions flottantes IEEE (add, mul, comparaisons, conversions, min, max, mov, abs, neg...) voire entières (mad, add, mul, shifts...)
    Ensuite implémenter la division et le reste en soft.
    Le jeu d'instruction est construit en pensant à l'archi de la FPU.

    Alors que l'approche suivie par NEON ça a l'air de créer un jeu d'instruction top cool pour l'entier et la virgule fixe, puis de l'étendre au flottant en mettant un ".f32" après chaque instruction... C'est beau, c'est orthogonal, ça fait jeu d'instruction RISC comme dans les bouquins, sauf que les instructions les plus utiles en entier ne le sont pas forcément en FP et vice-versa, idem pour la complexité d'implémentation et le partage de hardware...
    (qu'on me dise pas que c'est pour être future-proof : s'il y a un diviseur hardware alors c'est que les instructions d'estimation d'inverse et d'étapes de Newton-Raphson sont déjà obsolètes...)

    Et l'approche suivie par VFP, j'essaie toujours de la comprendre.

    (oui j'aime taper sur les petits )

  4. #364
    Il y a peu de jeux d'instructions qui supportent la comparaison avec PowerPC et Altivec . En fait meme les autres jeux d'instructions RISC comme Alpha ou SPARC supportent mal la comparaison si tu jettes un oeil sur le jeu d'instruction SIMD...
    fefe - Dillon Y'Bon

  5. #365
    Les copieurs qui sont arrivé après comme l'Itanium ou le GT-200 ont fait pas mal pour les modes d'arrondi aussi...

    Mais visiblement IBM compte bien conserver sa longueur d'avance : la FPU décimale du Power6 est franchement impressionnante : quad-precision (Decimal128), 8 modes d'arrondi, quantisation et arrondi explicites, précision des exceptions ajustable...
    Leur implémentation actuelle est franchement lente, mais en même temps ils s'en foutent tant que tous leur concurrents utilisent du soft à la place.

    Vivement que des constructeurs de CPU un peu plus "mainstream" suivent, ou au moins backportent le mode d'arrondi "Prepare for Shorter Precision" vers la FP binaire...
    Mais vu le temps qu'il a fallu pour (ne pas) avoir le FMA, je me fais pas trop d'illusions.

    (Après savoir s'il est utile d'implémenter la FP décimale en hard est un autre débat. Et vive le HS.)

  6. #366
    J'ai trouvé ça par hasard en regardant une news sur Moblin, un linux développé (en partie) par Intel pour les netbooks.
    C'est quoi cette histoire de compatibilité uniquement sur Atom ?
    Ils n'auraient pas rompu la sacro-sainte compatibilité x86 tout de même ? C'est une histoire de drivers ?

  7. #367
    C'est pas un atom qui faut, c'est le GMA, stout.
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  8. #368
    OK, c'est donc bien une histoire de drivers.

  9. #369
    Je sais ce n'est pas un Atom, mais c'est dans ce thread qu'on a le plus parle de Linux et d'autonomie de batterie. Pour ceux qui etaient encore sceptiques apres les donnees que j'avais publiees, encore un autre point avec un Lenovo W500: http://hardware.slashdot.org/story/0...-Poor?from=rss

    45 minutes avec install Ubuntu de base, 1h 30 avec tweaks. XP de base 3 heures...

    Comme le post Slashdot le suggere, Apple arrive a avoir une tres bonne autonomie avec un BSD donc c'est juste une question de maturite du power management sous Linux, meme avec les laptops des constructeurs qui supportent Linux...
    fefe - Dillon Y'Bon

  10. #370
    Citation Envoyé par fefe Voir le message
    Comme le post Slashdot le suggere, Apple arrive a avoir une tres bonne autonomie avec un BSD donc c'est juste une question de maturite du power management sous Linux, meme avec les laptops des constructeurs qui supportent Linux...
    Préliminaire : je n'ai pas lu le thread, ni ne tente de défendre à tout prix Linux

    Pourquoi penser qu'il s'agit d'une propriété de l'OS plutôt qu'une propriété/interaction des drivers avec l'OS ? On sait très bien qu'Apple exige d'avoir accès au code source des drivers avant de valider un HW pour leur plateforme, leur intégration est donc bien plus poussée que ce que n'importe quel fournisseur de driver Linux fait.

  11. #371
    Pour moi les drivers font parti de 'OS. Blamer les drivers en disant que ce n'est pas de la faute a l'OS c'est juste une maniere de dire que ton OS n'est pas mature... L'OS c'est ce qui permet d'utiliser ton hardware. Avoir des bouts qui sont super avances c'est bien, avoir des bouts qui rendent le tout inutilisable, ca rend l'OS inutilisable.

    Linux ce n'est pas juste un scheduler...

    Donc oui c'est un probleme de driver et de capacite a leur dire dans quel etat le device est suppose etre (donc un peu plus que les drivers). Et oui Apple fait le bon choix, ils veulent controler l'ensemble de ce qui touche au hard et ont toute l'infrastructure pour le gerer...

    PS: je n'ai rien contre Linux, j'utilise tous les jours, mais pas sur un Laptop...
    fefe - Dillon Y'Bon

  12. #372
    Avec les militaires il y a toujours quelque chose à craindre, à moins d’être mort.

  13. #373
    C'est bien de voire qu'il y a des gens qui bossent dessus .
    fefe - Dillon Y'Bon

  14. #374
    Surtout que c'est loin d'être à limiter seulement aux laptops et périphériques mobiles ... Moins consommer, ça intéresse tous les usages, non ?

  15. #375
    Les serveurs oui, les desktop nettement moins: Ca n'economise pas grand chose sur la note d'electricite d'un particulier pour une utilisation normale (bien sur c'est plus ecolo).
    fefe - Dillon Y'Bon

  16. #376
    Malgré tout, avec le passage à l'échelle, c'est toujours ça de gagné.

  17. #377
    [Troll]
    De toute façon, vu le taux d'utilisation de Linux pour les particuliers, même une réduction de 50% de la consommation ne ferait qu'une goutte d'eau dans la mer.
    Sans parler que le niveau à atteindre est à des années lumières du niveau actuel: je n'ai jamais vu un portable sous Linux tenir ne serait ce que la moitié du temps qu'il tient sous Windows.
    [/troll velu]
    There are only 10 types of people in the world: Those who understand binary, and those who don't.

  18. #378
    http://www.pcinpact.com/actu/news/53...burst-hugi.htm

    Certaines choses font un peu sourire, on a l'impression qu'Intel vient de découvrir qu'on pouvait couper le power sur les parties inutilisées d'un SoC. Je suis impressionné.

  19. #379
    Il y a une difference entre eteindre une partie de la puce alimentee par un VR externe en le coupant et les "embedded power gate" dont il parle.
    fefe - Dillon Y'Bon

  20. #380
    C'est ce transparent qui m'a fait sourire : http://www.pcinpact.com/affichage/53...hugi/75860.htm

    Bon OK, ça me fait sourire parce que j'ai discuté de très exactement ça avec un architecte de chez TI. Et comme je ne me considère pas comme bien malin, ça me fait rire que ce soit présenté comme un truc tip top, s'tout

  21. #381
    Ce slide est vide de nouveautes je suis d'accord , d'ailleurs un slide de Transmeta d'il y a 10 ans contiendra la meme chose .
    fefe - Dillon Y'Bon

  22. #382
    L'Atom pour la télé : CE4100
    http://www.intelconsumerelectronics....uct_Brief_.pdf

    Question bête (encore plus que d'habitude, j'ai une sale migraine) : pourquoi 7-9W pour 1.2 GHz ?

  23. #383
    C'est assez logique, on a (un peu) plus qu'un couple Poulsbo/Atom Z dans la même puce.

    Pour le CPU lui-même, c'est environ 2 W et environ 2,5 W pour le chipset, mais ici on a en plus un décodeur HD de plus (a priori), un IGP plus rapide et une partie southbridge plus complète (y a du SATA). La différence me parait pas irréaliste, surtout que le SpeedStep est pas nécessairement activé dans le CPU (pour un TV, c'est pas nécessaire)

  24. #384
    Je ne suis toujours pas convaincu : on a des boards complètes avec de l'OMAP3 qui consomment 2W et c'est du 65nm (je suis conscient que le CE4100 est plus performant, n'empêche...). Ou bien Intel a décidé, étant donné le segment, de ne pas faire trop d'effort pour réduire le power afin de réduire les coûts ?

  25. #385
    Le probleme est surtout de savoir ce que represente 7-9W. Si c'est un "TDP" calcule en allumant tous les elements du SOC a fond afin de donner l'enveloppe thermique du machin ce n'est pas tres etonnant, si c'est ce que ca consomme en utilisation typique ca fait un peu beaucoup. De toutes facons a 7-9W dans le type de boite auquel c'est destine ca passe tres bien en passif donc tu n'as aucun interet a essayer de le reduire.

    Autre chose, vu que tu as un facteur 2 entre des bons et mauvais die en power (plus si tu prends les dies vraiment tres bon et vraiment tres mauvais, mais tu n'en as pas en quantite), il est possible que le TDP soit fixe de maniere a garantir un yield important vu que le marche en question n'a que faire de 3 ou 4 watts de moins. Tant que personne ne va et mesure le power de tes systemes et se rend compte que tu en as a 3W et d'autres a 7W ca ne se sait pas .

    PS: plus tu pousse le process pour monter a haute vitesse plus ces phenomenes s'amplifient donc a 1.2 c'est peut etre pas ca.
    fefe - Dillon Y'Bon

  26. #386
    Merci, là je comprends mieux

    Néanmoins j'ai une question à ajouter : le 45LP doit être plus cher à produire que du 45 plutôt orienté performances, non ? Ce qui pourrait aussi jouer dans ce cas, permettant de conclure sereinement que ce chiffre de conso n'indique vraiment rien de rien

  27. #387
    Pas vraiment, mise a part des considerations de volume. Les process low power sont generalement juste tweakes pour reduire le leakage de maniere significative en sacrifiant de la vitesse. En general tu sacrifies x% de leakage pour 2x% de frequence et tant que tu ne tentes pas de trop pousser ta frequence ou limiter trop le power ce n'est pas vraiment plus cher en soi.
    Les process tweakes pour descendre a tres bas voltage sont eux beaucoup plus couteux (tu as probablement remarque la difference de prix entre les produits LV et ULV).
    fefe - Dillon Y'Bon

  28. #388
    Est-ce que ces choix de process ont une influence sur la performance/difficulté des IO et des parties analogiques du SoC (genre DAC vidéo...)? Ou c'est orthogonal?

  29. #389
    Les difficultes du cote analogique sont generalement exacerbees par les technologies destinees a ameliorer les performances des circuits digitaux a bas voltage oui. En revanche certains constructeurs font des choix dans leur process qui les amenent a etre meilleurs sur les circuits analogiques tout en conservant de bonnes perfs a bas voltage sur les circuits digitaux, mais en general ils sacrifient beaucoup de vitesse potentielle sur ces derniers.

    Donc il y a des dependances, mais aussi des possibilite de reduire ces interdependances.

    Les process differents d'un meme constructeur ne sont generalement que des revisions d'un meme process employant les memes materiaux. Tu as une certaine liberte dans la definition de ces revisions, mais nettement moins de parametres que lors de la definition du process de base.

    Par exemple: les fondeurs comme TSMC produisent beaucoup de circuits embarquant de l'analogique, alors que Intel va produire essentiellement du digital. Leurs process respectifs sont optimise pour leurs applications les plus courantes, et finalement derives pour s'adapter aux divers besoins des "clients".
    fefe - Dillon Y'Bon

  30. #390
    Est-ce à dire que ça va devenir de plus en plus casse-tête à mesure qu'on intègre de plus en plus dans les CPU ? Interfaces mémoire, liens HT/QPI, PCI-E/DMI, etc.

Page 13 sur 21 PremièrePremière ... 356789101112131415161718192021 DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •