Malgré ses efforts, ARM n'a pas encore réussi à percer le lucratif marché des serveurs, sur lequel Intel règne sans partage.
Une nouvelle tentative de conquête de ce marché arrive chez Qualcomm.

La société annonce l'arrivée de processeurs dotés de 40, 46 et même 48 cœurs destinés aux serveurs Cloud. Les cœurs sont cadencés à 2,2 GHz (Turbo à 2,6 Ghz), ont une cache L3 de 60 Mo, un TDP de 120W et supportent jusqu'à 768 Go de DDR4 2667 MHz.
Le modèle le plus haut de gamme coûte 1995$ et aurait les mêmes performances que le Xeon Platinum 8180 (28 cœurs, 2.5-3.8 GHz, 205W).
La force de ces processeurs ARM serait leur consommation. Si Qualcomm annonce 120W, elle est le plus souvent maintenue sous les 65W avec des pointes à 100W et un mode de "veille" de seulement 8W.

Attention toutefois à ceux qui vont déjà rêver à un Mac 100% ARM. Si multiplier des cœurs est simple pour augmenter la puissance de puces, en avoir autant n'a de réel intérêt que dans des serveurs faisant tourner de très nombreuses applications (ou plutôt process) parallèlement en tâche de fond, pas sur une machine devant laquelle se trouve un unique utilisateur, sauf logiciels très très spécifiques.

Lien vers le billet original

C'est déja une vieille info, le processeurs sont des les serveurs AZUR qui font tournber entre autre office 365 et le cloud microsoft et tournent sur une version de Windows server compilé ARM. l'achitecture des serveurs est open source et permet de s'affranchir des grands constructeurs de serveurs (dont Apple ne fait plus parti)

Ils servent de tests pour la future machine windows, un PC portable avec processeur snapdragon de la même marque, très faible consommation, grosse autonomie.

mais qu'attends Apple pour passer en ARM ? Ils ont largement le savoir faire et je suis sur que de beaux protos tournent quelque part.

Que cela se fasse sans perdre 30% de ses clients Mac.

Pour ma part je ne pense pas qu'ils attendent, et qu'ils sont prêt à perdre beaucoup de leurs clients historiques si ça leur fait gagner d'autres clients.

Pour moi, ils ont déjà planifié l'arrivée d'ARM sur des ordinateurs et ils ont déjà une stratégie d'introduction, et ils savent déjà quelles caractéristiques et notamment quelles IP ils veulent avoir dans leur puce et que ni Intel ni AMD ne peut leur fournir.

Je pense que le NPU ainsi que la GPU qu'ils ont développé en interne (notamment avec son excellent support FP16 que Imagination Technologies ne voulait pas fournir), intégrés dan une puce d'ordinateur portable, sans compter leur propre processeur d'image et leurs encodeurs, ce sont des avantages extrêmement concurrentiels, même si il n'y avait pas ARM aussi et son incroyable efficacité par watt.

Ils ont aussi, depuis longtemps, les meilleurs controleurs mémoires jamais vu sur ARM (conçu en interne!), une faiblesse historique des design génériques.
Ils ont aussi leur propre contrôleur de mémoire Flash, parmi les meilleurs et évidemment basé sur ARM, et qu'ils pourraient carrément intégrer dans leur CPU ARM.

Pour mettre les choses en perspectives, Apple a la capacité de sortir une CPU basée sur l'actuel A11 (en 6-coeurs rapides par exemple, avec peut-être 2 coeurs "lents" en plus), qui soit plus performante en multi-thread que les CPU des MacBook Pro retina 15", dans le facteur de taille et de consommation du MacBook retina 12", et probablement pour moins cher qu'actuellement où les puces Intel qui sont dedans coutent plus de 300$ en haut-de-gamme.
Ça devrait faire réfléchir quand-même...

PS: quelqu'un ici, qui se reconnaitra, sera probablement d'accord avec moi qu'il faudrait surveiller les compagnies développant des IP pour l'interconnexion de coeur au sein de CPU ou GPU, car c'est la clé pour une montée de gamme en multithreading. Qualcomm semble avoir la technologie, mais vu le climat entre Apple et eux, ça serait surprenant que ça vienne de là.

Ce message a été modifié par iAPX - 13 Nov 2017, 15:04.

Je suis globalement d'accord avec toi d'autant plus qu'Apple a horreur de la concurrence, qui peut laminer les marges. Donc, il faut se démarquer pour vendre des produits avec des marges 5 ou 6 fois supérieures à celles des concurrents PC.
Maintenant, je pense que si Apple passe demain à ARM sans compatibilité, ils perdront tous ceux qui font tourner BootCamp ou Parallels, l'essentiel de ceux qui veulent du Linux à côté et aussi ceux qui ne pourront attendre le bon vouloir d'Adobe, de Microsoft, et des autres logiciels professionnels.
Le risque d'hémorragie est là avec une transition délicate sur 4 ou 5 ans. Même une compatibilité X86 comme le préparent MS et Qualcomm n'empêchera pas les gens cités de partir à cause des performances forcément en nette baisse. Sinon, il faut des puces ARM à 10 coeurs pour espérer faire de l'émulation X86 32 bits sans énormes ralentissements.

