Microsoft supportera bientôt les applications 64 bits sous Windows ARM, Réactions à la publication du 06/04/2018

[Lionel]

Microsoft a fait un portage de Windows sur des puces ARM permettant de faire tourner des applications x86 32 bits sur ces processeurs.
La société a annoncé que cette limitation sauterait prochainement. Elle va proposer dans un futur proche un nouveau SDK qui sera capable de recompiler les applications 64 bits pour les faire tourner sur les PC ARM.
Il reste encore à convaincre les développeurs de faire ce portage, mais Microsoft semble confiant dans leur bonne volonté.

Voilà encore une information qui fera du tort à Intel qui, pour la première fois depuis des décennies, voit les bases de son avenir chanceler devant ces nouvelles tendances.

Lien vers le billet original

[falcon1]

Microsoft a fait un portage de Windows sur des puces ARM permettant de faire tourner des applications X86 32 bits sur ces processeurs.
La société a annoncé que cette limitation sauterait prochainement. Elle va proposer dans un futur proche un nouveau SDK qui sera capable de recompiler les applications 64 bits pour les faire tourner sur les PC ARM.
Il reste encore à convaincre les développeurs de faire ce portage, mais Microsoft semble confiant dans leur bonne volonté.

Voilà encore une information qui fera du tort à Intel qui pour la première fois depuis des décennies voit les bases de son avenir chanceler devant ces nouvelles tendances.

Lien vers le billet original

et dans 2 ans ils te proposent une version de windows à installer sur iPad.....

[Fafnir]

attention cela concerne Intel mais latéralement
l'un de mes jeux favori est World of Tanks, qui ne fonctionne sur MacOS qu'avec un wrapper mais passe en graphisme minimum sur mon Mac mini 2012.
Un lien vers un cadeau d'Intel pour les joueurs les plus assidu:
Intel® Trophy Leaderboard
https://worldoftanks.com/en/news/general-ne...n-announcement/

----

publicité d'une valise de voyage où on accède au Mac plus facilement
https://www.90fun.us/


Ce message a été modifié par Fafnir - 6 Apr 2018, 09:09.

[(The)Space]

Il reste encore à convaincre les développeurs de faire ce portage, mais Microsoft semble confiant dans leur bonne volonté.]

Il y a comme qui dirait un air de déjà vu...

[zero]

Il reste encore à convaincre les développeurs de faire ce portage, mais Microsoft semble confiant dans leur bonne volonté.

Il y a comme qui dirait un air de déjà vu...

La bonne volonté, oui mais on t-ils le temps ? Sans doute que oui pour les principales applications, celles qui rapportent le plus.

[gregoz]

A voir les premiers tests on est loin des résultats attendus en 32 bits... certains benchmarks font même état d'une puissance équivalente à un... atom n270 !!!! La bonne blague !

[iAPX]

A voir les premiers tests on est loin des résultats attendus en 32 bits... certains benchmarks font même état d'une puissance équivalente à un... atom n270 !!!! La bonne blague !

Il y a deux points, le premier est qu'il y a des puces à jeu d'instructions ARM plus performantes que d'autres et dans le ou les premiers modèles testés ça n'est pas une flèche, le second est que beaucoup testent des applications non-natives (x86 32bits émulé logiciellement) ce qui correspond à ce qu'ils peuvent utiliser à la sortie du bousin, mais qui ne correspondra plus à ce que les gens vont vivre d'ici la rentrée de septembre.

Je ne m'attend pas à de bonnes CPU en septembre (plutot pour 2019 si la mayonnaise prend), comparables à celles des MacBook Pro retina 13" actuels, ils atteindront peut-être le niveau de performances d'un MacBook retina 12", ce qui est suffisant pour une majorité de gens surtout si l'autonomie est meilleure (elle semble être incroyable là), en revanche des applications natives ARM il y en aura plein.
Et d'autres offres aussi coté matériel.

Apple est dans une meilleure position pour offrir des ordinateurs portables à base de jeu d'instruction ARM, ayant depuis un an des CPU comparables à celle d'un MBPr 13" 3.1Ghz dans les iPad Pro (A10X) et maintenant dans l'iPhone 8 (A11) et un meilleur contrôle sur les Applications et les Développeurs via XCode permettant de générer du code ARM et d'avoir plusieurs séries de codes dans le même exécutable mais aussi l'App Store sur lequel ils peuvent imposer une version ARM obligatoire petit à petit.

En revanche le premier modèle de HP a des qualité d'autonomie et de connectivité assez imbattable.

Ce message a été modifié par iAPX - 6 Apr 2018, 12:01.

[SartMatt]

Microsoft a fait un portage de Windows sur des puces ARM permettant de faire tourner des applications X86 32 bits sur ces processeurs.
La société a annoncé que cette limitation sauterait prochainement. Elle va proposer dans un futur proche un nouveau SDK qui sera capable de recompiler les applications 64 bits pour les faire tourner sur les PC ARM.

Attention, la limite qui saute, c'est uniquement sur la compilation à partir du code source, qui va pouvoir être faite en 64 bits et non plus seulement en 32 bits.
Pour ce qui est de faire tourner des applications x86, ça reste pour l'instant limité au 32 bits.

Il y a deux points, le premier est qu'il y a des puces à jeu d'instructions ARM plus performantes que d'autres et dans le ou les premiers modèles testés ça n'est pas une flèche, le second est que beaucoup testent des applications non-natives (x86 32bits émulé logiciellement) ce qui correspond à ce qu'ils peuvent utiliser à la sortie du bousin, mais qui ne correspondra plus à ce que les gens vont vivre d'ici la rentrée de septembre.

Même en natif, c'est pas la joie... Le simple démarrage du système, c'est deux fois plus long que sur des machines x86 du même segment...

