Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 17 sur 21 PremièrePremière ... 79101112131415161718192021 DernièreDernière
Affichage des résultats 481 à 510 sur 613

Discussion: Intel Atom

  1. #481
    Citation Envoyé par Møgluglu Voir le message
    Et la mémoire?
    Ils ont 8 slots SODIMM cachés au verso?
    Gagné
    http://www.semiaccurate.com/2010/06/...rvers-10u-box/

  2. #482
    Si on part d'une latence memoire (effective quand le systeme est charge, pas a vide) a 60ns et d'un bus 32 bits avec de la DDR2 800, ca fait 4.7 buffers de 64 bytes (5, ou 10 de 32 bytes j'ai la flemme de regarder la taille de la cache line) selon little's law.
    En pratique je doute que la latence memoire soit si bonne (un Nehalem qui peut taper les 40ns, sera dans les 60ns en charge), donc grosso modo je dirais soit 6 soit 12 buffers a vue de nez pour que ca tourne bien (buffers = miss trackable en parallele ici, tout n'a pas besoin d'etre dans le meme buffer).

    Nvidia sait faire des controleurs memoires corrects, donc je ne serais pas du genre a parier qu'ils n'arrivent pas a tirer ~70% du peak (ils ont l'experience de chipsets ayant une bande passante raisonable).

    Specint est pas trop intensif cote bande passante en moyenne a cote de Specfp (et surtout les versions rate), donc je doute que la bande passante pure soit vraiment une limite a la scalabilite dans le cas qu'on discute (meme si en avoir plus est probablement toujours mieux). L'efficacite du prefetcher a couvrir l'augmentation de latence par contre est assez fondamental dans le cas de Specint.

    Edit: bon en fait ils disent 4 buffers sur le whitepaper, et j'ai trouve des indications disant une line de 32 bytes...
    Support for four data cache line fill requests - further reduces stalls due to memory latency with
    either automatic or user driven prefetching to ensure the availability of critical data.
    Donc effectivement a moins d'avoir des super latences memoire ca ne va pas scaler bien loin, vu que c'est moins de la moitie effectivement necessaire (sauf si bien sur je me suis plante dans mes maths, ou les infos du whitepapre sont incompletes ce qui est probable).
    Dernière modification par fefe ; 15/06/2010 à 00h30.
    fefe - Dillon Y'Bon

  3. #483
    N'essaie pas de déduire des choses sur ma façon de répondre, je ne suis ni designer, ni micro architecte

    Les lignes de cache font 32 octets.

    Pour specfp j'ai un gros souci : je ne pense pas que gfortran soit très bon, et encore moins sur ARM.

  4. #484
    Citation Envoyé par newbie06 Voir le message
    Pour specfp j'ai un gros souci : je ne pense pas que gfortran soit très bon, et encore moins sur ARM.
    Pourquoi, le backend n'est pas exactement celui de gcc?

  5. #485
    Hum, il me semble que gcc ne peut completement s'abstraire de la cible et du front-end, ne serait-ce que parce que certaines constructions sont specifiques a un langage, et/ou que certaines patterns importantes n'apparaissent que dans un langage et sont donc mal optimisees.

    Puis si le back-end etait vraiment independant du reste gcc s'appellerait UNCOL

  6. #486
    Je suis d'accord que les représentations intermédiaires et les optimisations de gcc sont complètement C-centrique (gnat est une catastrophe de ce point de vue). D'ailleurs les comparaisons de perfs d'un même algo écrit dans plein de langages montrent bien ça.

    Mais ça ne devrait pas affecter le backend ARM plus que les autres, à moins qu'il soit aussi encore plus C-centrique que les autres?
    J'aurais dit qu'une fois tout mouliné dans la bouillie intermédiaire de gcc, tu n'as de toute façon plus grand espoirs de retrouver des patterns de haut niveau, mais j'y connais rien en compil...

  7. #487
    T'as raison theoriquement, ca doit etre comme ca. Mais les compilos sont une serie de hacks absolument terribles. En plus certains compilos detectent dhrystone, d'autres des bouts de SPEC, etc. Ouai, ca triche dans tous les sens.

    Bah je verrai bien

  8. #488
    http://emuco.is.ruhr-uni-bochum.de/f..._A9_MPCore.pdf

    Euh je lis bien 150ns de latence memoire (p18) ? J'espere que c'est un artefact lie au fait que ca n'opere qu'a 400MHz... Ils confirment aussi 4 lignes de cache de 32B en parallele...

    Donc avec 1 Channel de DDR2 800 32bits, il te faut 4 cores pour arriver a le saturer (enfin a 66% de bande passante) a moins que les prefetcher aient acces a des buffers separes. Effectivement je commence a voir ce que tu voulais dire a propos du systeme memoire.

    En gros t'as interet a ce que ton dataset tienne dans le L1 ou eventuellement le L2 (qui semble bien lent...) sur le A9 .
    fefe - Dillon Y'Bon

  9. #489
    Oui, c'est triste hein ?

  10. #490
    Disons que pour etre competitif sur le marche des serveurs avec un tel CPU, il va falloir outre les feature de reliability en mettre beaucoup par socket et trouver une solution pour la capacite par socket. Les applis server tiennent rarement dans les caches, et la perf est limite par une combinaison de la latence memoire et de la bande passante (en fonction du nombre de cores) et la ca va etre dur.

    Sur les applis client qui vont bien, tu peux compter sur tes caches pour absorber le manque de perf de ta plateforme: les 512k de L2 sont probablement suffisant a condition d'y avoir une latence et une bande passante raisonable et d'avoir cette capacite par core (et pas partagee comme ici):
    -60ns d'acces au L2 ? Il y a quelqu'un qui a fume grave la. Dans un process recent, une telle structure peut etre accedee en 2ns de plus que le premier niveau sans difficulte, si tu ajoutes un arbitre, change de domaine de frequence/Voltage etc... tu peux monter a 10ns, a voir les graphes on dirait que le L2 tourne a 100MHz et fait 6 cycles d'acces. Meme le L3 des Phenom premiere generation qui etait un peu foire cote latence et faisait plusieurs MB etait a moins du tiers de ca (et incluait le passage dans un L2). J'espere encore une fois que c'est juste parce que la plateforme de test tournait a une frequence beaucoup trop basse.

    Pourtant ce n'est pas si difficile que ca de dimensionner correctement un sous systeme memoire, c'est ce qui est le plus facile a simuler, et honnetement meme sans simulation juste avec little's law on peut faire qq chose de correct. Je suppose qu'il y a d'autres contraintes, comme le fait que de la memoire qui debite consomme tellement de power, que personne dans les segments traditionnels de ARM n'en mettra, et donc que ca ne sert a rien de designer pour.
    fefe - Dillon Y'Bon

  11. #491
    Il ne faut pas oublier une chose : le cache L2 ne fait pas partie de Cortex-A9 ; de plus sur le test-chip il y a eu gros foirage sur la vitesse (si je me souviens bien les data RAM L2 ne tournent pas a la meme vitesse que le reste...).

    Sur Tegra2 @ 1 GHz, la latence L2 est ~25 cycles et la latence RAM < 120 ns (mesures brutalement avec lat_mem_rd 16M ; un Atom 330 @1.6 semble etre a 15 cycles sur le L2 et a 130ns sur la RAM [j'ai du pousser le stride a 8K pour bloquer le prefetcher]). Je ne mentionnerai pas la bande passante RAM avec un bus 32-bit, c'est pas la peine.

    Quant au dimensionnement du sous-systeme memoire, tu as mis le point sur le probleme : les clients traditionnels ne sont pas vraiment interesses. C'est en train de changer avec de nouveaux acteurs qui ne sont pas dans la telephonie...

  12. #492
    Est-ce que le fait de passer par un interconnect générique genre AXI peut ajouter un surcoût significatif aussi?

    Edit: intéressant, c'est déjà plus raisonnable. Ça confirme que NVIDIA savent (encore) faire des contrôleurs mémoire à peu près décents... Même si 95ns de plus que le L2 ça fait encore beaucoup?
    Dernière modification par Møgluglu ; 16/06/2010 à 11h11.

  13. #493
    Un interconnect generique peut ajouter de la latence, mais si correctement dimensionne ne doit pas brider la bande passante. Dommage qu'A9 n'ait pas un L2 integre

  14. #494
    25 cycles, nettement mieux pour un cache non integre, meme si ca reste un peu lent: 15 cycles est bien lent pour un cache integre non partage de cette taille la, meme quand on serialise les tag lookups et data access pour economiser du power (mmm encore une phrase bien francaise). En fait ce qui fait un peu peur c'est que non seulement le nombre de cycles est eleve, mais qui plus est la frequence est faible.

    Pour les acces memoire 120-130ns est un peu lent mais vu que tu fais un stride de 8k tu passes ton temps a faire des page miss ce qui doit ajouter un peu plus de 20ns a la latence par rapport a un cas plus normal comme page empty ou page hit (tu ne reussiras jamais a monter tres haut non plus en bande passante en enchainant les page miss).

    Donc pour l'analyse que je faisais cis-dessus, la latence appropriee serait donc dans les 90-100ns donc la situation pour la bande passante est clairement meilleure pour Tegra, meme si ca reste assez mauvais dans l'absolu.

    Pour ce qui est de l'interconnect generique, a moins qu'il tourne a une frequence pitoyable, tu ajoutes 1 cycle d'encodage a l'entree 1 cycle de decodage a la sortie au maximum par rapport a un reseau dedie surtout a ces frequences. Le reste est domine par du delai RC qui est le meme pour tout le monde, a moins que ton reseau aime faire des detours. Voila donc ca fait +4 cycles au pire. Le changement de domaine si il y a un BGF (si tes domaines tournent a des frequences differentes et qu'il faut que tu fasses du flow control) il te faudra 3 a 4 cycles dans chaque direction (dont certains peuvent s'overlap avec des cycles dedies a encoder pour un interconnect generique). J'arrive a 12 cycles, 2 cycles d'arbitrage=14, ca fait un cache a 11 cycles si integre et non partage, bref c'est raisonable meme si ca devrait etre faisable en 7-8 a ces frequences la tant que le L1 est rapide.
    fefe - Dillon Y'Bon

  15. #495
    Question alacon du jour : j'ai toujours suppose que les divers Atom etaient identiques ; par exemple les Atom sans support 64-bit ont le materiel pour sauf qu'il est debraye par un fuse quelconque. Me gourre-je ?

  16. #496
    Je pense que c'est le cas.
    Mes propos n'engagent personne, même pas moi.

  17. #497
    Quand il s agit de cache, d'ios specifiques ou du nombre de core, on peut toujours se poser la question si la version castree est une version moins couteuse du die, produite afin d etre ecoulee en grande quantite. Quand les transistors relatifs a la fonctionalite desactivee ne sont pas facilement isolables sur un des cotes du die il ne reste que 2 options:
    - dans cette version du die un bug (ou une feature pas completement validee) qui n etait pas fixe au moment des premieres ventes est fixe dans des stepping posterieurs. Pour eviter d avoir un nom de ligne de produit qui ne represente pas les fonctionnalites, tous les dies de cette ligne de produit continueront a avoir cette fonction desactivee. Tout die de la nouvelle ligne de produit avec un numero de connu produit different aura cette fonction activee.
    -Differentiation de produit par desactivation de hardware fonctionnel a l'aide d'un fuse a des fins commerciales. C'est une pratique courante dans de nombreuses industries (automobile j ai oui dire), Intel est connu pour le faire, AMD a tendance a ne pas le faire sur autre chose que le nombre de die a ma connaissance.

    Je suspecte que les points que tu mentionnes appartiennent a la 2 eme categorie.
    fefe - Dillon Y'Bon

  18. #498
    Ma question va un peu plus loin en fait. Jusqu'a quel point peut-on debrayer (sur la chaine) le 64-bit ? Je pense en terme de power. J'imagine assez que la filasse ne peut etre "coupee" pendant la gravure, mais du moment que ca ne toggle pas, ca ne consommera rien sinon de la place. On doit aussi pouvoir concevoir certaines des unites fonctionnelles pour supporter du 32- ou 64-bit avec une intrusion minimale. Mais qu'en est-il de tous les registres (au sens architectural et au sens Verilog) ?

    Je ne cherche pas forcement la reponse pour Atom, je me doute que ca tient du secret industriel

  19. #499
    Je suis a peu pres certain que toute la logique ou presque liee a la partie haute des 64 bits est clock gatee, donc la consommation active en mode 32 bits sera la meme (d'ailleurs que ce soit la version 64 bits ou 32 bits, l execution de code 32 bit devrait generer le meme power dynamique) quel que soit le die.

    De meme, le leakage est quasi certainement present.

    De maniere general, mettre une power gate pour couper le leakage ne vaut le coup que si la capacitance derriere ta power gate est elevee, et bien entendu ce n'est faisable que si les fonctionnalites sont contigues. Un banc de registre aujourd'hui est bien trop petit pour justifier l ajout d une power gate autour (encore moins 1/2 banc de registre). L'ajout d'une power gate force generalement a augmenter le voltage (lorce que ce qui est derriere la gate est allume) a cause des pertes de la gate et c'est pour ca que ce n est rentable que sur des gros blocs (sans parler du fait qu il faut de la logique pour la controler).

    Qui plus est eliminer le leakage vaut le coup quand tu depenses 20 a 40% de ton power total dans des courants de fuite afin d avoir un process rapide. Considerant les marches cibles d'Atom je suis a peu pres certain qu'ils utilisent un process lent qui leak peu et fournit un argument supplementaire pour le: vraiment pas de difference.

    Bref je suppose que c'est un fuse qui permet d alterer le fonctionnement de la reponse a CPUID, point final. Apres si tu executes du code 32 bits sur une version 32 ou 64 bits tu ne devrais pas voir de difference de power a supposer que tes dies viennent de la meme region d un waffer.

    Tu peux remplacer 64 bits par a peu pres toutes les fonctions qui ne sont pas vraiment isoleees dans un coin du die, et dont le modele d utilisation et la capacitance ne permet pas de justifier la presence d une power gate.
    fefe - Dillon Y'Bon

  20. #500
    Bon j'ai des résultats SPECint pour l'Atom, mais ça me chagrine un peu : j'aimerais pouvoir bloquer la fréquence du CPU plus bas que 1.6 GHz, parce que scaler les 1.6 -> 1 sur le papier pour comparer à l'A9 c'est pas fair-play. Quelqu'un a une idée ?

  21. #501
    Citation Envoyé par newbie06 Voir le message
    Bon j'ai des résultats SPECint pour l'Atom, mais ça me chagrine un peu : j'aimerais pouvoir bloquer la fréquence du CPU plus bas que 1.6 GHz, parce que scaler les 1.6 -> 1 sur le papier pour comparer à l'A9 c'est pas fair-play. Quelqu'un a une idée ?
    Via un contrôle de speedstep il n'y a pas moyen ?

    @+, Arka



  22. #502
    Le 330 n'a pas speedstep il me semble...

  23. #503
    Citation Envoyé par newbie06 Voir le message
    Le 330 n'a pas speedstep il me semble...
    Ha, oui, tu as raison, erreur de ma part, ça me semblait tellement "basique" pour ce genre de processeur que je n'ai pas pris la peine de vérifier, erreur fatale.



  24. #504
    Oh mais c'est pas ta faute, je n'avais pas precise que j'utilise un 330

  25. #505
    Sans changer la clock de base tu auras du mal vu que tu n as pas acces au multiplieur.

    La methode classique:
    tu changes un peu ta frequence de base, mesure la perf de ton bench aux 2 frequences, calcule ta courbe de Amdahl a partir des 2 points et infere quelle serait ta perf a 1GHz. Bien sur il faut le refaire a chaque benchmark et pas sur le score global, et le scaling ne sera pas exactement le meme en changeant le multiplieur et la b-clock, mais ca ne devrait pas etre tres loin ( a plus ou moins 5%, surtout sur un truc regulier comme spec).
    fefe - Dillon Y'Bon

  26. #506
    Citation Envoyé par newbie06 Voir le message
    Oh mais c'est pas ta faute, je n'avais pas precise que j'utilise un 330
    Oui oui, mais je pensais naïvement (quand on considère le passif d'Intel) que tout les Atom avaient cette fonction.



  27. #507

  28. #508
    Y a t-il moyen d'avoir un ordre d'idée du genre d'optimisation que fait -march=atom dans GCC4.5 sans se palucher le code ? Je veux dire, un genre de synthèse rapide. Parce que d'habitude, ils s'arrangent pour optimiser la présentation des instructions par rapport à la prédiction et l'OOO, mais là, ya pas d'OOO.

    Cette question peut être élargie aux autres -march, mais dans l'immédiat, c'est sur un atom que je me pose la question.
    Mes propos n'engagent personne, même pas moi.

  29. #509
    Ca bouge le support Atom en ce moment, Intel y a colle de ses inges.

    Par ailleurs, contrairement a ce que tu dis, un processeur in order profitera mieux d'un bon scheduling de code, qu'un OoOE. Il est donc relativement important de bien decrire les pipes et les diverses contraintes.

    Voila ca ne repond pas a ta question, desole.

    ---------- Post ajouté à 16h00 ----------

    Citation Envoyé par Møgluglu Voir le message
    Une bataille ARM-Xilinx vs. Intel-Altera qui s'annonce?
    http://www.anandtech.com/show/3929/i...system-on-chip
    En fait non, Altera a aussi pris un Cortex-A9

  30. #510
    Je suppose que gcc doit commencer par désactiver SSE2 sur Atom.

    Citation Envoyé par newbie06 Voir le message
    En fait non, Altera a aussi pris un Cortex-A9
    Wabon?...
    Bravo, j'ai plus qu'à me mettre à l'ARM (j'ai encore le temps d'ici à ce que ces trucs sortent).

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
  •