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

Nicolas Furno |

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.

avatar eX0 | 

Comme j'expliquais à des amis il y a quelques jours, il faut savoir quel type d'application on utilise pour savoir quel processeur choisir.
Tous le monde raisonne en "c'est plus gros et plus de cœur donc plus puissant". Ben nan.
Il faut savoir si une application est optimise pour le multithread ou pas. Si elle est mono thread, Le Xeon est perdant au benchmark. C'est un processeur fait pour le multithread. Le core i7 est avantage par son boost mono processeur souvent supérieur à la fréquence maxi que peut atteindre un xeon.
Pour ça que pour le gaming un core i5 est plus rentable en terme de prix par rapport à un i7, les jeux étant avant tout des applications monocores qui bénéficient de la fréquence maximale du processeur que son nombre de cores.
Cette belle démonstration veut dire qu une chose:
• si tu veux réduire les temps de compilations avec Xcode il vaut mieux viser la vitesse maximum.

Par contre faire le test avec des applications exploitant le multicore comme Le traitement vidéo et on reparle :).

avatar RedMak | 

@eX0

Vous n'avez pas lu (compris?) l'article aparament ..

avatar eX0 | 

@RedMak

Si tu peux m'éclairer sur mon incompréhension je t en serais redevable.
Et ce serait intéressant pour les autres utilisateurs, vu qu on est nombreux à arriver à la même conclusion.

avatar C1rc3@0rc | 

@eX0

Tu as tout a fait raison et ton explication est incontestable.
Le plus fort la-dedans c'est qu'en mono-core ou en multithread jusqu'a 8 (virtuels) le Mac Mini 2012 (serveur) fait au moins aussi bien voir mieux que le Mac Pro, tous ceux qui ont des Mac Mini 2012 l'on constaté.

L'explication est simple: l'architecture x86 est tres energievore par nature, et plus le processeur doit etre "puissant" plus il va devoir avoir une frequence elevee, plus il va consommer... et plus il va chauffer.
Pour abaisser la consommation il y a 2 possibilités: augmenter l'efficacité energetique ou restreindre l'alimentation.
Et puisque l'architecture x86 ne peut pas beaucoup evoluer en terme d'efficacité energetique, Intel a travaillé sur l'optimisation de l'activite: un x86 est aujourd'hui conçu pour fonctionner le moins possible.

Cela explique 2 choses:
les Xeon, qui doivent faire tourner plus frequemment la plupart de leurs core ont donc des frequences inferieures aux Core i qui peuvent mettre a l'arret le plus souvent tous les core sauf 1 qui tourne au maximum.
dans les activités mono-tache sporadiques les Xeon sont tres mauvais par rapport aux "gros" Core i 7

L'anomalie que constate le gars de Linkedin, c'est que sur une tache normalement multi-thread le Mac Pro ne tient pas la route face a un Mac Mini actuel (pourtant doté des moins performants processeurs (Core i 5 ou i7 U => 2 core pour petits portables) apres le Core-M - )... sur la compilation de Swift.

Et pourtant le compilateur Swift est un des plus avancé qui soit et son utilisation de LLVM est évidement une des meilleures.

Cette situation met en évidence, pour une raison a démontrer, que la compilation de Swift n'est pas une tache bien parallélisable... ou parallélisée.
Le problème ne vient pas de Xcode, sinon Objective-C souffrirait du même problème. Le problème vient donc soit de MacOS, soit plus probablement de l'architecture de Swift.

avatar ziggyspider | 

eXO s'écarte un peu du sujet (et encore) mais je suis du même avis !

avatar Dr. Kifelkloun | 

