Le futur de no pc = supercalculateur ?

salut a tous :wink:

ja’i lu un article (dont voici le lien ):

www.techno-science.net… (P.S: si j’enfrain une regle effacer le lien svp)

à votre avis ce supercalculateur vaux quoi niveau performance ?

est’il plus puissant que le plus puissant des processeur de pc de bureau qui existe dans le comerce actuel ?

et kla bande passante sur le port auquel il est utiliser est’elle assé grande pour exploiter cette puissance ?

merci pour vos reponse

Bah, franchement si on regarde seulement niveau fréquence 64*75 ca fait 4800Mhz, pas énorme :neutre:

M’est avis qu’il manque un peut de cahce…2x8ko c’est léger mais le nombre de processeur doit certainement compenser cela.

Par contre niveau température, je crois que le barbecue Pci-e vient d’etre inventé :smiley:

Faut voir avec le Pci-e 2.0 pour la bande pssante.
Comme le dit MetallicaQC c’est pas énorme comme fréquence au total mais ca permet peut etre de faire fonctionner 64 programmes légers ensembles (d’ou le terme de super calculateur…) Par exemple avec des programmes de force brute cela reduit considérablement les temps de recherche du fait de la multi recherche.)

Sans compter qu’i n’est pas impossible je pense de mettre des proesseur au fréquencage plus élevé

EDIT: j’ai trouvé ca sur le meme site www.techno-science.net… on voit bien que ce qui compte c’est la capacité de calcul via le nombre de processeu ret non le frequencage.

La carte présentée est donc un reel pas en avant du fait qu’équiper les serveur individuel de ce type de carte permettrait surement de belles performances…
Edité le 30/07/2007 à 04:32

Euh ouai sauf que ça ne marche pas comme ça :ane:
Sinon nos CPU double coeur à frequence Y auraient des performances de simple-coeur à frequence Yx 2. Et Y x 4 pour les quadcore. Ce qui est loin d’etre un cas général.

Là on parle de systeme hautement parallélisé, chaque “CPU” etant considerer comme une unité de calcul qui va traiter des petites quantite d’informations et ne necessitant pas des grosses frequences prises une à une.

Un tel systeme n’est valable que pour des traitements dont la forme est adapté à la parallélisation à outrance, calcul scientifique, simulation numérique, traitement de données en grandes quantités etc. Mais pour une machine de bureautique on sait à peine exploiter 2 ou 4 coeurs de CPU qui doivent tout de meme posséder chacun une certaine puissance (un Core2duo à 500Mhz ça restera une grosse bouze).

Ce type de systeme n’a rien de nouveau dans l’univers des serveurs de ce type, ça fait des dixaines d’années qu’ils mettent en paralleles des CPU pour obtenir des puissances de calculs gigantesques (renseignes toi sur les supercalculateur des meteorologues ets autres, tu verras de quoi je parles). Maintenant on fait meme de la parallelisation de PC (le projet SETI est l’exemple le plus flagrant pour ça… ça s’appel le calcul de grille)

Donc pour repondre à ta question: non, je ne pense pas qu’on verra se genre de machine dans nos PC de bureau car ce n’est tout simplement pas adapté à l’usage. Ou alors il faudrait revoir entierement les systemes d’exploitations, les logiciels et la façon de penser une application… ce qui n’est pas pret d’arriver.

Dis toi une chose: une Formule 1 c’est peut-etre ce qu’il y a de plus rapide sur un tour de circuit ayant un bitume lisse comme le verre, mais quand il s’agit d’aller les faire les courses rien ne remplace ce bon vieux break ou un monospace compact pour cela :wink:

Là on parle de upercalculateur pour l’ordinateur de Buerau, c’est donc bien de parallélisme pour le bureau dont on parle.
C’est vrai qu’à l’origine le parallélisme massif a été conçu pour le calcul scientifique, mais on est loin des milliers de processeur dans nos ordinateurs. la pas en avant ici n’est peut-être pas la puissance, mais de commencer à faire fonctionner 64 processeur avec un langage adapté (et spécailement conçu) pour éventuellement utiliser un jour 646 processeur plus puissants

