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/PT11_02.jpg?zo_JCiURWPuEyr07GxE1BpoO8SUgjP6w=&itok=gIkkT6Bn
@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...
@byte_order
Pour qu'une tache soit parallelisable il ne faut pas que sa resolution soit sequentielle. Donc il ne faut pas avoir des choses comme
- calculer A
- calculer B a partir du resultat de A
- calculer C a partir du resultat de B
Faut avoir:
- calculer A
- calculer B a partir du resultat de A
- calculer C a partir du resultat de A
- calculer D a partir du resultat de A
Faut pas avoir non plus de verrouillage de ressource (acces sequentiel):
- lire le fichier A => ecrire dans le fichier B
- lire le fichier A => ecrire dans le fichier C
- lire le fichier A => ecrire dans le fichier D
Sachant que la première tache va se reserver l'acces au fichier A et que pendant cet acces aucun process (ni 2 ni 3) ne peut lire le fichier A.
Et puis dans l'image, y a des chose qui sont parallelisable et d'autres pas:
- appliquer un filtre de flou gaussien sur une image de 2000 x 3000, c'est assez simple, on decoupe l'image en rectangle de meme surface et chaque rectangle devient un processus d'application du filtre, et ça on le repartie sur l'ensemble des core disponible.
- faire un calcul de rendu d'eclairage, en fonction de la methode utilisé c'est plus ou moins parallelisable. Certaines approches utilisent la rediffusion de la lumiere en fonction de la reflectance des objets rencontré, ce qui demande de calculer l'intensité de lumiere reflechie par un objet proche...
C'est a peut pres valable pour tout les cas ou il faut calculer un impact evolutif...
Pareil pour les bases de données, si on a 20 requetes disctinctes on peut les attribuer chacune a un core. Si on a 3 requetes liees ( a -> filtre -> b -> filtre -> c => resultat) c'est séquentiel, impossible a paralléliser.
@ideclik :
C'est marrant ici. D'habitude les gens mettent en question le terme PRO pour certaines machines, et là quand Apple veut mettre des processeurs pour le coup vraiment "pro", les gens mettent la décision en doute et veulent des machins de petits joueurs...
@marc_os
Un proc serveur n'est pas un proc pro. C'est un proc serveur. Les missions d'un proc serveur sont différentes. Une première différence dans l'usage tient au nombre d'utilisateurs / clients. Serveur : plusieurs, voire beaucoup. Pro : un, voire plusieurs stations pour un utilisateur.
@marc_os
"C'est marrant ici. D'habitude les gens mettent en question le terme PRO pour certaines machines, et là quand Apple veut mettre des processeurs pour le coup vraiment "pro", les gens mettent la décision en doute et veulent des machins de petits joueurs..."
Je ne remet rien en doute. Je pose juste la question et vu les réponses assez opposées, je pense que cette question méritait d'être posée.
@ideclik
Un exemple ? Les logiciels de calculs de structures...
Ça bouffe et de la ram, et du CPU...
Et les Xeon ont des instructions supplémentaires que les processeurs grand public n'ont pas. La ram ECC est importante aussi, surtout pour l'exemple donné plus haut...
@Link1993
Quelles instructions supplémentaires utiles ?
En quoi la mémoire ECC est-elle importante ? Que se passe-t-il si elle ne l'est pas ?
OK pour la RAM par contre.
@ideclik
Channels mémoire, mémoire ECC (même si l'intérêt est TRÈS surestimé), caches volumineux, lignes PCIe, cycle de vie socket/chipset différent...
Dans le cadre d'un Mac, quelqu'il soit, ou d'un ordinateur ou station de travail non Critique! (avec un grand C et un point d'exclamation), la plupart du temps sans intérêt.
Quelle surprise ! Les processeurs de serveurs utilisent un socket de serveur et un chipset de serveur ! :-p
Bientôt sur MacG, un article pour expliquer qu'il fait plus chaud en été qu'en hiver. :-D
@papalou
"Bientôt sur MacG, un article pour expliquer qu'il fait plus chaud en été qu'en hiver. :-D"
il fait déja plus chaud au printemps qu'en été ?
La surprise c'est de trouver un cpu serveur (et donc le socket fait pour ça) dans un AIO de bureau, plutôt.
@fte :
Pour faire très simple : quand tu fais des millions et milliards de calculs mathématiques par seconde un tas d'erreurs arrivent dans les Rams. Les Ram ECC ont 2 (je crois) bits de plus par octet qui servent à vérifier que l'information est correcte (un truc du genre, je t'invite à lire sur le sujet sur Wikipedia ce sera plus précis).
Un jeu vidéo s'il fait une erreur vite fait sur un shader pendant une frame, tu vas à peine le voir et surtout Cest jeté à la poubelle de toutes façon.
Un calcul mathématique qui dure 3 jours et plante ou est invalide si un seul caractère n'est pas correct, tout de suite La ram ECC est vitale.
Second truc pour la personne qui demandait en quoi un i7 est moins bien qu'un xeon : notamment tout ce qui est computing (utilisation de la CG pour calculer de la puissance brute) va principalement mieux fonctionner sous un Xeon.
Et enfin le postulat de base : Si La machine va tourner 24/7 et je dis bien 24/7 à puissance Max, un i7 ne va pas tenir plus de quelques mois malgré sa qualité. Un Xeon est fait pour tenir la charge Max en permanence. Ça va réduire sa durée de vie evidemment Mais il est fait spécialement pour ça à la base. Certains logiciels, les rendus de visuels, La recherche, peuvent lancer un calcul pour une semaine et l'ordi est réellement à 100%. Même si l'i7 est bien refroidi, il tourne quand même à 100% et avec le temps ça va finir par le tuer. C'est comme si disons on prenait une voiture de sport de série et qu'on La faisait tourner à 4000 tours par minute. Elle peut le faire Mais sûrement que quelques heures, Alors qu'une voiture préparée pour cela comme une voiture des 24h du mans à peut être un cahier de charge différent. Sa version course GT va peut être donner plus de puissance (i7) Mais sa version 24h du mans est peut être plus fiable à long terme (Xeon)
Si quelqu'un se pose la question de ce que sont ces améliorations ou bien ne fait jamais de calcul gourmand, à priori l'iMac Pro n'est pas pour lui. Moi même j'ai besoin de puissance pour la production audio où pour le coup parfois on va taper dans les 60Go de RAM (instruments virtuels chargés et prêts à jouer en temps réel) et la puissance CPU directement proportionnelle au nombre de plugins utilisé et à la petitesse de la latence, Mais je sais que ce n'est pas 24/7 et l'ECC ne va rien changer pour moi au pire un bit d'audio raté. Du coup l'iMac Pro ne sera pas pour moi Si l'iMac normal propose l'i7 et la même possibilité de ram. Par contre peut être qu'un 8 core et 128Go de Ram et 4To de SSD rapide pourraient faire peser La balance si quand il sort l'iMac ne le propose pas.
Merci pour ce commentaire intéressant, pédagogique et constructif :-)
Super commentaire, très précis, constructif et pédagogique, avec des exemples pertinents :)
Merci! :)
En effet, merci pour ce commentaire ! :)
Très bons exemples surtout pour des noobs en hardware (comme moi ^^)
@LeSedna
"un tas d'erreurs arrivent dans les Rams"
Un tas ? C'est combien un tas ? 57'843'141'285 ?
Sais-tu les causes des erreurs mémoire ?
Indices : très très très faible et rayons cosmiques.
"La ram ECC est vitale."
En réalité, non, elle ne l'est pas. Ou plutôt elle ne l'est plus depuis longtemps, sauf cas exceptionnels. Et lorsqu'elle est utile, vraiment utile, elle n'est absolument pas suffisante pour garantir un taux zéro d'erreurs. Des vérifications logicielles sont indispensables. Et comme ces vérifications logicielles sont en place lorsque nécessaires, la mémoire ECC ne sert en pratique à rien.
"Un Xeon est fait pour tenir la charge Max en permanence."
Non. Enfin, oui, mais la différence n'est pas celle que tu sembles imaginer.
Un Xeon n'est absolument pas plus durable au niveau silicium qu'un i7. Les périphériques sont configurés différemment, les coeurs tournent à fréquence moindre avec une plus grande marge de sécurité, le packaging thermique est plus soigné... tu obtiendras le même résultat en abaissant la fréquence et tension d'un i7 consumer, et en lui collant un gigantesque radiateur très efficace.
La principale différence est qu'un Xeon est configuré pour plus d'IO (et mémoire) et plus de threads, là ou les Core sont configurés pour une puissance crête single thread supérieure.
C'est comme les puces "militaires". Le silicium est identique aux puces "civiles". Le boitier change parfois, et les conditions d'utilisation sont plus serrées. C'est la datasheet qui change le plus.
@ fte
«Et lorsqu'elle est utile, vraiment utile, elle n'est absolument pas suffisante pour garantir un taux zéro d'erreurs. Des vérifications logicielles sont indispensables. Et comme ces vérifications logicielles sont en place lorsque nécessaires, la mémoire ECC ne sert en pratique à rien.»
La verification peut prendre quelque fractions de secondes, le fait de recalculer peut prendre des heures, voire des jours.
Le principe de la RAM ECC, c'est de garantir un risque minimal de corruption de donnees au un niveau du traitement.
Ca veut pas dire que ce risque est nul et que l'on peut se passer de verification, ça veut dire qu'on reduit le risque et que l'on reduit de temps de traiement maximum (en l;occurence le recalcul)
Pour le calcul d'une images qui va apparaitre un 24ieme de seconde et sera effacée apres, qu'il y ait quelques pixels qui ne soient pas de la bonne couleur, c'est pas grave et on va préférer gratter un peu de vitesse plutot que certifier le resultat.
Pour le calcul d'une image astronomique, qui a necessité 250 prises de vue avec le telescope spacial Hubble et demande des jours de calculs, on va certifier l'integrité des données a chaque niveau et reduire les risques de corruption aussi a chaque niveau.
Pareil, pour un serveur de données ou de calcul, chaque requêtes doit être servie le plus vite et le plus fiablement possible, on va donc certifier l'integrité a chaque niveau.
Dire que la memoire ECC va permettre de supprimer la verification des donnees est absurde, comme il est absurde de dire qu'elle va garantir que les donnees sont valides a 100%. Y a des domaines ou on va favoriser le cout et la vitesse par rapport a la securité, et d'autre ou la vitesse depend de la securité: la on utilisera de la memoire ECC et des GPU Tesla, pas des GPU dediés au jeu.
Quand a la certification des Xeon, si leur niveau de certification est plus elevé que celui des Core i. Faut se rendre compte de la difficulté de graver des processeur a des finesses qui approchent la taille des atomes de silicium. Le silicium doit etre d'une qualité toujours meilleure et les causes de problemes se multiplies et Intel a du mal a maitriser la fiabilité de la gravure.
Pour que ce soit rentable, la politique est de categoriser le processeur sur son aptitude a passer des tests. Si on prend les Core i7000, pour la meme fabrication on va obtenir selon la note:
100% => Core i7-7700 k 4.20Ghz
95% => Core i7-7700 3.60Ghz
85% => Core i7-7700T 2.90Ghz
Apres on desactive des core
80% => Core i7-7567U 3.50Ghz
C'est une caricature, mais en pratique c'est le principe, en fonction du taux d'erreurs on baisse la frequence, on desactive des core et on certifie pour un type d'usage specifique. Apple fait de meme avec ses ARM, les meilleurs rentrent dans les iPad et les iPhone haut de gamme, les moins bons vont dans le AppleTV.
Avec les Xeon on a le meme principe.
@C1rc3@0rc
"La verification peut prendre quelque fractions de secondes, le fait de recalculer peut prendre des heures, voire des jours. "
Les deux affirmations sont fausses.
La mémoire ECC ne vérifie pas pendant quelques factions de secondes. Il n'y a pas d'interruption de service, et la détection est immediate lors des accès.
Si recalculer prend des heures ou des jours, la validation logicielle doit être revue sur une plus fine granularité, pour minimiser les reprises. Les devs qui travaillent sur ce genre d'usages ne sont pas des idiots, il n'y a pas de relances de plusieurs jours.
Allez, un lien juste pour le plaisir.
https://blog.codinghorror.com/to-ecc-or-not-to-ecc/
Il existe beaucoup d'études récentes (ces 5 dernières années), en particulier de Google, qui montrent exactement ce que cet article discute. Les erreurs sont essentiellement matérielles, détectées à la mise en service par un test mémoire exhaustif, et par des tests opérationnels réguliers. Les taux d'erreur des mémoires non ECC DDR3 et DDR4 sont 2 magnitudes inférieurs à ce qui était admis comme correct auparavant. Soit au niveau de ce qui était supposé pour les mémoires ECC.
Je n'ai pas retrouvé le lien malheureusement, mais Google a publié une étude en 2015 je pense, très détaillée, menée dans leurs datacenters pendant plusieurs années, qui concluait que les erreurs étaient assez importantes, plus que supposé, mais corrélées et essentiellement matérielles, et les erreurs soft pratiquement inexistantes. L'étude montrait en particulier qu'il vallait mieux abaisser la température de fonctionnement de 10 degrés que de compter sur l'ECC, et qu'il fallait changer les barettes tous les 20 mois après quoi le taux d'erreur grimpait en flèche. Les mémoires ECC vieillissent plus vite.
Google n'utilise pas, pour les serveurs conçus dans ses murs, de mémoires ECC. L'encombrement et la consommation plus importants, les joules dissipées, ne justifient pas l'utilité effective très réduite. Ils en utilisent des millions...
Après si on veut se distinguer de la plèbe hurlante par des matériels auxquels on attribue des propriétés mystiques, OK, cool.
La mémoire ECC est inutile aujourd'hui.
J'y pense... AH AH AH CA VA ETRE FUN DE CHANGER LES BARRETTES ECC MISSION CRITICAL DES IMAC PRO TOUS LES 20 MOIS.
Cette machine a vraiment un design de merde. Elle a de la gueule, mais tout le reste est d'une stupidité ahurissante.
@fte
Y a une trappe pour changer la Ram. Donc c'est quoi le problème ?
Ensuite l'analyse de Google est intéressante mais s'applique t-elle à tous les cas de figure ? Quelles sont les conséquences pour Google d'une erreur de calcul (matérielle ou logicielle) ? Baisser la température de 10° dans l'immensité d'une installation serveur c'est peut-être rentable quand on l'oppose par exemple au taux de remplacement des machines et surtout sur les économies d'énergie en refroidissement mais sur une utilisation de bureau ?
Enfin quel Core iX a 18 Core ? Quel Core iX supporte 128 Go de Ram ? Aucun. Donc il faut un socket adapté sur la carte mère. Donc soit on a 2 conception d'iMac Pro avec un socket XEON serveur ou un socket plus classique. Soit on en a qu'une seule et on choisi la même classe de proco pour toutes les machines.
La gamme aurait été illisible. On est chez Apple, pas chez Dell.
@LeGrosJeanLou
"Y a une trappe pour changer la Ram. Donc c'est quoi le problème ?"
Le problème c'est qu'il n'y a pas de trappe. Tout est collé.
"mais sur une utilisation de bureau ?"
Pas besoin d'ECC, effective ou non, dans ce cas, donc discussion inutile.
"Enfin quel Core iX a 18 Core ?"
i9 7980X
"Quel Core iX supporte 128 Go de Ram ?"
Les i7 78x0X et les i9 79x0X.
"Aucun."
7.
"il faut un socket adapté sur la carte mère"
LGA 2066.
AMD, Threadripper 16 cores 128 GB (256 théoriques). Epyc, de 8 à 32 cores, 256 GB (512 théoriques).
Mais comme je le disais plus haut, lorsque la conception de cette machine a débuté, il n'y avait d'autre choix que les Xeon. Mon seul propos était de dire que l'ECC n'est pas un critère de choix valide pour choisir un Xeon, parce que ça ne sert à rien.
"La gamme aurait été illisible. On est chez Apple"
La gamme est déjà illisible.
@fte
Ce moment où tu réalises que ton propre message est blacklisté. Parce que tu as répondu idiotement à quelqu'un de ta blacklist car la blacklist n'est pas active sur PC.
Gah.
@fte
Mais où t'es allé chercher que la Ram était collée ??? Même sur l'iMac 21 pouces elle est pas collée... Je comprends pas ton intérêt là.
Sinon Ok pour le 7980X dont la disponibilité n'a pas encore été annoncée. Il sera effectivement 18 cores.
Par ailleurs il me semble que les procos AMD ne gèrent pas l'hyperthreading donc pour 32 cores physiques t'as 32 Core logiques et pas 64. Le Xeon en a donc 4 de plus (c'est pas pour jouer à la plus grosse mais puisqu'on parle quantité...)
Moi je dis qu'il serait bon d'attendre les comparatifs une fois les machines sorties avant de s'étriper sur des considérations visiblement très personnelles.
@LeSedna
> Un calcul mathématique qui dure 3 jours et plante ou est invalide si un seul caractère
> n'est pas correct, tout de suite La ram ECC est vitale.
La RAM ECC ne détectera que quelques bits erronées et ne pourra rien faire d'autre que dire "oups, erreur, recommencez", ce que l'essentiel des logiciels va gérer d'une manière simple : ne pas savoir quoi faire et en gros, l'ignorer complètement.
Pour un calcul scientifique très long, où l'occurence non seulement d'un bit flip devient probable mais plusieurs aussi, y'a mieux : soit doubler toutes les écritures en RAM (shadow copy) pour pouvoir vérifier à la relecture (impact +30 à 50% les performances, et +100% en besoin RAM evidement) soit, et c'est souvent une solution finalement moins couteuse, doubler les calculs, en les faisant tourner sur 2 machines différentes et en comparant leurs résultats (partiels si possible et finaux).
> tout ce qui est computing (utilisation de la CG pour calculer de la puissance brute) va
> principalement mieux fonctionner sous un Xeon.
Je vois vraiment pas en quoi l'utilisation d'un GPGPU macherait mieux avec un Xeon qu'avec un iCore 7 desktop. Le nombre de lanes PCI ?
Enfin, l'analogie sur l'endurance des moteurs de compétition vs grand public trafiqué m'a fait rire, quand on sait la durée de vie d'un moteur de compétition...
Les Xeons sont surtout plus endurant parce que leur enveloppe de fonctionnement est réduite pour intégrer une plus grosse marge. Ils tiendront plus longtemps en moyenne, mais ils tournent en moyenne à moindre régime.
"Chaque fois qu'une lumière brûle deux fois plus, elle brille deux fois moins longtemps" - Eldon Tyrell
;-)
Les xeon sont souvent préféré au i7 haut de gammes, parce que moins cher.
Ils ont souvent un nombre de coeur élevé avec des fréquences un peu plus basses.
Les stations de travail (HP, dell etc..) tournent souvent avec des xeon.
A la base, les caractéristiques des Xeons vs les Core i c'est :
- possibilité de multi socket (exploité dans les anciens Mac Pro tour par exemple)
- plus de coeurs
- plus de cache mémoire
- support de la mémoire ECC
Avec les récents CPU core i, ces différences s'estompent "quelque peu" mais le Xeon reste un CPU de référence pour les stations de travail (et les serveurs), notamment par l'avantage de pouvoir en placer plusieurs sur la CM et le support de la mémoire ECC indispensable pour certains métiers dans le calcul et la recherche
D'où la décision d'Apple de proposer ce CPU pour ses machine desktop "pro", et ils ont raison
Pages