C'est bien gentil ce que vous nous racontez, mais il y a une grande partie (et même une large majorité à mon avis) des utilisateurs de MacBook Pro, iMac et Mac Mini qui ne savent même pas de quoi vous parlez. Normalement les acheteurs de Mac Pro savent ce qu'ils cherchent, mais ça représente quoi le Mac Pro chez Apple?
En ce qui me concerne, je ne sais pas définir le "thread". Pour le multithread, je ne sais multiplement pas. Le coeur est un organe qui sert à pomper du sang, et normalement un suffit si il pompe bien.
Bref... Je suis persuadé que toutes ces choses très importantes ne parlent pas à la plupart des acheteurs d'ordis Apple.
Donc on fait quoi? Y-a-t'il des moyens simples de comprendre de quoi une application besoin, et quand nous avons interêt à acheter quoi? Vu que Apple ne nous aide pas vraiment à choisir et fait exactement du "c'est plus gros (j'ajoute: et plus cher) et plus de cœur donc plus puissant", est-ce-qu'il y a un moyen approchable d'y voir plus clair pour un utilisateur lambda?

avatar byte_order | 

> est-ce-qu'il y a un moyen approchable d'y voir plus clair pour un utilisateur lambda?

Oui.

Monter en compétence sur les technologies au coeur des ordinateurs.
Ce n'est qu'ainsi que vous pourrez alors envisager de vous faire par vous même - c.a.d. en vous basant sur vos connaissances et non les avis d'autrui, vendeurs compris - sur l'interêt d'avoir telle technologie dans tel ordinateur ou pas.

Et d'acheter mieux informé.

Si cela vous parait trop couteux, chronophage etc, vous n'aurez jamais vraiment autre chose qu'une grille de lecture pondue par d'autres pour vous expliquez que selon eux c'est ça qu'il vous faut ou pas. Certains n'aurons pas d'autres arrière pensée que véritablement vous aidez, mais d'autres seront fatalement juge et partie.

avatar ovea | 

@byte_order

C'est pas comme ça qu'il faut sabordée l'utilisateur lambda, mille sabords ☠️

Sinon j't'montre mon Knuth ?

À part éradiquer définitivement les bugs en mettant en place un système de handlers et une programmation par acteur dans un langage concis, je vois pas comment traiter la parallèlisation en montant la garde au fork ? et de balancer des boulets de part et d'autre. La diplomatie des sema forts ?

Après le lambda c'est virer l'Apple ? pourrie ? à qui profite la communauté de dèv avec leurs bottes en peau de serpent ? qui font des logiciels totalement béta ? et mettre un OCaml au cœur ❤️ qui peut se décrire et s'écrire lui-même … la balle ⚾️ est dans ton camp, je garde la batte ?

avatar antoninGR38 | 

Un thread est un fil d'exécution ou tâche. 1 coeur = 1 unité de calcul pouvant traiter 1 seul thread (=tâche). Donc un processeur à n coeurs dispose de n unités de calculs capable d'exécuter n threads en parallèle de façon indépendante : vous exécutez donc plus de tâches dans un même laps de temps, encore faut-il que l'application soit suffisamment bien codée pour exploiter les coeurs disponibles (et dans le cas aussi où les tâches soient parallélisables).

Par analogie avec la vie réelle, en utilisant l'industrie du textile : 1 thread = tricoter un pull et un coeur équivaut à un ouvrier capable de tricoter un pull. Plus vous embauchez d'ouvriers, plus vous augmentez votre capacité de production (mais vous devez payer plus de salaires ;).

Au temps des Pentium, on augmentait la puissance avec la fréquence d'horloge (pour résumer vite fait) : le CPU = 1 unité de calcul devenait de plus en plus rapide mais n'exécutait toujours qu'un seul thread à la fois (seul les pros pouvaient se payer des bi-pro à l'époque). Maintenant qu'ils ont atteint la limite en fréquence, ils multiplient les processeurs pour augmenter en puissance, mais du coup le logiciel doit suivre car si les tâches ne sont pas parallélisées, le gain est nul (par analogie, ça reviendrait à refiler tout le travail à un seul ouvrier et ignorer les autres). C'est apparemment ce qu'il se passe ici, concernant la compilation des projets en Swift 3.

