AMD annonce le 4x4

[La Rédaction]

On connaissait le gros 4x4 de beauf avec pare-buffle intégré, mais AMD s'apprête à lancer un nouveau substitut pénien ayant le même nom. Les PC 4x4, qui devraient arriver au prochain semestre, seront des machines à double quadruple core. Oui madame, oui monsieur, double quadruple core.

Explication : vous aurez sur la même bécane deux CPU Athlon 64 X2 double core logés sur une carte mère avec deux sockets AM2, épaulés par deux cartes graphiques à double GPU – vraisemblablement des NVIDIA – ayant chacune leur port PCI-Express. Ca nous fait donc 4 CPU et 4 GPU, voilà, on a notre 4x4. Le tout sera géré par la technologie "Pacifica" d'AMD pour distribuer les données parmi tout ce petit monde. Le prix ? Ha ha ! Pauvre fou !

Voir la news (0 image, 0 vidéo )

[Guts]

Le prix ? Ha ha ! Pauvre fou !

je veux même pas le savoir

[jeeeff]

je veux même pas le savoir

ah si moi j'aimerais bien le savoir !!

j'aime bien quand les poils se dressent sur mes avant-bras musclés :D

[Garn]

jolie puissance de calcul mais je doute que ca serve beaucoup :P

[Ze_PIlOt]

ouf, ca me rassure, on a des galettes de bi dual core pour la renderfarm, je pensais qu'ils avaient déjà réussi à faire pire, mais c'est juste le gpu..

[lanef300]

Et moi qui me demandait avec quoi j'allais faire tourner FSX à fond...
Par contre ils disent pas si l'alim nucléaire est livrée?
Parce qu'avec du SLI ou du crossfire, va falloir des watts!

[NiarKal]

Ça doit être super bien pour faire des oeux sur le plat.

[mordorion]

Voilà, c'est ca qu'il nous faut pour Crysis en 1600, Hq, ombres full et aa16x

[AlSquire]

De toutes c'est impossible à garer en ville, alors dans ma chambre...

[NiarKal]

En fait ça mérite bien son appelation 4*4 : c'est tout aussi nocif pour l'environemment qu'un bon 4*4 des familles.

[fifou]

Ca tombe bien, pas plus tard qu'hier soir en regardant de nouveau les images de Crisis, je disais à ma femme qua fin 2007 je rajeunissais mon PC ..... fais moi confiance chérie, de toute façon avec les petites on ne peut pas profiter comme on veut des vacances .... autant rester à la maison et profiter du jardin nan ???

[braoru]

Comment revendre l’idée du smp… pathétique.

[Daystrom]

Sur Mac un biprocesseur DualCore existe et s'appele Quad.
Amd n'as rien inventé.

[Crashy]

Deja que c'est tendu de développer en dual core, alors en quad bof.

Je sens que je vais repasser sur Intel a la prochaine génération.

[super-kanard]

Sur Mac un biprocesseur DualCore existe et s'appele Quad.
Amd n'as rien inventé.

Bah de toute façon ya rien a inventer, le multi proc ça existe depuis des lustres.

La seule nouveauté c'est de vendre ça au grand public... Enfin à la tranche très très riche du grand public.

[Ze_PIlOt]

Comment revendre l’idée du smp… pathétique.

ca existe sur pc pour les machines de rendus depuis un moment. Tu bosses pas dessus, c'est juste de la puissance brute (avec la CM optimisée pour ça qui va bien). N'importe quelle app pro gere autant de thread qu'elle veut..

Mais du coup je pige pas le coup de mettre autant de puissance dans la CG, alors qu'une galette bi-dual core coute pas si cher, justement parce qu'il y une CG de merde sur la CM et un p'tit HD de 80 go...

Pour le "grand public" (pas pro, entendons nous), je vois, mais alors, pas du tout l'interet.. déjà l'interet du dual core sur une machine à tout faire est plus que limite.. Les "pros" bossent déjà en dual core depuis des lustres..

[SnakesMaster]

Moi je dis tant que ça fait baisser le prix des autres processeurs, chipsets ou CG plus abordable, eh bah ya pas de raison de gueuler :P

[Eld]

Deja que c'est tendu de développer en dual core, alors en quad bof.
Je sens que je vais repasser sur Intel a la prochaine génération.

bosser en dual ou quad core, c est pareil niveau pogrammation : il faut threader tout proprement
après, le nombre de processeurs sur lequel ça se répartir, ça doit être transparent pour le programmeur
sinon, intel aussi va faire du quad, qu'est ce que t'imagines :P

[Crashy]

