Mac mini en cluster : une bonne idée en théorie, un casse-tête en pratique…
Un bloc d’aluminium de 11 cm de haut et 20 cm de côté pesant 4 kg. Un processeur à trente cœurs, douze ports Thunderbolt 3, deux ports Ethernet 10 Gb/s. Non, ce n’est pas le portrait-robot d’un futur « Mac Pro Cube ». C’est la description d’un cluster de trois Mac mini, une configuration promue par Apple sur scène et pendant les présentations presse. Une configuration que nous avons testée pendant quelques jours.
L’idée, qui consiste à mettre en commun les ressources de plusieurs machines, n’est pas nouvelle. Sans même parler des premières grappes d’ordinateurs au milieu des années 1960, il faut rappeler que le clustering était un argument de vente… du tout premier Mac mini. À l’époque, les administrateurs système utilisaient Xgrid pour former un cluster de Mac, et Xsan pour partager un système de stockage.
Compressor était le logiciel le plus lent dans l'encodage de tous que j'ai essayé.
Voilà un article particulièrement intéressant. Il manque néanmoins :
- une présentation plus détaillée de la configuration de test, c'est pas mal mais pas assez, en plus comme il semble exister d'autres solutions de clusteriser des macmini aurait pu être intéressant de les comparer ;
- et surtout une investigation poussée sur le pourquoi des plantages.
À quand des clusters de mac pourvus d'e-GPU pour faire un peu de BigData ?
« Le cluster peut refuser de démarrer, ou soudainement arrêter de fonctionner. Une machine peut rester inactive pendant toute la durée d’un traitement, la grappe peut carburer jusqu’à planter sur le dernier fichier. Un encodage qui dure quelques dizaines de secondes peut rester bloqué pendant vingt minutes d’attente, l’application entière peut planter d’une manière qui exige une « réparation » de Compressor. »
Ça ressemble à du Windows décrit comme ça.
Autant utiliser uniquement FCP - sans Compressor - ça ira plus vite au final.
Par contre, le fait que l’encodage 8 bits sur T2 soit à la fois plus rapide et moins consommateur en énergie vs l’encodage 10 bits sur Intel est assez intéressant. Est ce que vous pourriez nous en dire plus à ce sujet ?
@PierreBondurant
La puce T2 en optimisé pour décoder du HEVC, contrairement à la puce Intel, du coup logiquement ça va beaucoup plus vite. Par contre la puce T2 est limité à du 8 bits du coup pour 10 bits c'est la puce Intel qui reprend la main car la puce T2 n'est pas autorisé à faire les calculs.
@fousfous
"La puce T2 en optimisé pour décoder du HEVC, contrairement à la puce Intel, du coup logiquement ça va beaucoup plus vite."
Si, les 8xxx et 9xxx disposent des instructions spécifiques qui accélèrent le décodage HEVC. Je crois que ça a été introduit avec la génération 7.
@fte
Tout à fait, depuis Kaby Lake, les processeurs Intel supportent le décodage et l'encodage hardware du HEVC en 4K 10 bits.
@fousfous
Merci pour ces précisions.
Ce serait intéressant de savoir comment ça marche au niveau des jeux d’instructions pour comprendre pourquoi il y a une telle différence entre les deux
@fousfous
Dans le test de MacG, la différence est de traitement est x10. C’est beaucoup plus que ce que ça devrait être, normalement x3. Je me demande d’où vient la différence?
@PierreBondurant
On compare du 8bits avec du 10bits donc ça accentue la différence, ça doit être pour ça.
@PierreBondurant
"Ça ressemble à du Windows décrit comme ça."
Tu n'as pas touché à Windows depuis 20 ans, c'est ça ?
@fte
Je bosse depuis 20 ans sous windows au boulot, je fais tourner des modèles de cash-flow écrit en C++, avant c’était du VBA sous Excel mais évidemment quand Windows change des mots du langage entre 2 versions sans le documenter c’est pas pratique quand tu as besoin du résultat lundi matin à 9h, beaucoup de requêtes SQL via Microsoft studio et bien sûr l’inénarrable suite MS Office avec ses add-ins pourris, et Outlook.
Donc quand j’entends « ça marche pas et on ne sait pas pourquoi » ça me rappelle immédiatement Windows!
@PierreBondurant
Tu me parles de problèmes avec Visual Studio et des addins Office, mais c'est Windows que tu accuses ?
Donc si Lightroom se traîne sur macOS, c'est macOS qu'il faut accuser ? Ou Xcode qui plante 10 fois par jour, et les playgrounds très instables au point d'êtres inexploitables, macOS.
Okay.
C'est un brin rapide, mais ok.
On devrait incriminer Intel en fait. C'est le point commun entre Visual Studio et Xcode.
@fte
Non ce serait plutôt l’inverse d’ailleurs: Windows le système d’exploitation est générateur de beaucoup plus de problèmes que Visual Studio, qui d’ailleurs n’est pas un mauvais un logiciel pour le coup.
Chez moi j’ai un mac depuis 2008, j’ai pu faire la différence, juste au niveau operating system, de la stabilité et de la sécurité entre les deux (je n’utilise pas Xcode)
J’ai un NAS depuis 2012 (Synology), ok c’est pas du tout la même chose, mais l’OS du NAS est aussi très stable et sécurisé. Je ne suis pas informaticien de métier mais en tant qu’utilisateur je peux faire la différence entre un truc qui plante sans arrêt et quelque chose qui marche!
@PierreBondurant
"Je ne suis pas informaticien de métier mais en tant qu’utilisateur je peux faire la différence entre un truc qui plante sans arrêt et quelque chose qui marche!"
Je suis informaticien et j'ai beaucoup de mal à identifier la cause de ce qui plante en général. Les conclusions rapides sont rarement justes.
"Je suis informaticien" ne veut pas dire grand chose. Il faut, par ailleurs, arrêter d'opposer son expertise à l'utilisateur : que le problème vienne de l'OS, du logiciel, d'un autre logiciel, de son installation électrique ou de la pleine lune, peu importe. L'utilisateur veut que ça fonctionne. Et dès lors que cela fonctionne avec un mac et pas avec un PC (ou l'inverse), la conclusion de l'utilisateur prime : le mac est supérieur au PC (ou l'inverse). Peu importe que cela soit parce que le mac résiste mieux à la pleine lune pour l'utilisateur. Il voit surtout le résultat.
C'est ça qui est bien avec non-informaticiens, ils n'ont aucunes compétences mais savent tout mieux que tout le monde. :)
C'est bizzare qu'il ne tente pas de vendre à microsoft ses talents d'utilisateur qui connait la cause de tout les soucis. Surtout en ce moment, avec les galères qu'elle a sur la màj d'octobre, ya surement moyen de gratter 10 millions de $. :)
Vendre des utilisateurs, ça existe déjà. Et ça rapporte effectivement. Ca s'appelle des tests utilisateurs. Et tout le monde en fait (souvent mal, mais c'est encore autre chose).
Ce qu'il en ressort souvent, ce que peu importe le plus logique pour la MOA ou la MOE : tu fais ce que l'utilisateur veut. D'ailleurs, il est recommandé de ne pas laisser les experts intervenir : ils sont simples spectateurs. Sinon, ils ont tendance à justifier des raisons de ceci ou cela. Or ... l'utilisateur s'en fout du pourquoi : il veut faire ce qu'il a en tête, vite et avec efficacité.
@coucou
C'est surtout qu'"informaticien" veut tout et rien dire, aujourd'hui.
Un technicien qui branche des fils et installe des OS, un mec de la DSI qui distribue des ordinateurs, ou une personne qui a un Bac+2 en développement web se prétendent tous "informaticiens".
@coucou
C’est quoi un informaticien au juste? C’est le mot le plus galvaudé du monde. Ça veut tout dire et son contraire. Finalement ça relève juste de la prétention et celle de fte ne nous surprend plus!
Quand on veut savoir ce qui plante, on surveille les services et les logs. C’est très facile d’identifier un plantage. Après, lire des logs sous Windows relève de la torture...
@bonnepoire
C'est pas fte qui a utilisé le terme d'informaticien, il la juste reprit, mais le mec qui y connait pas grand chose et qui le dit lui même d'ailleurs. :)
@coucou
Je cite fte alors:
« Je suis informaticien et j'ai beaucoup de mal à identifier la cause de ce qui plante en général«
@bonnepoire
"Je cite fte alors"
Dans une conversation, tu ne retiens jamais que la dernière phrase ? J'en ai une pour toi alors, je profite.
Fte a battu Chuck Norris juste en éternuant dans sa direction.
@ fte
Dixit le mec qui s'attache aux détails insignifiants d'une conversation pour ériger une montagne de pédanterie.
@bonnepoire
Insignifiants ? Accuser un OS de changements dans un compilateur ?
Arrête de te foutre de moi, veux-tu !?
@fte
Arrête de te foutre de moi, veux-tu !?
Où vois-tu que je fais référence à ça??? Va te coucher!
@bonnepoire
"Où vois-tu que je fais référence à ça??? Va te coucher!"
Tu n'arrives donc vraiment pas à suivre une conversation en entier ?
Je vais me coucher si je veux, j'ai passé l'âge qu'on me paterne, merci.
@coucou
Merci :)
@bonnepoire
« Quand on veut savoir ce qui plante, on surveille les services et les logs. C’est très facile d’identifier un plantage. »
Et quand on lit quelque chose comme ça on peut être assuré que la personne qui l'écrit n'est pas un informaticien et n'y connaît quasiment rien à l'informatique.
Tu dois être un spécialiste.
@bonnepoire
« Tu dois être un spécialiste. »
Je suis informaticien, je fais régulièrement du débuggage, et je sais que le plus souvent il ne suffit pas de "surveiller les services et les logs" pour identifier un plantage.
Ça serait exactement comme dire à un enquêteur "c'est facile de résoudre un crime, il suffit de regarder les indices".
@bonnepoire
"C’est très facile d’identifier un plantage."
Si c'était le cas, il n'y aurait plus de plantages. C'est si facile à identifier...
C'est dur de ne pas être prétentieux quand on lit de genre de commentaires, ça tient de l'exploit.
> Je bosse depuis 20 ans sous windows au boulot, je fais tourner des modèles de cash-flow
> écrit en C++, avant c’était du VBA sous Excel mais évidemment quand Windows change
> des mots du langage entre 2 versions
Un OS qui change les intructions d'un langage compilé !?
C'est pas Windows qui change les "mots du langage", mais l'éditeur de votre compilateur C++.
Il se trouve que vous utilisez celui de Microsoft, qui est également l'éditeur de Windows.
Mais vous pourriez utiliser un autre compilateur C++ que celui ce Microsoft, il en existe d'autre, et parmi ceux-là certains on plus le soucis de rétro-compatibilité.
Quand Microsoft change les "mots" du langage VBA, cela n'a rien à voir avec l'OS et tout à voir avec le fait que vous utilisez une environnement de développement dont l'éditeur ne garantie pas assez la rétro-compatibilité.
> beaucoup de requêtes SQL via Microsoft studio et bien sûr l’inénarrable suite
> MS Office avec ses add-ins pourris, et Outlook.
Le point commun ici, c'est pas Windows mais Microsoft. Nuance.
@fte
J'utilise Windows tous les jours et ça resemble bien à du Windows même si tu essayes d'évangéliser les gens pour switcher sur win et Android
@malcolmZ07
Ah, donc quand on essaye de souligner qu'aucun OS, qu'il soit Windows, macOS, iOS, Android, BSD, Haiku, DOS, QNX, AmigaOS, GEM/DOS etc ne peut changer les instructions supportés ou pas par un compilateur, on évangélise !?
Vous faites juste usage de l'abus de langage habituel en confondant Windows, l'OS, et les outils Microsoft, qui ne font absolument pas parti de l'OS Windows.
Je cross-compile quotidiennement du code C++ pour Linux et Windows, et j'ai eu des tonnes de maj de Linux et de Windows sur les machines cibles, et en aucun cas mon code C++ n'est devenu subitement plus compilable suite à une maj de ces 2 OS !
C'est quand je fait une MAJ du compilateur que je rencontre éventuellement ce cas de figure. Ou, pour reprendre l'exemple donnée, une MAJ du serveur SQL employé, qui lui aussi n'est pas un composant du système d'exploitation mais un programme tiers dont l'interface de programmation évolue non pas avec l'OS mais avec le cycle d'évolution de *ce* programme.
Un compilateur, c'est pas une plateforme logiciel ni un système d'exploitation, c'est un outil pour produire un code exécutable. Le système d'exploitation, lui, charge ce code en mémoire et le confie au processeur, en aucun cas il se permet de modifier sans prévenir les instructions possibles, qui de toute façon sont gravé dans le silicium (littéralement).
Si l'instabilité de l'environnement de programmation vous pose des soucis, il est temps d'envisager de changer d'outils de programmation, c'est aussi simple que ça.
@byte_order
Merci !
Ça fait du bien de lire cette mise au point.
@malcolmZ07
"même si tu essayes d'évangéliser les gens pour switcher sur win et Android"
Oh, je n'essaie pas de faire ça. M'en fiche de ce que les gens utilisent. Par contre, je réfute ce qui est à l'évidence faux.
@malcolmZ07
"J'utilise Windows tous les jours et ça resemble bien à du Windows"
C'est très scientifique et rigoureux comme approche : j'utilise tous les jours et ça ressemble.
Sinon, sérieusement, un argument qui tienne la route pour pointer Windows du doigt plutôt que, voyons, je cherche, le compilateur ?
C'est donc bien du "cluster" applicatif, c.a.d. que seules les applications ayant une fonctionnalité de calcul distribué, chacune à leur façon distincte, plus ou moins optimisée, exploitant plus ou moins les ressources réels de chaque machine ou juste un dénominateur commun, et souvent impliquant un déploiement (et les mises à jour) manuel préalable sur chaque machine, le permettent.
C'est quand même dommage qu'en ayant XSan et XGrid quelque part au fond d'un disque (mais p'tet plus les ingénieurs qui savaient comment cela fonctionnait, remarquez...), Apple ne propose pas un service de cluster au niveau système, dans macOS, pour inciter beaucoup plus d'applications à adopter le calcul distribué.
@byte_order
Peter Bright publie un compte-rendu assez javellisé du Mini chez ArsTechnica. Il en consacre une bonne partie à la clusterisation mise en avant par Apple. Voici un extrait :
« The same tends to hold true of a render farm. Again, the size makes it the best Mac for high-density deployments, but you wouldn't want to use that processor (and that GPU) in a render farm. Beyond the compiling software, rendering is a massively parallel operation, the kind of thing that GPUs excel at. GPU-based render farms are widespread and effective. Mac mini? It's stuck with Intel integrated graphics. So, sure, you could use the Mac mini this way, and, if you're strictly wanting CPU-based rendering, then it may (due to size) be the best Mac for the job. But it ain't the machine you'd design for this task.
On top of all this, if you really wanted to build your server farm or render farm out of small desktop PCs, the Mac mini isn't even necessarily the smallest. Intel's NUC line has a smaller footprint, for example. Even within the context of tiny computers, the Mac mini is awkwardly positioned unless, specifically, you need macOS. »
Apple devrait vraiment nous expliquer de façon convaincante, preuves à l’appui, en quoi macOS (même faisant abstraction des bécanes actuelles) serait tout à coup devenu optimal, ou ne serait-ce que viable, pour le calcul distribué.
XSan et XGrid sont encore là pour nous enseigner la méfiance envers l’entreprise, son éthique et sa mentalité, même quand le produit est correct (ou qu’il avait des chances de le devenir, comme dans le cas des X...).
https://arstechnica.com/gadgets/2018/11/mac-mini-review-a-testament-to-apples-stubbornness/
@occam
en fait.... le "Peter Bright a raison dans l'absolu avec son distinguo CPU/GPU pour les renders farm sauf... pour Compressor ou ça ne s'applique absolument pas !
Compressor est une pure moulinette CPU, (même si il y a une dose de GPU quand on le lance depuis FcpX, ce qui n'a rien à voir dans le process ... et pas de cluster dans ce cas, comme par hasard.... donc appliquer cela à ce débat est faux.
Après... cela te sert de support à "hating" et si ça te fait du bien ... tant mieux. mais la question n'est absolument pas là. Et c'est là que le mec raconte n'importe quoi. Evidemment qu'il n'est pas question de se lancer dans le big cluster multi-fonction, multi "métiers"...
on parle ici d'une fonction de complément pour la compression vidéo en milieu MAC OS
> on parle ici d'une fonction de complément pour la compression vidéo en milieu MAC OS
Et ce que moi je souligne c'est qu'on obtiendrait nettement plus de gain pour un prix inférieur si Compressor était capable d'exploiter plusieurs GPU.
Mais comme supporter plusieurs GPU cela signifier soit de l'eGPU encore très bancale soit de proposer des macs modulaires, avec donc des slots PCIe, ce que refuse Apple car cela ne va pas dans son sens de machine verrouillée non évolutive qui force au renouvellement complet, cette option, au rapport cout / performance nettement plus rentable pour l'utilisateur n'existe tout simplement pas, et ce arbitrairement.
Et comme elle n'existe pas matériellement, arbitrairement, son support logiciel n'est pas proposée, donc même l'option eGPU multiple n'est pas supportée.
Evidement que Apple préfère "convaincre/contraindre" ses clients captifs d'acheter 4 MacMini à > 1000$ chaque que de les autoriser à acheter 4 GPU à un fabricant tiers pour le même prix (mais un ratio prix / performance supérieure en terme de calcul) : dans le premier cas l'argent va dans sa poche, dans le second rien ne va dans sa poche.
Que Compressor soit une pure moulinette CPU est en soit une hérésie, de nos jours n'importe quel calcul boosté par un GPU même de milieu de gamme affiche des gains de factor x10 minimum par rapport à du pure CPU.
C'est uniquement parce qu'il s'agit du milieu macOS qu'il peut se permettre d'en être resté là, l'arbitraire matériel lui permettant de ne pas devoir affronter frontalement la concurrence, qui implique justement de changer d'OS et de matériel.
@byte_order
il y a deux problèmes avec ta réponse
1 - Tu pervertis le débat et tu te mets à parler d'autre chose.
On parle de la validité de ce test, (on ne discute pas sur la question de savoir si il faudrait basculer Compressor sur du GPU (débat pour lequel tu n'est pas compétent) ou si Apple devrait ouvrir sur plusieurs GPU et se lancer dans des usines à gaz pour images "Computer Generated) pour une activité qui reste de l'atelier créatif avant tout. (Au delà de permettre, d'avoir deux external GPU par exemple, ce qui est déjà le cas.)
Ce n'est pas le problème de Compressor à l'échelle de notre métier en fin de compte. Quand à la bascule sur GPU pour Compresser/Décompresser "10x plus vite " de la vidéo hahaha la bonne blague, si c'était si facile à Machine, OS etc égal ... et bein Resolve (surtout sur NVIDIA) irait bien plus vite par exemple or ce n'est pas le cas... Resolve se tient à niveau mais n'est pas plus rapide.
les renders farm de CGI c'est un autre domaine, ça se fait sur d'autres OS, Softs, Hardware et c'est très bien comme ça.
2 - Comme tu ne connais pas grand chose (voire rien) à la video tu te plantes sur l'enjeu de domaine. Non seulement tu raisonnes "rendu" au lieu de "COmpression/DECompression mais tu te bananes complétement en parlant "d'arbitraire matériel", les gens qui font de la video sur MAC aiment l'OS et les applications.
(dans les deux cas c'est le fonctionnement du hater qui veut absolument revenir avec quelque chose: et gnagnagna et gnagnagnagna (un peu roquet quand même...)
Il reste à prier qu'Apple planche sur un véritable Mac Pro…
Sinon on leur enverra des gilets jaunes pour bloquer leur campus halakon !!!
je pense qu'il faut des machines identiques. comme pour les barrettes de RAM, qui fonctionnent par paires, pour que ça roule sans problème. et généralement des machines que pour ça, pas pour d'autres opérations, avec d'autres logiciels installés.
Super test, mais avez-vous comparé la qualité de la vidéo finale entre 1 seul Mac mini et 1 cluster de 3 ?
Et la qualité entre la compression par la puce T2 et le processeur ?
On peut avoir des surprises, généralement mauvaises, de ce coté.
c'est la vitesse qui joue dans ce processus pas la qualité de la video qui dépend de réglages Logiciel (codecs, poids du fichier, format, etc) et pas matériel.
un cluster fait la compression plus rapidement normalement. il utilise plusieurs ordinateurs pour la tache.
le P2P fait pareil. ça marche beaucoup plus vite, parce que plusieurs ordinateurs sont utilisés pour le partage du même fichier. le principe est le même.
Pour ce qui est du test, et peut-être du coup les plantages, peut-être qu'un test avec un fichier plus long serait plus pertinent.
Du type plus de 10/15 minutes.
Il est possible que Compressor (que je n'ai pas utilisé depuis que FCPX est sorti ?) "n'arrive pas"/"ne trouve pas pertinent" de diviser la tache entre les bécanes et plante du coup.
Après, je n'ai pas bien compris l'histoire du cluster logiciel intégré au système. Il y a des softs, Maya ou Cine4D par exemple qui ont leur propre système de rendu déporté.
à tester aussi du coup.
> Après, je n'ai pas bien compris l'histoire du cluster logiciel intégré au système.
L'idée, c'est que si chaque logiciel doit implémenter son propre mécanisme de distribution d'une tâche de calcul sur plusieurs machines :
- chacun ne vas pas avoir la même façon de le faire
- chacun n'aura pas la même qualité d'implémentation, certains ne seront pas exempt de bug (comme cet article le montre dans le cas de Compressor)
- chacun n'aura pas les mêmes limites, en particulier l'exploitation d'un cluster de machine aux ressources hétérogènes (comme cet article le montre, la GPU n'est pas exploitée en mode cluster, uniquement sur le master)
- chacune ne prendra pas forcément en charge le déploiement automatique sur les machines du cluster, au contraire commercialement cela permet souvent d'obliger d'acheter une version complète du logiciel alors que seul la partie "calcul distribué" est nécessaire pour les machines esclaves.
- et surtout, la tâche d'implémentation de ce type de fonctionnalité étant loin d'être simple et donc coûteux, peu d'applications le feront, ce qui réduit de fait la rentabilité générique d'un cluster.
Faire du calcul distribué, cela se fait depuis que le réseau est disponible de manière systématique sur les ordinateurs.
Avoir une mécanisme de cluster au niveau système, comme XGrid, y'a peu de système d'exploitation qui le propose, et aucun OS grand public. C'est dommage de ne pas pousser vers là, alors que les infrastructures sont de plus en plus sur des clusters génériques.
Si c'est juste pour distribuer le code d'encodage de Compressor sur 3/4 unités de calcul, je suis persuadé qu'un ordinateur avec 4 slots PCIe permettant de mettre jusqu'à 4 cartes GPU permettrait à du code supportant du multiGPU d'atteindre de meilleurs résultats, par exemple. Pour l'avoir fait sur un projet de traitement temps réel du signal, y'a vraiment pas photo.
Mais évidement, des slots PCIe, dans un Mac Mini (ou récent, tout simplement) c'est devenu interdit. Cela permet trop longtemps de se passer de devoir racheter un nouveau mac...
Si c'est pour distribuer sur nettement beaucoup plus d'unité, le coût de déploiement, de maintenance de la configuration, de migration de machine, de maj de machine etc sont loin d'être neutre. Et y'a une limite à ce qui peut passer sur un bus de 10Gb/s, aussi.
oui, ça j'entends bien mais l'article est assez confus.
Ce que je ne vois pas c'est s'il y a sous Xcode et/ou dans l'OS des APIs dédiées* à cette utilisation ou seul Compressor a ce mécanisme pour l'instant.
* nouvellement sorties avec ce Mini/Mojave.
Pages