En fin de compte, il est inutile pour un utilisateur lambda d'avoir un processeur à 12 coeurs pour utiliser Safari, Mail et Word. Seuls les pros ont des besoins de puissance de calcul pour des tâches longues et complexes (calcul scientifique, montage vidéo, rendu 3D, etc.).

avatar byte_order | 

Le multicore n'a pas qu'un intérêt en terme de calcul.
Il est également interessant en terme de réactivité.

Ne pas oublier que l'application que tout le monde utilise en permanence, y compris toutes les autres applications, c'est le système d'exploitation.

Et ils sont tous massivement parallélisés de nos jours.
Ils sont donc, normalement, plus réactif.

Et c'est assez factuel : il devient difficile de trouver une situation ou l'OS ne répond plus pendant plusieurs secondes. Des applications qui répondent pas, oui, ça se trouve encore, des OS non reactif car trop occupé, c'est déjà moins facile a trouver.

avatar antoninGR38 | 

Oui, tu as raison. Je n'ai pas voulu parler de l'OS pour complexifier mon propos, mais il y aura toujours une multitude de tâches à exécuter en plus de l'application utilisée. Et moins il y aura de swapping (=bascule d'un thread en arrière plan pour en exécuter un autre), mieux ça sera.

avatar pocketalex | 

L'époque des CPU mono-core/mono-thread, j'ai bien connu

Si un logiciel bouffait 100% du CPU, ce qui arrivait souvent, toute la machine était bloquée, et, sur PC, jusqu'au curseur de souris !!!

Avec l'arrivée des Centrino, on a commencé à gagner en fluidité, l'OS répartissant les taches entre les coeurs, si un logiciel bouffe tout, il bouffera pas plus d'un coeur, et il en reste un pour gérer le reste, la machine est plus fluide

Bon ça c'était avant, aujourd'hui la moindre machine entrée de gamme est plus puissante que les PC haut de gamme de l'époque et bénéficie de 4 threads ... et je parle du bas de gamme actuel

Pour en revenir au Xeon, il est évident qu'un 12c est juste incomparablement plus puissant qu'un i7, mais l'exemple des couturiers est très explicite, si tout le travail repose sur les épaules d'un et d'un seul ouvrier...

avatar BeePotato | 

@ pocketalex : « l'exemple des couturiers est très explicite, si tout le travail repose sur les épaules d'un et d'un seul ouvrier... »

Dans le cas présent, ça semble plutôt être qu’il y a trop d’ouvriers qui s’acharnent à se répartir la tâche équitablement entre eux et qui du coup passent plus de temps à essayer de collaborer qu’à réellement travailler.

avatar pocketalex | 

@BeePotato : oui mais alors pourquoi ? Et là j'en ai pas la moindre idée. Je ne sais pas comment est géré ce compilateur et comment il se débrouille pour répartir les calculs. Visiblement mal, parceque pour arriver à ce qu'un escargot comme le Mac Mini talonne un avion à réaction comme le Mac Pro, c'est qu'il y a une sacré couille dans le potage