L'émulation x86 est une utopie, le niveau de performance en mono-thread ou même multithread des dual-core ne peut pas être atteint comme ça, il faut oublier.

Mais d'un coté nombre de logiciels ont déjà été porté en tout ou partie sur ARM, et ça inclus des éditeurs historiques comme Microsoft ou Adobe.
De l'autre coté, il y a un éco-système ARM incroyable, avec des spécialistes de l'optimisation ARM maintenant, prêt pour ça.
Il y a aussi des logiciels utilisant une VM, comm Java, je pense à NetBeans, PyCharm, etc. que j'utilise au quotidien et là, avec les capacité d'exécution incroyable des coeurs ARM pour Java, avec le sous-ensemble d'instruction Jazelle, ARM est mieux armé que du x86!!!
La plupart des logiciels que nous utilisons au quotidien n'ont aucune optimisation, ou ont des paths d'exécution principaux codé en haut niveau, qui ne demandent juste qu'à être recompilés, de la même façon qu'on est passé d'un modèle 32bits à 64bits en x86 avec beaucoup de logiciels n'ayant juste vécu qu'une recompilation.

Pour finir, last but not least, beaucoup, même un grande majorité n'utilisent quasiment que leur navigateur, au quotidien, avec du code déjà porté et optimisé pour ARM.

De toute façon, le passé l'a amplement démontré, Apple se fout complètement de ceux qu'elle laisse sur le bord de la route, du moment que ça sert ses intérêts!

PS: oui si ça arrivait, ou plutôt quand ça va arriver, ils vont laisser une bonne part des Pro dans la marde!

Ce message a été modifié par iAPX - 13 Nov 2017, 15:28.

Je serais curieux de connaitre le pourcentage de propriétaires de Mac qui utilisent vraiment BootCamp ou Parallels... Où peut-on trouver cela?

