Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 15 sur 30 PremièrePremière ... 5789101112131415161718192021222325 ... DernièreDernière
Affichage des résultats 421 à 450 sur 883
  1. #421
    Tu mets quelques dizaines de microsecondes a t'allumer et a t'eteindre sur un processeur moderne (l'essentiel du temps est passe a flusher les caches a l'eteignage et monter le voltage a l'allumage, sauver et restaurer l'etat ne prend pas beaucoup). En utilisation bureautique classique la majorite du temps les cores sont eteints, pareil pendant le playback video/audio.
    En gros si ton utilisation cpu vue depuis le taskmanager windows descend a 0 tu as certainement eteint le core un moment.
    Apres si tu as une pub flash, il y a de bonnes chances que tu n'aies aps le temps de rentrer dans le mode ou tu eteint le core donc tu payeras les courants de fuite sur tout le core, donc un core plus gros dissipera plus a process et conditions d'operation equivalents. Les courants de fuite sont a peu pres multiplies par 0.75 pour un noeud de process donc peut compenser un core plus gros d'1/3 (qu'un processeur dans un noeud de process plus ancien).

    Apres le leakage est exponentiel avec la temperature (10x de 10 a 100C, 2x de 100 a 110 pour donner une idee de la forme), proportionnel a V^2, et change dramatiquement suivant la revision du process (dans le meme noeud). Un processeur dans un process 2x plus lent pourra avoir entre 4 et 8x moins de courants de fuite.

    Tout ca pour dire qu'essayer d'estimer des courants de fuites entre 2 competiteurs sans un banc de mesure bien fait est mission quasi impossible, et que les quelques % (ou dizaines de %) de differences entre un core avec un decodeur plus petit ou plus gros disparait completement face aux autres parametres pour ce qui est des courants de fuite.
    fefe - Dillon Y'Bon

  2. #422
    Tiens, aussi, truc intéressant :

    les implémentation ARM pures (A9) sont synchrones sur les cores (comme en X86, non ?) alors que les implémentations Qualcomm ne le sont pas, et pour eux c'est un gros avantage.

    Vous en pensez quoi ?

    Sinon, dixit ARM, un A9 à 1 GHz (1 core), c'est équivalent à un dual A9 à 550 MHz en puissance, mais le dual n'a que 60 % de la conso. Et vu les graphs qu'ils montrent, les CPU sont assez chargés dès qu'on fait un truc basique comme du surf.

  3. #423
    Citation Envoyé par dandu Voir le message
    Sinon, dixit ARM, un A9 à 1 GHz (1 core), c'est équivalent à un dual A9 à 550 MHz en puissance, mais le dual n'a que 60 % de la conso. Et vu les graphs qu'ils montrent, les CPU sont assez chargés dès qu'on fait un truc basique comme du surf.
    Moui, enfin, c'est comme tout les dual core : il faut que le programme/système utilise de manière efficiente plusieurs threads. Le résultat d'ARM me parait très théorique.



  4. #424
    dans les demos, sous Android 3.0 je crois, ça marchait. Puis bon, les implémentations habituelles, c'est 2x1 GHz, aussi

  5. #425
    La raison pour laquelle un dual a 550 = 60% de la conso d'un simple core a 1GHz est qu'ils changent le voltage quand ils reduisent la frequence (comme tout le monde, c'est pour ca que faire des quad core n'est pas particulierement difficile si tu es pret a payer la surface...). Sur un bon process la frequence est proportionnelle au voltage jusqu'au voltage minimum (pour 40% de voltage en moins tu perds 40% de frequence, c'est la theorie: en pratique tout le monde perd plus de frequence que le voltage ne descend), et la conso est lineaire avec V^2F. Vu ce qu'ils annoncent soit 30% de la conso pour un core en divisant la frequence par presque 2, ca devrait reduire la conso d'un facteur 5 par core et ils obtiennent ~3 => le process ne scale pas aussi bien que ca avec le voltage: pas trop surprenant car je doute qu'ils aient plus d'un facteur 1.4 sur leur voltage entre le max et le min pour une perte de frequence de 1.8x (1GHz=>0.55).
    fefe - Dillon Y'Bon

  6. #426
    Qu'entends-tu par synchrone ? Que les CPU ne tournent pas à la même fréquence ?

    Sinon les browsers font partie des applications bien threadées non ? Du coup baisser la fréquence et répartir la charge sur deux coeurs pour gagner du power est intéressant. Bien sûr si les pages qu'on regarde sont pleines de JS et autre Flash, là pas le choix faut remonter la fréquence.

  7. #427
    oui, la fréquence des cores.

    Qualcomm explique que leurs appareils ont des cores qui ne sont pas à la même fréquence, alors que les Cortex A9 ont leurs fréquences liées. Et, dixit Qualcomm, ça permet des gains intéressants en consommation.

    Ce que j'ai vu, c'est des benchs classiques en js, temps de chargement de pages, etc., avec en plus un lecteur de musique en arrière plan (radio en ligne)

    ---------- Post ajouté à 17h12 ----------

    Citation Envoyé par fefe Voir le message
    La raison pour laquelle un dual a 550 = 60% de la conso d'un simple core a 1GHz est qu'ils changent le voltage quand ils reduisent la frequence (comme tout le monde, c'est pour ca que faire des quad core n'est pas particulierement difficile si tu es pret a payer la surface...). Sur un bon process la frequence est proportionnelle au voltage jusqu'au voltage minimum (pour 40% de voltage en moins tu perds 40% de frequence, c'est la theorie: en pratique tout le monde perd plus de frequence que le voltage ne descend), et la conso est lineaire avec V^2F. Vu ce qu'ils annoncent soit 30% de la conso pour un core en divisant la frequence par presque 2, ca devrait reduire la conso d'un facteur 5 par core et ils obtiennent ~3 => le process ne scale pas aussi bien que ca avec le voltage: pas trop surprenant car je doute qu'ils aient plus d'un facteur 1.4 sur leur voltage entre le max et le min pour une perte de frequence de 1.8x (1GHz=>0.55).
    La question serait, est-ce que c'est plus intéressant de descendre deux ores à 550 MHz ou garder un core à une fréquence plus élevée (genre 800 MHz) et descendre un autre très bas pour une tache annexe.

  8. #428
    Dans le cas de Qualcomm, la tension reste la même pour tous les cores, non?

    Du coup, le gain théorique est simplement linéaire, pas en n³.

    Le plus intéressant pour la conso serait d'avoir des multi-cœurs hétérogènes, en utilisant des cœurs basse conso (comme par exemple l'ARM 7 du Tegra 2) pour les tâches annexes. Mais je suppose qu'on en est pas là.

  9. #429
    pour la tension, je ne sais pas trop, pour les cores hétérogènes, Texas se lance la dedans avec l'OMAP5, qui a deux A15 et deux M4

  10. #430
    Citation Envoyé par Møgluglu Voir le message
    Dans le cas de Qualcomm, la tension reste la même pour tous les cores, non?

    Du coup, le gain théorique est simplement linéaire, pas en n³.

    Le plus intéressant pour la conso serait d'avoir des multi-cœurs hétérogènes, en utilisant des cœurs basse conso (comme par exemple l'ARM 7 du Tegra 2) pour les tâches annexes. Mais je suppose qu'on en est pas là.
    Faux. Les cores ont tous la meme tension chez Intel et AMD et le gain est en n^3 . Il te suffit de pouvoir eteindre les cores individuellement quand ils sont idle avec une power gate.
    fefe - Dillon Y'Bon

  11. #431
    Citation Envoyé par fefe Voir le message
    Faux. Les cores ont tous la meme tension chez Intel et AMD et le gain est en n^3 . Il te suffit de pouvoir eteindre les cores individuellement quand ils sont idle avec une power gate.
    Certes.
    Mais ça, tous les SoC à base de Cortex A9 le font, non?

    Qualcomm semble insister sur le cas où tous les cores sont actifs avec des charges déséquilibrées.

    Du coup, est-ce qu'ils ont raison de permettre la désynchronisation des fréquences de chaque core, ou est-ce que la stratégie "hurry up and get idle" avec power gating indépendant n'est pas plus efficace?

  12. #432
    La desynchronisation des frequences aide quand tu as un workload heterogene du point de vue des besoins en efficacite energetique ou du point de vue de la scalabilite avec la frequence, sinon "race to halt" gagne.
    Peut etre que dans l'embarque c'est commun mais dans les PC et serveurs ces cas d'heterogeneite sont assez rares. Les workloads heterogenes classiques peuvent etre geres par la methode classique d'eteindre le core quand inactif et garder tout le monde au meme voltage.

    L'autre benefice important du voltage different est de compenser la variabilite du process de fabrication de maniere plus efficace. En pratique 2 cores pourront atteindre la meme frequence avec des voltages differents, si tu n'as qu'un rail tu es oblige d'utiliser le voltage le plus eleve des 2 et ca genere des perte supplementaires. Le pire ton process sera du point de vue de la variabilite, le mieux ce sera d'avoir des rails independants.

    L'inconvenient des rails independants est que ca augmente la latencec de communication entre les cores, vu qu'il faut introduire des BGF entre les domaines (bubble generating fifo).
    fefe - Dillon Y'Bon

  13. #433
    Pour le fun, une news Intel.

  14. #434
    C'est Siemens ou Intel ?
    fefe - Dillon Y'Bon

  15. #435
    Infineon, j'ai vu la puce en question au MWC et tiqué sur le ARM11, le gars m'a très sérieusement expliqué que c'était pas un CPU généraliste et que les CPU Intel étaient mieux :D

  16. #436
    Même Intel (hors Infineon ou autre rachat) a des licenses pour certains coeurs ARM. Par exemple, 11 MPCore. Je me demande à quoi ça leur sert (ou a servi). Mais c'est vrai qu'ils peuvent toujours utiliser l'argument que ce sont des coeurs deeply embedded

  17. #437
    Citation Envoyé par fefe Voir le message
    Tu mets quelques dizaines de microsecondes a t'allumer et a t'eteindre sur un processeur moderne (l'essentiel du temps est passe a flusher les caches a l'eteignage et monter le voltage a l'allumage, sauver et restaurer l'etat ne prend pas beaucoup). En utilisation bureautique classique la majorite du temps les cores sont eteints, pareil pendant le playback video/audio.
    En gros si ton utilisation cpu vue depuis le taskmanager windows descend a 0 tu as certainement eteint le core un moment.
    Apres si tu as une pub flash, il y a de bonnes chances que tu n'aies aps le temps de rentrer dans le mode ou tu eteint le core donc tu payeras les courants de fuite sur tout le core, donc un core plus gros dissipera plus a process et conditions d'operation equivalents. Les courants de fuite sont a peu pres multiplies par 0.75 pour un noeud de process donc peut compenser un core plus gros d'1/3 (qu'un processeur dans un noeud de process plus ancien).

    Apres le leakage est exponentiel avec la temperature (10x de 10 a 100C, 2x de 100 a 110 pour donner une idee de la forme), proportionnel a V^2, et change dramatiquement suivant la revision du process (dans le meme noeud). Un processeur dans un process 2x plus lent pourra avoir entre 4 et 8x moins de courants de fuite.

    Tout ca pour dire qu'essayer d'estimer des courants de fuites entre 2 competiteurs sans un banc de mesure bien fait est mission quasi impossible, et que les quelques % (ou dizaines de %) de differences entre un core avec un decodeur plus petit ou plus gros disparait completement face aux autres parametres pour ce qui est des courants de fuite.
    En d'autres termes, l'avantage d'ARM sur la consommation au repos serait plus lié aux optimisations de l'architecture et du process qu'au jeu d'instructions ?
    Mon blog (absolument pas à jour) : Teχlog

  18. #438
    Ca me semble etre une meilleure maitrise de l'architecture de tous les composants sur le SOC. Intel fait ca en plein de chips avec des IOs qui consomment, et rendent la gestion de l'allumage/eteignage de tous les composants plus difficile ainsi que leur integration.

    Donc je dirais que la plus grosse difference vient de l'archi de la plateforme.
    fefe - Dillon Y'Bon

  19. #439
    Citation Envoyé par newbie06 Voir le message
    Sinon les browsers font partie des applications bien threadées non ? Du coup baisser la fréquence et répartir la charge sur deux coeurs pour gagner du power est intéressant. Bien sûr si les pages qu'on regarde sont pleines de JS et autre Flash, là pas le choix faut remonter la fréquence.
    Non. La plupart des navigateurs ne le sont pas, c'est actuellement l’exception plutôt que la règle*. Ça devrait changer assez vite**, mais c'est pas encore le cas. Tu me dira, le dual-core est encore l’exception sur les plate-formes où on trouve de l'arm.Les deux ont des chances d'arriver "en masse" sur le marché à peu près en même temps.

    *C'est actuellement principalement le cas de chrome et de ses dérivés
    **Firefox 4, IE9, etc...



  20. #440
    Ha ? Mon Firefox 3.5 là il fait tourner 10 threads sans compter le lecteur flash.

  21. #441
    Citation Envoyé par newbie06 Voir le message
    Ha ? Mon Firefox 3.5 là il fait tourner 10 threads sans compter le lecteur flash.
    Multithread oui, bien threadé, moi je trouve pas non plus. Les blocage sont nombreux, L'UI a souvent du mal, mon quad se tourne les pouces : à l'usage on a plutôt l'impression que tout se fait séquentiellement et que rien ou presque n'est parallélisé. Quant au plugin flash pas mieux, combien de fois je l'ai vu bouffer 100% d'un seul core...
    Pour moi il y a encore beaucoup de boulot avec Firefox.

    edit: actuellement, mon Firefox 3.6 fait tourner 24 thread.

  22. #442
    C'est vrai que ces threads semblent ne rien foutre...

  23. #443
    Infos sur les Xilinx à base de Cortex-A9 :
    7 series
    Zynq-7000

  24. #444
    Je viens de comprendre un truc.
    Désormais, Xilinx n'intègrent plus de cores CPU hard dans ses FPGA. Les PowerPC sont remplacés par rien du tout (en pratique, par du Microblaze en soft pour les 3 pelés qui se servaient des PPC).

    À la place, ils lancent une nouvelle gamme de produit : Zynq, qui n'est pas un FPGA, mais un SoC avec une partie reconfigurable. Et ça ne vise probablement pas les mêmes marchés que les FPGA avec cores CPU précédents.

    C'est bien plus radical que j'imaginais, en fait.

    Sinon, c'est pas le bon topic, mais leur techno d'interconnexion par silicon interposer a l'air prometteuse :
    http://www.xilinx.com/support/docume...Technology.pdf

  25. #445
    Je trouve plutôt amusant que MS fasse maintenant des previews sur ARM : IE10.

  26. #446
    Peut être une réponse à intel qui pousse fortement meego...

  27. #447
    En même temps, NVIDIA pousse très fortement Android et a juré après le fiasco Tegra 1 qu'on ne les y reprendrait plus à suivre Microsoft, donc c'est pas non plus l'amour fou de ce côté.

  28. #448
    Tegra 1 était visé pour être avec un OS microsoft?

  29. #449
    Citation Envoyé par Møgluglu Voir le message
    En même temps, NVIDIA pousse très fortement Android et a juré après le fiasco Tegra 1 qu'on ne les y reprendrait plus à suivre Microsoft, donc c'est pas non plus l'amour fou de ce côté.
    Heu, je crois que tu te trompes sur les relations nVidia - MS. La démo d'IE10 a été faite sur un Tegra 2, et le focus pendant le dév de T2 était très orienté Windows Mobile.

  30. #450
    Citation Envoyé par Møgluglu Voir le message
    En même temps, JHH pousse très fortement Android et a juré après le fiasco Tegra 1 qu'on ne l'y reprendrait plus à suivre Microsoft, donc c'est pas non plus l'amour fou de ce côté.
    Voilà, c'est corrigé.

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
  •