Certains ici, sous couvert d'une pseudo science à balle-deux, vont nous expliquer que c'est la faute d'Intel, d'autres, haters à la petite semaine, nous démontrer qu'un PC low-cost à 300$ est "aussi bien" qu'un Mac Pro (Si, si, j'ai déjà lu ce genre d'inepties et pas qu'une fois)

Perso j'en sais rien de ces histoires de temps de compilations, mais je me garderais bien de conclure qu'un Xeon 12c est plus lent qu'un I5 mobile.

Il est certain qu'une ferrari sera plus lente qu'une Twingo.... si on ne sais pas manipuler la boite de vitesse et qu'on reste en première

avatar BeePotato | 

@ pocketalex : « oui mais alors pourquoi ? »

Ben notamment parce que cette tâche n’est pas parallélisable à l’infini et qu’il semble qu’elle se retrouve (dans ce cas précis) sur-parallélisée.

« Je ne sais pas comment est géré ce compilateur et comment il se débrouille pour répartir les calculs. Visiblement mal »

Mal pour cette tâche précise. Peut-être que pour la compilation d’un autre code, le ralentissement se produirait pour un nombre de threads plus élevé. Difficile à dire.
Et surtout, très difficile à estimer pour les concepteurs du compilateur. Du coup, il semble qu’ils ont choisi, plutôt que d’essayer de limiter le nombre de threads utilisés, ils en lancent autant que possible, laissant à l’utilisateur le soin d’ajuster en fonction de ce qu’il observe.

Il est aussi tout à fait possible qu’il n’y ait pas encore eu beaucoup de travail fait sur cet aspect du compilateur (pour un langage encore en pleine évolution, ce ne serait pas surprenant), et que se pencher sérieusement dessus permettrait d’améliorer sensiblement les choses — ou, au contraire, de déterminer (via une série de tests) qu’il y a une valeur « magique » du nombre de threads à ne pas dépasser, et l’utiliser une bonne fois pour toutes.

« parceque pour arriver à ce qu'un escargot comme le Mac Mini talonne un avion à réaction comme le Mac Pro, c'est qu'il y a une sacré couille dans le potage »

Sauf que le Mac mini utilisé n’était pas un escargot, mais la version équipée d’un Core i7 tout ce qu’il y a de plus respectable.
Comme d’autres l’ont expliqué, il n’est pas étonnant qu’à nombre de threads égal et pour une tâche de calcul de ce genre (un truc qui ne dure pas des heures), ce processeur aille un peu plus vite qu’un Xeon du Mac Pro. Et vu que, sur ce coup, le Mac Pro n’a pas l’occasion de se rattraper grâce à son nombre de cœurs, il ne peut pas briller. Enfin, jusqu’à ce qu’on essaye de faire tourner autre chose en même temps que cette compilation — là, on va vite souffrir sur le Mac mini, alors que ça roulera tranquillement sur le Mac Pro.

« Perso j'en sais rien de ces histoires de temps de compilations, mais je me garderais bien de conclure qu'un Xeon 12c est plus lent qu'un I5 mobile. »

Mais personne n’en est arrivé à cette conclusion, d’autant plus qu’il n’y a pas d’i5 mobile impliqué dans cette comparaison. ;-)

avatar pocketalex | 

"Mais personne n’en est arrivé à cette conclusion, d’autant plus qu’il n’y a pas d’i5 mobile impliqué dans cette comparaison. ;-)"

On est parfaitement d'accord, mais regarde attentivement les commentaires de ce post (et surtout des autres), tu risquerais d'être surpris de certaines interventions

Ce qui m'étonne aussi dans cette conversation, c'est les comparatifs sur des temps de compilation de quelques secondes

Un Xeon, c'est sur la durée des taches intensives que l'on voit sa différence. Lancez un rendu 3D ou un export vidéo avec des plug-ins optimisés (CPU multi et GPU) et le Mac Pro va laisser sur place le Mac Mini
Le temps gagné peut aller jusqu'à des "heures", d'où les seules phrases pertinentes que j'ai lu ici :

dgaultie : "Marre de ce MacPro bashing à la con : ca reste une excellente machine"
moon21 "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 HellTiger | 

@PocketAlex, BeePotato, dgaultie , moon21 et d'autres

Merci pour ces commentaires factuels sensés :)
Cela fait du bien à lire !

Je trouve triste que MacG se lance dans ce type d'articles au titre racoleur.
Ca ne fait pas très serieux

avatar C1rc3@0rc | 

@byte_order

Ce que tu dis est vrai dans la limite de 4 core, au-dela il faut des process qui sont tres specifiques et tres parallelisable.

On peut avoir 10 applications lancées sur son Mac, en temps normal il y en a 2 au maximum qui sont actives, les autres attendant l'action de l'utilisateur.
Et encore, dans la plupart des usages l'application active passe son temp a attendre. C'est ce qui permet a Intel de produire des processeurs dont les core passent leurs temps eteint et qui donnent une impression de reactivité avec le mode turbo et la mise en cache predictive.

