On savait depuis avril dernier que les futurs Xeon E5-2600 V3, nom de code Haswell-EP, prévus pour le Socket 2011-3 embarqueront jusqu'à 14 cœurs et 35 Mo de ...
Lire la suite ...

On a une idée de la surface du die ?

Gros ...

AVX-512 au programme ? Ou c'est pour la génération encore après ?

AVX 512 ce n'est pas Broadwell mais Skylake, en 2014 en version desktop/portable et probablement 2016 en version serveur

Pour Skylake j'espère qu'ils sortiront au moins un 6 cœur 12 thread en version non E, 8/16 ça serait mieux

IBM  a des soucis à se faire, non?

Etonnant que le multi core se développant si bien et si monstrueusement dans les CPUs, que ce ne soit pas le cas pour les GPUs.

En fait les GPU sont monstrueusement multi-core, avec un grand nombre d'unités qui elle-mêmes exécutent plusieurs threads en parallèle, chaque thread réelle utilisant des unités de calculs vectorielles avec stockage des résultats conditionnels pour chaque entrée d'un vecteur.
 
Sans parler des fausses Threads accessibles en OpenCL ou CUDA, les GPU haut-de-gamme font tourner plus d'une centaine de threads en parallèle (chacune pouvant regrouper jusqu'à 64 entrées dans un vecteur).

Les GPU modernes sont intrinsèquement multi-core.

 
Jerry

A quand une fusion des deux (CPU et GPU)
Cad avoir des cores multi-fonction capable de traiter des opérations que ferait un CPU ainsi que les opérations des GPU.
Comme cela si on a plus besoin de puissance CPU pour une application/tache "on" attribue plus de cores pour cette fonction et si une tache/application demande plus de puissance GPU "on" attribue plus de cores pour cette fonction. Et tout cela en auto et transparent pour l'utilisateur.

Je viens de comprendre pourquoi il dit ça, il pensait au carte bi-gpu. Qui n'ont pas un intérêt énorme, puisqu'autant prendre un mono-gpu avec un nombre d'unités de calcul ultra élevé.