Là il manque quand même les références des processeurs utiliisés, et en terme de puissance, on parel plutôt en MFlops ou GFlops, ce qui multiplié par le nombre de processeur nous donne “la puissance de crête” qui est la limite supérieure de la machine (comprendre une limite inaccessible, mais que l’on tente d’approcher)

[HS]

Le_poilu t’est enfin de retour , je t’ai envoyer un MP en espérant que tu me répondra :wink:

[/HS]

en plus dans l’article il est marquer ce cette carque est aussi grande qu’une carte video mais de chez qui ?

voodoo 5 :smiley:

Moi je suis sceptique, on ne sait pas de quels processeurs ils parlent, en plus ils restent sur un bus PCI-X, en passant au PCIe ils pourraient encore améliorer la bande passante. Enfin il faut des programmes écrits spécifiquement pour ça (et même un langage, ce qu’ils ont fait apparemment)

Le genre de commentaire qui impose le respect :icon_biggrin:

Bon retour Le Poilu :jap:

J’etais pas parti :paf:

J’avais lu des articles sur la parallélisation et il me semble que l’échelle de perfs est logarithmique. Avec deux processeurs le gain était de 2 (environ). Pour 4 processeurs, la gain était de 3. Pour 8 processeurs, on était à 5 …

Bon c’était pour un type particulier de clusters et pour style de parallélisation ;). Le problème étant de conserver l’intégrité des données et de communiquer. Par exemple,

operation1 + opération2 = ?

Le cpu 1 met dans son cache l’operation 1 et retourne un résultat. Le cpu 2 met dans son cache l’operation 2 et retourne un résultat. Le cpu fait l’addition --> il a besoin des résultats 1 et 2 qui ne sont pas dans son cache et il va perdre du temps (surtout que lors de l’operation 1 et 2 il glandait :)).

C’est pas terrible de travailler comme ça, le plus efficace est de travailler par lot, chaque proc/coeur traite un lot de données puis quand ils ont finis ils se synchronisent.
Sur un grand nombre de traitements le temps de calcul moyen pour chaque proc/coeur tend à être le même donc la perte de temps lors de la synchro peu devenir négligeable si le nombre de traitements par lot est important.
Ex: un filtre sur une image, si tu as 4 coeurs/procs, tu découpes l’image en 4 et chaque coeur travaille dans son coin sur son bout d’image. Ils ne se synchronisent qu’à la fin pour rassembler leurs résultats.

oui c’est tout le probleme de la parallelisation du traitement.

C’est ce qui fait que c’est si dur de paralleliser un jeux-vidéo. Car on ne peut pas tout séparer: la moindre action du joueur ayant des répercution sur tous les elements du jeux (graphique, physique, IA etc). Comment traiter en parallèle la physique du jeu et l’affichage sachant que le second à besoin des resultats du premier et que le premier dépend de l’action du joueur… Action du joueur variant en fonction de ce qui s’affiche à son ecran…

C’est pour ça que pour l’instant les logiciels et applications exploitant le traitement parallele sont si specifique: traitement d’image ou de vidéo, rendu 3D, calcul scientifiques… etc. Pour ces applications il est possible de découper le traitement en morceaux indépendant à traiter.
Et même dans ce cas “idéal” le gain est loin d’etre 2x ou 4x.
On le voit bien avec cinebench qui se base sur le moteur de rendu 3D de Cinema4D (modelisation 3D). Le bench donne un resultat pour 1 core puis pour les n cores presents dans le CPU. Pour un Core 2 Duo le coeff de gain pour 2 core est en general de 1.85. Ceci etant imputables aux pertes de communication entre CPU, de goulet d’etranglement du FSB etc…

