L'iPhone 7 Plus talonne le MacBook Pro 13" "Skylake"

Florian Innocente |

Lancez Geekbench sur le nouveau MacBook Pro d’entrée de gamme et sur un iPhone 7 Plus, et l’on pourrait quasiment confondre les deux au vu (d’une partie) des résultats.

Tout cela doit être nuancé car les écarts ne sont pas homogènes, mais ces comparaisons sont toujours intéressantes à chaque renouvellement profond des gammes.

Sur les tests bruts exécutés avec un seul cœur, le portable équipé d’un Intel “Skylake” Core i5 de sixième génération est devant l’A10 d’Apple d’une courte tête. Il obtient un score de 3 689 contre 3 503 pour l’iPhone. Par contre, en multi-core, le chiffre est nettement à l’avantage du MacBook Pro avec 7 190 contre 5 683.

Dans les deux cas, ce sont des processeurs double cœur, un 2 GHz pour le Mac et un 2,34 GHz pour l’iPhone (dans les faits l’A10 en a quatre, deux principaux et deux plus petits qui ne sont utilisés que pour des tâches plus légères et ils ne fonctionnent jamais les quatre ensembles).

Les autres MacBook Pro 13“, ceux équipés d’une Touch Bar, utiliseront un processeur dual core cadencé à 2,9 GHz (options à 3,1 ou 3,3 GHz), ce qui devrait rebattre les cartes. Sans oublier les 15” qui auront des Core i7 Quad à 2,6/2,7 et 2,9 GHz.

Dans les tests simple cœur, l’exécution de quelques fonctions mathématiques en particulier donne l’avantage au portable, de même que la bande passante de la mémoire vive. Mais ailleurs, les deux architectures semblent marcher sur une même ligne et les différences entre elles sont ténues.

On rétorquera, à raison, que des processeurs Intel, comme ceux que l’on trouve dans les Mac Pro, restent plus performants et endurants sur des tâches lourdes ou capables d’être distribuées entre plusieurs processeurs. C’est une chose d’être excellent en sprint, c’en est une autre d’être aussi très rapide et régulier sur plusieurs tours de piste.

Néanmoins, dans l’environnement Apple, ce ne sont plus les Mac Pro qui font office de mètre étalon. On peut aller jusqu’à dire que le nouveau MacBook Pro 15" est en quelque sorte le successeur de la station de travail (en attendant d’être démenti, qui sait, par un renouvellement de la gamme des cylindres tombé du ciel).

Source : Apple

On a pris l’habitude depuis quelques générations de processeurs Intel pour les portables, à ce que les performances ne progressent que modérément. Tout l’inverse des processeurs Ax d’Apple qui bondissent toujours plus loin à chaque renouvellement annuel, sans sacrifier pour autant l’autonomie sur l’autel de la vitesse. Entre l’A8 de l’iPhone 6 qui n’est pas si vieux et l’A10 d’aujourd’hui, le pic de vitesse a été multiplié par 2.

Si l’avenir du Mac passe par les portables — et qui en doute aujourd’hui ? — on peut vraiment se demander jusqu’à quand Apple acceptera d’avoir la feuille de route de ses portables dépendante des sauts de puce d’Intel.


avatar Hideyasu | 

Va surtout falloir comparer avec un A10x, ca sera pas la même chose en multi je pense.

Mais dans 3-4 ans on rigolera devant la meme comparaison Mac/iPhone :)

avatar melen | 

Que donne la comparaison iPhone 7 et MacBook Retina 12" ?

avatar macouille007 | 

En toute logique les puces Arm d'Apple vont exploser les i7 d'ici 5-6ans les bénéfices on les connais déjà, consommation électrique en baisse, les puces chauffe moins donc dans un avenir proche on pourra dire adieu à ces audieux ventilateur. Bref le meilleurs des monde! Après faut voir l'intégration software, si Apple copie IOS sur mac ca sera bien dure...

avatar Stardustxxx | 

@macouille007
D'après quelle logique ?
D'ici 5 a 6 ans, la loi de Moore sera morte, donc les gains sur Arm ou x86 devront passer par autre chose.

avatar larkhon | 

du coup le Macbook Retina en prend pour son grade niveau perfs ?

avatar 0MiguelAnge0 | 

Ouais, le successeur de la station de travail avec un bordel ne supportant pas les API Nvidia et pour cause...
Merci pour la belle poilade...

Par contre niveau tarif, on est d'accord...

avatar Hideyasu | 

