Des traces de Xeon de classe serveur pour l’iMac Pro
C’est entendu, l’iMac Pro sera un monstre de puissance, une assertion qu’il faudra bien sûr valider en fin d’année quand le tout-en-un sera disponible. Apple n’a pas été avare de détails sur cette nouvelle machine, au-delà de sa couleur inédite et « badass » en gris sidéral. On sait par exemple qu’il fonctionnera avec des processeurs Xeon de 8, 10 ou 18 cœurs. Reste à savoir de quelle génération.
Le bloggueur Pikeralpha, qui a déjà repéré la présence d’une enclave sécurisée qui pourrait servir à Touch ID, en a rajouté une couche en évoquant des processeurs Xeon “Purley”. Cette référence apparait dans le code de la bêta de macOS High Sierra, qui indique que l’iMac Pro utiliserait un socket LGA3647 en lieu et place du socket LGA2066. Le premier est de niveau “serveur”, le second de niveau “ordinateur de bureau”.
De fait, Apple pourrait utiliser des Xeon Skylake-EX et Skylake-EP, qui s’appuient sur la plateforme “Purley”. Ils servent habituellement à propulser des serveurs. Apple se passerait donc des nouvelles puces Core X dévoilées il y a quelques temps par Intel, et qui fonctionnent avec un socket LGA2066. Rappelons aussi que l’iMac Pro s’offrira un GPU Vega (lire : iMac Pro : des cartes AMD Radeon Vega surpuissantes à mémoire HBM2 ultrarapide).
Quel intérêt de mettre des puces serveurs ? Je vois des proc non serveurs tenir une charge forte et longtemps dans les tournois de jeux sans que ça pose problème. La RAM spéciale ? Elle est vraiment si pourrie la ram non serveur ?
@rolmeyer
L'iMac Pro n'est pas une machine de gamer.
@LeGrosJeanLou
Le rapport avec la question ?
@NestorK
Le rapport c'est qu'il compare une utilisation de gamer à une utilisation de professionnel du calcul alors que clairement on en a absolument rien à foutre d'avoir du Xeon pour jouer.
@rolmeyer
C'est 80% de marketing, 20% de vraies raisons techniques.
Mais Skylake-X (oublions Kaby Lake-X, c'est... particulier) ou Threadripper auraient été des candidats on ne peut plus valables à des tarifs nettement plus mesurés. Meilleurs selon moi. Mais c'est moi, sans le 80% de marketing.
@fte
Pourrait-on envisager que, comme dans le cas de la recherche spatiale, Apple ait commencé à développer cette machine à un moment où ni l'architecture Ryzen, ni les Core i9 n'existaient et qu'elle ait préféré se baser sur une architecture qu'elle connaît depuis longtemps ? Qui peut savoir comment ces architectures vont se comporter sur le long terme ?
Après je veux bien admettre que l'intérêt du Xeon s'efface aujourd'hui face aux Core iX et que tu sois vraiment super calé dans le domaine. Je veux bien admettre aussi que les Apple, Dell HP et consorts vendent de la machine professionnelle Xeon parce que le marketing a fait son travail et qu'aujourd'hui ça rassure le manant d'avoir du Xeon plutôt que du Core iX mais j'aimerais quand même bien savoir aussi pourquoi des tripotées d'ingénieurs et de chercheurs compétents continuent malgré tout d'acheter ces procos aussi chers qu'inutiles.
NB : Je pense qu'une des raisons pour lesquelles on trouve du Xeon Server dans cet iMac réside sans doute dans le fait qu'Apple utilisera les mêmes procos dans son futur Mac Pro et que d'une part ça aura très certainement un intérêt pour cette machine (qui se montent bien en rack) d'autre part ça a du permettre à Apple de lancer tout de suite une grosse commande et donc négocier les prix. Et puis tiens, si Apple resussitait le XServe ?
«Pourrait-on envisager que, comme dans le cas de la recherche spatiale, Apple ait commencé à développer cette machine à un moment où ni l'architecture Ryzen, ni les Core i9 n'existaient et qu'elle ait préféré se baser sur une architecture qu'elle connaît depuis longtemps ?»
Non.
- L'iMac Pro est une reponse dans l'urgence a la gabegie du MacPro et a l'exode de pro vers Linux et Windows, sa conception a un mieux debuté il y a 2 ans, voir avant l'exercice de contrition d'Apple.
- Apple a des relations privilegiées avec AMD et ne pouvait pas ignorer les Ryzen
- Apple a des relations privilegiées avec Intel et ne pouvait pas ignorer les Core iX
«e pense qu'une des raisons pour lesquelles on trouve du Xeon Server dans cet iMac réside sans doute dans le fait qu'Apple utilisera les mêmes procos dans son futur Mac Pro»
Houla, faut se calmer la, y a les rumeurs, dont une, pas des plus fiables, sur laquelle porte cette news et il y a les informations fournies par Apple.
=> Apple a dit qu'il y aurait des Xeon, mais pas lesquels.
=> La rumeur suppose qu'il s'agit de versions de la classe serveur.
Que ce soit l'iMac Pro ou le futur hypothetique Mac Pro 2019, il n'y a rien de rationnel a y mettre des Xeon serveur dedans.
Les (i)Mac Pro sont au mieux de la classe des stations de travail et Intel a assez de processeurs dedies a cette classe entre les core i7 7700k, les Core iX, et surtout les Xeon E3.
Le meilleur candidat pour cette machine serait le Core i7 7700k 4Core 4.20Ghz et le i7-7820X 8 Core 3.60Ghz et le Xeon E3-1275V6 4 Core -3.80Ghz.
Apple parle aussi d'un 18 Core, et dans les 18Core, y a pas beaucoup de candidats:
- E5-4667
- E5-2697
- E5-2695
Dont aucun n'est destiné a autre chose que du serveur et tous sont sortis en 2016.
Ensuite, la machine ne sortira que dans 6 mois... Pourquoi si tard? Peut etre parce que la conception de la machine a debuté que trop recemment et que les processeurs que veut utiliser Apple ne sont pas encore annoncés par Intel...
Au final il faut se poser une question: qui va acheter cette machine:
- les developpeurs Apple
- des particuliers fortunés
- ceux qui se satisfont d'un Mac Pro poubelle
Donc tres peu de monde et des gens qui n'ont pas des besoins pour l'ecrasante majorité de memoire ECC et autres raffinements qu'on trouve sur les stations de travail et serveurs.
Au final, l'iMac Pro c'est quoi? C'est un Mac Pro poubelle, encore plus fermé, encore plus sensible a la monté en temperature, encore moins adapté au marché des stations de travail.
@C1rc3@0rc
Je partage le point de vue selon lequel cet iMac Pro est la suite logique du Mac Pro poubelle. Il n'est évolutif en interne que sur la Ram. Le stockage et maintenant la puissance graphique peuvent être étendus à l'extérieur (eGPU) et en ce sens cette machine est presque plus évolutive que son grand frère.
Le reste de votre analyse me paraît surtout l'expression sans filtre de votre exaspération. Et comme toujours ça nuit grandement au plaisir de vous lire. Essayez vous donc à la nuance, vos mots n'auront que plus de portée.
@rolmeyer
«Quel intérêt de mettre des puces serveurs ?»
Dans une station de travail ou un PC, strictement aucun, c'est totalement absurde.
D'ailleurs Intel a plusieurs classes de Xeon, certains pour les stations de travail et les autres pour les serveurs.
Faut imaginer le travail d'un serveur: typiquement il fait tourner une seule application qui gere un nombre considerable de processus et d'entress/sortie. Ça c'est la plupart des cas. Apres y a les serveurs de calcul, qui vont effectuer des long calcul sur plusieurs core et/ou processeur, voire qui dispatchent les calculs sur les GPU (serveur GPGPU => sciences, ingenierie, math,...)
Et finalement il y a les serveurs de "rendu d'image", ceux utilisé pour les films par exemple, ou on a un processeur qui fait tourner plusieurs GPU ultra puissant, et ou generalement on a des grappes de serveur dans un reseau rapide...
La conception d'un processeur pour serveur est donc faite pour supporter des processus qui s'executent en parallele sur de tres longues periodes (24/24), souvent avec de gros flux de données. Les contraintes sont donc l'inverse de celles des PC de bureau et a fortiori de portable.
Donc il doit etre stable, avoir une vitesse de croisiere qui peut etre tenu longtemp (donc surtout pas de guignolerie comme le turbo), une fiabilité plus importante que la vitesse (la frequence est plus basse que les processeurs de bureau), la consommation et le dégagement thermique sont secondaires.
En contre partie la machine doit disposer d'un alimentation ultra-fiable (redondante), puissante et d'un systeme de refroidissement puissant.
La question de la RAM ECC est aussi primordiale.
Lorsqu'on va copier un fichier ou appliquer un filtre sur une image, il peut y avoir une corruption de données dans la RAM. Si quelques octet sont corrompus, pour une image ça va faire quelques pixels de la mauvaise couleurs, pas tres grave dans un film, une affiche, une page WEB, un jeux,... et pour un fichier, soit l'algoritme de correction s'y applique, ou alors il est copier une seconde fois (et generalement il s'agit de copier un bloc et pas le fichier entier).
Quand on parle de serveurs, il y a des milliers d'echanges de données par secondes, une corruption en RAM ralentie ce traitement d'autant. C'est pire encore pour les calcul, ou certains peuvent prendre des jours, voire des semaines entieres... Quand on sequence de l'ADN, qu'on calcul un modele meteorologique, qu'on fait des calculs de charge et de résistance sur des infrastructure de plusieurs milliers de tonnes,... le processeur doit etre fiable, la memoire doit etre fiable, les interconnexions doivent etre fiables... On peut accepter de perdre un peu de vitesse, si on gagne en fiabilité.
Bref, mettre un Xeon de classe serveur dans un iMac est une absurdité totale. Je pense pas que les inge d'Apple soient idiots, et la seule explication c'est que le gars raconte n'importe quoi.
Un processeur taillé pour un serveur n'est pas forcément un signe de puissance plus importante.
Cela peut aussi vouloir dire qu'il ne dispose pas de certaines instructions qui ne sont utiles que pour le grand public, auquel cas c'est plutôt un désavantage.
Un Xeon n'est pas fait pour un usage grand public, ça rentre dans une station de travail ou dans un serveur.
La notion de puissance n'est pas la meme. On pourrait comparer un Xeon a un diesel de paquebot et un Core i7 xxxxk a une F1.
Mais pour illustrer la difference d'architecture je vais prendre 2 extremes dans la gamme Intel:
- le Core-M qui equipe le Macbook retina, 2 core, 1.10Ghz, Turbo 3Ghz, TDP 3.75 watt a 7 watt, 16Go RAM
- le Xeon E7-8894 v4, 24 core, 2.40Ghz, turbo 3.40Ghz, TDP 165watt, 3.07To de RAM
Deja a lire les specifications d'Intel on remarque le TDP qui est tres differents. Le TDP c'est pour simplifier, la puissance, en watt, necessaire de refroidissement pour que le processeur tourne normalement. Si le refroidissement n'est pas suffisant, le processeur ralenti puis s'arrete.
Petite astuce d'Intel, le TDP ne prend pas en compte le mode turbo.
Le TDP du Xeon c'est simple, pour qu'il tourne a 2.40Ghz, il faut evacuer 165watt.
Le Core-M, c'est a geometrie variable, y en a 3 TDP:
- 3.75 watt, le processur tourne alors a 600Mhz (0.6Ghz)
- 4.5 watt, le processeur tourne alors 1.10ghz
- 7 watt, le processeur tourne alors a 1.6 Ghz
C'est bizare, non?
En fait Intel a integre un mecanisme, dynamique (programmable), qui permet au Core-M de tourner, au choix pour le constructeur, selon 3 frequences. Le constructeur va donc choisir un mode selon la capacité de refroidissement de la machine. Ce mode defini la frequence normale de fonctionnement.
Donc dans une machine avec un bon ventilateur on peut esperer une frequence de 1.10 voir 1.60Ghz. Dans une machine sans ventil on aura plutot 600Mhz.
Apres y a le turbo. Le turbo, c'est la frequence maximale a laquelle peut tourner un seul core (les autres etant alors eteint).
- Xeon 3.40Ghz pour une frequence normale de 2.40Ghz
- Core -M 3.0Ghz pour une frequence normale de, oui y a un piege ici, entre 600Mhz et 1.60Ghz
Donc le turbo peut etre au maximum de 44% pour le Xeon et de 400% pour le Core-M!
Etonnant, n'est ce pas.
Faut se rappeler que le Xeon a 24 core et que le turbo ne vaut que pour un seul core. Si on est un peu rationnel, on va pas installer un processeur qui vaut pres de 9000$ et dispose de 24 Core, pour faire tourner une application mono-tache qui ne fera tourner qu'un seul core 44% plus vite...
En pratique, les situations ou le Xeon tournera en mode turbo sont tres rares.
Tout cela demontre quoi:
- un Xeon c'est un processeur multicore, fait pour tourner non stop en exploitant le maximum de core possible. Il est fait pour vraiment travailler.
- un Core-M c'est un processeur bi-core, fait pour fonctionner le moins possible afin de consommer le moins possible et chauffer le moins possible. En pratique c'est plus un mono-core d'ailleurs, le turbo etant sur-exploité.
Apres, il y a bien sur des instructions specifiques pour chacun, deja le circuit graphique du Core-M qui n'existe pas dans le Xeon, et les techno de securité du Xeon absente du Core-M. Mais il y surtout a une différence considérable de conception.
Peut on m'expliquer l'intérêt des Xeons ?
Il me semble avoir lu que les logiciels ne savaient pas exploiter cette puissance multicores et qu'au final un i7 (i9?) ferait mieux le job sur des tâches lourdes. Vidéos ou graphiques par exemple.
@ideclik
Les logiciels à utiliser avec cet iMac en sont capables... c'est pas pour Facebook Et eMail ce dark iMac.
@xDave
Peux tu me lister des logiciels qui exploitent mieux un Xeon qu'un i7 / i9 ?
@ideclik :
Ce n'est pas la question.
Les logiciels exploitent tous les cœurs ou non. Et ne pas le faire alors qu'Apple à sorti Grand Central Dispatch (libdispatch) depuis macOS 10.8 (7?), ça fait vraiment un bail, techno qui permanent de gérer les "threads" (ou plutôt tâches en parallèle ou en série, synchrones ou asynchrones), presque
les doigts dans le nez, c'est lamentable de la part du développeur.
@marc_os
GCD est arrivé avec 10.6 ;)
@marc_os
Ah ah ah les doigts dans le nez.
Bien sûr.
😂
@marc_os
Deja tu ne repond pas a la question de @ideclik.
Ensuite, nsulter les developpeur denote d'une meconnaissance du domaine et d'un dogmatisme magistral: la programmation parallèle est monstrueusement complexe et ne peut pas reposer sur une API, c'est avant tout une question de conception et de modelisation.
Et puis, mais la faut s'y connaitre un peu en informatique et en mathematique, il y a des problemes qu'on peut resoudre avec une approche parallele et d'autres qui sont purement sequentiels.
Et meme, il y a plusieurs approche du parallelisme, en fonction des domaine. Il y a meme des architecture d'ordinateur dediées au traitement parallèle, ce que ne sont pas les PC actuels.
Et il y a aussi des langages de programmation plus adaptés que d'autres a la programmation parallèle. Typiquement, les derivés du C ne sont pas adapté, et Swift non plus.
Tu parles de Grand Central Dispatch(2009), mais Apple avait aussi sorti OpenCL (2009) qui est depuis 2010 un standard du Khronos Group. Et ce ne sont pas les premieres tentatives de deplacer la complexite de la programmation parallele vers l'architecture ou l'OS.
Aujourd'hui l'API la plus utilisé c'est CUDA de Nvidia. Parce qu'elle permet de piloter finement et precisement le modele GPGPU, soit du calcul vectoriel.
Intel avait aussi tenté de faire aussi un hybride (SIMD) avec la farce qu'est devenu le Xeon Phi, derivé du naufrage qu'a ete Larabee.
Dans les faits GCD fonctionne bien pour attribuer des taches aux core des processeurs, du moment que ces taches sont bien definies. C'est efficace dans le cadre de plusieurs applications lancées en meme temps. En fait ça permet a l'OS d'eclater les applications en sous processus, et l'OS peut ordonnancer tout ce petit monde au mieux... mais ça s'arrete la.
Apres, on retombe sur les problemes de conception et de modelisation et la difficulté mathematique a paralleliser des problemes.
Au niveau des serveurs, la situation est assez differente puisque la nature des taches est tres souvent parallèle (faut servir plusieurs clients qui demandent la meme chose). Donc il est assez evident de pouvoir attribuer les taches au core, ou aux threads.
C1rc3@0rc
1. « les developpeur denote » c'est qui ça ? Je les insulterais alors que je ne sais même pas de qui tu parles ?
2. Tu as déjà essayé de synchroniser des threads à la main ? Et bien je suis désormais hyper heureux de pouvoir disposer de libdispatch et de pouvoir me concentrer sur l'essentiel.
Et quand tu dis: « C'est efficace dans le cadre de plusieurs applications lancées en meme temps » au sujet de libdispatch, on voit tout de suite que tu ne l'as jamais utilisé et que tu ne sais pas de quoi tu parles.
@marc_os
Tu as des problemes de memoire a court terme?
«Apple à sorti Grand Central Dispatch (libdispatch) depuis macOS 10.8 (7?), ça fait vraiment un bail, techno qui permanent de gérer les "threads" (ou plutôt tâches en parallèle ou en série, synchrones ou asynchrones), presque
les doigts dans le nez, c'est lamentable de la part du développeur.»
tu insultes clairement les developpeurs et met en avant leur supposée responsabilité dans la non exploitation du multicore
«Tu as déjà essayé de synchroniser des threads à la main»
en disant cela tu demontre que tu ne sais pas du tout de quoi tu parles. Cette phrase n'a aucun sens.
« Et bien je suis désormais hyper heureux de pouvoir disposer de libdispatch et de pouvoir me concentrer sur l'essentiel.»
Et l'essentiel c'est?
Construire un logiciel ça peut etre plusieurs chose:
- realiser une interface graphique qui permet d'interagir avec des appels a des API, ce que sont en gros 90% des app pour smartphone. La GCD est une API de plus.
- concevoir des applications realisant un traitement specifique et la faut deja comprendre la notion d’algorithme et de processus. GCD peut permettre de simplifier la realistation, une fois qu'on a modelisé les processus et determiné lesquels sont sequentiels, lesquels sont cooperant, lesquels sont concurrents.
- convevoir des librairies, et la faut en plus rendre la librairie compatible avec les API d'ordonancement
- concevoir des programmes serveurs ou faut gerer des contraintes qui vont de la fiablité, a l'efficacité en passant par la securité et tout ça dans des environnement clients-serveurs massifs, tournant sur les systemes virtuels... bon j'en parle meme pas.
-concevoir des compilateurs, qui vont devoir gerer les possibilités de traitement paralleles du langage et cela optimisé sur une machine cible...
hormis le premier cas, GCD ne peut pas te permettre de te "concentrer" sur l'essentiel, la modelisation du parallelisme etant une phase accessoire que dans ce 1er cas.
@ C1rc3@0rc
> tu insultes clairement les developpeurs
Non. Je sus développeur.
Mais si un développeur n'utilise pas les technos disponibles adéquates, alors oui il doit assumer son incompétence*.
> «Tu as déjà essayé de synchroniser des threads à la main»
> en disant cela tu demontre que tu ne sais pas du tout de quoi tu parles. Cette phrase n'a aucun sens.
C'est bien ce que je disais. Visiblement tu n'es pas développeur mais ça ne t'empêche pas de donner ton avis.
Excuses-moi si j'ai fait court, les développeurs auront compris, eux.
Donc rien que pour toi : Ce que je veux dire, c'est que si plusieurs tâches paralléles sont lancées qui chacune retourne un résultat, le thread qui devra gérer l'agrégation de tous les résultats devra en quelque sorte synchroniser le basard à la fin. Rien que gérer le passage des données d'un thread à l'autre, tâche qui peut sembler basique, n'était pas simple à implémenter à l'époque de OS X 10.0. Exercice: Tu installes OS X 10.0 et tu développes une application pour télécharger un truc sur le net, et ton interface affiche une barre de progression et un bouton ok à la fin. Ça peut te sembler trivial, mais fais le même exercice avec GCD et tu verras la différence de complexité.
Aujourd'hui, tu définis des dispatch_group, plus besoin de sémaphores pour savoir quand c'est fini, et tu as à disposition les "closures" (et les variables _block) qui te permettent de récupérer les données, "les doigts dans le nez". Et GCD réparti les tâches "concurrentes" automatiquement sur les cœurs virtuels et réels selon le processeur utilisé.
> Et l'essentiel c'est ?
Définir les tâches, s'occuper des algoritmes à implémenter, et ne pas se faire chier avec les boulons en utilisant les bons outils*. C'est aussi simple que ça, pas la peine d'évoquer tous les types de composants logiciels.
(*) Je viens d'un milieu artisant, céramique, bois.
Dans ce milieu, la parole est (ou était) :
On reconnait les bons ouvriers à leurs outils.
Sous-entendu, j'explique rien que pour toi, si tu utilises de mauvais outils, c'est que tu es un mauvais ouvrier.
En d'autres termes, si A => B alors non B => non A
soit : "bon ouvrier" => "bon outil" donc "mauvais outil" => "mauvais ouvrier".
Où l'on voit que les artisans maitrisent la contraposée.
@marc_os
"Non. Je sus développeur."
L'un n'empêche pas l'autre. Si ?
"Mais si un développeur n'utilise pas les technos disponibles adéquates, alors oui il doit assumer son incompétence*."
Ah bin voyons. Depuis quand un développeur a l'entière liberté des outils utilisables ? A part à travailler seul dans son coin, on n'a jamais cette liberté.
Je ne sais pas si c'est insultant. Il m'en faut beaucoup plus pour me sentir insulté. Mais désagréable et condescendant, ça l'est certainement.
Tous les logiciels de montage/traitement audio pro (aussi appelés DAW, pour Digital Audio Workstation, comme Pro Tools, Cubase, Logic, Sequoia, etc) savent tirer partie d'un plus grand nombre de coeurs.
Exemple (sous Pro Tools):
http://dt7v1i9vyp3mf.cloudfront.net/styles/news_large/s3/imagelibrary/P/...
@ideclik
Je pense qu'il ne peut pas.
Je dirais Oracle, dans les connus. Quelques autres obscures applications, comme certains systèmes experts. C'est très réduit.
Je dirais toute application dont le code est optimisé pour réduire le cache miss et qui traite des quantités importantes de données. Là, la différence de taille de cache L3 entre Xeon et i7 / i9 se voit vraiment.
Mais, oui, peu d'application.
Donc.
^_^
Et comme dans ce type de besoin d'optimisation, la tendance c'est de s'appuyer sur du GPGPU plutôt avec des perspectives de gain nettement plus important, in fine, de moins en moins.
Après, y'a l'aspect garantie d'endurance et de durée de vie commercial qui peut compter.
Mais ca ça fait pas de différence pour les applications...
Pages