Fermer le menu
 

Un Mac mini peut compiler plus vite qu'un Mac Pro

Nicolas Furno | | 16:03 |  76

Le Mac Pro a beau être un produit honteusement abandonné par Apple, il reste le Mac le plus puissant actuellement sur le marché dès lors qu’une tâche utilise plusieurs cœurs. Avec son option à 12 cœurs physiques, il aligne 24 cœurs logiques qui peuvent être exploités dans certaines tâches très précises. C’est le cas, notamment, lors de la compilation d’une app. Le code source doit alors être converti en code machine et rassemblé pour former un paquet prêt à être ouvert par un appareil, une tâche lourde qui bénéficie de la puissance d’un Mac Pro.

Du moins, ça c’est la théorie. En pratique, les résultats ne sont pas du tout aussi logiques et c’est même l’inverse qui se produit. C’est ce qu’a remarqué un responsable de LinkedIn quand les développeurs de l’app iOS ont commencé à abandonner leurs Mac Pro à 12 cœurs pour utiliser des MacBook Pro. Interrogés, ils ont répondu que les portables équipés de quatre cœurs seulement étaient plus rapides pour compiler l’app.

Avantage du Mac Pro : il peut facilement être recyclé en corbeille à papier. Corbeille pour un seul papier néanmoins : même alors, il n’est pas très efficace… Cliquer pour agrandir

Pour en avoir le cœur net, ce responsable a mené des tests sur tous les Mac qu’il a pu trouver, y compris sur un Mac mini affiché à 1339 € avec l’option Core i7. À titre de comparaison, le Mac Pro avec l’option 12 cœurs est vendu au minimum 8199 €. Sur chaque machine, il a compilé l’app iOS de LinkedIn en utilisant de plus en plus de cœurs et le résultat est étonnant.

Le Mac Pro est effectivement l’ordinateur le plus lent pour mener à bien cette tâche, alors que c’est l’iMac le plus rapide. Ce dernier est un modèle de 2015 équipé d’un processeur Core i7 à quatre cœurs physiques et huit cœurs logiques. Même le Mac mini fait systématiquement mieux que le Mac Pro, dernier du classement quel que soit le nombre de cœurs.

Par défaut, il faut plus de 10 minutes pour que le Mac Pro compile l’app, là où quatre minutes environ suffisent à l’iMac. Un écart énorme qui s’explique a priori par un bug. Xcode peut exploiter autant de cœurs que l’ordinateur peut en fournir, mais contre toute attente, le processus n’est pas accéléré en multipliant les cœurs, il est ralenti.

Ce graphique affiche le temps nécessaire pour compiler l’application de LinkedIn en fonction du nombre de cœurs utilisés. Le Mac Pro (en rouge) est le seul à pouvoir monter jusqu’à 24 cœurs. En jaune, l’iMac est bloqué à huit cœurs, mais c’est lui le plus rapide. Cliquer pour agrandir

Précisons que ce n’est pas systématiquement le cas et les apps développées uniquement en Objective-C ne souffrent pas du même problème. C’est Swift qui semble être le coupable dans l’histoire et a priori plutôt la troisième version. Notre développeur iOS se plaint également de lenteurs à la compilation depuis le passage à Swift 3 à la fin de l’année.

Suite à cette découverte, ce cadre de LinkedIn a essayé d’isoler le problème en utilisant différentes versions de macOS, en compilant une app beaucoup plus légère et même en testant une compilation avec un système installé sur APFS. Mais rien n’y a fait, il a obtenu systématiquement les mêmes résultats, ce qui l’amène à la conclusion qu’il y a un bug, soit dans macOS, soit dans Xcode.

En attendant un correctif (un rapport de bug a été créé), les développeurs trouveront à la fin de l’article deux solutions temporaires pour améliorer les temps de compilation. Il s’agit déjà de bloquer le nombre de cœurs utilisés par Xcode, sachant que le meilleur étant 5 pour un Mac Pro et 6 à 8 pour les MacBook Pro et iMac à quatre cœurs. Ensuite, désactiver l’indexation Spotlight de certains dossiers diminue également légèrement le temps nécessaire à la compilation.

Compilation en cours dans Xcode. Cliquer pour agrandir

Apple présentera Swift 4 lors de sa conférence développeurs, au mois de juin. Espérons que ce problème de performances sera réglé avec cette mise à jour qui doit apporter la stabilité, au moins pour le code-source.

Catégories: 

Les derniers dossiers

Ailleurs sur le Web


76 Commentaires Signaler un abus dans les commentaires

avatar robrob 16/03/2017 - 16:25