Oui, mais bon malheureusement la gestion des processeurs est pourrave sur Win XP(d'apres ce que j'ai lu, par défaut il attend d'avoir un CPU plein avant de foutre des taches dans le second), alors faut mettre des flags spéciaux lors de la creation des thread pour répartir les taches comme il faut, et même avec un systeme ayant une bonne répartition, faut toujours bien organiser ses thread.

Parcequ'au final, bien sur si on commence a concevoir une appli multithreadée on peut foutre autant qu'on veut et hop le systeme se débrouille meme si ya qu'un cpu. Maisya des taches plus importantes que d'autres, certaines qui de toute facon n'ont aucun intéret d'etre en parallèle.

Ca demande une certaine dose d'experience, et c'est aussi un argument contre la PS3 : 8CPU, ca va etre dur de bien les utiliser.

Bien sur tu peux foutre ca n'importe comment et basta, ca marchera, mais ca sera pas forcemment très efficace.

[Eno Onmai]

Ca demande une certaine dose d'experience, et c'est aussi un argument contre la PS3 : 8CPU, ca va etre dur de bien les utiliser.

Y'a pas 8 cpu sur la ps3, c'est un cpu et 8 sous proc, c'est la 360 qui a 3 cpu. Par contre, je rappelerais quand même à ses braves gens de Nvidia tout fier d'avoir réussis à mettre 4 cg en sli que le systeme de 3dfx (dont ils sont propriétaire) pouvait permettre de placer 32 chip graphiques en sli. (en en mettant 8 par carte, c'est jouable encore)

[Daystrom]

Oui, mais bon malheureusement la gestion des processeurs est pourrave sur Win XP(d'apres ce que j'ai lu, par défaut il attend d'avoir un CPU plein avant de foutre des taches dans le second), alors faut mettre des flags spéciaux lors de la creation des thread pour répartir les taches comme il faut, et même avec un systeme ayant une bonne répartition, faut toujours bien organiser ses thread.

Parcequ'au final, bien sur si on commence a concevoir une appli multithreadée on peut foutre autant qu'on veut et hop le systeme se débrouille meme si ya qu'un cpu. Maisya des taches plus importantes que d'autres, certaines qui de toute facon n'ont aucun intéret d'etre en parallèle.

Ca demande une certaine dose d'experience, et c'est aussi un argument contre la PS3 : 8CPU, ca va etre dur de bien les utiliser.

Bien sur tu peux foutre ca n'importe comment et basta, ca marchera, mais ca sera pas forcemment très efficace.

Faut etre lucide une telle machine ne pourra etre utilisé que syr Vista, et encore s'il n'y a pas de limitation du nombre de Core gerable comme sur Windows 2000 par exemple (version sation de travail 2 Processeurs, 4 et plus pour les versions serveurs).

[GloP]

bosser en dual ou quad core, c est pareil niveau pogrammation : il faut threader tout proprement
après, le nombre de processeurs sur lequel ça se répartir, ça doit être transparent pour le programmeur
sinon, intel aussi va faire du quad, qu'est ce que t'imagines :P

Heu non c'est pas super vrai, ca se passe pas comme ca. Souvent les perfs s'ameliorent pour 2 CPU si ca a ete fait pour marcher sur 2 et baissent, voire s'effondrent a 4 ou a 8 a cause de lock mutuels et qui rendent le dev plus difficile. Quoi qu'on fasse on doit toujours gerer des trucs externes au CPU qui doivent etre serializes, et gerer des acces exclusifs. Une zone memoire, un fichier, un GPU, ou n'importe quoi du genre. Alors un bon SDK ou une bonne lib, ca aide, et les gens qui font une lib multi-threadee peuvent la faire pour qu'elle apparaisse relativement transparente, mais si tu geres direct le multi-thread d'un truc complexe t'as interet a tester a 4 si tu veux que ca marche comme il faut avec 4 .

Oui, mais bon malheureusement la gestion des processeurs est pourrave sur Win XP(d'apres ce que j'ai lu, par défaut il attend d'avoir un CPU plein avant de foutre des taches dans le second), alors faut mettre des flags spéciaux lors de la creation des thread pour répartir les taches comme il faut, et même avec un systeme ayant une bonne répartition, faut toujours bien organiser ses thread.

Non ca c'est 100% faux. XP gere tres bien thread sur plusieurs procs (et si on veut comparer a autre chose, on peut...) faut pas croire tout ce qu'on lit sur slashdot ecrit pas un mec qui y connait autant que ma soeur en multi-threading (pas que ca soit une honte, mal ou quoi, mais ma soeur elle poste pas son opinion sur le multi-threading de X ou Y...). Et ca veut pas dire grand chose "avoir un CPU plein avant de fouttre des taches dans le second". Une tache non multi-threadee ne peut pas etre mise sur 2 core/CPU, et si c'est des process, c'est re-ajuste dynamiquement, meme si c'est potentiellement un round robin au depart. A la limite avec l'hyper-threading ca peut etre interessant de faire des distinctions, mais on rentre dans du detail. En plus les API sur tout systeme moderne qui a un OS multi-tache pre-emptif ne te laisse en regle generale qu'au mieux donner une indication de thread affinity et pas une regle en dur, les API POSIX ne continennent d'ailleurs pas directement de maniere de gerer directement l'affinite d'un thread. C'est une des differences avec le SDK de la 360 par exemple justement ou tu peux controller en dur le thread affinity des la creation du thread. Tu peux empecher un process d'utiliser tel ou tel CPU mais ca a pas trop a voir et c'est l'envers de ce dont tu parles. Et on parle pas des fiber qui elles (eux?) sont 100% user mode (et donc *tres* rapide a switcher puisqu'il y a pas de changement de contexte d'execution) et doivent "yielder" pour passer la main a un(e) autre fiber. Ca s'appelle des "green threads" il me semble sous d'autre OS (sunOS/bsd/?). Donc non, faut pas "organiser ses threads", il faut bien gerer les sections ou ils interagissent.

Parcequ'au final, bien sur si on commence a concevoir une appli multithreadée on peut foutre autant qu'on veut et hop le systeme se débrouille meme si ya qu'un cpu. Maisya des taches plus importantes que d'autres, certaines qui de toute facon n'ont aucun intéret d'etre en parallèle.

Si t'as une appli multi threade, le systeme va repartir les threads en essayant d'etre optimal et oui si t'as un qu'un CPU/core il s'en sortira. Dans l'autre sens ca marche pas forcement. Si t'as qu'un seul thread, le systeme saura pas quoi en faire sur 2 CPU/core (ou 2 sur 4 ou 4 sur 8 ) et le comportement peut changer et etre imprevisible si t'en avais 16 sur 2 et que tu passes a 16 sur 8. Comme dit plus haut si t'as un certain nombre de thread qui sont reparti sur 2 CPU/core, rien n'assure que les perfs vont pas baisser voire s'ecrouler une fois que tu passes a 4 ou 8. C'est pas necessairement transparent, ce qui en fait un facteur de difficultee en plus. C'est un classique des bases de donnees haute performance quand elles passent a 8 CPU, c'est un investissement majeur de developpement pour les faire marcher de maniere performante (et d'ailleurs le scheduleur de win2003 avec sql server s'en sort tres bien, y a qu'a voir les resultats des TPM). Le probleme c'est qu'il y a toujours besoin de synchroniser les threads et de les faire communiquer, de respecter des sections critiques qui ne peuvent etre touchees que par un thread a la fois, etc, etc. La gestion des caches du CPU et des invalidation de celui ci selon comment elle est geree (et AMD et intel ont des approches un peu differentes) ca peut avoir une influence non negligeable sur les perfs. Donc c'est pas tellement une question d'importance, c'est une question de combien ca coute de demarrer un autre thread (ou fiber) et de les synchroniser.

Ca demande une certaine dose d'experience, et c'est aussi un argument contre la PS3 : 8CPU, ca va etre dur de bien les utiliser.

Ca c'est clair 100% d'accord, ca demande une experience assez specifique. Et pour la PS3, c'est d'autant important que c'est pas des CPU a part entiere, il y a un CPU "principal" qui est in-order en plus, et des sous-core qui se comportent plus comme des DSP pur avec leur propre memoire et qui ne peuvent adresser la memoire centrale sans demander au CPU principal de leur ramener les donnees. A mon avis perso a moi, il faut donc vraiment les gerer "a la main" pour en tirer toutes les capacites et les difficultees de sections critiques et autre race conditions sont bien poilues. Je pense que c'est aussi vrai pour la 360, avec ses 6 hardware threads mais la symmetrie du systeme et la possibilitee de potentiellement isoler une mini zones du cache L2 rend les choses potentiellement plus facile a gerer automatiquement ou en mettant les mains en plein dedans.

[Crashy]

Non ca c'est 100% faux.

Ca me venait d'un linux geek, donc ca m'etonne pas que ca soit faux :P

[braoru]

Faut etre lucide une telle machine ne pourra etre utilisé que syr Vista, et encore s'il n'y a pas de limitation du nombre de Core gerable comme sur Windows 2000 par exemple (version sation de travail 2 Processeurs, 4 et plus pour les versions serveurs).

La limitation est au niveaux nu nombre de sockets pour les licences de Windows.