Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 12 sur 21 PremièrePremière ... 24567891011121314151617181920 ... DernièreDernière
Affichage des résultats 331 à 360 sur 613

Discussion: Intel Atom

  1. #331
    Citation Envoyé par newbie06 Voir le message
    Ouai mais tu ne peux pas coller deux autocollants "Intel Inside" et "Intel OS Inside" sur un MID, y'a pas la place.
    100% Intel, ça rentre

    Moi j'ai toujours pas compris à quoi ça servait ces trucs-là, mais bon...

  2. #332
    Citation Envoyé par Alexko Voir le message
    Moi j'ai toujours pas compris à quoi ça servait ces trucs-là, mais bon...
    Ha mais si, quand tu vas au petit coin et que t'as pas envie de lire, tu prends ton MID et tu surfes. C'est bô la technologie !

  3. #333
    J'en connais qui, dans ces circonstances, prennent leur laptop 15" voire 17" :D

  4. #334
    Ca c'est un coup à se cramer à un endroit sensible

  5. #335
    Je ne suis pas le seul à penser ça, mais je ne sais pas si je dois m'inquiéter de penser comme les types de The Inquirer

    http://www.theinquirer.net/inquirer/...axis-crumbling

  6. #336
    "La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24

  7. #337
    Amusant le nom du newser, il est pré-destiné à couvrir la sortie de LRB lui...
    J'ai posté un lien sur le topic en HD, Ion + Atom N330 passe bien pour de la lecture BR, mais est insuffisant pour de l'upscaling SD>HD, ou BR avec filtre externe pour avoir les sous-titres (qui désactive l'accélération par l'IGP). Je vous le remets ici.

  8. #338
    Citation Envoyé par Yasko Voir le message
    Amusant le nom du newser, il est pré-destiné à couvrir la sortie de LRB lui...
    On est au fond du bac, je me suis fait exactement la même réflexion
    "La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24

  9. #339
    Bon, j'ai fait des mesures sur mon Lenovo T61...
    Idle power: XP 10.5W, Vista 11.5W, Linux 18W (tous avec les derniers SP/ kernels etc...). Sans appel imo, sachant que l'autonomie est generalement determinee par le power idle. En charge par contre ca devient comparable (je dirais que c'est normal).
    fefe - Dillon Y'Bon

  10. #340
    Hé bien ça prouve qu'on ne m'a raconté que des âneries...

    Quelle version de Linux était-ce ? Version du kernel ? Le module cpufreq était-il correctement chargé et activé ?

  11. #341
    OpenSuse, 2.6.29, oui. Et de toutes facons ce n'est pas le CPU qui est responsable de la difference, le power du cpu est le meme entre XP et linux (j'ai des breakdowns detailles), par contre le reste ce n'est pas le cas (certains composants ont l'air peu ou pas power managed).
    fefe - Dillon Y'Bon

  12. #342
    Lamentable. A quand un support complet de l'ACPI et des drivers video au point ?
    En plus Linux est supporté par le constructeur sur cette gamme ?

  13. #343
    Oui, et ce n'est pas moi qui le developperai, et oui (ils distribuent Suse dessus).

    Tu oublies les drivers wireless dans la liste .
    fefe - Dillon Y'Bon

  14. #344
    Citation Envoyé par fefe Voir le message
    le power du cpu est le meme entre XP et linux
    Autrement dit, le mode tickless ne sert à rien?
    Si tu fais un coup de powertop, tu as un driver qui réveille le CPU toutes les 10ms?

    Ou bien parce que les latences de changement de C-state ont diminué sur Merom/Penryn par rapport à Dothan, le tickless n'a plus autant d'influence?

  15. #345
    Citation Envoyé par Møgluglu Voir le message
    Autrement dit, le mode tickless ne sert à rien?
    Si tu fais un coup de powertop, tu as un driver qui réveille le CPU toutes les 10ms?
    Ca sert un peu en fait, mais ce qui est economise (quelques dizaines de miliwatts en moyenne) est negligeable face a ce qui est mal gere. L'amelioration des C-states et la rapidite de transition a du empieter sur ces benefices oui.
    L'instrumentation pour mesurer le power est hardware au niveau des voltage regulators, l'OS n'a aucune idee que je suis en train de mesurer le power donc normalement mon influence est minime (et la meme quelle que soit l'OS).
    fefe - Dillon Y'Bon

  16. #346
    Citation Envoyé par fefe Voir le message
    L'instrumentation pour mesurer le power est hardware au niveau des voltage regulators, l'OS n'a aucune idee que je suis en train de mesurer le power donc normalement mon influence est minime (et la meme quelle que soit l'OS).
    OK.
    Sympa de pouvoir mesurer au niveau des VR, quand les ploucs comme nous doivent se contenter de la pince ampèremétrique sur le 12V.

    Mais je pensais plutôt à un driver existant genre wireless ou USB qui provoque plus de changements de C-states que nécessaire, ce que powertop détecterait facilement.

  17. #347
    Si c'etait le cas, le power du CPU serait nettement plus eleve. Il prend ~0.3W du total sous XP et Linux (le double sous vista). Meme si des optims seraient encore possible, ce n'est pas dans le CPU que tu economiseras les 7.5W de difference... Mais plutot dans ton northbridge, southbridge, wireless, HDD, VR, ou le delta avec XP est >500mW (jusqu'a plus d'1W pour certains).

    A vue de nez je dirais aussi que les fonctions d'eco d'energie de la memoire ne sont pas utilisees non plus sous linux (ou mal).

    Apres il est peut etre possible de mieux configurer les drivers etc (je suis particulierement ignorant de ce genre de choses vu que je n'ai pas cherche)... Pour faire tout ca, mais quand c'est un OS propose par le constructeur on pourrait s'attendre a ce que ce soit fait par defaut (ou par un outil de configuration fourni).

    Donc le probleme n'est pas le CPU, juste tout le reste (a part etonnament l'audio ).
    fefe - Dillon Y'Bon

  18. #348
    Je sais pas si ça a un rapport, mais je sais que sous Fedora ils ont modifié en profondeur la gestion du son par PulseAudio précisément pour éviter des réveils continus, et donc réduire la consommation.
    "La vaseline, c'est un truc que j'utilise systématiquement" - vf1000f24

  19. #349
    Citation Envoyé par fefe Voir le message
    Il prend ~0.3W du total sous XP et Linux (le double sous vista)
    Ah ouais quand-même

    Donc à l'échelle de la plate-forme, Atom n'apporte strictement rien en conso par rapport à Core 2 (on s'en doutait, mais je pensais pas à ce point-là...)
    La conso crête est différente, mais un C2D bloqué à la tension/fréquence mini ne doit pas monter bien haut non plus...

  20. #350
    Un C2D ULV exploite dans les memes conditions qu'atom a besoin d'environs 2.5x le budget. Ca demande un packaging et un solution de refroidissement beaucoup plus couteuse donc (et un die ulv coute beaucoup plus aussi, peu de dies/waffer ont les caracteristiques recquises).
    Dernière modification par fefe ; 02/07/2009 à 19h17.
    fefe - Dillon Y'Bon

  21. #351
    Ceci dit, ca confirme les impressions que j'avais, il y'a bien eu aucun effort de fait dans l'économie de puissance sur 'tout le reste' alors que coté CPU, ca a fait d'énormes efforts ...

    D'ou aussi les différences entre un Apple et un 'simple' PC à partir du moment ou la machine Apple est sans doute tripatouillée aux petits oignons pour maximiser la batterie (et/ou minimiser la puissance requise)

  22. #352
    En lisant le x64/IA-32 optimization reference manual (http://www.intel.com/Assets/PDF/manual/248966.pdf), je tombe par hasard sur les latences/débits d'Atom, pourtant soigneusement planquées dans une section à part.

    Le ADDPD de SSE2 (addition double packed) est fait en microcode en 5 cycles non recouvrables sur les 2 unités...
    Du coup il est bien plus rentable de faire 2 ADDSD (débit de 1, unité 1) quitte à bouffer un registre de plus...
    Quand à MULPD il n'ont même pas osé l'inclure dans la table... [edit: si ailleurs dans la doc: 9 cycles]

    Quand on parlait d'implémenter en microcode les instructions-legacy-X86-exotiques-que-plus-personne-n'utilise-de-toute-façon, je pensais pas que ça incluait l'addition SSE2.

  23. #353
    Les instructions packed de SSEx ont toujours ete lentes lorsque implementees sur des machines qui n'avaient pas des unites et un datapath de 128 bits (avant Merom chez Intel). Atom n'y echappe pas, mais pas plus que les vieux P3, Banias, P4 (dans une moindre mesure, le datapath etait de 128 bits et les unites de 64), le K7 etc... Atom est un processeur recent avec beaucoup des defauts des vieilles generations de x86, d'ailleurs c'est pour ca qu'il assez peu difficile, a mon avis, de predire quelles ameliorations lui seront apportees dans les futures generation

    En pratique une partie de la latence est recouvrable sur la plupart de ces archis, je ne sais pas exactement ce qu'il en est d'atom mais ca serait surprenant qu'ils blockent les 5 cycles du pipeline, 3-4 probablement (1 par moitie + 1 a 2 pour bouger les donnees).

    Si tu as du code packed et que tes donnes sont dans des registres 128 bits, tu n'iras pas plus vite que les instructions microcodees etant donnee qu'il te faudra shuffle la partie haute vers la partie basse pour utiliser les SD et reshuffle a l'arrivee a moins que tu les reschedule a la mimine. Bien sur si tu recompiles tout ton programme pour employer SD (et uniquement 64 bits des registres) ca ira plus vite, mais remplacer "betement" les instructions packed par du scalar ne devrait rien gagner.
    fefe - Dillon Y'Bon

  24. #354
    http://www.semiaccurate.com/2009/07/...r-atomic-bomb/

    14 SoC en cours de design @32nm, ça va être intéressant... Ou pas

  25. #355
    Citation Envoyé par fefe Voir le message
    Les instructions packed de SSEx ont toujours ete lentes lorsque implementees sur des machines qui n'avaient pas des unites et un datapath de 128 bits (avant Merom chez Intel). Atom n'y echappe pas, mais pas plus que les vieux P3, Banias, P4 (dans une moindre mesure, le datapath etait de 128 bits et les unites de 64), le K7 etc...
    Je n'ai plus les chiffres pour tous ces CPU, mais sur Dothan et P4 le débit est divisé par 2 et la latence augmente de 1 cycle (ou débit/4 et 2 cycle pour MULPD sur Dothan), je suis d'accord que c'est optimal étant donné les ressources dispo.

    Alors que Atom est quand-même pire :

    En pratique une partie de la latence est recouvrable sur la plupart de ces archis, je ne sais pas exactement ce qu'il en est d'atom mais ca serait surprenant qu'ils blockent les 5 cycles du pipeline, 3-4 probablement (1 par moitie + 1 a 2 pour bouger les donnees).
    C'est pourtant ce que dit la doc:
    ADDPD xmm, xmm: latency 6, throughput 5, units Both
    MULPD xmm, xmm: latency 9, throughput 9, unit ??
    (aprés c'est fort possible que les deux unités ne soient pas utilisées à fond pendant les 5/9 cycles)

    Ils confirment à un autre endroit que ce n'est pas pipeliné:
    Citation Envoyé par Intel
    Note that packed double-precision instructions are not pipelined, using two scalar double-precision instead can achieve higher performance in the execution cluster.
    Si tu as du code packed et que tes donnes sont dans des registres 128 bits, tu n'iras pas plus vite que les instructions microcodees etant donnee qu'il te faudra shuffle la partie haute vers la partie basse pour utiliser les SD et reshuffle a l'arrivee a moins que tu les reschedule a la mimine.
    J'ai l'impression que c'est exactement ce que le microcode fait.

  26. #356
    Citation Envoyé par Møgluglu Voir le message
    Je n'ai plus les chiffres pour tous ces CPU, mais sur Dothan et P4 le débit est divisé par 2 et la latence augmente de 1 cycle (ou débit/4 et 2 cycle pour MULPD sur Dothan), je suis d'accord que c'est optimal étant donné les ressources dispo.
    Dothan avait un datapath et des registres 64 bits donc pas besoin de shuffle la partie haute du registre vers l'unite. Mais le multiplieur DP n'etait pas completement pipeline...
    P4 c'est un peu plus complique, mais en gros tu as un datapath de 128 bits et une unite 64 bits, et pas besoin d'employer de shuffle vu que le datapath le fait tout seul entre les registres et l'unite. Tout etait pipeline sur P4.

    Alors que Atom est quand-même pire :

    C'est pourtant ce que dit la doc:
    ADDPD: latency 6, throughput 5, units Both
    MULPD: latency 9, throughput 9, unit ??
    (aprés c'est fort possible que les deux unités ne soient pas utilisées à fond pendant les 5/9 cycles)
    Atom est in order, une instruction implementee en microcode va couter plus cher que si le programmeur l'ecrivait vu que le microcode ne peut pas reordonnancer les instructions alors que le programmeur le peut. Sur une archi OOO il y a beaucoup d'instructions microcodees mais tu ne le vois pas vraiment grace au reordonnancement. En plus tout est sur le meme port d'execution ou presque donc chaque instruction de microcode bouffe de la bande passante.

    Bref vaut mieux compiler en scalar sur Atom , mais ce n'est pas sense etre une brute en FP. Tiens d'ailleurs je n'ai pas regarde, mais quelles sont les capacites flottantes d'un Cortex-A* ou autre cpu visant a etre integre dans des netbooks ?
    fefe - Dillon Y'Bon

  27. #357
    Citation Envoyé par fefe Voir le message
    Tiens d'ailleurs je n'ai pas regarde, mais quelles sont les capacites flottantes d'un Cortex-A* ou autre cpu visant a etre integre dans des netbooks ?
    A8 a une FPU lite (en français ça se traduit par "de merde") non pipelinée. L'unité SIMD (NEON) peut sortir deux opérations SP par cycle (mais pas de DP).
    Sur A9, la FPU est meilleure mais est toujours single issue. NEON est le même que sur A8.

  28. #358
    OK.
    J'avais regardé vite fait le jeu d'instruction VFP, et je me demandais à quelle genre d'archi le concepteur pouvait bien penser en écrivant le jeu d'instruction (un unfused multiply-add, pas de rint mais un div et un sqrt, pas de min/max...)
    En fait il y a juste un additionneur et un multiplieur en hard, le reste est fait en soft?
    Dernière modification par Møgluglu ; 22/07/2009 à 22h25.

  29. #359
    Le fused MA arrive dans la prochaine révision de l'architecture.
    Quant au rint il est bien présent, il s'appele VCVT.
    Et tout est fait en hard.

    Je me demande quelle doc tu as lue...

  30. #360
    Citation Envoyé par newbie06 Voir le message
    Le fused MA arrive dans la prochaine révision de l'architecture.


    Et tout est fait en hard.
    Même la division/sqrt? Ça peut effectivement avoir un intérêt pour la conso...

    Je me demande quelle doc tu as lue...
    L'ARM (Architecture Reference Manual, ah ah) de l'ARMv5:
    http://infocenter.arm.com/help/index...00i/index.html

    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.

    Edit: NEON n'a effectivement rien à voir avec VFP, NEON est en simple précision seulement et n'a pas de division (VCVT c'est un lrint, rien à voir )
    Dernière modification par Møgluglu ; 22/07/2009 à 23h51.

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
  •