Ca indique surtout que la compilation n'est pas encore bien optimisee pour Swift 3.
Ca s'ameliorera, la compilation de gros projets etant generalement assez facile a paralleliser vu que les differents modules peuvent etre compiles independamment.

avatar r e m y 16/03/2017 - 16:33 via iGeneration pour iOS (edité)

@robrob

Il est plus rapide d'abandonner le Mac Pro que d'optimiser Swift pour une compilation multicoeurs...

(Cela dit, peut être le Mac Pro 2013 aura-t-il un successeur... car si vous cherchez sur le site Apple la liste des Mac gérant Métal, vous verrez qu'il est écrit en dernière ligne Mac Pro 2013 ou plus récent)

avatar byte_order 16/03/2017 - 18:32

C'est même confirmé, des benchmarks Xcode frontend C++ montrent que les lenteurs avec 24 jobs parallèles observées avec Swift ne sont pas observés avec le compilo clang.



avatar dgaultie 16/03/2017 - 16:33 via iGeneration pour iOS

Ca veut juste dire que la compilation n'est pas optimisée pour le multicoeur : ce n'est pas le seul logiciel dans ce cas
Et donc c'est le mono cœur le plus rapide qui l'emporte ...
Marre de ce MacPro bashing à la con : ca reste une excellente machine

avatar r e m y 16/03/2017 - 16:37 via iGeneration pour iOS

@dgaultie

C'est juste factuel... si vous développez en Swift, la compilation de vos applications sera très lente sur un Mac Pro.

Il faudrait pouvoir brider la compilation pour qu'elle soit traitée par un seul cœur du MacPro. Peut-être pourrait-il alors être plus rapide que les autres Mac testés.

avatar fanchig 16/03/2017 - 17:26 via iGeneration pour iOS

Ça montre sans doute que les ingénieurs d'Apple n'utilisent pas le Mac Pro...

avatar byte_order 16/03/2017 - 17:51 (edité)

Pas faux.

avatar BeePotato 16/03/2017 - 23:49

@ fanchig : « Ça montre sans doute que les ingénieurs d'Apple n'utilisent pas le Mac Pro... »

Ou qu’ils savent ajuster correctement le nombre de threads utilisés pour leurs compilations et qu’ils imaginent que les autres développeurs en feront de même si nécessaire. ;-)

avatar bobdu87 17/03/2017 - 09:44

Nan ca ne tient pas la route....

avatar BeePotato 17/03/2017 - 10:29

@ bobdu87 : « Nan ca ne tient pas la route.... »

Ben si, pourtant. :-)

avatar moon21 16/03/2017 - 17:27

même débat que pour les cartes graphiques intégrées au mac pro : pas d'optimisation, pas de résultat.

avatar bobdu87 17/03/2017 - 09:45

Carte ultra dépassés.... donc bon

avatar moon21 16/03/2017 - 17:33

je dois ajouter que ce genre news est un peu légère et ne fait que donner des arguments infondés aux switchers-radins.

Un mac pro, c'est ultra rentable, plus qu'un iPhone ... faut-il encore en avoir l'utilité et pas simplement l'envie.

avatar bobdu87 17/03/2017 - 09:47

Infiniment moind entable qu'un PC au même prix....
Mon pauvre PC de taf qui a déjà 3 ans atomise le mac pro haut de gamme.... pour une portion du prix...

avatar pocketalex 17/03/2017 - 12:43

@bibdu87

Tu as entièrement raison, mais dans des proportions sommes toutes assez insignifiantes car pour les Xeon comme pour tous les autres CPU, les performances stagnent (mais le nombre de core à augmenté depuis 2013)

Du coup tu as quoi comme CPU ? le MacPro c'est des Xeon E5-2697 V2 de 4 à 12c, j'imagine donc que tu as un V4 comme le Xeon E5-2679 v4 @ 2.50GHz (20-c, un vrai monstre) ?

Dis nous, ça m'intéresse !

Par contre, ta bécane doit peut-être être plus puissante, mais pas forcément beaucoup moins chère qu'un Mac Pro, les stations de travail avec ces Xeons, ça douille pas mal...

avatar zoubi2 17/03/2017 - 19:34

J'admire la retenue de pocketalex....

avatar pocketalex 18/03/2017 - 01:27

@zoubi2

je sais pertinemment qu'il a un i7 (si c'est pas un i5), en attendant j'affute ma lame

avatar BeePotato 16/03/2017 - 17:34 (edité)

« ce qui l’amène à la conclusion qu’il y a un bug, soit dans macOS, soit dans Xcode. »