[os2]

machine fait pour du web fait pour rassurer ceux qui pense encore utiliser quelques x86 programme...

[iAPX]

...

Il y a deux points, le premier est qu'il y a des puces à jeu d'instructions ARM plus performantes que d'autres et dans le ou les premiers modèles testés ça n'est pas une flèche, le second est que beaucoup testent des applications non-natives (x86 32bits émulé logiciellement) ce qui correspond à ce qu'ils peuvent utiliser à la sortie du bousin, mais qui ne correspondra plus à ce que les gens vont vivre d'ici la rentrée de septembre.

Même en natif, c'est pas la joie... Le simple démarrage du système, c'est deux fois plus long que sur des machines x86 du même segment...

Relis bien mon premier point:

il y a des puces à jeu d'instructions ARM plus performantes que d'autres et dans le ou les premiers modèles testés ça n'est pas une flèche

Quand au temps de démarrage comme "benchmark", tu veux dire qu'un iMac Pro est donc moins performant qu'un Apple ][?
Ils ne font tout simplement pas les même chose, certaines étant communes, et pour le reste la CPU est quand-même très lente en monothread, il y en a d'autres plus performantes qui vont arriver.

Ce message a été modifié par iAPX - 6 Apr 2018, 17:24.

[SartMatt]

...

Il y a deux points, le premier est qu'il y a des puces à jeu d'instructions ARM plus performantes que d'autres et dans le ou les premiers modèles testés ça n'est pas une flèche, le second est que beaucoup testent des applications non-natives (x86 32bits émulé logiciellement) ce qui correspond à ce qu'ils peuvent utiliser à la sortie du bousin, mais qui ne correspondra plus à ce que les gens vont vivre d'ici la rentrée de septembre.

Même en natif, c'est pas la joie... Le simple démarrage du système, c'est deux fois plus long que sur des machines x86 du même segment...

Relis bien mon premier point:

il y a des puces à jeu d'instructions ARM plus performantes que d'autres et dans le ou les premiers modèles testés ça n'est pas une flèche

Quand au temps de démarrage comme "benchmark", tu veux dire qu'un iMac Pro est donc moins performant qu'un Apple ][? Ils ne font tout simplement pas les même chose, certaines étant communes, et pour le reste la CPU est quand-même très lente en monothread, il y en a d'autres plus performantes qui vont arriver.

Le Snapdragon 835, c'est l'une des puces ARM Les plus performantes du marché (je te rapelle que les puces d'Apple ne sont pas sur le marché, un constructeur ne peut pas les utiliser).

Quand à ton parallèle iMac Pro/Apple II, tu touches le fond en termes d'argumentaire là
.. Parce que moi je parle bien de comparer le temps de boot de machines de la même époque, dotées du même système d'exploitation (et à la limite, s'il y a des différences entre W10 x86 et W10 ARM, c'est plus dans le sens d'un allègement de la version ARM que l'inverse...) et visant le même marché. Donc je persiste, c'est bien un indicateur des performances de la machine relativement à d'autres machines. Pas le seul bien entendu, mais c'en est un quand même.

[joe75]

A voir les premiers tests on est loin des résultats attendus en 32 bits... certains benchmarks font même état d'une puissance équivalente à un... atom n270 !!!! La bonne blague !

Il y a deux points, le premier est qu'il y a des puces à jeu d'instructions ARM plus performantes que d'autres et dans le ou les premiers modèles testés ça n'est pas une flèche, le second est que beaucoup testent des applications non-natives (x86 32bits émulé logiciellement) ce qui correspond à ce qu'ils peuvent utiliser à la sortie du bousin, mais qui ne correspondra plus à ce que les gens vont vivre d'ici la rentrée de septembre.

Je ne m'attend pas à de bonnes CPU en septembre (plutot pour 2019 si la mayonnaise prend), comparables à celles des MacBook Pro retina 13" actuels, ils atteindront peut-être le niveau de performances d'un MacBook retina 12", ce qui est suffisant pour une majorité de gens surtout si l'autonomie est meilleure (elle semble être incroyable là), en revanche des applications natives ARM il y en aura plein.
Et d'autres offres aussi coté matériel.

Apple est dans une meilleure position pour offrir des ordinateurs portables à base de jeu d'instruction ARM, ayant depuis un an des CPU comparables à celle d'un MBPr 13" 3.1Ghz dans les iPad Pro (A10X) et maintenant dans l'iPhone 8 (A11) et un meilleur contrôle sur les Applications et les Développeurs via XCode permettant de générer du code ARM et d'avoir plusieurs séries de codes dans le même exécutable mais aussi l'App Store sur lequel ils peuvent imposer une version ARM obligatoire petit à petit.

En revanche le premier modèle de HP a des qualité d'autonomie et de connectivité assez imbattable.

Je comprend pas pourquoi l'autonomie serait vraiment top face à des cpu intels X86 qui consomment de moins en moins...pour moi la consommation de l'écran joue aussi beaucoup ainsi que le wifi, bluetooth, la 4G....on risque de se retrouver avec une autonomie constructeur ARM annoncée à 20h00 avec 8h00-10h00 en réel...mais bon j'espère me tromper.
Enfin l'argument de 20h00 n'est pas forcément très pertinent, j'utilise principalement mon portable branché à une prise de courant pour éviter au maximum d'user la batterie...

Après pour de l'embarqué sans écran oui ça peut être pas mal du tout en effet.


Edit : Les critiques du HP Envy X2 ARM S835 ne sont pas géniales pour les performances hors reconnaissance Windows Hello, peut être car il n'y a pas beaucoup d'applications optimisées/recompilées cependant le testeur dit pouvoir obtenir 15h en consultation au lieu des 22h00 affichées....
Donc fonctionne par émulation.
Je pense que la Surface 3 atom a un processeur plus rapide...mais 4Go et un disque dur EMMC pas SSD...

Ce message a été modifié par joe75 - 6 Apr 2018, 19:36.

[Guest_dtb06_*]

Pour moi ça ne marchera que sur des machines à moins de 600 euros.

[iAPX]

Pour moi ça ne marchera que sur des machines à moins de 600 euros.

Au début oui, mais ils sont le "gras" en terme de volume de la vente de PC.

[Pat94]

Citation (iAPX @ 6 Apr 2018, 12:45) *
Citation (gregoz @ 6 Apr 2018, 04:55) *
A voir les premiers tests on est loin des résultats attendus en 32 bits... certains benchmarks font même état d'une puissance équivalente à un... atom n270 !!!! La bonne blague !
Il y a deux points, le premier est qu'il y a des puces à jeu d'instructions ARM plus performantes que d'autres et dans le ou les premiers modèles testés ça n'est pas une flèche, le second est que beaucoup testent des applications non-natives (x86 32bits émulé logiciellement) ce qui correspond à ce qu'ils peuvent utiliser à la sortie du bousin, mais qui ne correspondra plus à ce que les gens vont vivre d'ici la rentrée de septembre.

Je ne m'attend pas à de bonnes CPU en septembre (plutot pour 2019 si la mayonnaise prend), comparables à celles des MacBook Pro retina 13" actuels, ils atteindront peut-être le niveau de performances d'un MacBook retina 12", ce qui est suffisant pour une majorité de gens surtout si l'autonomie est meilleure (elle semble être incroyable là), en revanche des applications natives ARM il y en aura plein.
Et d'autres offres aussi coté matériel.

Apple est dans une meilleure position pour offrir des ordinateurs portables à base de jeu d'instruction ARM, ayant depuis un an des CPU comparables à celle d'un MBPr 13" 3.1Ghz dans les iPad Pro (A10X) et maintenant dans l'iPhone 8 (A11) et un meilleur contrôle sur les Applications et les Développeurs via XCode permettant de générer du code ARM et d'avoir plusieurs séries de codes dans le même exécutable mais aussi l'App Store sur lequel ils peuvent imposer une version ARM obligatoire petit à petit.

En revanche le premier modèle de HP a des qualité d'autonomie et de connectivité assez imbattable.

Bonjour cette discussion m'amuse un peux :

Déjà on compare des puces actuelles au 6502 de l'apple II (1mHz 4kO de ras) LOL.... , mais enfin cela me rappel ma jeunesse car je me suis fait les dents sur ce type de machines qui à leurs époque étaient au top..

A cette époque et au vu la capacité mémoire ridicule des bécanes ont se tapais tout en assembleur (langage maintenant oublié par 99% des développeurs), actuellement les langages dit évolués C, C+ et consorts utilise des bibliothèques prés définis qui n'apparaissent plus dans le développement des softs elles sont traitées par les compilateurs qui mettent toutes les fonctions librairies dans l'exécutable.

Il suivi donc que ces librairies de fonctions soit tous simplement écrite dans les instruction de base du processeur utilisé (assembleur) et non pas interprétés par un émulateur et miracle les différents bouzins marcheront à toute allures (mais cela coute chère de ré écrire les librairies) .

Sinon pour ma part je pense que apple fric fait un erreur en voulant utiliser ces puces pour téléphones portables dans des micros,le fonctionnement des ces deux mondes étant très différents dés que l'on sort des APP dite bureautique et les mac redeviendrons des hors standards cela à déjà faillie tuer APPLE, mais là ils ont la chance pour l'instant de vendre du téléphone et ils compte la dessus....

Ce message a été modifié par Pat94 - 7 Apr 2018, 15:46.

[iAPX]

...
Sinon pour ma part je pense que apple fric fait un erreur en voulant utiliser ces puces pour téléphones portables dans des micros,le fonctionnement des ces deux mondes étant très différents dés que l'on sort des APP dite bureautique et les mac redeviendrons des hors standards ce à déjà faillie tuer APPLE, mais là ils ont la chance pour l'instant de vendre du téléphone et ils compte la dessus....

Oui et en 1980 le 8088 était tout sauf "le standard", puisqu'en 8bits le 6502 et le Z80 se tiraient la bourre en terme de parts de marché, et qu'en 16bits tout le monde attendait l'excellent 68000 (les docs complètes sont sorties vers 1979).

Que venait faire iNtel incapable de concevoir une CPU 8-bits aussi performante que les autres, ses ingénieurs étant parti pour fonder Zilog et sortir le bien meilleur et moins cher Z80?!?
En fait le choix du "standard" 8088, sorti après le 8086 n'était pas pour économiser, mais pour être sûr que l'IBM 5150 n'allait pas concurrencer leurs mini-systèmes: ils ont délibérément choisi une plateforme peu performante, et dans celle-ci la CPU la plus lente

Quand aux CPU Apple, sauf à ce que tu ai des informations auxquelles je n'ai pas accès, elles sont déjà d'un niveau comparable aux CPU Intel trouvé dans les MacBook retina 12", mais aussi dans les MacBook Pro retina touchbar 13" 3.1Ghz, et ceci dans le volume et avec le TDP de l'iPhone 8, et je suppute que l'A11X en 3-core sera comparable en multithreadé aux CPU des MacBook Pro retina 15" actuels (4-core elles) au sein du futurs iPad Pro.

Quand à ce que Apple développe probablement depuis un moment, c'est à dire des CPU pour ordinateurs portables, bénéficiant d'un TDP largement supérieur, avec plus de cœurs et conçues pour des fréquences très différentes (un iPhone 8 c'est 2.3Ghz, un MBPr 13" c'est 3.1Ghz sans aller nécessairement plus vite!) et des optimisations probablement différentes (par exemple plus d'unités vectorielles, un contrôleur mémoire revu, etc), j'attend de voir mais je ne serais pas étonné qu'avec du code natif, généré par XCode , elles soient du meilleur niveau, avec des avantages en terme d'autonomie mais peut-être aussi de performances!

Apple est dans une meilleur position que Microsoft+Qualcomm+devs extérieurs: ils ont une grosse expérience en migration de plateforme technique, avec la dernière migration relativement bien passée, ils maitrisent les outils de développement principaux (via XCode), ils maitrisent la distribution des logiciels et les règles afférentes (App Store) pour pousser puis forcer à avoir une version ARM incluse, ils maîtrisent totalement la conception de CPU, notablement avec des Ax qui ont un IPC très élevé leurs donnant de belles perfs en mono-thread (2.2X plus rapide que le SnapDragon utilisé par HP) et supportant très bien le multithreading (60% plus rapide mais avec la moitié des core, 3.2X plus rapide par core!), un niveau de performance d'une CPU Intel d'un TDP de 28W mais dans un format d'iPhone 8 et même pas besoin de multithreading!

Quand aux coûts ils sont assez évident, la CPU A10X d'un iPad Pro est bien plus performante que celle d'un MacBook retina 12" 1.4Ghz, dans un TDP équivalent, et l'iPad Pro 10.5" au complet est vendu le prix qu'Intel+Apple facturent pour juste la CPU du premier avce la marge du second: ça devrait faire réfléchir!

Pour moi il y a des possibilités chez Apple qui n'existent pas dans le 3some Microsoft-Qualcomm-HP.
Qu'ils le fassent ou pas, ça sera de toute façon intéressant d'observer les évolutions de la plateforme ARM sous Windows, une fois que des CPU potables seront dedans, et si Microsoft se fait greffer des couilles pour une fois, leur spécialité étant d'annoncer des plateformes prometteuses mais lâchant l'affaire au plus tôt, trop tôt, si elle ne rapporte pas immédiatement (encore un avantage d'Apple!) !

PS: quelques mois avant l'annonce du passage à Intel et aux x86, ça n'était que des rumeurs, bien cachées, alors que tout était déjà prêt avant la WWDC, et je m'attend à quelque-chose de similaire cette année pour un switch en 2019 sur les entrées-de-gamme (nouveau MBA par exemple!)

Il y a eu aussi la belle histoire des machines dev de la WWDC, des Mac Pro à l'extérieur avec un Pentium 4 à l'intérieur, "louées" pour $999 aux devs pour adapter leurs logiciels, puis finalement en leur offrant un iMac dual-core 6 mois plus tard en fin de location quand ils retournent leur Pentium 4. un iMac dual-core offert. Classieux!

Ce message a été modifié par iAPX - 9 Apr 2018, 13:54.

[Pixelux]

Oui, clairement Apple prépare depuis longtemps son switch vers les processeur ARM.

C'est complètement évident.

Dans le monde informatique cela fait un bon bout de temps que c'est dans l'air. Il y déjà depuis plusieurs années que des OS Linux qui tourne déjà sous ARM. Notamment Arch Linux.

Sur le fond c'est a peu près certain que tu as raison.

Ce message a été modifié par Pixelux - 7 Apr 2018, 15:43.

[Guest_CPascal_*]

Microsoft a fait un portage de Windows sur des puces ARM permettant de faire tourner des applications X86 32 bits sur ces processeurs.
La société a annoncé que cette limitation sauterait prochainement. Elle va proposer dans un futur proche un nouveau SDK qui sera capable de recompiler les applications 64 bits pour les faire tourner sur les PC ARM.
Il reste encore à convaincre les développeurs de faire ce portage, mais Microsoft semble confiant dans leur bonne volonté.

Voilà encore une information qui fera du tort à Intel qui pour la première fois depuis des décennies voit les bases de son avenir chanceler devant ces nouvelles tendances.

Lien vers le billet original

et dans 2 ans ils te proposent une version de windows à installer sur iPad.....

en fait c'est l'inverse
crosoft vend sur son store age of empires UN
win10 minimum requis
pas mal pour un jeu qui a 20 ans
https://www.microsoft.com/fr-fr/store/p/age...on/9n2kmdvlk85d

Ce message a été modifié par CPascal - 8 Apr 2018, 17:37.

[Ambroise]

Oui, clairement Apple prépare depuis longtemps son switch vers les processeur ARM.

C'est complètement évident.

Dans le monde informatique cela fait un bon bout de temps que c'est dans l'air. Il y déjà depuis plusieurs années que des OS Linux qui tourne déjà sous ARM. Notamment Arch Linux.

On ne peut même plus parler de plusieurs années : je pense qu'ARM doit être la première archi vers laquelle a été porté Linux, dès le kernel 1.0. ça fait dont largement plus de 20 ans.

Mais je ne vois rien de clair dans la volonté d'Apple de passer sur ARM. Il y a 10 ans c'était déjà un sujet de discussion et il reste aujourd'hui le même fossé pour passer les Mac sur ARM. Les tâches que l'ont fait couramment sur un iPad seraient tout à fait faisable sur un Mac/iOS/ARM. Mais s'il y a besoin de puissance CPU alors on reste encore aujourd'hui dans deux mondes différents :
quand un x86 de dernière génération peut débiter sur chaque thread matériel 64 opérations flottantes par cycle d'horloge alors qu'un ARM de dernière génération (comme l'A11) n'en fera que 8, et que de plus le x86 peut disposer de 36 threads matériels (contre 6 pour l'A11 (dont 4 dont les performances en SIMD sont bridées)) alors le switch impose de sacrifier tout un marché.

2304 opérations flottantes par cycle pour un x86 (qui n'est pas le plus puissant des x86, mais les Xeon Phi à 144 threads ne seront jamais utilisés par Apple) contre 32 opérations flottantes par cycle pour un ARM, cela fait un sacré fossé à combler avant que le second puisse remplacer le premier.

A mon avis s'il y a des mac ARM ça restera des machines iOS qui devront cohabiter avec les mac OSX/x86. Juste une nouvelle gamme d'iPads munis de claviers fixes.

[SartMatt]

Intel préparerait pour 2020 une nouvelle puce combinant des cœurs classiques et des cœurs type Atom pour faire un système à la big.LITTLE : http://www.tomshardware.fr/articles/big.li...ld,1-67281.html

Ça va permettre de faire des PC ayant une autonomie similaire à celle de ces premières machines Windows ARM (autonomie qu'on atteint déjà avec des PC à base d'Atom), mais sans perte de performances en crête et sans restreindre la compatibilité logicielle...

[Webtourist]

Microsoft a fait un portage de Windows sur des puces ARM permettant de faire tourner des applications X86 32 bits sur ces processeurs.
La société a annoncé que cette limitation sauterait prochainement. Elle va proposer dans un futur proche un nouveau SDK qui sera capable de recompiler les applications 64 bits pour les faire tourner sur les PC ARM.
Il reste encore à convaincre les développeurs de faire ce portage, mais Microsoft semble confiant dans leur bonne volonté.

Voilà encore une information qui fera du tort à Intel qui pour la première fois depuis des décennies voit les bases de son avenir chanceler devant ces nouvelles tendances.

Lien vers le billet original

et dans 2 ans ils te proposent une version de windows à installer sur iPad.....

en fait c'est l'inverse
crosoft vend sur son store age of empires UN
win10 minimum requis
pas mal pour un jeu qui a 20 ans
https://www.microsoft.com/fr-fr/store/p/age...on/9n2kmdvlk85d

C'est une ré-édition de l'emblématique titre, qui tire partie des CPU et GPU récents (4K, davantage d'unités, etc...), donc des machines sous Win10.
Un peu normal qu'aujourd'hui les "nouveaux" jeux ne supportent pas forcément Win7, sorti il y a maintenant 9 ans, bientôt obsolète et ne supportant pas entièrement les CPU et GPU d'aujourd'hui!

Trouve moi un programme/jeux Apple sorti en 2017 et compatible avec SL (10.6), bon courage!

[iAPX]

Intel préparerait pour 2020 une nouvelle puce combinant des cœurs classiques et des cœurs type Atom pour faire un système à la big.LITTLE : http://www.tomshardware.fr/articles/big.li...ld,1-67281.html

Ça va permettre de faire des PC ayant une autonomie similaire à celle de ces premières machines Windows ARM (autonomie qu'on atteint déjà avec des PC à base d'Atom), mais sans perte de performances en crête et sans restreindre la compatibilité logicielle...

Il restera le problème du coût: la "taxe" Intel...

La situation ne sera plus tenable à un moment, avec des actionnaires exigeant des bénéfices (60% de marge brute en étant fondeur c'est quand-même énorme) alors que leurs concurrents en font peu et auront probablement besoine de moins de silicones pour des performances comparables (la complexité du jeu d'instruction x86 64bits et ses encodages a un prix lourd, même en terme de perfs puisqu'incapable de traduire autant d'instructions que capable d'en exécuter sur beaucoup de générations récentes)

Ce message a été modifié par iAPX - 9 Apr 2018, 14:20.

[SartMatt]

Intel préparerait pour 2020 une nouvelle puce combinant des cœurs classiques et des cœurs type Atom pour faire un système à la big.LITTLE : http://www.tomshardware.fr/articles/big.li...ld,1-67281.html

Ça va permettre de faire des PC ayant une autonomie similaire à celle de ces premières machines Windows ARM (autonomie qu'on atteint déjà avec des PC à base d'Atom), mais sans perte de performances en crête et sans restreindre la compatibilité logicielle...

Il restera le problème du coût: la "taxe" Intel...

Pas pire que la taxe Qualcomm ou qui que ce soit d'autre... Je te l'ai déjà expliqué l'autre jour, chiffres à l'appui, que les 60% de marge brut d'Intel ne sont pas exceptionnels dans ce secteur.

alors que leurs concurrents en font peu et auront probablement besoine de moins de silicones pour des performances comparables (la complexité du jeu d'instruction x86 64bits et ses encodages a un prix lourd, même en terme de perfs puisqu'incapable de traduire autant d'instructions que capable d'en exécuter sur beaucoup de générations récentes)

Alors là, je suis loin d'être convaincu... Il y a quelques années, en comparant la taille des puces, on pouvait voir qu'un Apple Cyclone dual core nécessitait plus de surface qu'un Atom quad-core (et bien plus de transistors d'après les chiffres officiels), alors même que ce dernier embarquait beaucoup plus de cache (cache qui occupait le gros de la surface)... Et c'est pareil chez Qualcomm.

La réalité, c'est qu'aujourd'hui si tu veux faire une puce ARM performante, tu ne peux plus te contenter d'une puce simple (on laisse ça aux puces "LITTLE"), mais au contraire, tu atteins des niveaux de complexité similaires au x86, parce que tu adoptes la même façon d'architecturer ta puce : décodage des instructions en micro-ops, réorganisation de ces micro-ops, fusion des micro-ops, pour au final les injecter dans le vraie cœur d'exécution, dont le jeu d'instructions n'a plus grand chose à voir avec celui exposé par les interfaces externes de la puce.

Tiens, juste pour comparaison, un Snapdragon 835, qui met deux fois plus de temps à démarrer Windows 10 qu'un i7 dual core, c'est 73mm² de silicium en 10 nm (pour 3 milliards de transistors). Un i7 hexa cœur avec 12 Mo de cache en 14nm, c'est à peine le double (et en nombre de transistors, on est du même ordre... Intel n'a pas communiqué le nombre, mais les estimations tournent autour de 2 à 4 milliards)... Et pour des performances qui sont très largement plus que doublées...

[iAPX]

...
Tiens, juste pour comparaison, un Snapdragon 835, qui met deux fois plus de temps à démarrer Windows 10 qu'un i7 dual core, c'est 73mm² de silicium en 10 nm (pour 3 milliards de transistors). Un i7 hexa cœur avec 12 Mo de cache en 14nm, c'est à peine le double (et en nombre de transistors, on est du même ordre... Intel n'a pas communiqué le nombre, mais les estimations tournent autour de 2 à 4 milliards)... Et pour des performances qui sont très largement plus que doublées...

On ne tire pas sur l'ambulance

Le fond est que pour le prix de juste une CPU de MBr 12" 1.4Ghz affublée de la sacro-sainte marge Apple de 40%, on peut avoir une CPU à base de jeu d'instruction ARM largement plus performante (A10X) surtout en multithreadé, dans un TDP similaire, et l'iPad Pro 10.5" qui va autour

Ce message a été modifié par iAPX - 9 Apr 2018, 17:34.

[Ambroise]

Il restera le problème du coût: la "taxe" Intel...
La situation ne sera plus tenable à un moment, avec des actionnaires exigeant des bénéfices (60% de marge brute en étant fondeur c'est quand-même énorme)

Intel sert des dividendes indécents, c'est vrai, mais ça n'est pas ce qui explique leurs coûts de fabrication élevés.
Lorsqu'ils ont voulu se lancer dans les processeurs pour smartphone à moins de 50$ il y a quelques années, ils n'ont eu d'autres choix que de faire fabriquer leurs Atom Sofia par TSMC simplement parce que le procédé 28nm de TSMC revenait à Intel trois fois moins cher que leur propre procédé 22nm. Il n'était pas question de marges ici : juste de la complète incapacité d'Intel à obtenir des coûts de fabrication compétitifs avec ceux d'un fondeur indépendant.

Et s'ils n'arrivent pas être compétitifs c'est que leurs procédés ont été conçus pour produire des composants logiques hautes performances mais sont sous-optimaux pour l'analogique. Les SoCs y coûtent des fortunes parce qu'au lieu d'y intégrer des IPs analogiques pour les composants qui font ce que sont les SoCs (PCIe, communications, température, arbres d'horloge...), tout y est développé dans de complexes et coûteuses versions numériques.

L'autre aspect limitant chez Intel c'est que les procédés de fabrication visant les hautes performances imposent des fabrications en un nombre élevé de couches, chaque couche pouvant nécessiter plusieurs expositions, et ces procédés complexes entraînant des règles d'organisation des éléments logiques très contraignantes qui peuvent nuire à la densité des designs. En somme ils peuvent tourner à 5Ghz, avoir des sous-parties qui tournent à 10Ghz, distribuer des courants forts en n'importe quel point tout en coupant alimentation et horloges des sous parties non utiles, mais en revanche les fabrications sont longues, complexes et coûteuses et les densités de transistors peuvent être faibles pour les clients qui ne seraient pas des spécialistes du design 3D.

Intel propose un procédé low cost (le 22nmFFL) dédié à la faible puissance avec de grandes capacités analogiques, des bibliothèques d’éléments logiques très riches et peu de contraintes spatiales - mais c'est une nouvelle approche chez Intel : les prix sont sans doute compétitifs mais les marges ne sont pas moins importantes pour autant.

[iAPX]

Il restera le problème du coût: la "taxe" Intel...
La situation ne sera plus tenable à un moment, avec des actionnaires exigeant des bénéfices (60% de marge brute en étant fondeur c'est quand-même énorme)

Intel sert des dividendes indécents, c'est vrai, mais ça n'est pas ce qui explique leurs coûts de fabrication élevés.
Lorsqu'ils ont voulu se lancer dans les processeurs pour smartphone à moins de 50$ il y a quelques années, ils n'ont eu d'autres choix que de faire fabriquer leurs Atom Sofia par TSMC simplement parce que le procédé 28nm de TSMC revenait à Intel trois fois moins cher que leur propre procédé 22nm. Il n'était pas question de marges ici : juste de la complète incapacité d'Intel à obtenir des coûts de fabrication compétitifs avec ceux d'un fondeur indépendant.

Et s'ils n'arrivent pas être compétitifs c'est que leurs procédés ont été conçus pour produire des composants logiques hautes performances mais sont sous-optimaux pour l'analogique. Les SoCs y coûtent des fortunes parce qu'au lieu d'y intégrer des IPs analogiques pour les composants qui font ce que sont les SoCs (PCIe, communications, température, arbres d'horloge...), tout y est développé dans de complexes et coûteuses versions numériques.

L'autre aspect limitant chez Intel c'est que les procédés de fabrication visant les hautes performances imposent des fabrications en un nombre élevé de couches, chaque couche pouvant nécessiter plusieurs expositions, et ces procédés complexes entraînant des règles d'organisation des éléments logiques très contraignantes qui peuvent nuire à la densité des designs. En somme ils peuvent tourner à 5Ghz, avoir des sous-parties qui tournent à 10Ghz, distribuer des courants forts en n'importe quel point tout en coupant alimentation et horloges des sous parties non utiles, mais en revanche les fabrications sont longues, complexes et coûteuses et les densités de transistors peuvent être faibles pour les clients qui ne seraient pas des spécialistes du design 3D.

Intel propose un procédé low cost (le 22nmFFL) dédié à la faible puissance avec de grandes capacités analogiques, des bibliothèques d’éléments logiques très riches et peu de contraintes spatiales - mais c'est une nouvelle approche chez Intel : les prix sont sans doute compétitifs mais les marges ne sont pas moins importantes pour autant.

Le problème, comme évoqué avec le cas de l'iPad Pro 10.5" (Apple A10X) et le MacBook retina 12" 1.4Ghz, c'est qu'Intel pourrait peut-être faire plus lent pour moins cher, mais ils sont déjà bien plus lents.

Et je suis d'accord qu'il y a quelque-chose de structurel chez Intel qui est bloquant pour pouvoir être compétitif sur les marché mobiles, et ça ne tient ni des compétences internes ni d'impossibilité, mais ça n'est tout simplement pas leur structuration.

[Ambroise]

Le problème, comme évoqué avec le cas de l'iPad Pro 10.5" (Apple A10X) et le MacBook retina 12" 1.4Ghz, c'est qu'Intel pourrait peut-être faire plus lent pour moins cher, mais ils sont déjà bien plus lents.

Les réflexions ultra simplistes ne mènent pas à grand chose. L'ipad pro donne de meilleurs scores que le macbook retina lorsque l'on utilise un benchmark qui favorise iOS sur OSX, mais ça n'indique rien sur la vitesse du processeur. Sur un OS mono-application, geekbench 4 charge le processeur à 100% et vide la batterie à vue d'oeil alors que sur un OS d'ordinateur il ne consomme rien. Je viens de le lancer sur le Surface Book 2 sur lequel je suis en train d'écrire et Geekbench 4 occupe 13% de temps CPU comment pourrait-on tirer la moindre info d'un benchmark aussi inadapté ?

Et sinon un procédé de fabrication low-cost et low-power ne donnera pas des processeurs plus lents : bien au contraire. Sur un macbook retina le CPU est utilisé dans un mode volontairement ultra bridé et il est construit avec des technos spécialisées pour les fonctionnements à pleine performance et les hautes fréquences.

[iAPX]

Le problème, comme évoqué avec le cas de l'iPad Pro 10.5" (Apple A10X) et le MacBook retina 12" 1.4Ghz, c'est qu'Intel pourrait peut-être faire plus lent pour moins cher, mais ils sont déjà bien plus lents.

Les réflexions ultra simplistes ne mènent pas à grand chose. L'ipad pro donne de meilleurs scores que le macbook retina lorsque l'on utilise un benchmark qui favorise iOS sur OSX, mais ça n'indique rien sur la vitesse du processeur. Sur un OS mono-application, geekbench 4 charge le processeur à 100% et vide la batterie à vue d'oeil alors que sur un OS d'ordinateur il ne consomme rien. Je viens de le lancer sur le Surface Book 2 sur lequel je suis en train d'écrire et Geekbench 4 occupe 13% de temps CPU comment pourrait-on tirer la moindre info d'un benchmark aussi inadapté ?

C'est ta façon d'analyser ce que fait geekbench 4 qui est ultra-simpliste, avec des outils inadéquats et sans comprendre ses patterns de fonctionnement, pire en prétendant qu'il favorise une plateforme plutôt qu'une autre, alors qu'étant basé sur du code existant en production, il devrait en théorie favoriser du x86 (et ce n'est pas le cas).
Quand à un OS d'ordinateur, il alloue la CPU quasiment à 100% au test sauf à ce que tu testes avec des applications chargées et qui consomment des ressources ce qui n'est pas le cas là.

Dans ton cas tu as une CPU avec 8 threads (probablement 4 cœurs et 8 threads), avec l'exécution d'un des tests mono-thread chargeant un core virtuel à 100% et un affichage de 13% qui parait totalement normal suivant les modalités de calculs de ce pourcentage (qu'il faudrait discuter sur des pages). faut prendre avec des pincettes les pourcentages de tous les outils qui veulent simplifier les affichages.

Et sinon un procédé de fabrication low-cost et low-power ne donnera pas des processeurs plus lents : bien au contraire. Sur un macbook retina le CPU est utilisé dans un mode volontairement ultra bridé et il est construit avec des technos spécialisées pour les fonctionnements à pleine performance et les hautes fréquences.

Il n'est pas plus bridé que dans le format physique et la batterie d'un iPad Pro, au contraire, son enveloppe de fonctionnement lui permet de débiter 18W en pointe pour un TDP réel au-dessus de 7W en continu, et je doute que dans un format d'iPad Pro 10.5" et avec sa batterie il puisse tourner aussi vite...

Ce message a été modifié par iAPX - 10 Apr 2018, 14:14.

[Ambroise]

moins de silicones pour des performances comparables (la complexité du jeu d'instruction x86 64bits et ses encodages a un prix lourd, même en terme de perfs puisqu'incapable de traduire autant d'instructions que capable d'en exécuter sur beaucoup de générations récentes)

Ce sont des arguments d'il y a 30 ans. Ils relevaient déjà du discours performatif à l'époque et les processeurs ont évolué depuis.
Il n'y a pas besoin de plus de silicium pour décoder un jeu x86 que pour un jeu RISC ultra simplifié depuis que les caches existent. Déjà parce que les étages de décodage d'un pipeline représentent une part insignifiante des transistors utilisés dans un CPU et surtout parce qu'un jeu d'instruction comme celui d'ARM (or Thumb) peut demander 100% de taille de code en plus par rapport à un x86 (codage moins efficace d'instruction, nécessité d'utiliser davantage d'instructions pour faire le même travail) ce qui implique des caches externes (et internes si le jeu d'instruction n'est pas microcodé) plus gros (et à 32 transistors par octet de cache ça chiffre vite).

Les principales architectures de CPU qui prétendent produire de la puissance sont aujourd'hui passées à la traduction d'instructions comme le font les processeurs CISC depuis les années 70. Elles ont du coup des décodeurs complexes qui transforment un jeu d'instruction externe en jeu interne optimisé pour les contraintes matérielles des CPUs modernes. De ce point de vue, le x86 présente un avantage fort : il est optimisé pour l'usage externe avec une forte densité de code et il convoie beaucoup plus d'information de haut niveau que les jeux ARM qui ont été conçus eux (jusqu'au v7, le jeu ARM 64 bits est moins contraint de ce point de vue là) pour être efficaces en interne, alors même qu'ils ne sont plus utilisés qu'en externe.

J'ai pu le voir il y a peu en faisant de la cross-compilation vers une cible ARM depuis un AMD64. Une fonction de bas niveau executée sur AMD64 s'effondrait totalement en perf sur ARMv8 (code 1500% plus gros, performances 200 fois plus faibles). Et l'illustration est simple (et facilement reproductible sur mac en visant l'iphone) :
Cette fonction toute simple se contente de compter les bits d'un entier 32 bits :

Code

#include <cstdint>

auto bitcount(uint32_t n)  {
    auto count = 0;
   while (n)  {
      ++count;
      n &= (n - 1);
   }
   return count;
}

Bien sûr Clang identifie facilement les invariants et optimise (-O3) sans difficulté en produisant en bytecode LLVM une représentation de décomptage de bits.
Une fois passé en ARM on obtient :

Code

bitcount(unsigned int):
        mov     w2, 0
        cbz     w0, .L1
.L3:
        sub     w1, w0, #1
        add     w2, w2, 1
        ands    w0, w0, w1
        bne     .L3
.L1:
        mov     w0, w2
        ret

mouais. Pas top. On voit qu'il faudra de nombreux cycles d'horloge pour décompter ces bits : même une fois que le décodeur de l'ARM aura réussi à fusionner le add et le ands.

Que se passe-t-il du côté du x86 ?

Code

bitcount(unsigned int):
        popcnt  eax, edi
        ret

Oui : une seule instruction : c'est ça le CISC.
A l'usage il n'y a même aucun call (ni ret) lorsqu'on appelle cette fonction, le compilateur préférant le remplacer directement par popcnt.
Et en interne le x86 traduit cette instruction en une uop à peu près identique. L'information de haut niveau est conservée de bout en bout et il existe plusieurs centaines d'autres cas ou des instructions complexes convoient le même genre de richesse.


Le jeu ARM a perdu l'information sur le comptage de bits et il ne peut pas la reproduire. Et en plus de fournir un code largement plus lourd et plus lent, cela impose des contraintes lourdes : sur du code multithreadé la version ARM sera exposée à des race conditions et nécessitera d'user de coûteuses barrières mémoires alors que la version popcnt peut être atomique.

[iAPX]

moins de silicones pour des performances comparables (la complexité du jeu d'instruction x86 64bits et ses encodages a un prix lourd, même en terme de perfs puisqu'incapable de traduire autant d'instructions que capable d'en exécuter sur beaucoup de générations récentes)

Ce sont des arguments d'il y a 30 ans. Ils relevaient déjà du discours performatif à l'époque et les processeurs ont évolué depuis.
...

Je ne reproduirais pas l'exemple aimablement choisi par mon interlocuteur (et visiblement écrit par lui-même ce qui m'en raconte beaucoup), car il reste que sur le même code C utilisé principalement sur X86, et utilisé par Geekbench 4, un Apple A11 2-core/2thread à 2.3Ghz dans un simple iPhone 8 est aussi rapide qu'une CPU de MacBook Pro retina 13" 2-core/4-thread à 3.1Ghz même sur du multithreadé: c'est ça la réalité des choses, même si d'aucun trouveront toujours un contre-exemple.

Quand à mes arguments d'il y a 30ans, ils sont plutôt récents, puisqu'il y a des limites de traduction "décodage" d'instructions sur de nombreuses générations de CPU Intel X86 depuis les Core™2 et jusqu'aux dernières, leur empêchant hors des boucles de remplir leurs unités d'exécutions, leur meilleures performances étant dans des boucles courtes où là les instructions x86 ne plus à traduire "décoder" mais il utilise son jeu d'instruction interne VLIW (là on est loin du CISC ).

On peut argumenter sur les raisons, moi je présage que le jeu d'instruction puisse être un facteur permettant aux CPU Apple A11 d'être plus performantes par cycle (de loin), il n'est probablement pas le seul car son architecture interne doit être aussi éloigné de la plupart des autres architectures ARM qu'un Core™2 devait l'être d'un Pentium 4.
Mais il n'en reste pas moins que d'évidence ça poutre déjà dans un facteur de taille et de TDP d'iPhone 8, et que la version A11X qui devrait arriver dans de futurs iPad Pro devrait faire très fort avec un cœur ou deux en plus et un TDP revu à la hausse.

Quand aux tests choisi pour démontrer que l'un est meilleur que l'autre, au lieu de leur faire exécuter un travail courant avec du code existant tel-que et voir ce qu'il se passe, remplaçant cela par du C de débutant, je me permettrais au moins de corriger l'impétrant en lui signalant que ce genre de function s'écrit comme ça et s'inline très bien ou peut être utilisée en macro:

Code

  v = v - ((v >> 1) & 0x55555555);                    // reuse input as temporary
  v = (v & 0x33333333) + ((v >> 2) & 0x33333333);     // temp
  c = ((v + (v >> 4) & 0xF0F0F0F) * 0x1010101) >> 24; // count

PS: @Ambroise ton texte est plus brillant que ton code et en le lisant on pourrait croire qu'une CPU plus lente est plus rapide. Mais les faits sont têtus!

Ce message a été modifié par iAPX - 11 Apr 2018, 14:12.