Faut pas oublier non plus que les A d'Apple sont conçus pour être utilisé sur téléphone.
Si ils conçoivent un CPU pour ordinateur ca sera pas la même chose à mon avis (surtout en puissance, un ordinateur est moins limité qu'un iPhone).

Donc dire que le Xeon explose un Arm iPhone 7, encore heureux j'ai envie de dire, mais ça n'enlève pas la capacité de l'Arm de prendre le relai dans les années à venir

avatar lezardon | 

Bonjour ! Est ce que l'iphone pourrait remplacer le mac mini un jour ?

avatar roquebrune | 

est ce que ARM est utilise dans les iphones 7 et 7+ ? ou l'ipad pro ?

avatar Rez2a | 

@roquebrune

Oui, depuis le tout premier iPhone en fait, mais ce n'est que depuis le premier iPad et l'iPhone 4 que Apple a pris la main sur la conception de leurs propres processeurs ARM (là où les constructeurs de téléphones Android utilisent des processeurs ARM "génériques" qui équipent des téléphones de constructeurs différents).

On pourrait même comparer la position de Apple sur les ordis et celle de Samsung sur les téléphones par exemple : lorsque Intel prend du retard sur son nouveau processeur, Apple se retrouve en retard pour ses ordis aussi. Lorsque le nouveau Exynos n'est pas au niveau et équipe quand même le nouveau Galaxy, et bien il se retrouve à la traîne et c'est pas la faute de Samsung.

avatar Stardustxxx | 

@Rez2a
"Lorsque le nouveau Exynos n'est pas au niveau et équipe quand même le nouveau Galaxy, et bien il se retrouve à la traîne et c'est pas la faute de Samsung."

Ce n'est pas la faute de Samsung, et pourtant Samsung conçoit et produit l'Exynos...

avatar Rez2a | 

@Stardustxxx

Ah oui là j'ai bien dit n'importe quoi, j'ai confondu avec les Snapdragon, désolé.

Pour le reste, je maintiens que les modifications à effectuer au niveau du code seront minimes voire inexistantes pour la majorité des développeurs, et pour les éditeurs d'applis pro qui utilisent certainement un paquet de code bas niveau genre Adobe & cie, ça ne fait aucun doute que Apple leur laisserait démarrer la migration avec quelques mois d'avance.

Enfin, pour l'incompatibilité avec les GPU AMD/Nvidia, pour moi ça ne fait aucun doute que Apple en profiterait aussi pour amener ses propres GPU sur ordi ; je doute vraiment qu'ils aient porté Metal sur macOS pour faire gagner quelques % de perf aux 2-3 éditeurs qui jouent le jeu pour l'instant.

Encore une fois c'est toujours une hypothèse et Apple pourrait ne jamais passer à l'ARM, mais pour moi y a trop de pions placés à l'avance pour que ça ne veuille rien dire, en particulier Bitcode et Metal. Par contre j'ai jamais parlé de remplacer les Xeon des Mac Pro par des A10 Fusion, ça paraît évident que si ils attaquent, ça va être avec le MacBook.

avatar Stardustxxx | 

@Rez2a
Cela depend de ton appli, mais si en théorie la compilation multiplateforme est trivial, en pratique c'est autre chose. Il y a beaucoup de paramètre en jeu.
Rien que sur iPhone, la resolution de l'iPhone dépend du model, tu dois donc adapter ton code en fonction du device.
Et puis, tu as les bugs des compilateurs et le support qu'ils offrent (gcc vs clang vs vs).

Les gravité des modifications a apporter va surtout dépendre de la complexité de l'appli.

Metal n'apporte pas grand chose de plus que les technos équivalente : Vulkan, Direct 12.
Et puis les GPU utilisé par Apple sont des PowerVR. Les gens ont peut-etre oublié mais cette technologie a existé sur PC il y a un moment (fin 90), et cette architecture s'est fait défoncé par nVidia et AMD, et PowerVR s'est concentré sur le mobile ou cette architecture a des avantages.

Je ne savais pas que les GPU nVidia étaient incompatibles avec ARM... Et pourtant il y a des chips Tegra.

avatar Rez2a | 

@Stardustxxx

Là par contre je ne te suis plus, l'adaptation des interfaces aux différentes résolutions des iPhone se fait à l'exécution, sûrement pas à la compilation. Un bundle pourra être différent entre un iPhone 7 et un iPhone 7 Plus par exemple, mais ça sera uniquement au niveau des assets, pas au niveau du code compilé.

avatar Stardustxxx | 

@Rez2a
Tu assumes qu l'interface sera identique quelque soit la résolution.
Ce n'est pas forcément le cas.

Tu veux un autre arguments : l'aspect ratio de l'écran.
Ou sinon tu as du code conditionnel en fonction des capacités de ton device : code Siri, code touchId...

Bref, l'hétérogénéité de l'écosystème fait que a un moment tu vas devoir adapter ton code pour une raison x ou y.

avatar Rez2a | 

Je comprends a quoi tu fais référence mais je ne vois pas en quoi le compilateur en est responsable.

Typiquement, faire crasher une appli iOS codée en Obj-C c'est simple : tu utilises une méthode introduite dans iOS 10 et tu fais tourner ça sur un iPhone sous iOS 9, ça va planter à l'exécution.

Tout au plus Apple à optimisé le compilateur avec Swift : ça va refuser de compiler si t'utilises une méthode iOS 10 et si t'as pas prévu le check pour iOS 9. Mais c'est une optimisation liée au langage, pas à l'archi.

Niveau architecture en revanche, c'est la même chose : que tu fasses tourner ton appli sur iPhone (donc avec un exécutable compilé pour ARM) ou sur le simulateur sur ton ordi (avec un exécutable compilé pour x86), ça va crash de la même manière.

Le code conditionnel va rentrer en jeu au moment de l'exécution, et la magie de LLVM/Clang fait que maintenant ça t'empêche de compiler dans la plupart des cas avec Swift. Mais c'est par sécurité, pas parceque c'est impossible techniquement de compiler ça. Et il s'en fout encore plus que tu veuilles faire tourner ça sur un ARM ou un x86.

Après je dis pas, quand tu codes en bas niveau, y a des parties que tu pourras réécrire pour gérer les 2 archis si ça arrive un jour. Mais dans la grande majorité des cas, le compilateur est capable de faire le taf pour toi.

Il faut vraiment pas sous estimer Apple et leur expérience des transitions d'architectures, encore moins maintenant qu'ils ont la main sur l'IDE, le langage, le compilateur et la distribution.

avatar jojostyle94 | 

J'imagine la transition x86 vers Soc Apple assez proche. Et je ne voit pas pourquoi elle serait compliquée avec l'expérience qu'ils ont à propos de l'iPhone. Et je ne vois pas pourquoi non plus des personnes seraient frustrées vu que les performances seront là.

avatar RBC | 

Peut être pas si proche que ça mais personne ne sait ce qui existe dans les labos "secrets" d'Apple et c'est sûr qu'il y existe déjà des déclinaisons desktop des Ax et vu la puissance des derniers iPhones on peut deja se dire que ça va carburer sévère ! Un gros A10 ou un D1 qui comprendrait 5 (A10) par exemple voir plus exploserais la plupart des i7 voir même des Xéon d'Intel et si la puissance est décuplée ça sera encore plus facile pour virtualiser les anciens systèmes...

avatar SartMatt | 

" Un gros A10 ou un D1 qui comprendrait 5 (A10) par exemple voir plus exploserais la plupart des i7 voir même des Xéon d'Intel "

1 A10 arrive tout juste dans quelques benchs théoriques (pas en situation réelle, avec des vrais applis conçues pour exploiter pleinement les capacités d'un CPU x86, et notamment les instructions complexes qui ont été ajoutées au fil des versions) à approcher en monothread un i7 parmi les plus lents disponibles.

Dès qu'on passe à en multithreads, le petit i7 à deux cœurs creuse l'écart.

Et toi, tu imagines qu'en mettant 5 A10, donc en faisant une configuration qui nécessite d'emblée beaucoup de threads pour être exploitée correctement, ça arriverait à dépasser des i7 à 4 cœur et des fréquences 50 à 100% plus élevées que le petit i7 (donc au final, une puce 3 à 4 fois plus rapide que l'i7 du MBP en multithread) du MBP 13" ?

Accessoirement, faut quand même pas oublier qu'il y a encore plein d'applications qui ne savent pas profiter d'un grand nombre de cœurs (donc en pratique, ce sera souvent beaucoup plus rapide pour une même puissance brute d'avoir 4 cœurs plutôt que 10) et que même dans les applications exploitant énormément de threads, avoir plein de petits cœurs n'est pas forcément optimal par rapport à quelques gros (typiquement, les solutions ARM à plusieurs dizaines de cœurs pour serveurs, elles rivalisent avec les Xeon quand le serveur est à saturation, mais elles s'écroulent quand le serveur n'est pas saturé, parce que la latence est beaucoup plus grande : elles peuvent traiter autant d'opération que le Xeon à pleine charge, grâce à la forte parallélisation, mais le temps de traitement unitaire des opérations atomiques, qui va déterminer les performances à faible charge, est plus long, les cœurs étant unitairement moins performants).

Pages

CONNEXION UTILISATEUR