Intel gagne des sous (un peu moins que l'année dernière, on nous ferait presque croire qu'ils ne vendent plus aucun processeur Desktop) mais Intel vire 12000 personnes soit ~10% de ses effectifs mondiaux. Ils ont piqué le business model de chez IBM?
Intel gagne des sous (un peu moins que l'année dernière, on nous ferait presque croire qu'ils ne vendent plus aucun processeur Desktop) mais Intel vire 12000 personnes soit ~10% de ses effectifs mondiaux. Ils ont piqué le business model de chez IBM?
Envoyé par François
On m'a proposé de sous-traiter pour Intel à Montpellier, à l'époque où je cherchais du taff'.
Ca faisait pas rêver des masses: rédiger des programmes de tests à la con pour vérifier que leur driver ne se viandait pas. En SSII
Tu m'étonnes qu'ils lourdent s'il outsourcent la moindre tâche à faire.
Reste a voir ce qu'Atom va devenir : un CPU pour les PC low cost et pour l'embarque seulement ?
L'embarqué/"Internet of Things" c'est pas censé être Quark?
Envoyé par François
Attends, quand même, y a... heu... trois smartphones Asus, un Orange et une tablette Samsung (de mémoire)
Salut les canards avancés
Dites, comment ça se passe les cartes mères bi-CPU Intel ?
J'ai deux trois questions à ce sujet parce qu'on pourrait s'en monter une pour le boulot (ils veulent que j'assemble la machine avant mon départ, après, ils ne sauront peut-être plus faire ).
- L'OS voit-il les deux CPUs comme un seul ?
- Est-ce qu'un seul process créant des threads de calcul peut les faire tourner (via l'affinité, ou en laissant l'OS décider) sur l'ensemble des deux CPUs (une moitié sur le premier, l'autre sur le second) ?
- Je sais que la mémoire est virtuelle, et que les adresses ne sont jamais hardware, mais dans le processus du context switch les données finissent tôt ou tard par être accessibles en RAM, comment est-elle gérée ? Les deux CPUs ont accés à toutes les barrettes, ou chacun les siennes ?
Voici le fonctionnement actuel : on a un grand tableau d'alloué, et autant de threads que possible de démarrés (enfin, un par cœur logique, au-delà ce serait débile), mais pas d'accès concurrentiel.
Comme ça :
(oui bon les cases sont mal mappées sur les flèches et les threads, mais vous avez compris )
Si nécessaire, bien que ce serait un peu relou, il serait possible de séparer tout ça en plusieurs tableaux, mais il faudra tôt ou tard que le tableau complet soit accessible intégralement par un même thread. C'est une DLL C/C++ de calcul intensif appelée tantôt par ma console de test C/C++, tantôt par le programme final C#/.NET.
Merci d'avance
Techniquement, il voit déjà chaque contexte hardware (pour l'Hyperthreading) de chaque cœur comme un CPU différent. Avec plusieurs sockets tu vas juste avoir encore plus de CPU dans ta machine.
Oui, dans les deux cas : par défaut ou en le forçant par l'affinité.Est-ce qu'un seul process créant des threads de calcul peut les faire tourner (via l'affinité, ou en laissant l'OS décider) sur l'ensemble des deux CPUs (une moitié sur le premier, l'autre sur le second) ?
C'est du ccNUMA. Chaque socket est branché sur sa propre mémoire physique. Mais tu as un mécanisme de cohérence qui permet d'aller taper dans la mémoire du voisin si ta donnée s'y trouve, et de la remonter dans ton cache. C'est transparent pour le soft, qui a l'impression d'avoir une seule mémoire. Par contre les perfs seront meilleures quand tu tapes dans ta propre mémoire que dans celle du socket d'à-côté.Je sais que la mémoire est virtuelle, et que les adresses ne sont jamais hardware, mais dans le processus du context switch les données finissent tôt ou tard par être accessibles en RAM, comment est-elle gérée ? Les deux CPUs ont accés à toutes les barrettes, ou chacun les siennes ?
Grosso-modo quand tu fais un malloc l'OS décide où placer les données. Par défaut il essaiera de l'allouer sur le socket sur lequel tourne le thread qui fait le malloc / premier accès. Mais si tu passes le pointeur à un autre thread ou que le thread est migré, tu peux te retrouver avec des accès distants. Il y a moyen de forcer le placement ou bidouiller les politiques avec numactl.
Dans ton cas si tu fais un seul gros malloc et que tu distribue les bouts aux threads, ça peut mal se passer ou bien se passer (si l'OS fait le placement lors du premier accès et que tu accèdes toujours au même bout de mémoire avec le même thread).
L'OS va bien voir chaque CPU et l'ensemble de ses coeurs séparément, mais niveau programmation c'est transparent, tu crée les threads comme d'hab et ce sera juste la gestion de l'affinité qui changera un peu si tu veux mettre les mains dedans.
Pour la mémoire, c'est un fonctionnement NUMA : les procs ont accès à toute la mémoire, mais chaque proc accèdera plus rapidement à "ses" barrettes. Sous Linux ça peut se gérer finement avec la libNuma mais vu que tu parles de .NET va falloir te trouver un expert en fenêtres. Après ce n'est pas forcément indispensable.
Par contre c'est pas très clair sur quelle partie tu prends la main et qu'est-ce qui est figé dans ta lib.
Si tu gère toi-même les tableaux et que tu es sûr de ne pas avoir d'accès concurrents pendant le plus gros de ton calcul, ce qui marche pas mal est de faire une initialisation en "first-touch" : le thread maître alloue ton gros tableau en mémoire, puis ensuite chaque thread va mettre à 0 uniquement la sous-partie du tableau sur laquelle il va travailler. Ca va te "préchauffer" les caches en étant sûr que chaque coeur n'ait rapatrié que ce dont il aura besoin.
Edit : Pfffff et voilà, premier post dans la section et je me fais déjà griller par un taulier.
Merci pour vos réponses, elles sont très claires !
Ce que je pourrais faire pour améliorer les perfs du point de vue des accès mémoire : J'alloue dans chaque thread seulement la mémoire dont il a besoin (actuellement sur un i7-6700K, ce serait son "huitième du tableau complet"), il travaille dessus et... ah bah non merde. Je peux pas.
En gros, que ce soit mon appli console C/C++ ou l'appli .NET en C#, c'est elle qui alloue la mémoire, elle ne fait qu'en donner le pointeur à la classe de la DLL qui gère les threads et les calculs. Du coup faut que ce soit côté C# qu'ils gèrent comment s'y prendre.
Sinon, pour être plus clair :
- J'ai un Singleton "Cluster"
C'est lui va gérer les threads et les calculs, il encapsule en de simples appels d'une fonction toute l'intelligence, de cette façon l'appli C# des messieurs haut-niveau a juste à dire "fait moi ce calcul lourd sur ce tableau que je t'ai alloué"
Les résultats seront ensuite utilisés dans plein d'autres aspects de l'application (y'a de la base de données, des web-services, etc)- J'ai des instances de ma classe "Device" dans le Cluster
Elles héritent d'une classe "Thread" personnalisée qui rend plus confortable l'utilisation des threads Windows, et ont deux rôles différents en fonction de ce qu'on a spécifié au Cluster
Soit ce sont juste des threads CPU, et ils font les calculs via des méthodes/fonctions classiques
Soit ce sont des threads CPU uniquement là pour gérer chacun un GPU, afin de gérer explicitement la mémoire et l'exécution, ils s'occupent de tout (allocation, copies, lancement des kernels, etc)
Dans tous les cas donc, ils se trimballent avec un "start" et un "count" indiquant de quel à quel élément ils doivent travailler.
Basiquement sur mon i7-6700K du boulot, soit je demande explicitement à tourner sur CPU et je spécifie que je veux 8 threads de calcul, soit je le laisse tenter de chercher des GPUs utilisables pour du CUDA et je finis avec deux threads CPU de "calcul" car il y a deux GTX 770 à gérer dans cette machine.
(Au passage, actuellement la version GPU n'est... pas fonctionnelle à 100%, mais peu importe).
Il va falloir trouver un moyen de leur côté, en C#, pour allouer 1 tableau pour chacun des N threads, de taille (1/N), et passer ça en paramètre de façon différente du coup. Actuellement le tableau est envoyé en un seul pointeur, logique. Ou accepter que les perfs soient moins bonnes.
Après, c'est un calcul assez lourd, avec de rares accès en lecture et/ou écriture à ce tableau, la plupart du temps on écrit simplement le résultat à chaque index. De temps en temps, on fait aussi une somme avec un autre tableau, et on fait une lecture et une écriture de plus.
Oui, il n'y a pas de raison de penser que les effets NUMA vont poser problème. Il faut juste savoir que ça existe pour le jour où on rencontre le problème et pour ne pas faire complètement n'importe quoi avec les accès mémoire.
Déjà le bus QPI entre sockets a une bande passante et une latence pas ridicule, ensuite les données sont mises en cache localement, et enfin tu n'as que deux sockets donc a priori au moins une chance sur deux d'avoir les données au bon endroit... Il faut déjà bien stresser la mémoire pour voir l'effet NUMA.
Au passage tu as des effets NUMA avec les GPU aussi. Sur la carte mère bi-socket, tu dois avoir des slots PCIe de chaque côté, en haut et en bas. Ils sont reliés à des sockets différents. Si tu mets un GPU en haut et un en bas, chaque CPU aura son GPU préféré. Si tu les mets tous en bas, il y aura un CPU plus proche des GPU que l'autre.
(Par exemple sur notre Dell T7910 avec GTX 980+Titan X, on est dans le second cas avec les deux cartes bien collées ensemble en bas et des câbles d'alim qui traversent tout le boîtier, parce que sinon le capot ferme pas. )
Bah à priori pas besoin de t'embêter, comme je disait plus haut :
Dans ton singleton "Cluster" tu alloue le tableau complet. Allouer signifie juste que le système va réserver une zone de mémoire virtuelle, mais ne va pas faire d'accès à la mémoire en tant que tel.
Dans les différents "Device" tu vas effectuer une première opération (une bête mise à 0 par exemple), c'est à ce moment-là que le système va réellement allouer des pages pointant vers la mémoire physique.
Oui en effet, toi tu as déjà une bonne idée d'à quel point ces calculs sont lourds
C'est bon à savoir que ça vaut aussi pour les GPUs, mais je pense que je l'aurais déduit si tu ne me l'avais pas dit : c'est un socket, et pour avoir des performances optimales il faut avoir des PCI-E câblés sur le socket au lieu du chipset, donc si y'en a deux, bah ça parait logique que tous les ports ne soient pas aussi bien câblés sur tous les sockets.
C'est vrai, du coup, je pense que ça ira. Et puis comme dit par Mogluglu c'est pas non plus si mauvais en performances. On n'est pas sur du fichier d'échange
Merci pour vos infos, du coup. Je vais pouvoir transmettre ça au boss, et assembler la machine avant mon départ.
Pardon, mais c'est pas le boulot d'OpenMP que de subdiviser un grand tableau en autant de threads que de coeurs dispo (ou nombre paramétrable en dur s'il le faut)?
Sur un bi-xeon avec HT et Linux SMP, on voit bien 24 coeurs (2 x 6 coeurs réels seulement). Et lorsque je lance un calcul de FFT, je vois très bien la vitesse croître jusqu'à 10 threads de calcul, puis se dégrader au delà, ce qui semble bien normal.
Et une question avec OpenMP: si j'alloue un tableau pour le traiter avec // OpenMP, le tableau va-t-il être alloué sur la mémoire d'un CPU ou bien chaque moitié sur chaque mémoire?
Je me doute que les programmeurs de FFTW_smp ont réparti les données sur les deux CPU, mais est-ce si simple avec du code à soi?
Et question pour finir: avec le Xeon Phi, y-a-t-il encore un vrai intérêt à sortir du bi ou quad Xeon pour effectuer des calculs?
En cas de Xeon Phi sur carte, il peut bien y avoir un problème de BP si les données en entrée et en sortie de traitement sont volumineuses, mais dans ce cas on peut aussi acheter un Xeon Phi CPU maintenant...
Bah comme je disais plus haut : le malloc ne fait que réserver de la mémoire virtuelle. C'est lorsque les threads vont réellement taper dans les éléments du tableau que les pages mémoire seront allouées, et le placement sur les différentes banques mémoire sera plutôt géré par numactl.
Je viens de voir que FFTW était implémentée sur la base de MPI lorsque plusieurs CPU sont dispos. J'ai lu quelques présentations, et j'ai vu qu'OpenMP et MPI étaient parfois utilisés ensemble.
Mais ça serait possible de voir une routine qui "alloue et initialise un tableau de telle sorte qu'il soit explicitement stocké équitablement sur deux jeux de barettes mémoire"?
Je viens de voir que ma fac d'origine a pondu une API pour ça: https://www.open-mpi.org/projects/hwloc/
Inria Bordeaux en force
Code:/***************************************************************** * Sixth example: * Allocate some memory on the last NUMA node, bind some existing * memory to the last NUMA node. *****************************************************************/ /* Get last node. */ n = hwloc_get_nbobjs_by_type(topology, HWLOC_OBJ_NUMANODE); if (n) { void *m; size = 1024*1024; obj = hwloc_get_obj_by_type(topology, HWLOC_OBJ_NUMANODE, n - 1); m = hwloc_alloc_membind_nodeset(topology, size, obj->nodeset, HWLOC_MEMBIND_BIND, 0); hwloc_free(topology, m, size); m = malloc(size); hwloc_set_area_membind_nodeset(topology, m, size, obj->nodeset, HWLOC_MEMBIND_BIND, 0); free(m); }
Sinon, par défaut, le code suivant marcherait donc pour un bi-Xeon à 6 coeurs par CPU? Si on fait un 'numaclt -a' avant?
Code:size_t N = ; float *mem = (float*) malloc( 2 gigas merci ); // first touch policy #pragma omp parallel for num_threads(24) for (size_t i = 0; i < N; i++) mem[i] = 0; // gros calcul #pragma omp parallel for num_threads(10) for (size_t i = 0; i < N; i++) { // gros calcul sur tableau }
Apparemment, il y a moyen de faire ça de manière plus explicite avec OMP_PLACES: http://openmp.org/sc13/OpenMP4.0_Int...ngYan_SC13.pdf
C'est pas super clair pour moi, mais mon bouquin OpenMP est resté au labo...
Dernière modification par vectra ; 29/05/2016 à 13h31.
Si tu mets num_threads(24) dans les deux cas et que tu ajoutes un schedule(static) ça devrait bien se passer :
http://stackoverflow.com/questions/1...edule#10852852
Table 2.5, page 60 http://www.openmp.org/mp-documents/openmp-4.5.pdf
D'après les specs, ça fait ce que tu veux si tu es dans la même région parallèle, même chunk_size ou pas de chunk_size, même nombre d'itération et pas de SIMD.
J'ai eu le problème récemment, c'est le seul cas que la norme autorise pour garantir que les mêmes threads vont taper les mêmes données. Tous les autres cas n'offrent aucune garantie. Donc il faut ouvrir la région parallèle, faire les 2 omp for et la refermer. A priori, ne pas le faire dans la même zone parallèle *peut* marcher, mais ce n'est pas garantit par les specs.
Intel va fermer tous ses centres de R&D en France (dans le cadre de son plan de restructuration et des -12000 emplois dans le monde).
EDIT : Je viens de voir que c'était posté dans le topic Intel et Larrabee, moi je poste dans le bon topic na.
Ouch.
Dire qu'on m'avait proposé un boulot pourri de presta pour chez eux.
Heureusement que j'ai pas en mesure d'accepter. Mes espoirs d'évoluer vers du mieux ou vers chez eux auraient été un peu douchés.
-750 postes
Et la tuerie finale:
monde."Intel continue ses opérations en France pour accompagner la transformation de la société en une entreprise qui motorise le cloud et les milliards d'objets connectés"
de.
merde.
En même temps, pendant 15 ans, j'ai changé de PC tous les 2-3 ans. J'ai changé mon Q9650 il y a 1 mois après 7,5 ans de service et la P35 sur laquelle il était après 9 ans. Et Ca faisait environ 3 ans à peine qu'il se faisait rouster par les machines de calcul du BE aéro.
Les pros ont tellement de temps pour valider les solutions que par essence, ils ont du matos obsolète à sa mise en service. Sauf pour les machines "bureautique", mais là, mon téléphone perso rouste mon portable pro, c'est pas avec ça qu'on fait des marges.
Les particuliers ont soit connu l'informatique et finalement on change moins souvent. Les autres qui n'ont connu qu'internet ont une tablette ou une PS4. (Oui, je pense que la compétence "informatique" au sens "avoir une notion de comment ça marche" a disparu)
Donc je ne pense pas que le PC va disparaitre, juste que ça va se contracter pour atteindre une zone fixe : pro + joueur. Et le matos des serveurs, parce que le cloud, c'est d'abord des serveurs.
Mes propos n'engagent personne, même pas moi.
Le PC souffre de sa maturité et de sa fiabilité
Effectivement, je suis moyen-motivé pour changer le 2500K que j'ai à la maison, et qui ne m'a à l'époque pas coûté si cher que ça.
Et de l'absence de leader crédible capable de tirer les Steambox.
Moyennant un coût absolument prohibitif en marketing et une machine bien foutue, bien configurée et bien reviewée (ça, c'est moins cher que le marketing), ça peut enterrer le marché console en quelques années. Mais mettre un budget prohibitif pendant "quelques années", alors qu'on ne maitrise pas l'OS ou la plateforme, ... Mais une fois que c'est fait, tu peux repartir sur un BM de une console par an, la compatibilité fera que les gens gueulent pas trop, ça tirera les ressources dispo pour les jeux, du coup ça refera une obsolescence du matos en quelques années, sans que ce soit aussi sec que PS3->PS4 puisque la compatibilité continue.
Mes propos n'engagent personne, même pas moi.
C'est pas plus ou moins ce qui se dessine dans les consoles? Je crois qu'au moins Microsoft s'apprête à sortir une version repumpée de la One. Maintenant que c'est que du PC à l'intérieur du dedans (enfin je crois), ça deviendrait logique à terme.
Oui les consoles ont l'air de se tourner vers un modèle très proche du PC (ou plutot des Macs) où tu as plusieurs configurations disponible qui feront toutes tourner les jeux mais pas forcément au même niveau de performance.
Et Microsoft encore plus vers un modèle complètement libre avec des Xbox comme configurations "pré-approuvés" qui font tourner tous les jeux Xbox ainsi que tous les PC Windows 10+ qui sont aussi compatibles avec ces jeux. (Voir les annonces de l'E3 de cette année, tous les jeux ou presque, étaient annoncé Xbox and Windows 10 exclusive).
Par contre, on est pas près de voir une console Intel Inside ®®®®®.
Sony prépare aussi sa "PS4.5" mais n'a juste rien annoncé pour cet E3, et elle devrait etre bien sur compatible avec la PS4.
Moi, qui compte me tourner vers des métiers liés à l'architecture matérielle, je sens bien que mon futur n'est pas en France. (Déja que pour un stage d'été je suis déja en Allemagne...)