Surprise : La Windows Surface Pro 9 sous ARM est lente

Encore une fois la promesse de Microsoft de proposer une tablette Surface Pro 9 qui corrigerait les défauts des précédentes s’avère fausse.

C’est une sorte de tradition, la Surface Pro 9 de Microsoft s’avère tout aussi médiocre en terme de performances que les précédents modèles. Si on résume l’histoire de ce segment de l’industrie à lui tout seul, on a exactement le même parcours à chaque fois.

Microsoft annonce un super produit sous Windows piloté par une puce ARM. Avec des performances équivalentes à celles d’une puces x86. « Vous ne verrez pas la différence ! ». Le produit sort, il est très cher et propose effectivement les mêmes performances qu’une puce x86 entrée de gamme. Par contre, si vous regardez ses capacités par rapport au prix exigé par Microsoft, vous pouvez avoir un engin autrement plus rapide sous AMD ou Intel. 

Mais Microsoft se veut rassurant, ils expliquent que leur technologie est jeune et qu’ils vont faire mieux la prochaine fois, il s’associe à Qualcomm pour proposer dans le future une nouvelle puce extraordinaire qui va tout changer. Et rebelote. La puce sort, les machines sortent, les performances sont dégueulasses et tout le monde regarde ses chaussures chez Microsoft avant de promettre que finalement ca sera la prochaine génération qui résoudra tous les soucis.

La dernière des dernières générations en question, c’est donc la Surface Pro 9. Et comme pour les précédentes, les performances globales sont bien en dessous de ce que proposent les modèles qui emploient une puce x86. Tout en étant vendu à un prix premium, bien entendu. Pire encore, la Surface Pro 9 ARM est proposée à un tarif plus élevé que sa consœur la plus rapide sous Intel. Pour cause de 5G intégrée, cette version ARM. Au final, le travail de collaboration a porté ses fruits entre Microsoft et Qualcomm puisque la solution est nettement plus rapide qu’auparavant mais à quel prix ? Au sens propre comme au figuré, cela n’a plus rien à voir avec la promesse initiale portée par Microsoft.

 

La promesse de Microsoft a été tenue par Apple

Si la Surface Pro 9 ne parvient pas à porter Windows, c’est probablement à cause de son lourd passif de compatibilité. Malgré cela, pas mal d’applications et de jeux refusent de fonctionner sur la tablette, même en émulation. L’émulation en elle même est toujours aussi catastrophique avec des performances clairement à la traine.  

C’est le jour et la nuit par rapport aux propositions d’Apple qui, lors de leur passage vers ARM et depuis lors, ont prouvé qu’un système pouvait être piloté par une de ses puces de manière performante et même proposer une émulation x86 satisfaisante. Apple a non seulement mis en place un duo matériel et logiciel efficace mais a réussi l’exploit de séduire avec . Ce que  la Surface Pro 9 tente de faire mais ne parvient toujours pas à réaliser. 

Sur les Macbook et les iPad, Apple a pris à bras le corps le développement d’une solution ARM avec des fonctions câblées exceptionnelles pour certains traitements, et en a fait un atout pour le développement de ses applications phare. L’arrivée récente du logiciel de montage vidéo DaVinci Resolve de Blackmagic sur les tablettes iPad en est un excellent exemple.

En face, la Surface Pro 9 propose une solution dont les seuls vrais avantages sont la présence d’un modem 5G intégré et… l’exploitation d’une Intelligence Artificielle améliorant les appels vidéo… Le SoC SQ3 de Qualcomm et Microsoft propose un recadrage automatique pour suivre votre visage et une fonction de floutage automatique de l’arrière plan en temps réel. Tout le reste de la proposition de calcul est médiocre ou n’a aucun avantage par rapport à ce que propose une des puces traditionnelles. L’argument de l’autonomie est de moins en moins viable au fil du temps puisque les puces Intel à faible consommation ont tendance désormais à proposer de très bons scores. Et surtout l’autonomie prévue par Microsoft pour ses tablettes ARM ne prend pas en compte le fait que leur lenteur à exécuter des tâches n’offrira pas de temps de travail supplémentaire mais du temps d’attente non productif.

Quelle leçon tirer de cet énième échec ?

Microsoft et Qualcomm ont déjà annoncé travailler à une nouvelle puce pour 2023-2024 qui devrait résoudre tous les problèmes rencontrés. C’est exactement la même promesse encore et encore. Et j’ai bien envie de les croire. Pourquoi pas. Mais il faudra plus que cette promesse pour faire basculer le consommateur vers ces produits.