On ne demande pas du tout la même chose à un CPU qu'à un GPU. Pour un GPU c'est facile, la tâche qu'il doit accomplir est massivement parallèle, donc on blinde d'unités de calcul et quand il y a besoin de masquer de la latence (attente d'une unité de texture par exemple), on n'a qu'à prendre un autre jeu de données (thread) pour faire tourner l'unité de calcul en attendant. C'est très schématique mais en gros sur un GPU on met le paquet sur la logique d'exécution et y a pas de gros besoins sur la logique de contrôle (bon c'est en train d'évoluer là aussi).
 
Pour un CPU la plupart du temps il n'a pas vraiment souvent des problèmes à traiter qui se parallélisent aussi bien, parce que sinon on serait maintenant capable de le faire traiter par le GPU de toutes façons. Il faut donc pousser vers plus de performances par thread, essayer de décortiquer la file d'instructions pour pouvoir être capable de faire tourner un maximum d'unités de calcul en parallèle. Et c'est pas simple à cause principalement de la nature séquentielle des instructions et des dépendances entre elles. C'est pour ça qu'on ne peut pas mettre autant d'unités de calcul, on ne pourrait pas toutes les exploiter en même temps, et on complexifie à mort la logique de contrôle pour trouver un maximum d'occasions de faire tourner celles présentes.
 
Donc non, a priori on continuera encore longtemps à voir une nette séparation entre CPU et GPU, et du coup ça ne semble pas très judicieux d'avoir beaucoup de coeurs pour la partie CPU...

ockiller,
  pour ces explications

18 cores, 36 threads, impressionnant !! Evidemment à 5000 euros le CPU, ce sera pas pour le quidam du coin et celui qui sait faire de la programmation parallèle aura plutôt intérêt à investir dans le GPU, beaucoup moins cher par TFlops.

@wils: En fait c'est déjà le cas sur les CPUs. Les unités SIMD (SSE, AVX) sont proches des unités des GPUs. L'idée de base est d'exécuter une instructions sur plusieurs données.  Pour autant, ce que dit ockiller est tout à fait juste. Les architectures sont fondamentalement différentes (latency vs throughput oriented).

 
pas vraiment
 
le power8 a 12 coeurs et chaque coeur supporte 8 threads
le sparc m6 a 12 coeurs et chaque coeur supporte 8 threads
Sparc X+ a 16 coeurs et chaque coeurs supporte 2 threads
 
spact t5 a 16 coeur et chaque coeur supporte 8 thread
 
faut voir combien de ram est supporté, bande passante, combien de socket est supporté par le mainframe
 
par exemple pour le  
 
spart X+, 64 cpu peut être mis dans un mainframe ce qui donne 2048 threads simultannée
sparc m6 , 96 cpu peut être mis dans un mainframe ce qui donne 9216 threads simultannée
 
l'architecture sparc est en autre libre

Je tousse un peu sur ta dernière phrase, dans le sens ou l'architecture du SPARC est libre mais son implémentation est propriétaire, c'est à dire que chaque constructeur fait sa tambouille pour améliorer la base qui est libre, sans un devoir d'en faire profiter les autres.
Les T1 (2006) et T2 (2008) sont les seules implémentations qui ont été rendu disponibles au public. Depuis, Oracle (qui a racheté Sun) a travaillé sur une nouvelle spécification mais je ne suis pas pas certain quelle soit "libre" (ou alors au sens Oracle du terme, c'est dire...).

 
http://www.intel.fr/content/www/fr [...] etail.html
 
Ca vous dit quelque chose ? C'est du x86
 
Power et Sparc, c'pas trop la même chose, entre IBM/Apple/Motorola et Sun/Oracle ... Tu voulais peut être parler du CELL ?

 
J'y vois surtout un intérêt pour la virtualisation (cloud, infra entreprise, etc...) comme VMware vend ses licences par CPU physique.
D'ailleurs ça serait sympa de voir des tests de CPU pro (Xeon et AMD jesaispasquoi) sur de la virtualisation.

opteron

Là c'est un peu spécial. On peut toujours faire exécuter les tâches d'un GPU par un CPU. Pour du rendu 3D basé sur de la rastérisation (DirectX, OpenGL, ...) c'est pas une bonne idée, les GPU sont bien plus efficaces. Un coeur de CPU moderne arrive quand même a sortir une bonne puissance de calcul grâce effectivement à ses unités vectorielles et sa fréquence. Par contre quand on n'est pas en manque de threads à exécuter, masquer la latence devient beaucoup plus simple et on peut drastiquement simplifier les coeurs pour en mettre beaucoup plus (pas besoin d'Out of Order par exemple !).
 
Le Xeon Phi c'est juste ça, Intel a repris un coeur CPU relativement simple qu'il avait (Pentium 1), lui a remis des unités vectorielles pour redonner de la puissance de calcul, et je ne sais plus s'ils ont aussi mis des unités spécialisées comme des unités de texturing/filtrage, ce qui est bien plus efficace que d'utiliser les unités généralistes (aussi pour la consommation).
 
Par contre ça reste du x86, donc du point de vue taille du CPU et efficacité énergétique ça doit quand même peser un peu, par contre la volonté d'Intel était d'être raisonnablement compétitif sur la rastérisation, mais profiter de la polyvalence de leur puce pour enfoncer tout ce qui se faisait sur du ray tracing par exemple. Finalement ça s'est pas passé exactement comme ça...

à quand les 8 coeurs sur desktop...ça stagne trop...on veut envoyer du pâté sur des apps multithread  avec des puces à moins de 300eur.

ça serait pas par thread physique (hors HT) plutôt ?
Après le pb du gros serveur avec pleins de VM, c'est qu'en cas de panne / maintenance les impacts sont énormes

 
Sauf que tu as tout de même des limites de nombre de cœurs par CPU que ce soit pour Veeam ou pour Vmware.