Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 15 sur 22 PremièrePremière ... 578910111213141516171819202122 DernièreDernière
Affichage des résultats 421 à 450 sur 658

Discussion: Archi GPU et GPGPU

  1. #421
    Citation Envoyé par Møgluglu Voir le message
    Effectivement plein de gens se plaignent que les comms entre CPU et GPU sont trop lentes et diminuent l'intérêt du GPU. Et ils suggèrent en général l'intégration du GPU dans le CPU comme la solution qui va régler tous les problèmes...

    Sauf que l'avantage de bande passante de x5 du GPU, il devient quoi du coup?
    Ça limite à des applis qui sont limitées uniquement par le calcul ou dont les jeux de données tiennent dans le cache L3, espèce qui me semble en voie de disparition...
    Dans l'absolu, rien n'empêche de mettre le CPU et le GPU sur le même die et de garder un bus de 256 bits pour y mettre de la GDDR5 ou autre mémoire rapide. Naturellement ça rendrait la gestion de la mémoire un peu plus compliquée que du tout partagé.

    En pratique ce n'est pas ce qui se passera sur Sandy Bridge et Llano parce que ce sont des produits destinés à un usage mainstream plutôt que HPC hétérogène, mais ça pourrait arriver sur un "APU" basé sur Bulldozer+ et Nothern Islands+, ou Haswell et Knights Corner…
    Dernière modification par Alexko ; 29/10/2010 à 23h43.

  2. #422
    Citation Envoyé par newbie06 Voir le message
    Deux dies, je ne suis pas sur que ca limite beaucoup les problemes de dissipation thermique...
    Une partie du moins. Les gros radiateurs que les canards affectionnent sont capables de dissiper pas mal de watt.
    Le principal problème je crois, c'est la densité thermique, les quelques points chauds d'un die qui limitent l'ensemble.
    En augmentant la surface et en éloignant les points chauds, on limite ces problèmes.

  3. #423
    Citation Envoyé par newbie06 Voir le message
    Je vois deux possibilites : ton probleme tient en cache GPU mais pas CPU, ou bien tu utilises les unites de rasterization. Sinon, je ne te crois pas
    J'ose meme pas imaginer que tu aurais ose compiler ton code en -O0 ou que ton CPU est un Atom.
    Oh non, rien du tout ça. J'exploite juste un bug de performance de la micro-archi Core. (et un peu de gcc et de la libc aussi)
    Et je suis honnête : je me compare avec un Nehalem. Contre un Merom/Penryn, je gagne un facteur 3 en plus.

    C'est un peu comme si je m'amusais a benchmarker un Atom contre un A9 en oubliant de forcer l'utilisation de SSE au lieu de x87, ce serait malhonnete et "misleading".
    En passant, quel est l'écart de perf entre x87 et SSE sur un processeur moderne (avec un compilo pas foutu de vectoriser, comme gcc)?

    Citation Envoyé par Alexko Voir le message
    Dans l'absolu, rien n'empêche de mettre le CPU et le GPU sur le même die et de garder un bus de 256 bits pour y mettre de la GDDR5 ou autre mémoire rapide. Naturellement ça rendrait la gestion de la mémoire un peu plus compliqué que du tout partagé.
    Avec un arbitre qui gère bien les prios pour pas trop pénaliser la latence CPU, ça devrait être faisable...
    Mais la GDDR5 c'est cher, et à génération équivalente et à prix raisonnablement équivalent tu auras toujours un facteur genre 4 ou 5 en capacité en faveur de la DDRx...

    En pratique ce n'est pas ce qui se passera sur Sandy Bridge et Llano parce que ce sont des produits destinés à un usage mainstream plutôt que HPC hétérogène, mais ça pourrait arriver sur un "APU" basé sur Bulldozer+ et Nothern Islands+, ou Haswell et Knights Corner…
    Faut voir s'il y a un marché suffisent pour ce genre de puces pour que ça soit rentable...

  4. #424
    Citation Envoyé par Møgluglu Voir le message
    En passant, quel est l'écart de perf entre x87 et SSE sur un processeur moderne (avec un compilo pas foutu de vectoriser, comme gcc)?
    J'avais un facteur 2 ou 3 sur des boucles alacon que gcc vectorise sans souci. Ha oui c'etait un truc hyper moderne, un Atom.

  5. #425
    Citation Envoyé par newbie06 Voir le message
    J'avais un facteur 2 ou 3 sur des boucles alacon que gcc vectorise sans souci.

    Newbie, c'est un Dieu.
    Il arrive à faire vectoriser des boucles à gcc.

    Sérieux, ça marche sur autre chose que les 3 exemples de la doc ce truc? Jamais réussi à lui faire vectoriser un memcpy, même en mettant plein de restrict et d'__align__...

  6. #426
    Citation Envoyé par Møgluglu Voir le message

    Newbie, c'est un Dieu.
    Il arrive à faire vectoriser des boucles à gcc.

    Sérieux, ça marche sur autre chose que les 3 exemples de la doc ce truc? Jamais réussi à lui faire vectoriser un memcpy, même en mettant plein de restrict et d'__align__...
    Je ne suis pas un dieu (quoique les femmes m'appellent ainsi... ha non c'est pas de ca dont on parle), mais mes boucles etaient vraiment triviales et j'utilise une version recente de gcc.

    Code:
    float p_add(float *pa, float *pb, float *pc)
    {
      int i;
    
      for (i=0; i<256; i++){
        pa[i] = pb[i] + pc[i];
      }
    }
    gcc44 -O3 -ftree-vectorize -S test-fp2.c

    Code:
            .p2align 4,,15
    .globl p_add
            .type   p_add, @function
    p_add:
    .LFB0:
            .cfi_startproc
            testb   $15, %dil
            leaq    16(%rdi), %rax
            je      .L14
    .L2:
            xorl    %eax, %eax
            .p2align 4,,10
            .p2align 3
    .L7:
            movss   (%rsi,%rax), %xmm0
            addss   (%rdx,%rax), %xmm0
            movss   %xmm0, (%rdi,%rax)
            addq    $4, %rax
            cmpq    $1024, %rax
            jne     .L7
            rep
            ret
    .L14:
            leaq    16(%rsi), %rcx
            cmpq    %rcx, %rdi
            jbe     .L15
            leaq    16(%rdx), %rcx
            cmpq    %rcx, %rdi
            jbe     .L16
    .L9:
            xorps   %xmm2, %xmm2
            xorl    %eax, %eax
            .p2align 4,,10
            .p2align 3
    .L5:
            movaps  %xmm2, %xmm0
            movaps  %xmm2, %xmm1
            movlps  (%rsi,%rax), %xmm0
            movlps  (%rdx,%rax), %xmm1
            movhps  8(%rsi,%rax), %xmm0
            movhps  8(%rdx,%rax), %xmm1
            addps   %xmm1, %xmm0
            movaps  %xmm0, (%rdi,%rax)
            addq    $16, %rax
            cmpq    $1024, %rax
            jne     .L5
            rep
            ret
    .L15:
            cmpq    %rsi, %rax
            jae     .L2
            leaq    16(%rdx), %rcx
            cmpq    %rcx, %rdi
            ja      .L9
    .L16:
            cmpq    %rax, %rdx
            .p2align 4,,2
            jbe     .L2
            .p2align 4,,5
            jmp     .L9
            .cfi_endproc
    C'est pas parfait, mais c'est pas mal, non ?

  7. #427
    Mouais. Aussi surprenant que ça puisse paraître, si je remplace 256 par n ça marche encore.
    Je comprend pas trop pourquoi il splitte les load en 2 instructions, mais admettons...

    Aller, la prochaine fois, soyons fous, on tente la boucle SAXPY.

  8. #428
    Citation Envoyé par Møgluglu Voir le message
    Mouais. Aussi surprenant que ça puisse paraître, si je remplace 256 par n ça marche encore.
    Je comprend pas trop pourquoi il splitte les load en 2 instructions, mais admettons...
    J'en sais rien, pour moi c'est illisible le SSE...
    Aller, la prochaine fois, soyons fous, on tente la boucle SAXPY.
    Ca se vectorise aussi, t'as qu'a tester, spice de flemmasse !
    Code:
    float saxpy(float *y, float *x, float a, int m, int n)
    {
      int i;
    
      for (i = m; i < n; i++) {
        y[i] = a * x[i] + y[i];
      }
    }
    ->
    Code:
            .p2align 4,,15
    .globl saxpy
            .type   saxpy, @function
    saxpy:
    .LFB0:
            .cfi_startproc
            pushq   %rbp
            .cfi_def_cfa_offset 16
            cmpl    %ecx, %edx
            pushq   %rbx
            .cfi_def_cfa_offset 24
            jge     .L11
            .cfi_offset 3, -24
            .cfi_offset 6, -16
            movl    %ecx, %ebx
            movslq  %edx,%r10
            subl    %edx, %ebx
            salq    $2, %r10
            cmpl    $5, %ebx
            leaq    (%rdi,%r10), %r8
            leaq    (%rsi,%r10), %r10
            jbe     .L9
            testb   $15, %r8b
            jne     .L9
            leaq    16(%r10), %rax
            cmpq    %rax, %r8
            jbe     .L17
    .L12:
            movl    %ebx, %r11d
            shrl    $2, %r11d
            leal    0(,%r11,4), %ebp
            testl   %ebp, %ebp
            je      .L6
            movaps  %xmm0, %xmm1
            xorl    %eax, %eax
            xorps   %xmm3, %xmm3
            xorl    %r9d, %r9d
            shufps  $0, %xmm1, %xmm1
            movaps  %xmm1, %xmm4
            .p2align 4,,10
            .p2align 3
    .L7:
            movaps  %xmm3, %xmm1
            addl    $1, %r9d
            movaps  %xmm3, %xmm2
            movlps  (%r10,%rax), %xmm1
            movlps  (%r8,%rax), %xmm2
            movhps  8(%r10,%rax), %xmm1
            movhps  8(%r8,%rax), %xmm2
            mulps   %xmm4, %xmm1
            addps   %xmm2, %xmm1
            movaps  %xmm1, (%r8,%rax)
            addq    $16, %rax
            cmpl    %r11d, %r9d
            jb      .L7
            cmpl    %ebp, %ebx
            leal    (%rbp,%rdx), %edx
            je      .L11
    .L6:
            movslq  %edx,%rax
            salq    $2, %rax
            addq    %rax, %rsi
            addq    %rax, %rdi
            .p2align 4,,10
            .p2align 3
    .L8:
            movss   (%rsi), %xmm1
            addl    $1, %edx
            mulss   %xmm0, %xmm1
            addq    $4, %rsi
            addss   (%rdi), %xmm1
            movss   %xmm1, (%rdi)
            addq    $4, %rdi
            cmpl    %edx, %ecx
            jg      .L8
    .L11:
            popq    %rbx
            popq    %rbp
            ret
            .p2align 4,,10
            .p2align 3
    .L17:
            leaq    16(%r8), %rax
            cmpq    %rax, %r10
            ja      .L12
            .p2align 4,,10
            .p2align 3
    .L9:
            movss   (%r10), %xmm1
            addl    $1, %edx
            jge     .L11
            .cfi_offset 3, -24
            .cfi_offset 6, -16
            movl    %ecx, %ebx
            movslq  %edx,%r10
            subl    %edx, %ebx
            salq    $2, %r10
            cmpl    $5, %ebx
            leaq    (%rdi,%r10), %r8
            leaq    (%rsi,%r10), %r10
            jbe     .L9
            testb   $15, %r8b
            jne     .L9
            leaq    16(%r10), %rax
            cmpq    %rax, %r8
            jbe     .L17
    .L12:
            movl    %ebx, %r11d
            shrl    $2, %r11d
            leal    0(,%r11,4), %ebp
            testl   %ebp, %ebp
            je      .L6
            movaps  %xmm0, %xmm1
            xorl    %eax, %eax
            xorps   %xmm3, %xmm3
            xorl    %r9d, %r9d
            shufps  $0, %xmm1, %xmm1
            movaps  %xmm1, %xmm4
            .p2align 4,,10
            .p2align 3
    .L7:
            movaps  %xmm3, %xmm1
            addl    $1, %r9d
            movaps  %xmm3, %xmm2
            movlps  (%r10,%rax), %xmm1
            movlps  (%r8,%rax), %xmm2
            movhps  8(%r10,%rax), %xmm1
            movhps  8(%r8,%rax), %xmm2
            mulps   %xmm4, %xmm1
            addps   %xmm2, %xmm1
            movaps  %xmm1, (%r8,%rax)
            addq    $16, %rax
            cmpl    %r11d, %r9d
            jb      .L7
            cmpl    %ebp, %ebx
            leal    (%rbp,%rdx), %edx
            je      .L11
    .L6:
            movslq  %edx,%rax
            salq    $2, %rax
            addq    %rax, %rsi
            addq    %rax, %rdi
            .p2align 4,,10
            .p2align 3
    .L8:
            movss   (%rsi), %xmm1
            addl    $1, %edx
            mulss   %xmm0, %xmm1
            addq    $4, %rsi
            addss   (%rdi), %xmm1
            movss   %xmm1, (%rdi)
            addq    $4, %rdi
            cmpl    %edx, %ecx
            jg      .L8
    .L11:
            popq    %rbx
            popq    %rbp
            ret
            .p2align 4,,10
            .p2align 3
    .L17:
            leaq    16(%r8), %rax
            cmpq    %rax, %r10
            ja      .L12
            .p2align 4,,10
            .p2align 3
    .L9:
            movss   (%r10), %xmm1
            addl    $1, %edx
            mulss   %xmm0, %xmm1
            addq    $4, %r10
            addss   (%r8), %xmm1
            movss   %xmm1, (%r8)
            addq    $4, %r8
            cmpl    %edx, %ecx
            jg      .L9
            jmp     .L11
            .cfi_endproc
    En parlant de flemmasse va ptet falloir que je me bouge pour installer gcc 4.5.1

  9. #429
    Dites, vous avez une idée de la consommation de Knights Ferry ?

  10. #430
    Juste à temps par rapport à la discussion sur les unités spécialisées des GPU : l'analyse de Slimer Fermi sur B3D :
    http://www.beyond3d.com/content/reviews/55

    Pour une fois, le point de vue est entièrement sur le pipeline graphique, plutôt que sur le GPGPU.
    Je suis largué.

  11. #431

  12. #432
    Citation Envoyé par Yasko Voir le message
    Une partie du moins. Les gros radiateurs que les canards affectionnent sont capables de dissiper pas mal de watt.
    Le principal problème je crois, c'est la densité thermique, les quelques points chauds d'un die qui limitent l'ensemble.
    En augmentant la surface et en éloignant les points chauds, on limite ces problèmes.
    je repond à ça après la bataille:
    le probleme n'est pas tant que tout le die soit bouillant (tous les transistors vont consomer plus) que la difference de temperature entre 2 transistors designés pour être à la même temperature, ce qui va entrainer un déséquilibre entre eux et donc un mauvais comportement.

  13. #433
    Le probleme n'est pas tant le mauvais comportement lie a un gradient de temperature trop fort que la fragilisation associee aux hautes temperatures. Comme tu le dis, le leakage croit exponentiellement avec la temperature, et donc plus tu chauffe plus tu dissipes ce qui va contribuer a chauffer plus. A forts courants (necessaire pour alimenter ce circuit qui dissipe autant) et forte temperature les risques d'electromigration s'accentuent dramatiquement. Le resultat est effectivement des glitches, precurseurs d'une rupture definitive de ton circuit.

    En general le glitch est le bienvenu car tu preferes faire crasher le programme qui te faisait chauffer massivement plutot que de continuer a l'executer et faire chauffer jusqu'a la rupture.

    En supplement les materiaux employes dans le packaging ne sont pas prevus pour tenir dans le temps a des temperatures elevees, et dans ce cas le gradient thermique entre les materiaux se transforme en une forte tension physique qui risque d'amener au package qui se fissure.
    fefe - Dillon Y'Bon

  14. #434
    Les amateurs de propagande (avec parfois quelques morceaux de science dedans, sur un malentendu) peuvent visionner la quasi-intégralité des quelques centaines de talks au GTC 2010 :
    http://developer.download.nvidia.com...0_Archives.htm

    OMG, Theo Valich qui vend du Tegra et du Quadro pour des bagnoles électriques.

  15. #435
    Citation Envoyé par Møgluglu Voir le message
    Les amateurs de propagande
    Charlie? ;-)
    Blague à part, en effet Nvidia ne sais plus quoi faire pour fourguer ses produits...
    http://valid.x86-secret.com/cache/banner/313021.png

  16. #436
    Citation Envoyé par DJ_DaMS Voir le message
    Blague à part, en effet Nvidia ne sais plus quoi faire pour fourguer ses produits...
    En fait, je trouve au contraire que ça devient du plus en plus pro et crédible, par rapport à il y a quelques années.

    Si on passe sur l'aspect marketing de ce genre de conf constructeur (c'est pas pire qu'à l'IDF), la plupart des exposés techniques sont sérieux. Je recommande ceux sur les techniques de programmation (ici ou ), les bibliothèques (ici et suivants) et les autres outils.

    Mais je suis probablement victime de lavage de cerveau...

  17. #437
    Il y a generalement une bonne distance entre le "message" de la direction de la compagnie et le niveau technique d'ingenieurs parlant de leur travail .

    IDF, GTC et compagnie sont des grand-messe marketing, mais il reste quand meme beaucoup de presentations de sujets techniques interressant fait par gens qui savent ce qu'ils disent.
    fefe - Dillon Y'Bon

  18. #438
    Intel vient d'annoncer un driver OpenCL en alpha pour x86: http://software.intel.com/en-us/whatif/ . Aucune idee de ce que ca vaut mais je pense qu'on ne tardera pas a savoir maintenant que c'est disponible .
    fefe - Dillon Y'Bon

  19. #439
    Si on se fie aux exemples de la doc (Performance Guide), leur gestion du flot de contrôle a l'air très basique. Voire inexistante.
    C'est bien, ça va faire changer d'avis tous ceux qui trouvent que les GPU c'est pas efficace sur du code plein de branchements.

    Dommage que j'ai pas le temps de reverse-engineerer tout ça.

  20. #440
    http://www.xbitlabs.com/news/video/d...computers.html
    Les centrales nucléaires ont encore de beaux jours...
    http://valid.x86-secret.com/cache/banner/313021.png

  21. #441
    Hum j'ai raté quelque chose ou l'article que tu donnes en lien montre qu'un fort accent est justement mis sur l'efficacité MFLOP/W ?

  22. #442
    Certe, ils ont même interet à diminuer la conso pour arriver à mettre sur pied pareil monstre !
    Il n'en reste pas moins qu'on fera toujours face à des puces énormes et energivores, et a part pour des utilisation particulières, ce n'est plus trop la tendance, et d'ici 10 ans probablement encore moins...
    Ceci était pour justifier mon troll à peine masqué sinon de manière générale c'est intéressant de voir ce qui se profile à moyen-long terme.
    http://valid.x86-secret.com/cache/banner/313021.png

  23. #443
    Il y a des problèmes qui ont besoin d'une performance énorme et qui nécessiteront toujours des monstres de calcul qui consomment. Mais ce qui compte c'est que maintenant on ne fait plus ça sans se poser la question de l'augmentation de la perf/W. On n'en est plus aux 115kW d'un Cray 1

    Après coller ce genre de chip sur un desktop, là c'est un autre débat...

  24. #444
    Citation Envoyé par newbie06 Voir le message
    Après coller ce genre de chip sur un desktop, là c'est un autre débat...
    L'architecture en elle-même (ou du moins ce que Bill Dally en a présenté) doit pouvoir coller à n'importe quel marché.
    Le Processor Chip avec ses 128 SM, 8 Latency Cores et 1024 bancs SRAM de 256KB, le tout relié par un NoC "qui va bien" est comme ce qu'on fait maintenant en juste un peu plus gros.
    L'archi des SM ressemble de loin à ce que fait ATI depuis le R600 :


    Pour ne vexer personne ils mélangent un peu tout ce qu'on connaît :
    - Communication : load/store, passage de message et DMA.
    - Mémoire locales : reconfigurables entre caches locaux, caches distribués, scratchpad.
    (On échappe aux mémoires transactionnelles, heureusement.)

    C'est très bien, mais maintenant il faut réfléchir à comment on pourrait programmer ce truc.

  25. #445
    Citation Envoyé par Møgluglu Voir le message
    C'est très bien, mais maintenant il faut réfléchir à comment on pourrait programmer ce truc.
    Facile, c'est comme pour l'Itanium, t'auras un super compilo... ou pas

  26. #446
    Non, là tu confonds avec Larrabee.

  27. #447
    Ha on sort tous les cadavres des placards d'Intel ? iAPX432 ? 8086 !

  28. #448
    Je n'avais pas réalisé jusqu'ici à quel point Intel à "retourné sa veste à 180 degrés" entre Larrabee et le GPU de Sandy Bridge.

    À en croire le compte-rendu de Goto de la présentation à l'IDF (http://pc.watch.impress.co.jp/docs/c...07_412173.html et http://pc.watch.impress.co.jp/docs/c...14_413951.html) :

    - mort au RISC, vive les jeux d'instructions CISC, ça colle mieux aux langages haut-niveau et ça simplifie le compilateur,

    - partout où on en a eu l'occasion, on a mis des unités spécialisées, parce que le hardware générique c'est mal,

    - les jeux d'instructions SIMD c'est has-been, place au SIMT Native Parallel Compute.

    C'est ignoble cette acharnement, alors que l'herbe n'a même pas encore repoussé sur la tombe de Larrabee.

  29. #449
    Citation Envoyé par Møgluglu Voir le message
    Je n'avais pas réalisé jusqu'ici à quel point Intel à "retourné sa veste à 180 degrés" entre Larrabee et le GPU de Sandy Bridge.

    À en croire le compte-rendu de Goto de la présentation à l'IDF (http://pc.watch.impress.co.jp/docs/c...07_412173.html et http://pc.watch.impress.co.jp/docs/c...14_413951.html) :

    - mort au RISC, vive les jeux d'instructions CISC, ça colle mieux aux langages haut-niveau et ça simplifie le compilateur,

    - partout où on en a eu l'occasion, on a mis des unités spécialisées, parce que le hardware générique c'est mal,

    - les jeux d'instructions SIMD c'est has-been, place au SIMT Native Parallel Compute.

    C'est ignoble cette acharnement, alors que l'herbe n'a même pas encore repoussé sur la tombe de Larrabee.
    Ce qui est curieux, c'est qu'aux dernières nouvelles, Larrabee n'est pas mort et reste la solution HPC d'Intel (Knights). Le problème, c'est qu'à la base ils voulaient intégrer des cores de type Larrabee sur les dies de CPU grand-public pour servir à la fois à la 3D et au GPGPU.

    Là, Intel choisit une autre voie pour ses GPU grand-public, et a visiblement l'intention d'en faire quelque chose d'adapté au GPGPU, remplaçant complètement Larrabee pour le grand-public.

    Du coup Intel va se trimballer une archi HPC grand-public et une autre pour les pros (en plus de leurs CPU classiques) ? Ça sent un peu fort l'Itanium, non ?
    Mon blog (absolument pas à jour) : Teχlog

  30. #450
    Citation Envoyé par Møgluglu Voir le message
    Je n'avais pas réalisé jusqu'ici à quel point Intel à "retourné sa veste à 180 degrés" entre Larrabee et le GPU de Sandy Bridge.

    À en croire le compte-rendu de Goto de la présentation à l'IDF (http://pc.watch.impress.co.jp/docs/c...07_412173.html et http://pc.watch.impress.co.jp/docs/c...14_413951.html) :

    - mort au RISC, vive les jeux d'instructions CISC, ça colle mieux aux langages haut-niveau et ça simplifie le compilateur,

    - partout où on en a eu l'occasion, on a mis des unités spécialisées, parce que le hardware générique c'est mal,

    - les jeux d'instructions SIMD c'est has-been, place au SIMT Native Parallel Compute.

    C'est ignoble cette acharnement, alors que l'herbe n'a même pas encore repoussé sur la tombe de Larrabee.
    Ton interpretation est erronnee , Intel a toujours fait ses GPUs de la meme maniere (et les architectures Intel et Nvidia ont toujours ete assez proche), Sandy Bridge n'est pas un retournement de veste, juste une evolution de la generation precedente. Certes le marketing agressif qui a ete fait autour d'un produit inexistant etait different, mais tu remarqueras que les gens qui tenaient ce discours ont disparu .

    Si je cherchais une theorie du complot, je dirais que Larrabee etait juste une diversion pour forcer Nvidia et AMD a mettre trop de hardware generique pour faire de la place a Sandy Bridge mais ca serait probablement crediter Intel de trop d'intelligence...

    ---------- Post ajouté à 22h31 ----------

    Citation Envoyé par Alexko Voir le message
    Du coup Intel va se trimballer une archi HPC grand-public et une autre pour les pros (en plus de leurs CPU classiques) ? Ça sent un peu fort l'Itanium, non ?
    La ressemblance ne cesse de grandir .
    fefe - Dillon Y'Bon

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
  •