Puce Snapdragon X Plus

Plus moins bien

Qualcomm dévoile son Snapdragon X Plus et trois variantes du modèle Elite

Puce Snapdragon X Plus

Abonnez-vous pour tout dévorer et ne rien manquer.

Déjà abonné ? Se connecter

Abonnez-vous

Qualcomm a levé le voile sur son Snapdragon X Plus, une version moins puissante que l’Elite, mais également moins onéreuse. Alors que cette ligne de puces doit permettre enfin l’avènement des machines Windows sur puces Arm, faisons un rappel sur les enjeux.

C’est peu dire que des puces Arm performantes sont attendues dans le monde Windows. Difficile d’oublier les tentatives sur Windows RT et Windows 10. Depuis, des machines existent bien – notamment une déclinaison de la tablette Surface – mais le problème est à chaque fois le même : les performances.

On le sait, quand une application arrive sur Windows on Arm dans une version compilée spécifiquement pour cette architecture, les performances font un énorme bond. Google l’a rappelé récemment pour son navigateur Chrome, qu’il a pris le temps (c’est un euphémisme) de peaufiner. La firme de Mountain View s’est probablement dit qu’il n’était pas question de rater le coche sur la prochaine génération d’ordinateurs portables et tablettes devant embarquer les Snapdragon X.

Dans le cas d’une application non compilée pour Arm, c’est l’émulation x86 qui prend le relai. Et là, le résultat est très différent, particulièrement dans les applications lourdes. La couche d’émulation fournie par Microsoft n’est pas aussi efficace que Rosetta chez Apple. Bien que l’arrivée des puces de Qualcomm soit très attendue, elles ne règleront pas ce point d’un coup de baguette magique.

Et voilà le Snapdragon X Plus

Il y avait surtout deux informations à retenir de la présentation de Qualcomm. D’une part, l’arrivée d’un modèle Plus, moins puissant que le modèle Elite et qui doit alimenter des machines plus accessibles.

Le Snapdragon X Plus disposera de 10 cœurs (tous de type Oryon), dont 6 performants (P) et 4 efficaces (E), tous fonctionnant à 3,4 GHz. La mémoire cache est de 42 Mo, comme sur le Snapdragon X Elite.

La puce, gravée en 4nm, peut être accompagnée d’un maximum de 64 Go de LPDDR5X. La partie GPU, de type Adreno, n’est pratiquement pas détaillée. Tout juste, sait-on qu’elle doit délivrer une puissance de 3,8 TFLOP et accueillir jusqu’à trois écrans 4K en 60 Hz, deux écrans 4K en 120 Hz ou un écran 5K en 60 Hz, tous en HDR10.

La puce intègre bien sûr un NPU (Neural Process Unit) dont la puissance est de 45 TOP, selon Qualcomm. Au vu des ambitions de toute la tech sur l’intelligence artificielle, ce type d’information pourrait avoir bientôt autant d’importance que le CPU et le GPU.

Comme avec le Snapdragon X Elite, on retrouve le codage/décodage matériel pour l’AV1, le Wi-Fi, le Bluetooth 5.4, la 5G ou encore le double ISP 18 bits.

Trois variantes du Snapdragon X Elite

On s’en doutait, Qualcomm l’a confirmé : sa puce la plus puissante existera en plusieurs versions. Pour les différencier, l’entreprise propose une nomenclature qui n’a rien d’évident :

Qualcomm a donc fait l’impasse sur des noms simples au profit de référence comme « Snapdragon X Elite X1E-84-100 ». Les deux premières informations sont simples : 1 signifie « première génération » et E « Elite ». Vient ensuite un numéro pour indiquer la puissance générale. Dans le cas présent, 84 est le plus élevé. Quant à la dernière information, elle est « réservée » et n’a pour l’instant aucune utilité.

Nous avons résumé les principales informations dans le tableau ci-dessous, pour bien montrer les différences entre les trois variantes de la puce Elite et la Plus. On remarque que la mémoire cache, la puissance du NPU et le type de mémoire gérée sont invariables. Les seules réelles différences que l’on voit sont dans la capacité à augmenter la fréquence de la puce quand seuls un ou deux cœurs sont utilisés (Turbo) et l’augmentation de la fréquence pour le modèle 84.