L'analogie de @ antoninGR38 est tres bonne, et explique aussi pourquoi lorsqu'on multiplie les core ils fonctionnent d'autant moins vite: plus il y a de tricoteurs qui travaillent en meme temps plus il faut d'espace, plus il faut les alimenter et plus il y a de production de problemes: chaleur, mouvements, flux,...

Concrètement aujourd'hui utiliser plus de 4 core necessite des applications serveurs ou la machines doit traiter un flux soutenu de requetes sur de longues periodes. L'autre domaine c'est le calcul long et paralellisable. Bref des domaines loin du grand public.

Par contre avec la generalisation de la VR et des traitements du langage (et des big data) le besoin de puissance en parallele est en train de monter tres vite, et aujourd'hui la puissance manque autant en vitesse qu'en parallele. Alors pour l'instant on encloude, mais ça ne marche que tant que l'usage est tres restreint. Inevitablement il va falloir que les machines decuplent en puissance et deviennent massivement parallele. Le hic, c'est que le modele de l'informatique industrielle et commerciale est construit sur le séquentiel...

avatar byte_order | 

Dans la plupart des OS modernes, y'a désormais au moins toujours la pile de connectivité (réseau, bluetooth, etc) et les services en tâche de fond élaborés style iCloud, OneDrive, les notifications, les handoffs, etc, la pile USB vu que des composants internes sont souvent connecté sur ce bus eux aussi, un système d'indexation de contenu voire un système de reconnaissance de la parole qui tournent en tâche de fond. Ca en fait des tâches qui doivent tourner en parallèle sans impacter la réactivité perçue par l'utilisateur.

C'est parce que les quad-cores sont désormais répandus que ces fonctionnalités sont désormais non seulement possible sans conséquences néfastes pour l'utilisation habituelle, mais qu'elles sont disponibles de base désormais.

Il n'y a aucune raison qu'à l'avenir il n'y ai pas le même genre de besoin pour plus de tâches de fond sans impacter la réactivité pour l'utilisateur. Des IA qui analysent le comportement pour anticiper des assistances, déclencher des processus de protection, optimiser les données et leur organisation selon les usages propres de chacun, l'analyse profonde des échanges de données et l'activité des processus pour détecter les tentatives d'attaque, les comportements à risque, etc.

Ce type de fonctionnalités n'est pas réellement possible actuellement sur des dual ou quad-cores sans ressentir un impact trop notable.

Dans 10 ou 20 ans, quand tous le monde aura au minimum un octocore (c'est quasiment le cas pour les smartphones premium...) ces fonctionnalités s'ajouteront aux autres de base.

Je ne crois pas à un "seuil" de capacités qui serait suffisant pour tout le monde et pour longtemps. Toute l'histoire de l'informatique montre qu'on a toujours poussé toujours plus loin les capacités de calcul brut comme en parallèle, les bandes passantes d'accès aux données, etc.

Tout simplement parce que ce ne sont pas les usages actuels qui déterminent les capacités futures, mais les usages futurs.

> donnent une impression de reactivité avec le mode turbo et la mise en cache predictive.

C'est pas une impression, puisque qu'elle s'observe réellement. La nuance, c'est qu'elle s'obtient désormais sans imposer d'être gourmande en énergie en permanence pour cela.

> Concrètement aujourd'hui utiliser plus de 4 core necessite des applications serveurs
> ou la machines doit traiter un flux soutenu de requetes sur de longues periodes.

Jettez un oeil au code de VLC. Vous verrez à quel point ce type d'application pourtant grand public profite largement de plus de 4 cores si elle le peut.

Je pense que vous sous-estimez le nombre d'application qui, parce qu'elles reposent sur des librairies capables d'exploiter le parallélisme par exemple, peuvent tirer parti de plus de coeurs. Les jeux vidéos sont aussi très gourmands en la matière, et c'est très grand public (enfin, pas sur macOS faute de gpu correct, okay, mais bon, ça change rien au sujet).

> Inevitablement il va falloir que les machines decuplent en puissance et
> deviennent massivement parallele

Pas forcément.
Y'a un marché sur la location d'infrastructure "scalable" de calcul qui commence à naître. A terme, il n'est pas impossible qu'on loue de la puissance de calcul massivement parallèle comme on loue aujourd'hui 5 Go de stockage cloud par an, par mois, etc.

Les standards de programmation et la bande passante manquent encore pour le permettre au grand public, mais cela viendra. Une infrastructure de distribution dynamique de tâches est déjà au coeur de nombre d'applications modernes dans des entreprises, soit en interne soit louée. Un jour quelqu'un va se dire qu'on pourrait tirer un profit à en vendre au grand public aussi, qu'il manque juste des outils clients sur les OS grand public pour cela...

avatar bobdu87 | 

Pour savoir qui pompe bien c'est sur youporn qu'il faut aller ;)
Pour le reste, Apple a lancer swift qui est un très bon langage mais visiblement ça peine sévère ) la compilation...
Mais bon le mac pro étant mort ça interpelle encore quelqu'un?