Les problèmes sont encore et toujours les mêmes. Intel et AMD n’attendent pas Microsoft et Qualcomm gentiment pour leur laisser le temps de les rattraper. Apple est déjà arrivé au bout de la course également de son côté. Même si une Surface Pro 10 sous ARM apparaissait l’année prochaine et faisait au moins aussi bien qu’un processeur concurrent, où serait réellement sa plus-value ? Il faudrait qu’elle fasse mieux, vraiment mieux, pour pousser l’utilisateur à choisir cette voie risquée de l’émulation pour certains de ses usages. Le nombre d’échecs rencontrés par le passé n’inspire pas vraiment confiance et encore une fois, rares seront ceux qui tenteront l’aventure.

Microsoft devrait abandonner cette voie. Non pas l’idée de proposer un produit sous ARM, Apple nous a montré que c’était possible. Mais tenter de proposer un Windows avec tout son passif est une idée qui semble être sans issue. La Surface Pro 9 est plus chère et moins rapide qu’une solution Intel classique sous Windows, ce ne serait probablement pas le cas avec une solution sous Linux. C’est le pas à franchir pour Microsoft, développer autre chose que Windows qui sera compatible avec des outils Microsoft classiques développés sur mesures mais qui pourra porter également d’autres applications tierces d’autres développeurs. A condition de les séduire, comme a su le faire Apple.

Le souci étant le risque pris pour pas grand chose au final. Les avantages du monde ARM au main d’un Microsoft ne sont pas nombreux : le matériel est  et restera totalement bridé, impossible d’installer en remplacement du Windows fourni autre chose sur la Surface Pro 9. Une palanquée de protections logicielles sera mise en œuvre pour empêcher l’utilisateur de faire ce qu’il veut de son achat et surtout, en face, restera toujours et encore des solutions x86 qui ont déjà investi un même format avec brio.

Qui ira choisir de s’enfermer avec Microsoft ?

 

Faites découvrir le site en le partageant


Soutenez Minimachines avec un don mensuel : C'est la solution la plus souple et la plus intéressante pour moi. Vous pouvez participer via un abonnement mensuel en cliquant sur un lien ci dessous.
2,5€ par mois 5€ par mois 10€ par mois Le montant de votre choix

Gérez votre abonnement