Quelles performances et autonomie ?

Qualcomm a beau donner des indications, on ne saura réellement ce que ces puces ont dans le ventre qu’à la sortie des machines les exploitant. Sur la partie GPU par exemple, le modèle Snapdragon X1E-84-100 – donc le plus gros – annonce 4,6 TFLOP. C’est à peu près la puissance d’une puce M3 d’Apple. Il n’y a donc pas à rougir. Mais toutes les autres variantes de la puce sont à 3,8 TFLOP, soit environ la puissance d’un M2.

Si nous comparons les puces Snapdragon X Elite et Plus avec des puces Apple, ce n’est pas le cas de Qualcomm. L’entreprise établit ses comparaisons avec Intel et AMD. Ce qui a du sens : bien que les nouvelles puces laissent envisager des appareils légers, assez performants et dotés d’une bonne autonomie, Qualcomm n’est pas en compétition avec Apple. On reste dans l’univers Windows, où les processeurs d’Intel et AMD règnent en maîtres.

Sur l’autonomie, justement, c’est le grand flou. Qualcomm ne donne pas de précisions, même si l’on peut s’attendre à des TDP entre 15 et 30W selon le modèle de puce.

Quel type d’appareil ?

On attend bien sûr de voir les premiers ordinateurs équipés de ces nouvelles puces. Sans trop réfléchir, on se doute que l’on va surtout voir des portables, hybrides ou non, ainsi que des tablettes. Ce sont les appareils les plus à même de recevoir en premier des puces taillées pour l’efficacité, avec probablement de grands écarts avec des machines concurrentes équipées de processeurs AMD ou Intel.

La gamme tarifaire dépendra des constructeurs et de la manière dont ils envisagent ces possibilités. On peut tabler sur des ordinateurs portables fins, légers et mettant l’accent sur l’autonomie autour des 1 000 à 1 200 euros. Il y aura sans doute des modèles plus chers avec le plus gros Elite, mettant l’accent sur les performances.

Les jeux permettront d’y voir plus clair sur les performances graphiques. On pourrait se retrouver avec des ordinateurs dépassant les 1 500 euros et aux performances peu adaptées pour les titres récents. Là où, dans cette gamme de prix, on trouve des modèles puissants, avec des GPU dédiés. Mais la puissance graphique n’est qu’un critère parmi d’autres.

Commentaires (12)


D’après SemiAccurate, Qualcomm a pipé les benchs, et les OEM n’atteindraient en situation réelle que 50% des perfs promises par Qualcomm :

https://www.semiaccurate.com/2024/04/24/qualcomm-is-cheating-on-their-snapdragon-x-elite-pro-benchmarks/

Si cela est avéré, c’est encore un moment « PC on ARM » qui fera pschit …
Comme tout système ouvert, Windows est sur un vrai défi.. Déjà abandonner le 32b en était un, mais passer sur ARM sera encore plus complexe.
Il y a tellement d’applications et d’éditeurs sur Windows que la marche forcée (un peu en mode Apple) n’est pas vraiment possible.

Pondre un ultrabook, en ARM qui est juste destiné à faire du Office et Web principalement (donc sur des applis ARM), on devrait quand même arriver vite à de bonnes perfs et une bonne autonomie. Je suis curieux de voir ces Snapdragon dans une machine.
Le temps d’arriver à un émulateur X86 performant par contre je doute que ce soit si simple, aussi puissant soit les processeurs ARM. A mon avis Windows va avoir le c entre deux chaises un très long moment…

Ce serait intéressant d’avoir une notion de tarifs, je sens bien le prix moins élevé qu’un i7 mais la machine 2 fois plus cher à l'achat :nonnon:
Des émulateurs déjà pas trop mal il y en a (genre fex-emu).

Mais un problème sous-jacent, c'est que pour le moment sans extension spécifique, émuler un x86 nécessite d'utiliser des pages de 4ko de mémoire.
Or, c'est aussi contre performant actuellement.