Soit dans le compilateur Swift.

avatar pecos 16/03/2017 - 17:38 (edité)

Je ne comprends pas, là.
Vous parlez bien de "minutes", pas de "secondes" ???

J'ai des apps sur l'appstore qui sont moyennement complexes, en objective-C uniquement.
Et ça ne met jamais plus de quelques secondes à compiler et à envoyer au simulateur.
Pour l'envoi au device, ça peut mettre des minutes, mais c'est APRES la compilation que ça dure.

De 2 choses l'une, et sans parler du gros souci de multithread avec le macpro :
Si j'avais des apps pour iOS qui compilent en "plusieurs minutes", soit je jette l'ordi, soit je jette le code.

Et pitié, ne me dites pas que l'app linkedin est *incomparablement* plus complexe que les miennes (déjà c'est pas sûr, je demande à voir le code) : je veux bien que ça mette un peu plus longtemps à compiler, mais il y a des limites.

(tiens, déjà que j'avais pas trop envie de me mettre à Swift que je trouve pas très fini, ça m'encourage encore un peu plus... hi hi...)

avatar byte_order 16/03/2017 - 17:55

> Et ça ne met jamais plus de quelques secondes à compiler et à envoyer au simulateur.

Même après un clean, c.a.d. une compilation "totale" !?

avatar pecos 16/03/2017 - 18:15 (edité)

Je viens de le faire : ~ 5 secondes pour compiler une build après "clean all targets".

Et quand ça a déjà compilé au moins une fois, c'est quasi instantané.

C'est un peu plus long quand je redémarre sous el Capitan et que je compile avec XCode 8.2.1 sous iOS 10.2, mais pas de beaucoup.
On va dire une petite dizaine de secondes, et quelque secondes quand on n'a pas fait de clean avant.

(ça s'améliore pas, XCode, c'est sûr, mais quand même. En fait ce qui est plus long avec XCode 8, c'est l'envoi de la build au simulateur, ça met effectivement 2 ou 3 secondes au bas mot, alors qu'avec une vieille version d'XCode c'est instantané))

Bon.
C'est vrai qu'il n'y a que 6250 lignes de code dans ce programme.
Le paquet fait 137,6 Mo.
Il contient 3909 éléments.
L'éxécutable 64 bits fait 397 Ko.
Je veux bien imaginer que l'app linkedin est un peu plus complexe.
OK.
Mais c'est qu'une app iOS, c'est pas photoshop CC, non plus.

Maintenant pour tout dire, je pisse du code toute la journée, là.
Et je compile plusieurs centaines de fois pas jour.
À chaque petite modif, en fait. ;-)

Vous imaginez si je devais attendre 10 minutes à chaque fois ?
Faite juste le calcul.
Autant aller directement à pôle emploi ou remplir un dossier pour RSA base.

avatar byte_order 16/03/2017 - 18:37

Y'a quelques années j'ai du bosser sur du code C++ d'un logiciel militaire : plateforme de développement : une station solaris.

J'ai pleuré.
Tous les jours.
Jusqu'à la fin de la mission.

Je devrais pas le dire, mais j'ai fait des compilations "en douce" sur mon laptop linux (un pauvre i3 pourtant) tellement j'avais mal à mon cycle de build et que j'y tenais plus.

avatar C1rc3@0rc 16/03/2017 - 23:48

Et elle avait quel processeur ta station Solaris?

avatar byte_order 22/03/2017 - 11:40

C'était de mémoire une sparcstation 20 je crois. De l'UltraSparc j'imagine.

Dans le militaire, il n'est pas rare de devoir travailler sur des technos dépassées car les choix techniques d'un projet sont consolidés (sourcing des pieces de remplacement compris) sur 20 a 40 ans, encore. Question d'auto-suffisance.

C'était juste pour souligner qu'espérer des build cycles quasi instantanés n'est pas une réalité dans pas mal de secteur encore, soit parce que le code est très lourd et complex soit parce que les plateformes de build ne peuvent pas être assez performante pour ça.

avatar BeePotato 16/03/2017 - 23:56

@ pecos : « Vous imaginez si je devais attendre 10 minutes à chaque fois ? »

Je me rappelle une époque où c’était le cas (ok, dans mon cas ce n’était pas 10 minutes, mais tout de même plusieurs).
Et du coup, on ne s’amusait pas à compiler à chaque petite modif. On avait plutôt tendance à attendre d’avoir fait un ajout assez conséquent — et à bien se relire avant de lancer la compilation. :-)

Les environnements de développement actuels sont nettement plus agréables, faut bien l’avouer.

Pages