Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 23 sur 26 PremièrePremière ... 13151617181920212223242526 DernièreDernière
Affichage des résultats 661 à 690 sur 764
  1. #661
    La RAM serait sur l'arrière de la CG, donc pas génial mais pas catastrophique non plus.

  2. #662

  3. #663
    Super, il va falloir une nouvelle carte-mere pour Sandy Bridge
    Et le 6 coeurs sera un EE, donc Extremely Expensive.
    Je me demande si je ne dois pas commencer a regretter mon X58.

  4. #664
    Citation Envoyé par newbie06 Voir le message
    Super, il va falloir une nouvelle carte-mere pour Sandy Bridge
    Pour un utilisateur de SoC soudés sur le PCB, tu es bien difficile.
    Au fur et à mesure qu'on rajoute des bouts de chipset dans le CPU, il faut bien qu'on en enlève de l'autre côté...

    Déjà je trouve très fort qu'on arrive avec juste 3 ou 4 sockets différents à avoir autant de CPU avec un nombre de canaux mémoire, PCIe, QPI différents, un TDP, nombre de cores, répartition des domaines de tensions core/uncore différents, etc.

  5. #665
    Citation Envoyé par newbie06 Voir le message
    Super, il va falloir une nouvelle carte-mere pour Sandy Bridge
    Et le 6 coeurs sera un EE, donc Extremely Expensive.
    Je me demande si je ne dois pas commencer a regretter mon X58.
    Mais non, c'est le Westmere qui sera un EE dans sa version 6-core. Sandy Bridge c'est la génération suivante (le tock). Du coup, le 6-core sera probablement le haut de gamme normal, avec le 8-core en EE. Et bon, c'est 2011 quand même, donc c'est pas étonnant qu'il faille changer de carte-mère.

  6. #666
    Changer de carte-mere tous les deux ans, ca me gave. Ouai OK ce n'est pas specifique a Intel, mais ca me gave quand meme.

    Quand aux SoC soudes sur PCB, quand une machine complete te coute 150 Euros, soit moins qu'une CM, ca passe mieux

  7. #667
    En presque 20 ans et une bonne 12 aine d'achats de PC avec des processeurs AMD, Cyrix et Intel, je n'ai jamais reussi a upgrader sans changer CPU et carte mere (je dois etre un sacre boulet !):
    -soit la plateforme avait change et on etait force d'en racheter une
    -soit les cartes meres avaient evolue suffisament (genre PCI vs VLB ou AGP vs PCI) pour justifier l'achat d'une nouvelle carte mere meme si cela n'etait pas obligatoire.

    Ca fait 20 ans que je vois du monde se plaindre de l'incompatibilite de sockets, d'une generation a l'autre, et 20 ans que ca n'a aucun sens de mettre un nouveau processeur sur une plateforme depassee. Les overdrives des annees 90 me font encore rire, mais apparament il y a encore de la demande pour mettre un processeur moderne dans une plateforme qui le ralentira suffisament pour rendre l'upgrade inutile. Le temps des performances venant uniquement du CPU est revolu depuis vraiment longtemps (performance != spec).

    Bien entendu je ne change pas de CPUs tous les 6 mois, la ca aurait peut etre un interet (mais les plateformes ne changent pas tous les 6 mois non plus).

    Dans les prochaines annees tu verras la DDR4 arriver, des nouvelles versions de SATA qui pourront tirer parti des performances croissantes des SSD, l'integration des circuits graphiques en plus du controleur memoire et probablement l'integration de toujours plus de composants de la carte mere. Chaque nouvelle evolution demandera une nouvelle carte mere (qui coutera de plus en plus cher par rapport au CPU, meme si il y aura de moins en moins de composants dessus: les I/O a haute vitesse coutent tres tres cher), comme ca a toujours ete le cas par le passe. D'ailleurs, de tous les composants dans un PC, c'est probablement le processeur qui evoluera le moins. Peut etre que finalement ca vaudrait le coup de garder le meme processeur pour pouvoir changer la carte mere en gardant son CPU .

    Bref, rien de nouveau.
    fefe - Dillon Y'Bon

  8. #668
    Ho, mais laissez-moi râler en paix

    Moi aussi je change toujours de carte-mère quand je change de CPU

    La seule chose qui me laisse froid dans les évolutions à venir est bien l'intégration du graphique sur le CPU. Les joueurs auront toujours besoin d'une carte. Bon OK ça voudra dire aussi des économies d'énergie...

  9. #669
    Bah c'est juste pour remplacer les IGP, en tout cas je pense. Concrètement, je suis pas sûr que ça change vraiment grand-chose, à part sur les laptops.
    Dernière modification par Alexko ; 23/10/2009 à 18h38.

  10. #670
    Chais pas si les Chinois ont pompe l'article du Doc sur SB, mais en tout cas un mec a mis un lien sur RWT : http://realworldtech.com/forums/inde...00823&roomid=2
    Ca vaut tous les Chinois du monde ca (ouai ca fait beaucoup ).

  11. #671
    Le FBI chinois a fait disparaître et la news du Doc et le thread associé... Aurait-il trop parlé ?

  12. #672

  13. #673

  14. #674
    http://www.semiaccurate.com/2009/08/...cores-and-all/

    Quelques commentaires interressants sur le ringbus et l'algorithme de routage, predit aussi pour Sandy Bridge par DocTB (plus possible de link l'article) donc pas seulement une feature server.
    fefe - Dillon Y'Bon

  15. #675
    Je me demande si le mode Turbo peut être mis à jour par microcode et si Intel proposera cela un jour pour les anciens i7 (là je me doute que je me fais des illusions ). Ou bien existe-t-il vraiment une différence matérielle qui fait que cela est impossible ?

  16. #676
    Hein ? Y'a déjà le Turbo sur les i7...

  17. #677
    Oui bien entendu que les i7 9xx ont le Turbo. Toute la question est de savoir s'il est possible que ce mode soit mis à jour pour accroître l'accélération comme c'est le cas sur les i5 et les i7 8xx (cf. http://www.pcinpact.com/actu/news/53...5-i7-turbo.htm).

    Si je me souviens bien, le power control (et donc le contrôle du turbo [déduction hasardeuse ?]) est fait par un contrôleur programmable, donc potentiellement son programme peut être mis à jour...

  18. #678
    Ah pour augmenter le nombre de bins... Je sais pas si c'est faisable par microcode, mais il faudrait que chaque core soit individuellement certifié capable de monter 2 bins plus haut, ce qui, a priori, ne doit pas être le cas sur les i7 9xx.

  19. #679
    Les i7 9xx ont 2 bins de turbo alors que les i7 8xx montent jusqu'a 5 bins. Le probleme pour updater les 9xx n'est pas de patcher le microcode, mais de leur faire subire les tests necessaires sur la chaine d'assemblage pour garantir qu'ils atteindront le bon nombre de bins au bon voltage. Vu qu'ils ne seront jamais re-testes et re-bin, ils resteront avec leur turbo un peu faiblard (mais une frequence garantie un peu plus haute) et un bon potentiel d'overclocking.

    L'inconvenient du turbo est que la frequence de base a laquelle le cpu est vendu n'a plus grande signification, l'avantage est que ca exploite une partie de la marge d'overclocking de maniere fiable et sans risque sans consommer plus que le budget d'energie alloue.
    fefe - Dillon Y'Bon

  20. #680
    J'imagine que ça risque de devenir un peu plus violent dans les années qui viennent. Sur un quad-core, 3 cores en idle ça laisse déjà pas mal de marge niveau power, mais si y'a 16 cores au total pour 15 en idle...

    En contre-partie ça doit être la merde à tester et avoir une mauvaise influence sur les yields, mais bon on peut toujours mettre beaucoup de bins sur le haut de gamme, et moins sur le bas — voire pas du tout.

  21. #681
    Yop les canards!! Dites je me demandais pourquoi il y avait autant de niveau cache (L1,2,3) et pourquoi leur vitesse decroit respectivement?

    Je sais que le cache L1 sert pour les instructions et les données, le L3 pour communiquer entre les coeurs et le L2 sert d'intermediaire entre le L1 et le L3. Mais pourquoi ne pas faire qu'un seul gros cache bien bourrin qui separe instruction et donnés?

  22. #682
    La vitesse des cache (bande passante) decroit avec leur taille, leur latence augmente avec leur taille et leur cout croit avec la taille.

    C'est la raison pour laquelle tu as une hierarchie au lieu d'un seul gros cache.

    Ca fonctionne parce que les acces memoire ne sont pas aleatoires et ont des proprietes statistiques connues de localite spatiale et localite temporelle:
    - si tu accedes a une adresse, l'adresse suivante a de tres forte probabilite d etre acceedee
    - si tu accedes a une adresse, il y a 90+% de chances que tu y accedes de nouveau dans un futur proche.

    Je recommande la lecture de wikipedia sur les caches, ca devrait repondre au moins partiellement a tes questions.
    fefe - Dillon Y'Bon

  23. #683
    Citation Envoyé par fefe Voir le message
    La vitesse des cache (bande passante) decroit avec leur taille, leur latence augmente avec leur taille et leur cout croit avec la taille.
    Oui et pourquoi? (parce que bon c'est un peu l'origine de ma question quand meme).

    "Leur cout croit avec la taille" c'est un peu une evidence puisque ca signifie moins de place sur le wafer....mais si on fait un gros cache qui a la meme capacité que l'adition des trois caches ca devrait pas couter plus cher.
    Dernière modification par Banjo ; 23/09/2009 à 22h04.

  24. #684
    C'est (en partie) lié à l'associativité du cache. Plus l'associativité est petite et plus le cache est rapide (tu parcours une ligne plus vite mais tu as plus de risques de faire des "evicts" et donc un cache miss par la suite). L'associativité des caches croit selon leur niveau.

    Après, les niveaux de cache tournent à des vitesses différentes. Comme le L1 a une taille réduite, il peut se permettre d'avoir des transistors qui vont plus vite et consomment plus. Plus la taille augmente et plus on doit limiter le budget puissance.

    Il doit y avoir d'autres raisons, mais je m'arrête là pour ma part.

    Edit :
    La latence augmente selon les niveaux car il faut passer par les différents niveaux de cache inférieurs pour charger une donnée.
    Dernière modification par Yasko ; 23/09/2009 à 23h01.

  25. #685
    Citation Envoyé par Bncjo Voir le message
    mais si on fait un gros cache qui a la meme capacité que l'adition des trois caches ca devrait pas couter plus cher.
    Par contre il sera ultra-lent, en tout cas au moins aussi lent que le dernier niveau de cache... [Edit: en fait pas autant, comme dit l'edit de Yasko.]

    La métaphore foireuse du jour:
    Suppose que tu ais plein de bouquins que tu consultes plus ou moins régulièrement.
    Tu mets les plus fréquemment lus sur un coin de ton bureau, les moins souvent lus sur une étagère à côté du bureau, les encore moins souvent lus au grenier. Et ceux que tu ne lis quasiment jamais sont à la bibliothèque municipale, tu les a pas achetés/empruntés.
    Ce que tu proposes, c'est de t'aménager un grenier un peu plus grand en y mettant une étagère et un coin de bureau pour y mettre tous les bouquins...

    Intuitivement une grosse mémoire est plus lente qu'une petite, ne serait-ce que parce qu'il faut aller chercher l'information plus loin... (coût du routage)

    Il n'y a guère que les algorithmiciens pour s'imaginer qu'un tableau de taille n s'accède en O(1).
    Dernière modification par Møgluglu ; 23/09/2009 à 23h16.

  26. #686
    Citation Envoyé par Yasko Voir le message
    C'est (en partie) lié à l'associativité du cache. Plus l'associativité est petite et plus le cache est rapide (tu parcours une ligne plus vite mais tu as plus de risques de faire des "evicts" et donc un cache miss par la suite). L'associativité des caches croit selon leur niveau.
    Super. J'ai d'ailleurs trouvé un cours qui explique bien tout ca (enfin bien mieux que wikipedia): http://www.liafa.jussieu.fr/~carton/.../Cours/Caches/

    Intuitivement une grosse mémoire est plus lente qu'une petite, ne serait-ce que parce qu'il faut aller chercher l'information plus loin... (coût du routage)

    Il n'y a guère que les algorithmiciens pour s'imaginer qu'un tableau de taille n s'accède en O(1).
    Effectivement, plus n croit, plus le temps de recherche d'une adresse croit aussi. Mais alors, quand on produit des cellules de ddr3 par exemple de 2Gb et d'autres de 4Gb, ces dernières seront donc moins performante non?

  27. #687
    Non, pour la RAM, cela ne change rien.
    L'adresse des instructions et des données est connue précisément (elles sont stockées dans le code du programme et celui-ci est chargé en mémoire), contrairement aux données dans un cache associatif (/non direct).
    Dans la RAM, toutes les données sont "à plat", et rangées dans des pages, banques, etc, ce qui fait que cela ne change pas fondamentalement la manière dont les données sont accédées, que la RAM ait des chips de 2 ou 4 Gb.

    L'associativité du cache est une technique qui permet de limiter leur taille (ce qui est leur principale problématique -problématique que l'on ne retrouve pas avec la mémoire), et la hiérarchie leur permet de rester rapide, mais cela implique de faire des choix (prédictions, remplacement, ...)

  28. #688
    Citation Envoyé par Bncjo Voir le message
    Oui et pourquoi? (parce que bon c'est un peu l'origine de ma question quand meme).

    "Leur cout croit avec la taille" c'est un peu une evidence puisque ca signifie moins de place sur le wafer....mais si on fait un gros cache qui a la meme capacité que l'adition des trois caches ca devrait pas couter plus cher.
    Je vais essayer de faire une explication detaillee du pourquoi mais ca risque d'etre un peu long .

    Si tu prends une cellule de SRAM 6T dans un process donne, elle aura un temps d'acces donne (en picosecondes). Si organise un groupe de n de ces cellules, et que tu as n fils pour lire le contenu de cette cellule, ton debit sera essentiellement: n/cycle, avec la longueur de ton cycle qui est la latence d'acces a une cellule + la latence pour traverser le fil.

    Dans un process donne, suivant la taille que tu choisiras pour ta cellule tu obtiendras un different temps de cycle. Plus tu augmente la taille d'une cellule plus elle sera rapide (et tu pourras augmenter la frequence), mais plus tu augmente sa taille plus la latence du fil sera importante. En augmentant sa taille tu augmente aussi sa capacitance (tu as reduit sa resistance ce qui a contribue a la reduction du temps de cycle).

    Une fois que tu as augmente sa taille, tu peux envoyer un voltage plus eleve, et augmenter sa vitesse encore plus. Le probleme est que l'energie dissipee par ta cellule va croitre au cube.

    Pour avoir beaucoup de bande passante a une zone memoire, il te faut beaucoup de fils en parallele. Plus ces fils sont longs, plus ils sont lents a traverser, mais plus ils sont larges plus ils sont rapides (tu peux monter la frequence).

    En pratique la vitesse de traversee d'une piste de dimensions donnees n'a quasiment pas evolue depuis l'invention du cmos (en passant de l'alu au cuivre ca a evolue mais c'est a peu pres tout si on compare a l'evolution de la vitesse des transistors). Donc si tu veux transporter un signal a haute vitesse sur 1cm il va te falloir une piste de la meme taille qu'il y a 10 ans alors que tu veux 10x la bande passante donc 10x le nombre de fils. La seule solution pour augmenter le nombre de fils sans changer la latence est d'aller moins loin: tu pourras avoir plus de fils.

    Si tu regardes un processeur comme Nehalem, tu as une hierarchie memoire a 5 niveaux (si tu ne prends pas en compte tes disques):
    -La DRAM, cellules 1T beaucoup plus denses (capacite accrue a couts egal), moins cheres, a temps d'acces eleve, derriere un nombre faible de fils tres longs qui tournent a basse frequence
    -Le L3, 8Mo, avec 4x plus de fils que la memoire et 2x la frequence
    -les L2, 256Ko*4 avec 4x plus de fils que le L3 et 1.3x la frequence
    -les L1, 32ko*8 avec 4x plus de fils que les L2 et 1x la frequence
    -les bancs de registres plusieurs ko*4 avec ~4x plus de fils que les L1 a 1x la frequence

    A chaque niveau tu reduis la capacite, augmente la taille de ta cellule reduit le nombre de fils et reduit la distance a parcourir: reduit la latence et augmente le debit. Tu augmentes aussi l'energie dissipee par cellule a chaque niveau.

    Ca c'est juste si tu consideres des memoires indexees directement. Si tu as des caches tu dois aussi prendre en compte l'architecture de tels caches et la propriete des acces. Plus il y a de streams concurrents qui veulent acceder a la memoire, plus il faut augmenter l'associativite de tes caches pour maintenir leur efficaciter et eviter d'ejecter des donnees utiles.

    L'associativite d'un cache coute tres cher en temps d'acces sauf si tu es pret a depenser beaucoup d'energie. Pour acceder a un cache associatif rapidement, tu accedes a chaque voie en parallele, donc tu depenses associativite fois trop d'energie. Si tu decides de calculer d'abord dans quelle voie ta donnee est cela augmente le temps d'acces mais reduit l'energie.

    Je ne detaillerai pas plus sur les caches (il y a plus a dire que ce que le cours que tu link mais c'est pour une autre fois).

    Vu de tres loin le cout d'un transitor (ou d'un fil/une piste) a une relation lineaire avec la surface qu'il occupe. En pratique l'energie qu'il va dissiper a un cout aussi qui est non negligeable. Il faudra lui acheminer le courant, et dissiper la chaleur associee, ce qui se transforme en $ de cout sur le package, les etages d'alimentation, etc...

    Donc au final, si tu veux un faible temps d'acces et une haute bande passante tu accedes a une petite memoire, et plus tu augnmentes ce temps d'acces et reduis la bande passante, plus tu peux avoir de capacite.

    PS: mmm je me relirai plus tard, j'espere que c'est comprehensible
    fefe - Dillon Y'Bon

  29. #689
    Citation Envoyé par Bncjo Voir le message
    Super. J'ai d'ailleurs trouvé un cours qui explique bien tout ca (enfin bien mieux que wikipedia): http://www.liafa.jussieu.fr/~carton/.../Cours/Caches/



    Effectivement, plus n croit, plus le temps de recherche d'une adresse croit aussi. Mais alors, quand on produit des cellules de ddr3 par exemple de 2Gb et d'autres de 4Gb, ces dernières seront donc moins performante non?
    Pour addresser 2x la quantite de memoire il te faut 1 bit, qui ne te coutera pas vraiment en temps d'acces (surtout qu'il est deja dans le calcul que tu aies 512Mo ou 8Go). Ensuite ca depend comment tu as augmente la capacite de tes barettes memoire:
    -tu as ajoute une autre barette, plus loin = tu as des fils qui vont plus loin et il te faut un multiplexeur pour connecter tes 2 barettes vers le controleur memoire= tu as augmente la latence de la longueur de ces fils+ le multiplexeur
    -tu as change pour une barette employant des puces de memoire employant un procede de fabrication avance qui te permet d'avoir 2x la densite de cellules dans la emme taille de puce. Resultat, le temps d'acces reste constant vu que les dimensions de tes fils n'ont pas change (dans le temps d'acces a la DRAM, le temps d'acces a la cellule de memoire est negligeable a cote du temps de traversee de tes fils et du temps necessaire a faire comprendre a la DRAM quelle adresse tu veux).

    C'est d'ailleurs pour ca que si tu regardes la latence de la SDRAM d'il y a 10 ans et la latence de la DDR la plus recente, tu ne trouveras quasiment pas de changements, bien que la capacite ait decuple.
    fefe - Dillon Y'Bon

  30. #690
    Specs des Clarkdale et Arrandale après l'IDF, tableaux au format poster et version floutée de photo du Doc :
    http://pc.watch.impress.co.jp/docs/c...27_331818.html

    Les Arrandale (mobile) supportent le "Package Turbo", où le CPU et le GMCH sont overclockés indépendamment jusqu'aux limites du TDP global et/ou de la température des hotspots.

    Sinon quand fefe disait que les power gates ça prenait de la surface, je pensais pas que c'était à ce point-là:

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
  •