Donc:
* soit on peut émuler du x86
* soit on gagne (jusqu'à 15%) en perfs.

Wosgien

Des émulateurs déjà pas trop mal il y en a (genre fex-emu).

Mais un problème sous-jacent, c'est que pour le moment sans extension spécifique, émuler un x86 nécessite d'utiliser des pages de 4ko de mémoire.
Or, c'est aussi contre performant actuellement.

Donc:
* soit on peut émuler du x86
* soit on gagne (jusqu'à 15%) en perfs.
J'ai du mal à comprendre ton affirmation.

On parle ici d'émuler un du x86 non pas pour faire tourner un OS dessus mais simplement une application. J'ai l'impression que les pages de 4ko sont un non sujet ici, mais il y a peut-être un truc qui m'échappe. Pour moi, la gestion des pages, c'est l'OS qui le fait avec la gestion de la MMU et ensuite des exceptions qui font charger la page si les données ne sont pas en mémoire. Une application ne gère pas elle-même la pagination et donc l'émulateur n'a donc pas non plus besoin de la gérer.

fred42

J'ai du mal à comprendre ton affirmation.

On parle ici d'émuler un du x86 non pas pour faire tourner un OS dessus mais simplement une application. J'ai l'impression que les pages de 4ko sont un non sujet ici, mais il y a peut-être un truc qui m'échappe. Pour moi, la gestion des pages, c'est l'OS qui le fait avec la gestion de la MMU et ensuite des exceptions qui font charger la page si les données ne sont pas en mémoire. Une application ne gère pas elle-même la pagination et donc l'émulateur n'a donc pas non plus besoin de la gérer.
Une application peut demander recourir à des pages plus grandes sur l'x86_64 tel que 2 MiB et 1GiB par exemple. Évidemment l'OS doit pouvoir gérer ces situations.
Sous Linux : Huge Page.

En pratique, quand j'ai besoin, j'utilise mmap et madvise. L'intêret est de ces grandes pages est de pouvoir réduire la pression sur le TLB, un cache mémoire en charge de faire le lien entre mémoire virtuelle et physique. Pour certaines applications (notamment BDD, traitement de fichiers de grands volumes ou encore calculs), ce genre d'optimisations permet d'améliorer les performances de, facilement, quelques dizaine de pourcents comme indiqué par @Wosgien.
Modifié le 25/04/2024 à 18h50

Historique des modifications :

Posté le 25/04/2024 à 18h49


Une application peut demander recourir à des pages plus grandes sur l'x86_64 tel que 2 MiB et 1GiB par exemple. Évidemment l'OS doit pouvoir gérer ces situations.
Sous Linux : Huge Page.

En pratique, quand j'ai besoin, j'utilise mmap et madvise. L'intêret est de ces grandes pages est de pouvoir réduire la pression sur le TLB, un cache mémoire en charge de faire le lien entre mémoire virtuelle et physique. Pour certaines applications (notamment BDD, traitement de fichiers de grands volumes ou encore calculs), ce genre d'optimisations permet d'améliorer les performances de, facilement, quelques dizaine de pourcents.

fred42

J'ai du mal à comprendre ton affirmation.

On parle ici d'émuler un du x86 non pas pour faire tourner un OS dessus mais simplement une application. J'ai l'impression que les pages de 4ko sont un non sujet ici, mais il y a peut-être un truc qui m'échappe. Pour moi, la gestion des pages, c'est l'OS qui le fait avec la gestion de la MMU et ensuite des exceptions qui font charger la page si les données ne sont pas en mémoire. Une application ne gère pas elle-même la pagination et donc l'émulateur n'a donc pas non plus besoin de la gérer.
Tu parles du cas de la recompilation d'appli. Mais en général la recompilation d'appli s'accompagne de la recompilation des librairies qu'elle charge.
Ces librairies peuvent être assez bas niveau.

Il y a des applis "bateau" qui peuvent être recompilées sans problème, mais elles sont très rares. Même des librairies XML ont du mappage de fichier en RAM, ce qui nécessite un accès à l'OS. Et beaucoup sont compilées avec des limites de 4ko "en dur", tout simplement parce que la taille de page est indiquée dans les scripts de compilation (en se disant que si on devait aller sur un autre OS, il "suffirait" de recompiler).

La plupart des émulateurs haut-niveau ont tout de même un lien fort à l'OS, ou alors il faut réécrire tous les appels - et même là, rien n'est garanti, on peut facilement tomber sur un bout de code qui alloue 4ko et détecte de lui-même les exceptions lors d'un dépassement de page (anti-virus ... anticheat?)

Et détecter les dépassement de page "à la main" parce que le système a des pages plus grandes est très coûteux.

Bref, sans des pages de même taille, ou sans un CPU qui peut gérer en même temps des pages de 4k et 16k/64k, aucune garantie possible de compatibilité des softs.
Après lecture des commentaires, et bien, j'ai pas compris.
Quelqu'un a une ou des vidéos qui vulgarise bien l'interaction cpu, os, pages, mémoire, (et un peu compilation, mais sur ce dernier, je commence à être en terrain connu) ? Siouplé :)
Il faut regarder comment la mémoire virtuelle est gérée. Et côté CPU, regarder ce qu'est le TLB.

En fait, l'OS présente un espace mémoire à chaque appli. Cet espace mémoire semble contigu, mais l'OS le découpe en morceaux de 4k (lié à ce que le CPU sait gérer). Chaque fois que l'application veut lire en mémoire, il faut vérifier dans quel morceaux de 4k cela tombe, si ce morceaux est en mémoire ou sur le disque, si l'application a le droit d'y lire, écrire, ...

Donc quand on parcourt un tableaux, tous les 4k l'appli est interrompue pour que l'OS vérifie tout cela, fasse en sorte que la mémoire soit là, ...

Quand on fait du traitement de données et qu'on tape partout dans la RAM, on est interrompu plein de fois, mais heureusement le CPU a des mécanismes pour que les pages les plus récentes soient plus rapides à accéder.

C'est normalement transparent pour une appli lambda.


Le problème, c'est que 4ko, c'est trop juste maintenant. On a des mécanismes pour avoir des pages plus grandes, mais c'est très spécifique à certaines applis et ça demande de taper dans l'OS: on est moins portable.

Une solution serait de passer à des pages de 16ko, 64ko. C'est possible sur certains ARM, à ma connaissance pas sur PC, et c'est déjà un boost pour le traitement (y compris pour le javascript).

Par contre, quand on fait de l'émulation, certaines fonctionnalités pointues sont liées à ces pages, et les limites sont souvent compilées dans le code, impossibles à retrouver. Donc un soft très optimisé comme un jeu, une BDD, risque de ne pas fonctionner sur un OS dont les pages sont de taille différente.
Emuler la détection de ces limites est extrêmement coûteux (cela revient à checker logiciellement chaque accès mémoire...)

Pour résumer:
* Un passage du x86 à l'ARM avec la même taille de page: on peut émuler sans trop se poser de questions
* Un passage du x86 à l'ARM avec un taille de page inférieure: on peut émuler sans trop se poser de questions, mais on perd en perfs
* Un passage du x86 à l'ARM avec un taille de page supérieure: on peut émuler des trucs simples ... mais il y a des limites, des risques, mieux vaut se focaliser sur le natif et les runtimes type Java/C#

Wosgien

Il faut regarder comment la mémoire virtuelle est gérée. Et côté CPU, regarder ce qu'est le TLB.

En fait, l'OS présente un espace mémoire à chaque appli. Cet espace mémoire semble contigu, mais l'OS le découpe en morceaux de 4k (lié à ce que le CPU sait gérer). Chaque fois que l'application veut lire en mémoire, il faut vérifier dans quel morceaux de 4k cela tombe, si ce morceaux est en mémoire ou sur le disque, si l'application a le droit d'y lire, écrire, ...

Donc quand on parcourt un tableaux, tous les 4k l'appli est interrompue pour que l'OS vérifie tout cela, fasse en sorte que la mémoire soit là, ...

Quand on fait du traitement de données et qu'on tape partout dans la RAM, on est interrompu plein de fois, mais heureusement le CPU a des mécanismes pour que les pages les plus récentes soient plus rapides à accéder.

C'est normalement transparent pour une appli lambda.


Le problème, c'est que 4ko, c'est trop juste maintenant. On a des mécanismes pour avoir des pages plus grandes, mais c'est très spécifique à certaines applis et ça demande de taper dans l'OS: on est moins portable.

Une solution serait de passer à des pages de 16ko, 64ko. C'est possible sur certains ARM, à ma connaissance pas sur PC, et c'est déjà un boost pour le traitement (y compris pour le javascript).

Par contre, quand on fait de l'émulation, certaines fonctionnalités pointues sont liées à ces pages, et les limites sont souvent compilées dans le code, impossibles à retrouver. Donc un soft très optimisé comme un jeu, une BDD, risque de ne pas fonctionner sur un OS dont les pages sont de taille différente.
Emuler la détection de ces limites est extrêmement coûteux (cela revient à checker logiciellement chaque accès mémoire...)

Pour résumer:
* Un passage du x86 à l'ARM avec la même taille de page: on peut émuler sans trop se poser de questions
* Un passage du x86 à l'ARM avec un taille de page inférieure: on peut émuler sans trop se poser de questions, mais on perd en perfs
* Un passage du x86 à l'ARM avec un taille de page supérieure: on peut émuler des trucs simples ... mais il y a des limites, des risques, mieux vaut se focaliser sur le natif et les runtimes type Java/C#
Ok c'est plus clair, merci :)
Ça sent la déception ces Snapdragon X Elite Plus Pro Deluxe 2000-42. On nous a vanté le talent d'être supérieur au M3, sauf que c'est clairement l'ultra haut de gamme qui se confronte à l'entrée de gamme, et avec des performances pas forcément aussi impressionnantes que ne le prétendent les annonces.

Reste à voir l'approche tarifaire qu'il y aura autour, mais à mon avis il va pas falloir qu'ils s'emballent trop pour pas que tout ça parte en échec commercial.
On a des infos concernant l'(/la non-)ouverture de ces snapdragons, a-t-on des pilotes open source ? Voir un support noyau Linux ? Comment s'en sort gcc avec cette archi ?

Si oui c'est là où ça va causer, sous Linux (ou tout soft open source en général) il suffit de recompiler, pour avoir les perfs optimales.
Il y a des pilotes open source pour un certain nombre d’éléments (la micro-architecture* ARMv8 est publique donc GCC et consorts s’en sortent sans problème, la partie graphique est basée sur l’architecture Radeon—dont Adreno est une anagramme—donc il y a peut-être quelque-chose aussi) mais il reste beaucoup d’éléments qui n’ont aucune solution open source.

C’est d’ailleurs une des raisons qui entraîne la fin du support des téléphones Android : puisque le pilote n’est pas mis à jour, il n’est pas possible de passer sur le noyau plus récent de la nouvelle mouture (les ROM alternatives trafiquent souvent Android pour le faire tourner avec l’ancien noyau).

C’est aussi pour ça que Fairphone n’a pas choisi un processeur Snapdragon pour son numéro 5 mais une version destinée à l’IoT/l’industrie pour avoir un support plus long.

(*) Pas certain que ce soit le bon terme, les sachants peuvent corriger.
Modifié le 28/04/2024 à 13h09

Historique des modifications :

Posté le 28/04/2024 à 13h06


Il y a des pilotes open source pour un certain nombre d’éléments (la micro-architecture ARMv8 est publique donc GCC et consorts s’en sortent sans problème, la partie graphique est basée sur l’architecture Radeon—dont Adreno est une anagramme—donc il y a peut-être quelque-chose aussi) mais il reste beaucoup d’éléments qui n’ont aucune solution open source.

C’est d’ailleurs une des raisons qui entraîne la fin du support des téléphones Android : puisque le pilote n’est pas mis à jour, il n’est pas possible de passer sur le noyau plus récent de la nouvelle mouture (les ROM alternatives trafiquent souvent Android pour le faire tourner avec l’ancien noyau).

C’est aussi pour ça que Fairphone n’a pas choisi un processeur Snapdragon pour son numéro 5 mais une version destinée à l’IoT/l’industrie pour avoir un support plus long.

Fermer