La loi de Moore a-t-elle encore un avenir ?
Oui, répond un ingénieur, si les développeurs se mettent à la programmation parallèle

Le , par Gordon Fowler, Expert éminent sénior
Bill Dally est un des ingénieurs les plus importants de Nvidia.

Dans une tribune publiée dans le magasine Forbes, l'ingénieur en chef doute fortement que la loi de Moore puisse encore s'appliquer aux processeurs (CPU) : « Les performances des CPUs ne peuvent plus doubler tous les 18 mois », constate-t-il, « et cela va poser un grave problème à de nombreuses industries qui reposent sur cette croissance des performances ».

Optimiste, Bill Dally en tire cependant une raison d'espérer « La bonne nouvelle, c'est que […] la programmation parallèle peut relancer la loi de Moore et fournir une nouvelle base pour la croissance et l'innovation commerciale ».

Le scientifique sait cependant qu'il ne suffit pas de dire « y'a qu'à » pour que les choses se fassent.

« Le défi pour l'industrie va être d'abandonner des pratiques vieilles de plusieurs dizaines d'années et de s'adapter à cette nouvelle plateforme […] il existe une énorme résistance au changement ».

Cette résistance ne viendra pas, d'après lui, que des fondeurs.

Elle touchera aussi les développeurs. Surtout par manque de formation, précise-t-il. « Convertir la quantité gigantesque de programmes séquentielles (NDR : ou linéaires) existant pour les faire tourner sur une architecture parallèle est une formidable tache, qui est rendue encore plus difficile par la pénurie de programmeurs formés à la programmation parallèle ».

La programmation dite linéaire consiste à exécuter les instructions les unes après les autres pour obtenir un résultat souhaité. La programmation parallèle consiste au contraire à décomposer les tâches pour les faire exécuter simultanément par différents CPU. On comprend aisément le gain de vitesse que peut représenter ce modèle.

Mais les problèmes posés sont nombreux. Comme le note Lainé Vincent « toutes les tâches ne peuvent pas être parallélisées […]. De manière générale, celles qui peuvent être threadées, peuvent être parallélisées. Il existe cependant quelques exceptions ». Les choses ne seront donc pas si simples à mettre en place.

Bref, « après 40 ans de programmation linéaire […] une rupture avec les pratiques de longue date » serait devenue plus que nécessaire.

Mais qu'on se rassure, il ressort de cette interview que la loi de Moore n'est pas (encore) de l'histoire ancienne.

Source : La tribune de Bill Dally dans Forbes

Lire aussi :

Introduction à la programmation parallèle par Lainé Vincent

NVIDIA travaille étroitement avec Microsoft, pour préparer une nouvelle technologie de processeurs graphiques pour les calculs parallèles
Microsoft se paye Interactive Supercomputer, spécialiste du calcul parallèle

Les rubriques (actu, forums, tutos) de Développez :

Hardware

Et vous ?

Etes-vous d'accord avec cette analyse ou pensez-vous au contraire que la Loi de Moore est d'ores et déjà à mettre au musée de l'Histoire Informatique ?

Les développeurs francophones sont-ils suffisamment formés à la programmation parallèle ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de sparthane777 sparthane777 - Provisoirement toléré https://www.developpez.com
le 07/05/2010 à 13:26
Citation Envoyé par gangsoleil  Voir le message
Je precise un peu : le developpement du parallelisme doit se faire en plus de l'utilisation des multi-coeurs.