avatar ddrmysti | 

"C'est bien gentil ce que vous nous racontez, mais il y a une grande partie (et même une large majorité à mon avis) des utilisateurs de MacBook Pro, iMac et Mac Mini qui ne savent même pas de quoi vous parlez"
Non.

Ce n'est pas parce que tu affiches ton ignorance que la large majorité l'est également. Et qu'à cela ne tienne, en quoi le fait que des gens soient ignorant devrait empêcher un site spécialisé en informatique de parler d'informatique pour se focaliser uniquement sur la consommation ?

avatar zoubi2 | 

@ddrmysti

"en quoi le fait que des gens soient ignorant devrait empêcher un site spécialisé en informatique de parler d'informatique pour se focaliser uniquement sur la consommation ?"

+1 Vous m'avez ôté les mots du clavier...

avatar ovea | 

@ddrmysti

Le problème de la programmation par interface graphique,
c'est que ce qu'on ignore … à tord,
c'est ce qui se cache en dessous la couche programmable.

Du programme par un langage,
on est passé à
l'art de programmer graphiquement une interface …

Est-ce que les outils théoriques des systèmes de réécriture ont migré vers des organigrammes fonctionnels représentants les flux d'informations ?

Pas si sûr !!!
C'est un fait d'incompréhension que de négliger l'équivalence entre un language et une interface en théorie de la programmation, pas un fait d'ignorance, sinon de l'antériorité du premier sur le second qui se voit moins bien implementé, pour le plus grand bonheur de ceux qui utilisent encore l'interface en ligne de commande ? … par exemple ?

avatar Bigdidou | 

@Dr. Kifelkloun

Ne te décrit pas plus béotien que tu n'es.
Sinon, tu as un coeur mais précisément avec deux threads : le coeur droit pour la circulation pulmonaire, le gauche pour la systémique.

avatar McDO | 

@eX0

Je suis d'accord sauf sur la partie gaming. Les jeux récents exploitent très bien le multi coeur. Et l'i7 offre de meilleure perf qu'un i5, surtout en monde ouvert.

avatar robrob | 

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 | 

@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 | 

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 | 

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 | 

@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 | 

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

avatar byte_order | 

Pas faux.

avatar BeePotato | 

@ 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 | 

Nan ca ne tient pas la route....

avatar BeePotato | 

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

Ben si, pourtant. :-)

avatar moon21 | 

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

avatar bobdu87 | 

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

avatar moon21 | 

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 | 

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 | 

@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 | 

J'admire la retenue de pocketalex....

avatar pocketalex | 

@zoubi2

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

avatar BeePotato | 

« 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 | 

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 | 

> 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 | 

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 | 

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 | 

Et elle avait quel processeur ta station Solaris?

avatar byte_order | 

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 | 

@ 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

CONNEXION UTILISATEUR