Ou VMware Fusion pour moi, avec de nombreuses VM sous Linux (usuellement Ubuntu Desktop ou Ubuntu Server suivant l'usage), mais pas que Linux.

Indispensable pour me permettre de faire tourner une batterie d serveurs en parallèle et mesurer les consommations de ressources, même quand je prends mon café
(mais ça marchera très bien avec des VM Linux Ubuntu pour ARM!)

PS: pour les controleurs de mémoire Flash Apple, ils sont en fait au-dessus des meilleurs controleurs disponible partout ailleurs, comme ce nouveau SSD avec un controleur Marvel, qui est littéralement écrasé par ce qu'on trouve dans les MacBook Pro depuis longtemps en écriture!

Ce message a été modifié par iAPX - 14 Nov 2017, 01:48.

Prix Intel ou prix Apple ?



Je pense plus à une cohexistence entre deux gammes, au moins au début.
Même s'il y a des bénéfices, la nécessité de changement n'est pas du tout la même qu'avec la transition PowerPC.

Prix Intel, avec plus de 50% de marge coté Intel, pour des puces qui outent largement moins de 100$ à produire, probablement du coté dr 50$.

Avec la marge Apple derrière, près de 40%, ça fait mal!

Il y a possibilité d'enlever près de 400$ au prix d'un Macbook retina 12" haut-de-gamme si Intel n'est plus dans le coût!

Je ne doute pas de l'utilité pour certains mais on parle de quoi là, 0.1% des utilisateurs de Mac? Peut-être moins?

@iAPX

Tu as essayé d'utiliser Docker à la place de tes coûteuses VM ?

Parce que ta mesure de perf... sachant que ta solution sera sûrement déployée à travers Kubernates et des Pods docker ....

Tu fais ce que tu veux, tu suis la mode, moi je n'en vois pas l'intérêt, je préfère penser par moi-même.

Tu sais pourquoi les VM existent?
À cause d'OS n'offrant pas de services permettant d'isoler correctement les tâches et avec une gestion moderne des droits (pas une des annés 60, allez un des années 70, comme en trouvait après dans Novell Netware).

Tu sais pourquoi Docker et d'autres existent?
Parce qu'on s'aperçoit que c'est évidemment trop lourd pour rien une VM par service/site/etc.

Résultats on a plein de VM, elle-même pouvant contenir plein de trucs séparés avec Docker ou d'autres, on a rajouté un layer en général au lieu de s'en débarrasser, tout ça parce que on tient à garder de vieux systèmes qui ont été conçu pour des CPU 16bits et de la RAM qui se mesure en Ko, pour un seul utilisateur à la fois, et dont on essaie d'étendre tant qu faire ce peut l'usage, alors que tout le modèle est inadapté aux capacités des ordinateurs modernes.

Comme on dit "We can solve any problem by introducing an extra level of indirection."

Et là des niveaux d'indirections ou d'abstractions, on en manque pas, on en a même tellement que tout ça se traine médiocrement

Je ne pense pas par moi même dans l'univers java... c'est clair, je fuis autant que je peux...

Mais c'est le truc de base aujourd'hui pour les gens qui font du service en masse... K8s and Docker

I like docker in my processs because I can build the Ubuntu version of the application without using too much resources, a lot of ready images and containers available quickly, launched and killed in a snap

Ce message a été modifié par Hebus - 14 Nov 2017, 16:13.

Tu le dis bien "c'est le truc de base", je dirais que tout le monde fait pareil, suit les mêmes voies, c'est même dogmatique à un point

Et, à la fin, je l'ai vu à de nombreuses reprises, on termine avec quelques requêtes complètes/seconde et par core physique (avec session et suivi et tout, pas en envoyant du pré-maché caché), par exemple avec Drupal 8 qui atteint des sommets, mais même des trucs qui devraient être beaucoup plus performants ne sont pas au niveau où ils devraient être, un gachis immense.

10 000 requetes/seconde et par core physique sont largement possible (et même bien plus!), avec session, contenu individualisé, sans RIEN cacher (on gagne du temps là, vraiment!), avec des technologies modernes qui exploitent correctement le hardware moderne, en tournant résolument le dos aux vieilleries historiques, et programmable en langage de haut-niveau!
Ça ouvre la voie à des architectures plus légères (ARM au hasard), et à des hébergements de sites où on peut en mettre beaucoup beaucoup plus sur le même serveur physique.

Mais pour tout ça, comme je l'écris, il faut se débarrasser des préjugés, des dogmes, et surtout des vieilleries qui sont là historiquement, "parce que" ou "tout le monde fait comme ça"...

Ho merde je suis passé en anglais ...

Ha ... va convaincre un décideur qu'il faut peaufiner ...

Quand tu fais une remarque de l'ordre de l'efficacité et qu'on te répond... pas grave on mettra plus d'instances... et l'entropie mon gars ?

Par contre tes 10000/s ... ça dépend ce que ton serveur réalise, nous si on traite par cœur 300 requêtes de taille classique en 1 seconde on est content ... bon c'est du calcul assez couteux.

Je ne sais pas c que tu fais, ni combien de coeurs physiques sont utilisées pour 300 requêtes par secondes

Je sais juste qu'on peut obtenir largement plus de 10 000 requêtes par secondes et par coeur, sur du contenu classique, en regénérant tout à chaque fois pour chaque utilisateur, sans rien cacher (surtout!) pour des sites de e-commerce par exemple. Ça fait quand même autour d'un million d'instructions exécutées, la majorité pour le rendering du HTML malheureusement!

Ce message a été modifié par iAPX - 14 Nov 2017, 16:26.

En gras ...

40 millions d'instructions 64bits par requête?
Donc tous les services intégrés sur un serveur (incluant DB/persistance et caches foireux)? Ou tu as oublié de compter ceux-ci (classique)?

SeLoger.com a par exemple démarré sur un Pentium-100, je ne m'imagine pas ce qu'ils se serait passé si on avait eu besoin d'exécuter 40 millions d'instructions par requête

J'ai mis du temps, mais faut bien que je vienne mettre mon grain de sel :-)

D'abord, j'ai trouvé ce blog qui compare un de ces processeurs Qualcomm avec les processeurs Intel. Je trouve cela beaucoup plus intéressant, et il semble que la personne soit assez neutre : Qualcomm/ARM vs Intel

Quelques remarques :
- Le haut de gamme a 48 coeurs et est donc fait pour le calcul massivement parallèle, un peu comme les Xeon Phi. Et si les Xeon Phi étaient un succès commercial, ça se saurait... Bref, c'est pour du calcul massivement parallèle et il faut donc avoir le workload qui va avec :-)
- Sur un coeur, le processeur Intel est toujours devant
- Avec OpenSSL et tous les coeurs, c'est soit Qualcomm, soit Intel devant, selon l'algo utilisé. Avec Gzip et tous les coeurs, c'est Qualcom qui est devant. Avec Go, le Qualcomm s'écroule comme une *?#$ à cause d'un logiciel mal optimisé.

J'aimerais avec des benchmarks avec des nombres flottants et là, j'ai très peur pour la puce ARM.

En tout cas, spéculer sur l'intérêt des puces ARM sur un portable à partir de ce genre de benchs, c'est comme spéculer sur la qualité du moteur des Clio en regardant ce que fait Renault en Formule 1. C'est absurde (attention, je n'ai pas dit qu'il était absurde de mettre du ARM dans un portable).

Ce message a été modifié par DonaldKwak - 14 Nov 2017, 17:58.

A supprimer

Ce message a été modifié par Hebus - 14 Nov 2017, 17:39.

Exactement ce que je suis en train de réaliser dans mon coin, les workloads ne peuvent pas être les mêmes à cause de l'inefficacité en terme d'IPC et de la fréquence plus basse, qui concourent à augmenter les latences (et ça c'est le début de la fin!).

Certains comme @Hebus doivent avoir des sites web bien lourds pour consommer autant de cycle, probablement avec raison, mais pour la plupart des sites qui font moins de 1000 requêtes/secondes (99% des sites, voir plus!), de l'ARM à 1Ghz devrait suffire en monocore!!!