Si on prend un PC standard avec un CPU a 4 coeurs, on peut envisager par exemple les scenarii suivants :
Mode normal : firefox, winamp, un petit jeu a la con dans un coin, avec en arriere plan thunderbird et open-office. Chacun doit pouvoir disposer d'un peu de puissance de calcul, et pour cela il semble raisonnable de laisser l'OS gerer le truc.
Mode gros jeu : la, incontestablement, le parallelisme explicite (c'est a dire que le jeu est developpe pour utiliser plusieurs processeurs) devient interessant : on calcule plusieurs choses en meme temps sur les differents coeurs, et aussi sur le GPU de la carte graphique, qui se charge de l'affichage.
Dans ce cas, l'OS ne doit pas avoir en charge la repartition des differents calculs sur les processeurs ni sur les coeurs.

Ce mode est aussi applicable pour les PC que pour les serveurs, et pour tous les types d'applications. Mais il faut de la volonté, du temps, et de l'argent pour que ca commence a se democratiser.

Si on prend mon cas à moi qui veut profiter des nouveautés qui sortent parce que le métier me tiens à coeur, je vais dépenser un budget pour avoir une carte mère récente , une CG récente et un pross récente avec une alim de base adaptée à la conso ... je pense que c'est plus de la volonté qu'il faut, après les autres facteurs temps et argent relèvent plus de l'indécision .
Enfin c'est perso mon avis. Je veux réellement apprendre en restant en veille technologique permanente.
Sinon pour en revenir au multicores, les cartes mères permettent de les activer ou pas, donc effectivement ça change rien au développement en parallèle et linéaire, sur un Core, après quand on active tout les coeurs, faudrait surtout se mettre à la page, et développer des méthodes permettant d'optimiser le parallèle en fonction des coeurs présents dans le pross ... enfin, moi je me la sens tester sur du multicores un script par exemple permettant d'effectuer du parallèle.
Bref, merci du renseignement, je reviendrais bientôt vers vous pour de plus amples informations
Avatar de Franck SORIANO Franck SORIANO - Membre expert https://www.developpez.com
le 07/05/2010 à 13:45
Citation Envoyé par gangsoleil  Voir le message
Il n'y a pas un, mais des parallélismes.

Oui, "programmation parallèle" c'est un terme générique qui désigne simplement le fait de faire plusieurs choses en même temps.
Après il peut se décliner d'un grand nombre de façons (multi-threading, calculs vectoriels, ...).

Si je reprends l'exemple :

La version linéaire 1 est en fait du parallélisme (cas très particulier , qui ne sera efficace que dans de rares cas),

Détrompe-toi. C'est le fonctionnement classique d'un serveur. Et c'est généralement ce qui donne les meilleures performances : Tu attends une fois pour obtenir le processeur, tu fais tes 4 opérations, tu as terminé.
D'un point de vue, théorie des files d'attente, tu es dans la configuration où tu as une file d'attente unique, avec N guichets pour dépiler la file. C'est la configuration optimale qui permet de minimiser le temps d'attente des clients et d'utiliser au maximum chaque guichet.
Dans les autres architectures, tu attends un processeur libre pratiquement à chaque opération.
Dans le premier cas, tu fais la queue une fois. Tu arrives au guichet, tu réalises toutes tes opérations.
Dans les autres cas, tu fais la queue une fois. Tu arrives au guichet, tu réalises une seule opération. Et tu retournes faire la queue pour pouvoir faire la deuxième.
Dans les deux cas, les guichets travaillent de la même façon. Le nombre total d'opérations traitées est le même. Le temps de traitement est le même. Mais dans le deuxième cas, tu ajoutes de nombreux temps d'attente qui allongent les temps de réponse... le tout à charge constante.

Si on considère 4 processeurs, et un modelé parallèle en pipeline, on peut avoir la chose suivante (je passe volontairement la phase d'initialisation, et considère les calculs N a N+ ):

Code : Sélectionner tout
1
2
3
4
5
 
proc1 : enregistre N,  enregistre N+1,  enregistre N+2,   
proc2 : cherche N-1,   cherche N,       cherche N+1,  
proc3 : calcul N-2,    calcul N-1,      calcul N,  
proc4 : compte N-3,    compte N-2,      compte N-1,
Ce modelé permet, si on enlève les phases d'initialisation et de finalisation, de diviser le temps total de calcul par le nombre de processeurs !! Le gain est colossal, à condition que le problème soit modélisable sous forme de pipeline, ce qui n'est pas toujours le cas.

En fait, c'est la même chose que dans "linéaire 1", mais en pire : Le calcul se fait aussi en 4 temps, mais avec des synchronisations obligatoires entre chaque étape :
Proc1 exécute "enregistre N". Il faut attendre que Proc2 ait terminé "cherche N-1" pour pouvoir enchaîner "Cherche N". Et si Proc2 termine "Chercher N-1" avant que proc1 n'ait terminé "Enregistre N", il va devoir attendre que Proc1 ait fini !
Dans cette version, tu vas diviser le temps de traitement global par le nombre de processeurs, mais il faut ajouter les temps d'attente dûs aux synchronisations.
Dans la version linéaire 1, tu n'as pas ces temps de synchronisation alors que tu divises également le temps de traitement global par le nombre de CPU du fait que tu traites une transaction par CPU.

Mais dans la pratique, du fait des blocages, linéaire 1 et parallèle 2 seront identiques, car tu découpes ton traitement en tâches à exécuter, et l'OS va attribuer le CPU en fonction des tâches activables. Dès que le traitement d'une étape va bloquer sur une E/S, le CPU sera ré-attribué à une autre tâche, ce qui donnera parallèle 2 en pratique.

Pour en revenir a la question première :
Cela fait des années que je milite pour le calcul parallèle au sein des entreprises, mais je constate que l'idée actuellement la plus répandue est que ça ne sert a rien, il suffit de 2 choses :
  • multi-threader et laisser faire l'OS
  • acheter une machine plus puissante

Pourtant comme tu l'as dit toi-même, multi-threader c'est déjà du calcul parallèle.
Et oui, il vaut mieux faire confiance à l'OS pour attribuer le CPU aux threads activables plutôt que d'essayer de faire le travail à sa place.

Je reprends ton exemple de Parallèle 2. Si tu affectes les tâches aux CPU sans qu'un CPU ne puisse servir à un autre traitement, tu vas rapidement rencontrer des problèmes de synchronisation : Les 4 opérations ne mettant pas exactement le même temps pour s'exécuter, le CPU qui exécute la tâche la plus longue sera rapidement saturé, tandis que les autres seront en famine...
Si tu laisses faire l'OS, il fera en sorte que les CPU soient chargés au maximum de ce qui est exécutable.

Citation Envoyé par gangsoleil
Mode gros jeu : la, incontestablement, le parallélisme explicite (c'est-à-dire que le jeu est développe pour utiliser plusieurs processeurs) devient intéressant : on calcule plusieurs choses en même temps sur les différents coeurs, et aussi sur le GPU de la carte graphique, qui se charge de l'affichage.
Dans ce cas, l'OS ne doit pas avoir en charge la répartition des différents calculs sur les processeurs ni sur les coeurs.

Le jeu est un bon exemple où le parallélisme est intéressant en effet. Mais pas en attribuant explicitement les tâches aux CPU.
C'est même un bon exemple d'inefficacité : le GPU ne peut exécuter que des calculs graphiques. Donc si les CPU sont saturés par exemple pour calculer l'IA, tu ne peux pas utiliser la puissance du GPU pour décharger le CPU.
C'est un peu moins vrai dans l'autre sens, mais même dans ce cas, on ne fait pas un équilibrage dynamique de la charge entre "calcule par le GPU" ou calcul par le CPU.
Donc on se retrouve avec une puissance de calcul d'un côté qui n'est pas utilisée, et une autre de l'autre qui est saturée !

Bon dans ce cas, on ne peut pas vraiment faire autrement.
Mais le principe reste le même si tu réserves manuellement les CPU pour des tâches données.

Ca a un sens si tu fais du temps réel et que tu veux être sûr d'avoir un CPU disponible pour réagir à un événement donné critique, mais si tu cherches une utilisation optimale de ta puissance de calcul, il ne faut jamais qu'un CPU se tourne les pouces (ou alors il qu'a ce moment il n'y ait rien à faire).
Et le meilleur moyen d'y parvenir, c'est de laisser l'OS attribuer le CPU aux tâches activables.

Citation Envoyé par sparthane777
Sinon pour en revenir au multicores, les cartes mères permettent de les activer ou pas, donc effectivement ça ne change rien au développement en parallèle et linéaire, sur un Core, après quand on active tout les coeurs, faudrait surtout se mettre à la page, et développer des méthodes permettant d'optimiser le parallèle en fonction des coeurs présents dans le pross ... enfin, moi je me la sens tester sur du multicores un script par exemple permettant d'effectuer du parallèle.

Et bien si, si tu programmes en linéaire, tu ne multi-thread pas ton appli. Donc tu ne tireras profis des différents coeurs que si tu as d'autres applications à exécuter en même temps, ou que c'est un serveur qui exécute plusieurs transactions en même temps (mais dans ce cas, c'est le serveur qui est multi-threadé). Pour une appli cliente pure, ce n'est pas très intéressant. Tu as acheté de la puissance de calcul que tu n'utilises pas.
Pour faire de la programmation parallèle dans ton appli, il faut la multi-threadée, mettre en place les synchros indispensables.
Et ça ne servira probablement à rien dans l'hypothèse d'un serveur.
Avatar de gangsoleil gangsoleil - Modérateur https://www.developpez.com
le 07/05/2010 à 14:18
Bonjour,

Dans mon post, j'ai confondu deux cas. Merci de m'avoir corrigé.

Concernant le calcul sur GPU, cela fait l'objet actuellement de tres nombreuses recherches, afin de pouvoir calculer dessus et aussi de pouvoir recuperer le resultat (ce qui est evident avec un CPU et qui ne l'est plus sur un GPU). Mais il s'agit la d'un autre debat.

Concernant le fait de laisser un OS organiser les processus sur les differents coeurs disponibles, je ne suis pas d'accord avec toi pour dire que c'est la meilleure chose a faire. Ou tout du moins pas tant que les algorithmes des OS seront ceux qui sont actuellement implementes.
Prenons un programme mono-threade, qui prend 100% d'un coeur. Faisons-le tourner sur une machine à 4 coeurs, avec un OS actuel, et regardons ce qui se passe :
Le système te dit que le CPU global est utilisé à 25%, ce qui est vrai
Si tu regardes la charge réelle par CPU, tu t'aperçois que ton processus se ballade un quantum sur un coeur, deux sur un autre, etc etc etc ... Ceci est également vrai sur des machines multi-processeurs.
Dans ce cas précis, tu as 3 CPU qui ne font rien, et un qui tourne à bloc. Et plutôt que de dédier un CPU à cette tache, ce qui implique de ne pas avoir a recharger tous les registres et les mémoires caches, le système le ballade de partout, perdant un temps fou.
D'ailleurs, si tu as l'occasion de faire le test en dediant un processeur du système à ta tache, tu verras le gain de performance (enfin la encore, ce n'est pas vrai, car ça va dépendre de la tache, et principalement de ses accès mémoires).

Je pense que le problème du parallélisme est bien montré ici : il est nécessaire de l'adapter en fonction d'un très grand nombre de paramètres, et il est difficile de trouver des règles géneriques.

On peut aussi évoquer le parallélisme utilisé par les physiciens, qui programment en Fortran. Pourquoi ce langage ?? L'une des raisons est qu'il existe des compilateurs qui sont capables de générer des codes parallèles à partir de code linéaire. Alors certes, on n'a pas le même gain que si le programme était écrit de manière parallèle, mais cela ne mobilise pas un informaticien en plus du physicien lors de la phase de developpement. Et le gain par rapport à un programme linéaire est tout même important d'après ce que j'ai compris.
Avatar de OWickerman OWickerman - Membre averti https://www.developpez.com
le 07/05/2010 à 16:03
Et moi qui croyais que le seul instrument fiable de traitement parallèle de l'information était le Yi-King...
Avatar de Franck SORIANO Franck SORIANO - Membre expert https://www.developpez.com
le 07/05/2010 à 19:06
Citation Envoyé par gangsoleil  Voir le message
Concernant le fait de laisser un OS organiser les processus sur les différents coeurs disponibles, je ne suis pas d'accord avec toi pour dire que c'est la meilleure chose à faire. Ou tout du moins pas tant que les algorithmes des OS seront ceux qui sont actuellement implémentes.
Prenons un programme mono-thread, qui prend 100% d'un coeur. Faisons-le tourner sur une machine à 4 coeurs, avec un OS actuel, et regardons ce qui se passe :
Le système te dit que le CPU global est utilisé à 25%, ce qui est vrai
Si tu regardes la charge réelle par CPU, tu t'aperçois que ton processus se ballade un quantum sur un coeur, deux sur un autre, etc etc etc ... Ceci est également vrai sur des machines multi-processeurs.
Dans ce cas précis, tu as 3 CPU qui ne font rien, et un qui tourne à bloc. Et plutôt que de dédier un CPU à cette tache, ce qui implique de ne pas avoir à recharger tous les registres et les mémoires caches, le système le ballade de partout, perdant un temps fou.
D'ailleurs, si tu as l'occasion de faire le test en dédiant un processeur du système à ta tache, tu verras le gain de performance (enfin la encore, ce n'est pas vrai, car ça va dépendre de la tache, et principalement de ses accès mémoires).

La situation que tu décris n'est un problème que dans le cas où :
1. La tâche dure suffisamment longtemps sans réaliser la moindre I/O ni synchronisation pour se faire préempter.
2. Le traitement qui est aussi long est capable de travailler en ayant toutes les données dans le cache, sans jamais aller chercher de données en mémoire centrale.

C'est quand même un cas assez rare. D'autre part, tu ne peux changer de coeur qu'à l'issue de la fenêtre de préemption (ou d'une synchronisation), et même à ce moment-là, il n'est pas dit que l'OS te réaffecte sur un autre.

Mais la plupart du temps, tu n'utilises pas le CPU pendant plus de 15 minutes sans réaliser une E/S (ou alors il faut revoir ton algorithme...). Donc ta tâche va être suspendue en attente d'une E/S.
Et au moment où elle pourra repartir, tu as tout intérêt à ce qu'elle reparte sur le premier CPU disponible, plutôt que de devoir attendre que celui sur lequel tu l'as affecté soit libre !
Avatar de kimz kimz - Membre habitué https://www.developpez.com
le 09/05/2010 à 11:25
J'ai l'impression que dans le débat de la performance est concentré puissance des processeurs vs. puissance des machines, en faisant presque abstraction du rôle de la RAM, Hdd (heureusement que les E/S sont quand même discutées).

Loi de moore, avenir du parallélisme dans les futures architectures, je veux bien, mais aujourd'hui le développement de la RAM, pour ne prendre qu'un exemple, marche-t-il "en parallèle" avec la puissance des µProc ?
Avatar de gangsoleil gangsoleil - Modérateur https://www.developpez.com
le 10/05/2010 à 9:48
Bonjour,

La loi de Moore porte uniquement sur le nombre de transistors dans un processeur, en indiquant que celui-ci double tous les 18 à 24 mois.

Cependant, les autres composants sont également touchés par cette loi, et suivent également des croissances du même type. C'est notamment le cas de la capacité mémoire.
Avatar de kimz kimz - Membre habitué https://www.developpez.com
le 16/05/2010 à 13:36
Bonjour,
Citation Envoyé par kimz  Voir le message
J'ai l'impression que [del]dans[/del] le débat de la performance est concentré puissance des processeurs vs. puissance des machines

Je me suis peut être mal fait comprendre (y a un *dans* de trop sur le début de ma phrase), je ne parle pas de la loi de moore en elle-même, son énoncé est clair, je parle de la tendance des gens à penser que la performance d'un PC ou d'un serveur est uniquement relative à la puissance du ou des microprocesseurs qu'il intègre
Avatar de gangsoleil gangsoleil - Modérateur https://www.developpez.com
le 17/05/2010 à 9:29
Bonjour,

Tu as parfaitement raison : on se concentre trop sur le processeur, et pas assez sur le reste.
Aujourd'hui, trouver une machine équilibrée à un prix raisonnable (c'est-à-dire pas un PC de gamer) chez un constructeur est quasiment impossible : il y a toujours au moins un composant trop faible par rapport aux autres, qui déséquilibre la machine. Et ce composant n'est jamais le processeur.

Par contre, sur les serveurs, ce n'est pas vrai : ils sont globalement équilibrés, entre autre parce qu'ils intègrent moins de composants (pas de carte graphique 3D par exemple).
Avatar de davrous davrous - Membre actif https://www.developpez.com
le 17/05/2010 à 19:35
Citation Envoyé par Bourgui  Voir le message
Etant donné que l'on va vers des archi type cloud (on va dire que le gros du travail est fait sur les serveurs, type web), le multi threading n'est pas obsolète ? Étant donné qu'on va être dans un cas ou des serveurs lancent en même en parallèle des applications linéaires, du coup au niveau performance ça revient au même.

Je m'étais renseigné pour savoir si sur une appli asp.net il était utile de faire du multithreading mais au final les réponses étaient plutôt négatives : le serveur s'en charge.

Après j'ai peut-être loupé quelques choses.

Hello,

C'est une remarque que j'entends souvent étant en charge de la relation technique avec les développeurs chez Microsoft sur les technologies Web & Cloud. Pourtant, même un développeur Web a intérêt à s'intéresser au développement parallèle pour toutes les bonnes raisons déjà citées dans ce thread. En effet, un développeur Web aura 2 choix dans une architecture Cloud pour gérer des pics de charge/améliorer les performances de son appli :

1 - augmenter le nombre de serveurs dédiés à son application en laissant la plateforme (ex: Windows Azure) lui attribuer davantage de ressources
2 - revoir son code et voir comment mieux tirer parti du hardware en analysant les sections parallélisables

L'avantage du point 2 est qu'il devrait lui couter moins cher en consommation/hosting s'il se débrouille bien. Ensuite, plus tard, une fois l'ensemble optimisé, il pourra envisager l'option 1 pour laquelle le cloud a été conçu. Sinon, il peut toujours opter pour la solution de facilité, mais elle va lui couter plus cher et son employeur ne va peut-être pas apprécier.

Les développeurs Web pensent souvent que le // n'est pas fait pour eux car ils assistent à des démos de calculs de Raytracing ou autres calculs complexes qui ont l'avantage d'être facilement parallélisable et très visuels pour faire comprendre aux gens l'avantage de ce mode de programmation. Effet pervers: on se sent moins concerné. Alors que l'on pourrait imaginer paralléliser des traitements sur la couche d'accès aux données, du traitement d'image côté serveur, des recherches en mémoire/base, etc. Mais bon, c'est sûr que ça en jette moins qu'un lancer de rayon avec des réflexions dans tous les sens! ;-)

Pour revenir sur l'ensemble du thread, je suis d'accord sur le fait que cela fait longtemps que les concepts // existent. Mais jusqu'à présent, ils étaient confinés à des usages et une population très réduite et spécifique. Le défi est de rendre accessibles ces concepts à la masse. Il aura donc un gros boulot d'éducation/formation mais également le besoin d'outillage et de nouveaux frameworks. Par exemple, chez nous, .NET 4.0/VS 2010 a eu un gros focus sur la simplification du développement //. Bien sûr, comme vous l'avais dit, il ne suffira pas de mettre ".EnableParallel = true;" pour bénéficier magiquement de tous les coeurs. Mais sur certaines parties, comme LINQ et son pendant P/LINQ, rendre // un parcours de fichier XML ou une collection en mémoire devient super simple. Il y a donc certainement une partie de la réponse du côté des frameworks. Il me semble d'ailleurs qu'il y a quelque chose dans le pipe pour la prochaine version de Java aussi. Nous avons également constaté (d'expérience!) que le debbuging d'applications fortement multi-threadées ou multi-tâches était un vrai cauchemar. Le simple fait de s'attacher à l'application changeant son état et empêchant de reproduire le bug pour le corriger... De ce côté-là, VS 2010 a également revu le debugger et il y a des projets de recherches innovant chez nous. Il s'appelle Chess : http://research.microsoft.com/en-us/projects/chess/ et vous pouvez trouver un bout d'explications en FR ici : http://blogs.msdn.com/ericmitt/archi...-et-chess.aspx

Pour terminer, vous avez oublié d'évoquer il me semble que la programmation parallèle va plus loin que la meilleure utilisation des CPUs multi-coeurs x86. Il va falloir également mieux utiliser en // les énormes capacités de traitement que nous offrent les GPUs et autres puces spécialisées. DirectX 11 apporte une première réponse de ce côté-là. Mais on pourrait imaginer un framework de haut niveau capable de distribuer les tâches sur les différentes puces en fonction de leur spécialisation.

Donc la loi de Moore est bien morte, mais on savait depuis longtemps que cela arriverait.

Bref, la programmation parallèle s'avère particulièrement passionnante et va tous nous faire bosser dans les années qui viennent avec le Cloud computing également. Profitez de votre prise de conscience avant-gardiste. Cette compétence va vite devenir critique sur le marché !

Bye,

David
PS : un membre de mon équipe anime un blog sur ce sujet : http://blogs.msdn.com/devpara/
Avatar de kimz kimz - Membre habitué https://www.developpez.com
le 18/05/2010 à 12:35
Citation Envoyé par gangsoleil  Voir le message
(...)
Par contre, sur les serveurs, ce n'est pas vrai : ils sont globalement équilibrés, entre autre parce qu'ils intègrent moins de composants (pas de carte graphique 3D par exemple).

Je suis d'accord, de toute façon dans la majeure partie du temps les constructeurs offrent des serveurs entry sans composants spécifiques à l'intérieur, à charge du client de dimensionner selon ses besoins les RAM, RAID, HDD ...
Reste que pour le grand public, il faudrait plus de vulgarisation en rapport avec le calibrage, un système est un tout, par définition
Offres d'emploi IT
Développeur java H/F
Capgemini - Pays de la Loire - Nantes (44000)
Spécialiste systèmes informatiques qualité et référent procédure H/F
Safran - Ile de France - Colombes (92700)
Responsable technique java/jee H/F
Capgemini - Midi Pyrénées - Toulouse (31000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil