Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 19 sur 26 PremièrePremière ... 911121314151617181920212223242526 DernièreDernière
Affichage des résultats 541 à 570 sur 764
  1. #541
    Citation Envoyé par Foudge Voir le message
    D'ailleurs, pour nous simple dev qui ne comprenons pas tout ce que vous avez dit, comment oublier le x87 ? Il suffit simplement de le dire au compilo (je pensais que celui-ci utilisait du SSE uniquement là ou c'était possible et rentable) ?
    Heureusement quand on compile en x86_64, les complilos génèrent à peu près tous du SSE/SSE2 pur. (Le x87 n'est déjà pas un cadeau, si on le mélange avec du SSE c'est encore pire...)

    Par contre en IA-32, par défaut le code doit pouvoir tourner sur un 386, donc avec aucune des instructions introduites ces 15 dernières années...
    Il faut au minimum dire au compilo de générer du code pour P4/K8 (pas juste optimiser pour P4) pour avoir une chance d'avoir du SSE2.

    J'imagine que ça ne concerne que les codeurs bas niveau et/ou dont la performance du code est un facteur critique, non ?
    Il y a aussi les arithméticiens, qui aiment jouer avec les modes d'arrondis, les précisions et les opérateurs exotiques, et qui aussi étrange que ça puisse paraître tiennent absolument à ce que quand ils écrivent a+b ça fasse une addition et pas autre chose .

  2. #542
    Citation Envoyé par Møgluglu Voir le message
    Je me plaçais dans le cas de cette hypothèse :



    C'est pas moi qui l'ai dit

    Et la latence du MULPS/MULSS est à 4 cycles, contre 5 pour le MULPD/MULSD et FMUL.
    Oui mais dans un cas les opcopdes sont differents, et le controle est le plus possible dependant uniquement des opcodes. Si tu es dependant de registres, il faut verifier dynamiquement les dependances et pouvoir recuperer des cas particuliers, genre un changement de ce registre arrive en parallele avec l'execution d'une instruction en dependant (C'est en SMT donc dans corei7 que ce genre de choses se corsent).
    Mais pour un multiplieur flottant le datapath de l'exposant est normalement pas sur le chemin critique. Même, il est certainement plus court en mode x87 qu'en mode IEEE-754 (pas de biais différents à appliquer à l'exposant suivant le format).
    Donc si on a une unité capable de faire du 80-bit x87 et du 64-bit SSE, alors elle est capable de faire du 64-bit x87 au moins aussi vite que le SSE.
    Oui et non. Oui en theorie si tu separes ton unite de la microarchitecture qui doit l'utiliser. Quand tu l'integres a un processeur OOO ca devient moins immediat. Bien entendu tu peux envisager d'encoder dans l'instruction la precision actuelle x87 vu que ca ne change pas si dynamiquement que ca, mais ca ajoute pas mal de complexite quand meme. Des instructions ayant un seul opcode et ayant une latence variable il n'y en a pas tant que ca, et elles ont systematiquement une latence longue (ce qui permet d'eviter d'avoir a speculer dans les schedulers).

    Je suis d'accord avec toi que c'est tout a fait faisable, mais le cout ne vallait probablement pas les eventuels benefices sinon ca serait implemente.

    Certes. Mais on pourrait imaginer répliquer le bit qui va bien du registre de contrôle plus près du scheduler.
    Ce n'est pas vraiment une question de distance physique, et en plus repliquer des variables globales c'est en general chercher les ennuis .


    Comme quoi c'est pas totalement délirant
    Pour AMD on peut comprendre qu'il cherchent à éviter de passer à chaque fois par leur multiplieur monstrueux de ~90 bits spécial division...
    Tout a fait. Et le x87 d'AMD est generalement plus clean que celui d'Intel a mon gout.
    fefe - Dillon Y'Bon

  3. #543
    Havendale et Auburndale annulés, pas de GPU intégré dans le package en 45nm. Il faudra attendre Clarkdale et Arrandale en 32nm prévus pour 2010.
    http://theovalich.wordpress.com/2009...e-fusion-cpus/

    Oui, je sais c'est Theo , mais depuis la news a été reprise par des gens sérieux avec plus de détails (http://pc.watch.impress.co.jp/docs/2.../kaigai488.htm).

  4. #544
    En fait, plus qu'un retard des dual-core basés sur Nehalem, ça semble être Westmere qui serait en avance. Début 2010, c'est assez aggressif pour un nouveau process...
    Du coup, plutôt que d'avoir des Havendale et Auburndale d'une durée de vie de quelques mois en attendant de sortir tous les Westmere en même temps au 2e trimestre 2010, Intel aurait choisi de passer directement au 32nm, en avançant sa date de sortie.

    On se retrouverait donc avec des Westmere dans les segments "value/mainstream" avant le haut de gamme.

  5. #545
    Penryn a été introduit fin 2007 donc l'arrivée du 32 nm début 2010 n'a rien de surprenant, on devrait même voir les premiers produits fin 2009.

  6. #546
    C'est surtout que c'était infaisable en 45 nm (chez Intel comme chez AMD). En masse s'entend, rappelons que c'est supposer être quelque chose de relativement basique, pas du haut de gamme, donc niveau cout...

  7. #547
    Oui, mais sachant que le GMCH reste de toute façon en 45nm, en quoi est-ce irréalisable de le coller à côté d'un die de 120mm² et réalisable pour un die de 80mm² en 32nm?

    Intel a déjà collé dans un même package des CPU plus gros que ça.
    J'aurai pensé au contraire que la maturité du process simplifierait les choses...

  8. #548
    Je le savais déjà mais quand même, je suis TRES impressionné par les perf du Core i7 en audio.

    Avec une latence normale il se permet de taquiner un bi xeon (core 2), et lorsqu'on se rapproche d'une latence de 0, il le bat sans problème.

  9. #549
    Citation Envoyé par Møgluglu Voir le message
    Oui, mais sachant que le GMCH reste de toute façon en 45nm, en quoi est-ce irréalisable de le coller à côté d'un die de 120mm² et réalisable pour un die de 80mm² en 32nm?

    Intel a déjà collé dans un même package des CPU plus gros que ça.
    J'aurai pensé au contraire que la maturité du process simplifierait les choses...
    We managed to get some additional details about the new star of Intel CPUs, the mighty dual core 32nm Clarkdale. Despite the fact that this CPU will be developed in 32nm process and probably come at even faster speeds than current 3.33GHz for dual core, the graphics will stay at 45nm.


    Intel calls such an approach a Multi Chip Package, which means that graphics will simply move from the chipset to the CPU socket, but it won't be natively designed with the Clarkdale 32nm CPU. The GPU on the chip will be a physically different chip.

    The real fusion style, native CPU with IGP from Intel comes later. Clarkdale 32nm should bring Nehalem technology to cheaper PCs and you can expect samples in Q4 2009 with some serious quantities in Q1 2010 and onwards.

    We don’t expect miracles from this graphics, as it’s likely to be the same, or very similar to the IGP you have in G45 generation of chipsets. Do we need to remind you how bad G45 really is? Well, lets just say that G45 is sorry excuse for an integrated GPU graphics.
    C'est FudZilla, but still !

  10. #550
    C'est quoi le second die de taille différente que l'on voit sur Westmere ?



    http://www.matbe.com/actualites/imprimer/59561/

  11. #551
    Citation Envoyé par Yasko Voir le message
    C'est quoi le second die de taille différente que l'on voit sur Westmere ?

    http://www.matbe.com/images/biblio/d...0000083786.jpg

    http://www.matbe.com/actualites/imprimer/59561/
    Il semble y avoir un élément de réponse sur cette news de PCI
    http://valid.x86-secret.com/cache/banner/313021.png

  12. #552
    Dernière modification par newbie06 ; 11/02/2009 à 19h53.

  13. #553
    Avec Intel et AMD en train de mettre le contrôleur mémoire et le GPU sur le même package que le CPU, je me demande si on ne va pas finir par voir des SoC sur desktop.

    Après tout, pour un PC à vocation bureautique, en 22 nm quel est le plus rentable ? Un dual-core SMT (soit 4 threads) serait amplement suffisant, et laisserait largement la place pour le reste.

  14. #554
    Citation Envoyé par Alexko Voir le message
    Avec Intel et AMD en train de mettre le contrôleur mémoire et le GPU sur le même package que le CPU, je me demande si on ne va pas finir par voir des SoC sur desktop.
    Ça impliquerait de se débarrasser d'abord de toutes les interfaces accumulées depuis 25 ans qui rendent obligatoire un southbridge, un contrôleur LPC, une flash de BIOS, un contrôleur PATA, un générateur d'horloge et quelques puces de monitoring, entre autres bidules qui tapissent les cartes mères actuelles .

  15. #555
    Citation Envoyé par Møgluglu Voir le message
    Ça impliquerait de se débarrasser d'abord de toutes les interfaces accumulées depuis 25 ans qui rendent obligatoire un southbridge, un contrôleur LPC, une flash de BIOS, un contrôleur PATA, un générateur d'horloge et quelques puces de monitoring, entre autres bidules qui tapissent les cartes mères actuelles .
    Les SoC sont très rarement seuls sur une carte
    Ils peuvent avoir en externe de la flash, de la RAM, un contrôleurs pour les signaux video, un contrôleur pour la gestion du power. Bon c'est sûr que niveau intégration en général y'a au moins le CPU, l'accélérateur 3d, le contrôleur mémoire et quelques fioritures. Ouai le PC va rattraper l'embarqué

  16. #556
    Oui quand je dis SoC, j'entends "toutes les fonctions du CPU, GPU, northbridge et southbridge dans un seul package, voire die".

  17. #557
    Le northbridge est en train d'etre absorbe dans le CPU, le southbridge c'est moin probable pour de betes contraintes de process. Les process destine aux hautes vitesses employes dans les CPUs ne sont vraiment pas faits pour les IO a hauts voltages comme ce qui est employe dans les southbridges. Les SOC sacrifient beaucoup de vitesse potentielle de maniere a integrer toutes ces IO.
    Bien entendu, quand je parle d'integration, je parle d'integrer sur le meme die. Il est tout a fait possible de faire des multi-chip-packages avec un CPU qui integre le northbridge et un southbridge sur un process different, et on a nettement plus de chances de voir ca arriver avant.
    fefe - Dillon Y'Bon

  18. #558
    Chez Anandtech :
    Nehalem Xeon EP update: too good but true

    Je crois que si je pouvais déjà passer commande, je le ferais.

  19. #559
    Citation Envoyé par fefe Voir le message
    Il est tout a fait possible de faire des multi-chip-packages avec un CPU qui integre le northbridge et un southbridge sur un process different, et on a nettement plus de chances de voir ca arriver avant.
    N'est-ce pas exactement ce que montre la photo de Yasko ? (Je veux dire le multi-chip sur process differents.)

    Citation Envoyé par Stéphane.P Voir le message
    Chez Anandtech :
    Nehalem Xeon EP update: too good but true

    Je crois que si je pouvais déjà passer commande, je le ferais.
    Tu geres une grosse base SAP ?
    Ca me laisse passablement froid ce genre de bench, meme s'il semble que dans ce cas, SAP soit vraiment sensible a des choses plus interessantes que le debit disque ou les perfs de la DB. Mais ca renforce mon envie de Nehalem...
    Dernière modification par newbie06 ; 12/02/2009 à 09h33. Motif: Fusion automatique

  20. #560
    Citation Envoyé par newbie06 Voir le message
    N'est-ce pas exactement ce que montre la photo de Yasko ? (Je veux dire le multi-chip sur process differents.)
    Oui, mais la c'est un CPU et un northbridge, les IO de PCIe, de memoire et de display sont nettement plus faciles a faire sur un process rapide que celles de disque, USB, wireless, qui souvent necessitent de hauts voltages et de gros circuits costauds.
    Le northbridge est en train d'etre absorbe, et le southbridge ce n'est pas encore pour tout de suite, en tout cas avec les CPUs haute performance (je serais moins surpris de voir Atom arriver dans un SOC).
    fefe - Dillon Y'Bon

  21. #561
    Citation Envoyé par newbie06 Voir le message
    Tu geres une grosse base SAP ?
    Ca me laisse passablement froid ce genre de bench, meme s'il semble que dans ce cas, SAP soit vraiment sensible a des choses plus interessantes que le debit disque ou les perfs de la DB. Mais ca renforce mon envie de Nehalem...
    Non, pas de SAP, mais quand je vois le gain en perf du Nehalem par rapport au Penryn (dans mon application, plus que ce que révèlent les benchs habituelles), je me doute que ça va être tout aussi bon pour ces nouveaux Xeon..... et puis j'ai déjà de la demande

  22. #562
    En l'occurrence, c'est plus qu'un northbridge puisqu'il intègre un GPU. D'où la taille de ce die d'ailleurs, à peu près identique à celle d'un penryn, et environ 50% plus gros qu'un nehalem en 32 nm.



    En intégrant le contrôleur mémoire sur le die NB/GPU, la latence mémoire CPU ne risque pas d'en prendre un coup par rapport à Bloomfield ? (et Gulftown ?)

  23. #563
    Citation Envoyé par Yasko Voir le message
    En l'occurrence, c'est plus qu'un northbridge puisqu'il intègre un GPU. D'où la taille de ce die d'ailleurs, à peu près identique à celle d'un penryn, et environ 50% plus gros qu'un nehalem en 32 nm.

    http://images.anandtech.com/reviews/...update/igp.jpg

    En intégrant le contrôleur mémoire sur le die NB/GPU, la latence mémoire CPU ne risque pas d'en prendre un coup ?

    Euh, les Northbridge integrent des GPU depuis quand ? Une dizaine d'annees ? Ce n'est rien de plus qu'un northbridge avec graphique integre, au lieu d'etre sur la carte mere, il est dans le meme package que le CPU. Ca leur permet probablement de monter la frequence du bus reliant le NB au CPU vu qu'ils designent le PCB contrairement aux cartes meres, et que les traces sont courtes.

    La latence memoire devrait etre similaire a celle d'une machine avec un chipset moins les quelques nanosecondes que le signal mettait a parcourir les quelques centimetres qui separaient le CPU du chipset. Les latences memoires seront a mon avis plus proches de celles d'un chipset que d'un controleur memoire integre.

    Nvidia doit etre content de voir son business chipset pour Intel partir en fumee (apres Bloomfield ou ca avait deja commence) . Qui ira acheter un chipset integre chez un tiers quand il y en aura deja un dans le package du CPU?
    Dernière modification par fefe ; 12/02/2009 à 15h23.
    fefe - Dillon Y'Bon

  24. #564
    Oui, on est d'accord.
    C'est un peu étonnant d'ailleurs d'imposer ce GPU sur toute la gamme mainstream. Ca fait monter le cout du "CPU", alors qu'au final ce GPU sera probablement souvent désactivé (sur les configs gamer du moins). Ils auraient pu aussi sortir juste un die shrink de Lynnfield. A moins qu'ils veuillent pousser les joueurs vers la gamme high-end (enfin bon, c'est le prix de vente qui sera déterminant, pas la présence d'un GPU qui ne servira que peu au final).
    Plus le fait que la gamme mainstream ne sera que dual core...

    Pour le second paragraphe, ça confirmerait donc une moins bonne latence mémoire sur Clarkdale que Bloomfield/Gulftown.

  25. #565
    Citation Envoyé par Yasko Voir le message
    C'est un peu étonnant d'ailleurs d'imposer ce GPU sur toute la gamme mainstream. Ca fait monter le cout du "CPU", alors qu'au final ce GPU sera probablement souvent désactivé (sur les configs gamer du moins). Ils auraient pu aussi sortir juste un die shrink de Lynnfield. A moins qu'ils veuillent pousser les joueurs vers la gamme high-end (enfin bon, c'est le prix de vente qui sera déterminant, pas la présence d'un GPU qui ne servira que peu au final).
    Plus le fait que la gamme mainstream ne sera que dual core...
    Y'aura pas aussi Lynnfield dans la gamme mainstream ? Enfin c'est ce que je comprends du slide en haut de cette page : http://www.anandtech.com/cpuchipsets...spx?i=3513&p=5

    Quant au fait que le 32nm (Westmere) ne sera dans un premier temps que pour un dual core + GPU, n'est-ce pas pour attaquer le plus gros marche du pas cher et rentabiliser au plus vite les investissements process ? Genre le PC carrouf ou le PC qui finit dans les machines de merde qu'on nous refile au boulot.

  26. #566
    Citation Envoyé par Yasko Voir le message
    Oui, on est d'accord.
    C'est un peu étonnant d'ailleurs d'imposer ce GPU sur toute la gamme mainstream. Ca fait monter le cout du "CPU", alors qu'au final ce GPU sera probablement souvent désactivé (sur les configs gamer du moins). Ils auraient pu aussi sortir juste un die shrink de Lynnfield. A moins qu'ils veuillent pousser les joueurs vers la gamme high-end (enfin bon, c'est le prix de vente qui sera déterminant, pas la présence d'un GPU qui ne servira que peu au final).
    Plus le fait que la gamme mainstream ne sera que dual core...

    Pour le second paragraphe, ça confirmerait donc une moins bonne latence mémoire sur Clarkdale que Bloomfield/Gulftown.
    En dehors des jeux tout le monde aura plutot interet a utilise le GPU integre sur les plateformes ou la conso d'energie est importante. La conso d'un GPU integre sans GDDR, VR et autres joyeusetes sur une carte PCIe ca economise beaucoup d'energie. Bien entendu pour ca il faut que le GPU "discret" s'il y en a un de present puisse se mettre en veille complete et qu'il soit possible de switcher dynamiquement entre les 2 (reste a voir si Lucid proposera leur truc bientot ou non).

    Sur desktop l'interet est nettement plus limite, mais pour faire des petites boites silencieuses pourquoi pas...
    fefe - Dillon Y'Bon

  27. #567
    Citation Envoyé par newbie06 Voir le message
    Y'aura pas aussi Lynnfield dans la gamme mainstream ? Enfin c'est ce que je comprends du slide en haut de cette page : http://www.anandtech.com/cpuchipsets...spx?i=3513&p=5
    Lynnfield, c'est du 45 nm. En gros, pour le passage au 32 nm, Lynnfield gagne un GPU (et du cache ?), et perd 2 cores et de la latence mémoire.

    D'accord avec ton dernier post, fefe. C'est juste une problématique de gamer. De toute manière, qu'avec un dual core, ca limite déja les possibilités. Pour le jeu sur Westmere, ce sera donc Gulftown only.

  28. #568
    Citation Envoyé par Stéphane.P Voir le message
    mais quand je vois le gain en perf du Nehalem par rapport au Penryn (dans mon application, plus que ce que révèlent les benchs habituelles), je me doute que ça va être tout aussi bon pour ces nouveaux Xeon..... et puis j'ai déjà de la demande
    Faut bien reconnaître que ça a de la gueule, aussi.


  29. #569
    Oula ! Impressionnant...

    Question sur Beckton : c'est soi-disant du 8 coeurs avec 24 Mo de L3 (http://en.wikipedia.org/wiki/Nehalem...oarchitecture)) et 2.3 milliards de transistors (http://xtreview.com/addcomment-id-77...n-beckton.html). Le tout en 45 nm.

    Ca sera vraiment du single die ?

  30. #570
    Moi j'en ai une autre : va pas y avoir un goulot au niveau de l'accès des durs SATA connectés à l'unique ICH10 pour 128 thread ?

    /me sort

    /me hurle de dehors "Surtout pour le swap"
    Mes propos n'engagent personne, même pas moi.

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
  •