7 commentaires sur ce sujet.
  • hle
    7 novembre 2022 - 12 h 25 min

    Je me souvient qu’un utilisateur Mac de MS Excel (sur PowerPC il me semble) c’était aperçus que la version PC sous émulateur était plus rapide pour un fichier avec beaucoup de Macro que le version Mac en Natifs! Donc j’ose pas imaginé pour tous un OS la version ARM !

    On est loin du boulot que Apple a fait lui. Mais eux on de l’expérience avec iOS pour le téléphone. Qui ce souvient de Windows Mobile sur les téléphone ? SIC !

    Répondre
  • 7 novembre 2022 - 17 h 10 min

    « La Surface Pro 9 est plus chère et moins rapide qu’une solution Intel classique sous Windows, ce ne serait probablement pas le cas avec une solution sous Linux. C’est le pas a franchir pour Microsoft, développer autre chose que Windows… »

    L’énorme problème pour faire cela, c’est surtout de sortir de 40 ans d’un modèle de comptabilité de binaires sur source clos du duo wintel. Et au delà de Microsoft, il faut qu’éditeurs tiers et fabricants de matériels veuillent suivre (enfin un support GPU sans histoire sous Linux?). Donc on reste coincé sur de l’émulation x86, avec sans doute des options pour l’accélérer matériellement sous ARM bien bloquées légalement par Intel… et/ou historiquement avec en mémoire l’échec de Transmeta, aux raisons non démenties/accentuées depuis.

    Apple a réussit a concilier les deux (binaires fermés sur sources mixtes), mais en maîtrisant le matériel ce qui simplifiait déjà les choses (peu de divergence vs monde PC) et en sachant choisir sa licence quand ils sont partis sur une base BSD côté OS à une heure ou Ballmer parlait de Linux comme d’un cancer (rapport à l’aspect contaminant, voir métastasant, de la GPL). Changer régulièrement d’architecture permet aussi au quotidien de garder l’essentiel de son code portable y compris côté éditeurs tiers.

    Google a bien basé Androïd sur un fork de Linux, plus favorable à de larges options matérielles sans vouloir devenir constructeur exclusif soit-même, mais totalement contourné le problème licence (entre autres sécurité et indépendance d’architecture) côté applicatif en l’isolant dans sa JVM (ce qui tenait la route niveau perf pour un applicatif de smartphone et reste bien moins pénalisant que de l’émulation).

    En l’état, si Microsoft veut déborder du PC x86 il n’a guère comme option que d’arrêter windows, reprendre le projet WINE afin de gérer l’historique x86… et faire sa distribution Linux avec ses services d’intégration offerts (ou bien moins cher qu’une licence windows OEM actuelle, sinon au moins les gros s’en passeront!) aux fabricants de PC: AMHA, ils sont pas mûrs, sinon on n’aurait pas ces tentatives un peu désespérées avec Qualcomm…

    Répondre
  • 7 novembre 2022 - 18 h 20 min

    Le vrai problème, quand on compare Microsoft et Apple, c’est qu’Apple a fait une bascule complète (et que ça n’est pas la première fois). Ça contraint les éditeurs à porter leurs programmes s’ils ne veulent pas être mis de côté et perdre une source de revenue.

    Avec Windows ARM, Microsoft maintient deux OS, dont l’un représente une part infime des Windows actuels et futurs. Quel éditeur sensé va faire l’effort de porter (et maintenir) un programme dans ces conditions ?

    À moins de financer ces portages, ils ne verront pas le jour. Et ce financement ne sera peut-être même pas suffisant : je pense que Microsoft est marqué au fer rouge avec son expérience Windows Mobile sur ce point…

    Bref, à moins de concurrencer Windows avec un autre OS, je ne vois pas de solution pour Microsoft sur une autre architecture que le x86.

    Répondre
  • Gab
    7 novembre 2022 - 23 h 19 min

    Est ce que le navigateur web et la suite office sont bien optimisés sous Windows ARM? (ca parait être la moindre des choses). Ca couvrirait déjà les besoins de pas mal de ‘manager’qui ne font que du’ office’…

    Répondre
  • 7 novembre 2022 - 23 h 29 min

    Microsoft peut très bien rester sur du Windows, mais doit s’inspirer de la manière de développer d’Apple: en gros, tant qu’on utilise les API d’Apple et l’environnement de développement « maison » (Xcode), créer un programme pour une plate-forme se « limite » à cocher cette plate-forme (ARM, x86 ou, anciennement, PowerPC) dans les paramètres du projet. On peut même créer des programmes qui embarquent le code pour s’exécuter sur plusieurs plate-formes, le tout au sein d’un même binaire.
    Du coup, développer pour une « autre » plate-forme est bien plus simple…

    Répondre
  • CHP
    8 novembre 2022 - 0 h 31 min

    Le problème de Microsoft c’est qu’ils ne savent plus créer d’OS en code assembleur et ce depuis longtemps. Je me souviens quand, dès le départ, le noyau HAL de WinNT 3.x était développé sur des systèmes RISC (DEC si je me souviens bien) puis cross-compilés pour du x86.
    Tout passe maintenant par de la cross-compilation. C’est sûr que pour du « debuggage » c’est top mais c’est raté dès le départ pour faire un OS performant et compacts (et je n’ose pas imaginer plus pour faire de l’émulation).

    A l’inverse et d’origine, Linux était écrit en assembleur mais je ne saurait le confirmer pour les noyaux récents.

    A ma connaissance, le seul OS « moderne » qui reste encore entièrement écrit en assembleur est MenuetOS :
    https://fr.wikipedia.org/wiki/MenuetOS

    Répondre
  • 8 novembre 2022 - 17 h 40 min

    @CHP:
    Sauf que… c’est bien le RISC qui a achevé (avec la portabilité, entre autres bonnes raisons) l’assembleur: La raison est que le compilateur a une « vision » globale du programme écrit que l’on a pas en écriture directe de code machine, même en s’appliquant, permettant des optimisations exploitant au mieux la structure interne du processeur et particulièrement bénéfique au RISC.
    L’assembleur ne se justifie plus que pour quelques parties très bas niveau (quelques initialisations post-reset dans le but de pouvoir appeler du C au plus tôt et en premier lieu une zone de ram interne/cache afin d’avoir la pile nécessaire aux appels de fonctions, les parties bas niveau liées aux interruptions/mémoire virtuelle).
    Dans le noyau Linux, même pas certain que l’on dépasse le % par architecture supportée.
    Ce qui n’empêche clairement pas de devoir parfois s’intéresser au code compilé: Les bugs compilateur, c’est rare mais cela arrive (sur PowerPC, un bug eu existé avec revoyure selon les versions il y a une quinzaine d’années, voyant alloué le registre r0 qui comme sur bcp d’archi RISC représente qqsoit son contenu la valeur 0 pour certaines instructions, à mauvais escient: Amusant, car d’une compilation à l’autre on tombait dessus… ou pas… à la moindre ligne de source changée). Les bugs processeurs aussi.

    Répondre
  • LAISSER UN COMMENTAIRE

    *

    *