L’échelle des perfs dépend complètement des algorithmes utilisé, et de l’architecture de la machine.
Voir la Loi D’amdhal :
fr.wikipedia.org…

  1. on peut séparer un algo parallèle en son Temps Séquentiel Ts (partie non parallélisable) et son Temps parallèle Tp:
    T=Ts +Tp / n

avec “n” nombre de proc, on voit qu’en minimisant Ts on peut tenter d’approcher une’“accélération” (terme dédié) égale au nombre de proc.

  1. Mais il y a aussi le problème de temps de transfert de données (de mémoire):
    Tp = Td +Tc
    Le temps d’exécution parallèle est lui même fonction du temps de caclul mais aussi du temps Td de transfert de données car bien souvent les algo parallèles nécessitent de se communiquer des données entre Thread pendant le temps du calcul: par exemple le cas d’école de multiplication de matrices, dans lequel on se communique les resultats entre lignes et colonnes.

Si donc ce temps de transfert spécifique au parallélisme est supérieur au gain obtenu par parallélisation, l’algo parallèle n’est pas rentable, et même s’il est inférieur, cela limite l’accélération.

Dans ce cas, cela dépend non-seulement de l’algo (de son ratio données-calcul) mais aussi de l’efficacité du bus ou du réseau qui relie les procs (d’ou les amélioration attendue notamment avec les connexion 3D pour augmenter encore la connectivité des processeurs)

Bref on ne peut jamais dire que n procs sont n fois plus pluissant qu’un proc, ni qu’ils sont ln(n) fois plus puissant, on peut simplement affirmer que la puissance est strictement inférieure à n fois un proc.

Cette limite on l’appelle puissance de crête, égale à n fois la puisssance d’un proc, même si on sait qu’elle n’est jamais atteinte dans la réalité.

edit: désolé pour les fautes, j’ai du mal à taper dans cette petite fenêtre.

PS: d’ac avec le poilu qui démontre par la pratique ce qu’on connait par la théorie. Et la video est effectivement un des domaines qui se parallélise le mieux.
Edité le 30/07/2007 à 17:09

deltree -> ça c’est de la théorie pure.

Maintenant pour appliquer ça dans le monde réel c’est une autre paire de manche :ane:

Non, c’est ce que je disais, si on est capable de calculer la moindre perte de temps de calcul entre Temps séquentiel et Temps de transfert de données parallèle, on peut calculer combien notre algorithme est mauvais, en étant juste un poil en dessous de la réalité :smiley:

faut-il une accélération > 1 ou une efficacité proche de 1 ?

  • pour une efficacité proche de 1, par exemple avec 8 proc de la puissance 6 on a une efficacité = 0.75
    Si on se limite à des algos purement parallélisable, comme la video, la 3D etc., on est capable d’exploiter le parallélisme: et même si avec 8 procs on a la puissance de 6, on est plus rapide donc on a gagné quelque chose.

  • une accélération supérieure à 1
    Même si avec 8 procs, on avait la puissance de seulement 1.5 procs, on serais content dans le cas ou c’est une course à la puissance, et qu’on a plus aucun autre moyen d’en gagner, là ça devient un problème économique, mais qui n’est pas forcément contraignant dans la monde militaire par exemple (si ça peut leur permettre de casser un code tout est bon à gagner)

bref ça s’adapte davantage aux algorithme connus et spécifiques: les solutions graphique sont déjà largement parallèle. Mais pour du traitement général, même les compilateurs actuels ne sont pas forcément adaptés, car c’est le programmeur qui est obligé lui-même de paralléliser son code, tant qu’on en sera à cet état de fait, le parallélisme sera effectivement difficile pour le grand public

NB: j’emploie des termes de cours de parallélisme: efficacité, accélération comme on peut les retrouver dans des articles sur le parallélisme: efficacité = accélération / nb proc

holala sa fé mal a la téte toute ces doné burte je v directe prendre une aspirine et comprendre sa en detail moi :smiley: