Mac: Apple pourrait annoncer sa transition vers ARM lors de la WWDC, Réactions à la publication du 09/06/2020

[iSpeed]

Attendez avant de critiquer et puis si ça vous plaît pas, MB deviendra WinBidouille

[lolo-69]

Bon, ce sera le coup de grâce me concernant... J'attend que mon dernier Mac claque et adieu la Pomme.

[Fars]

du coup, c'est pas le moment d'acheter un mac...

Au contraire, il faudra acheter un des derniers Mac Intel pour la compatibilité avec le reste du monde.
Ensuite, quand il sera obsolète, je passerais sans vergogne à Windows ou Linux.

C’est ce que j’ai fait il y a presque un an.
Et pour mon usage perso, rien de tel que linux pour retrouver une ame d’enfant.
4 machines à la maison, transition faite, et tout le monde est content.

[SartMatt]

Pour ma part, je pense qu'il y a beaucoup de fantasmes avec l'ARM.

OK, Les puces ARM ont progressé à un rythme intéressant mais ... elles n'ont fait que rattraper les puces Intel, alors qu'Intel fait visiblement face à un mur technologique.

Pourquoi, une fois Intel rejoint et ce mur atteint, ARM pourrait-il le franchir "si" aisément ? Corollaire, pourquoi Intel se sachant concurrencé et rattrapé, n'aurait-il pas compris comment ARM pourrait le doubler ?

Tout a fait.

Il y a une bonne analogie pour comprendre ça, c'est celle du sportif débutant. Un ado qui déciderait de se lancer dans une carrière de sprinter, au début, il va voir se performances augmenter rapidement, et son écart avec le record du monde du 100 mètres va rapidement fondre. C'est pas pour autant, aussi prometteur soit-il, qu'il va réussir à battre ce record...

Que les puces soient plus adaptées à une progression en terme de puissance par Watt est possible. Mais en terme de "puissance" pure (ce qui semble l'élément qui motive les enthousiaste pour l'ARM), je suis plus que sceptique.

On a d'ailleurs bien vu avec les quelques tentatives d'incursion d'ARM dans le marché serveur que pour pouvoir venir titiller les performances d'un Xeon d'entrée de gamme, c'est bel et bien l'efficacité énergétique qui a dû être sacrifiée, avec en conséquence une efficacité énergétique en usage réel inférieure à celle des Xeon les mieux optimisés...

Et à l'inverse, dans l'autre sens, en simplifiant ses puces et en sacrifiant les performances, Intel a réussi à égaler l'efficacité énergétique des puces ARM mobiles.

Il n'y a pas de miracle, il n'y a que des murs et des difficultés croissantes à mesures qu'on s'en approche. Et le débat sur quelle est l'approche la plus efficiente entre le RISC et le CISC n'a plus lieu d'être depuis longtemps : les processeurs performants d'aujourd'hui, il n'y en a pas un seul qui soit réellement RISC et pas un seul qui soit réellement CISC, les hautes performances passent systématiquement par un mécanisme de découpage-réordonnancement-regroupement d'instructions, avec un cœur d'exécution travaillant en réalité avec un jeu d'instructions n'ayant plus grand chose à voir avec celui exposé en externe...

[vlady]

Attendez avant de critiquer et puis si ça vous plaît pas, MB deviendra WinBidouille

Tout le monde sait que ça sera : fin, avec la connectique minimaliste (fait pour vendre du iCloud et autres services), bourré de colle, quasi-irréparable, flanqué d'un T2 (ou similaire encore plus obscure) et cher (vu le prix du clavier pour iPad).

[ericb2]

Après quelques années de recul, et vu comment la chose s'installait, je suis prêt à parier que Rosetta est implémenté en hardware, et qu'on nous a gentiment fait croire que c'était du logiciel.

Et quel était ce hardware ? Une unité cachée dans les processeurs Intel, rien que pour Apple ? Un circuit dédié que personne n'aurait jamais découvert sur la carte mère des Mac Intel ? Ça ne tient pas debout. La vitesse de Rosetta vient du fait qu'il fonctionne sur le même principe qu'un JIT — une fois un block de code converti en x86, il est exécuté nativement.

Sérieusement, tu saurais tout ce qu'il y a dans les processeurs Intel ?

Je ne serais absolument pas choqué qu'Apple ait fait implémenter un module sur mesure, sinon une "feature " hardware, à activer online avec toutes les précautions possibles. D'ailleurs, il y a bien la possibilité de passer little endian <-> big endian en temps réel dans les x86 et descendants, donc je ne serais absolument pas surpris si ça existait.

Pour ce qui est des "unités dédiées" n'importe quel processeur ARM, c'est exactement ça : du sur mesure. Alors pourquoi Intel qui est sur place, et dans la logique America first, n'aurait pas pu le faire ? Ce ne sont pas les américains qui ont inventé le poker (j'y croyais mais non) mais qu'est-ce qu'ils jouent bien !


Juste un exemple, tout ce qui est embarqué pour faire du décodage matériel, c'est prêt pour des années (hevc etc). Et comme par hasard, quasiment rien n'est accessilble sous Linux. Mais c'est là, et bien là, et c'est carrément impressionnant. C'est tellement moins difficile d'avoir de l'avance quand on a le mode d'emploi et les clés !


(https://github.com/intel/media-driver/ => regarder ce qui est accessible "librement" )

Ce message a été modifié par ericb2 - 9 Jun 2020, 20:32.

[jeremos]

C'est tout le contraire. macOS, c'est petit et replié sur soit par rapport à Linux.

Pour la partie serveur, oui, tu as totalement raison, c'est vrai.
Pour le desktop et pour un utilisateur de macos, tu conseilles quelle distrib ?

[SartMatt]

Après quelques années de recul, et vu comment la chose s'installait, je suis prêt à parier que Rosetta est implémenté en hardware, et qu'on nous a gentiment fait croire que c'était du logiciel. Quand je vois tout ce que Intel cache à Linux avec l'accélération matérielle (je suis dans VAAPI depuis plusieurs mois pour dire ça), ce serait dans ... l'ordre des choses.

Nope, c'était 100% logiciel, développé par une boîte anglaise, qui a été rachetée par IBM quelques années plus tard (j'ai un collègue qui a bossé sur des projets pour IBM avec les gens de cette boîte après le rachat).

D'ailleurs, ça marchait très bien sur des hackintosh, y compris avec des CPU AMD, preuve qu'il ne fallait aucun matériel spécifique.

La vitesse de Rosetta vient du fait qu'il fonctionne sur le même principe qu'un JIT — une fois un block de code converti en x86, il est exécuté nativement.

Et aussi le fait que les premiers Mac Intel avaient des CPU beaucoup plus puissants que les derniers Mac Power, donc forcément, même si le code produit n'était pas optimisé au mieux, ça pouvait quand même tourner plus vite que sur les Power.

Et faut pas oublier que la traduction n'était nécessaire que pour le code de l'application, tous les appels aux API de Mac OS étaient routés directement vers les implémentations Intel de ces API.

Pour le desktop et pour un utilisateur de macos, tu conseilles quelle distrib ?

Si j'en crois cet outil d'aide à la décision, Chrome OS :

 2020_06_08.jpeg ( 24.81 Ko ) Nombre de téléchargements : 72

[ericb2]

@sarmatt

"D'ailleurs, ça marchait très bien sur des hackintosh, y compris avec des CPU AMD, preuve qu'il ne fallait aucun matériel spécifique."

Je veux bien te croire, surtout que tu en sais plus que moi sur le sujet, mais n'y a-t-il pas une grosse base commune entre AMD et Intel au niveau des instructions ?

[SartMatt]

Je ne serais absolument pas choqué qu'Apple ait fait implémenter un module sur mesure, sinon une "feature " hardware, à activer online avec toutes les précautions possibles.

Rosetta tourne aussi sur CPU AMD.

D'ailleurs, il y a bien la possibilité de passer little endian <-> big endian en temps réel dans les x86 et descendants, donc je ne serais absolument pas surpris si ça existait.

L'endianess n'est qu'une toute petite fraction du problème...

Et à quoi fait tu références quand tu parles de switcher l'endianess en temps réel sur les x86 ? Les x86 n'ont pas la même endianess selon qu'on est en 16, 32 ou 64 bits, mais il ne me semble pas qu'ils soient bi-endian dans l'un de ces 3 modes. Et les CPU qui sont bi-endian (ARM et Power 64 notamment) ne supportent à ma connaissance pas la bascule en temps réel, faut choisir le mode à l'initialisation (une bascule temps réel, ce serait compliqué, puisque il faudrait pour chaque donnée stockée en mémoire savoir si elle doit être traitée comme du big ou du little...) et ensuite c'est au mieux un mode différent en fonction du process qui tourne, mais pas une bascule en temps réel.

Pour ce qui est des "unités dédiées" n'importe quel processeur ARM, c'est exactement ça : du sur mesure.

Un processeur ARM, c'est tout sauf ça... Avoir des unités spécifiques, gérant un jeu d'instruction différent du jeu d'instruction ARM, c'est strictement interdit sur un CPU ARM (interdit par les conditions de licence d'ARM). Dès que tu veux gérer ne serait-ce qu'une instruction qui n'est pas dans le jeu d'instruction ARM, ça doit passer par un co-processeur (même si physiquement, tu peux l'intégrer dans la même puce bien entendu), avec toutes les conséquences que ça implique (I/O pour les échanges de données entre CPU et co-CPU, ce dernier n'ayant accès directement ni à la RAM, ni aux caches, et encore moins aux registres). C'est ce qu'avait du faire Intel pour ajouter le MMX sur ses CPU ARM, avec du coup des performances très en deça du MMX x86.

[vlady]

C'est tout le contraire. macOS, c'est petit et replié sur soit par rapport à Linux.

Pour la partie serveur, oui, tu as totalement raison, c'est vrai.
Pour le desktop et pour un utilisateur de macos, tu conseilles quelle distrib ?

Ubuntu, c'est pas mal je trouve. Mais je commence à vraiment à m’intéresser à Manjaro (basé sur Arch, rolling release donc), je trouve le design de Manjaro plus fin, plus soigné. Pop OS c'est bien aussi (surtout pour les jeux, car intègre les drivers Nvidia et AMD). Elementary OS c'est un peu dans l'esprit de macOS, mais je n'aime pas trop, je préfère une rupture plus nette, autre chose.

[SartMatt]

"D'ailleurs, ça marchait très bien sur des hackintosh, y compris avec des CPU AMD, preuve qu'il ne fallait aucun matériel spécifique."

Je veux bien te croire, surtout que tu en sais plus que moi sur le sujet, mais n'y a-t-il pas une grosse base commune entre AMD et Intel au niveau des instructions ?

La base commune, c'est le jeu d'instructions x86 justement. Si Intel avait ajouté en douce un support du jeu d'instructions Power sur ses CPU, pourquoi AMD l'aurait-elle fait de son côté ? Aucune raison de le faire, puisqu'elle n'aurait pas été au courant (on part du principe que c'est caché, c'est toi même qui le dit), et quand bien même elle aurait appris que ça existe, pourquoi donc se serait-elle fait chier à l'implémenter dans ses CPU (avec en plus du coup une licence à payer pour utiliser ce jeu d'instructions...) alors qu'Apple n'en est pas client ?

Surtout que si on en croit les témoignages sur le forum d'osx86project, Rosetta peut notamment tourner sur l'Athlon 64 2800+ (avec juste un patch pour permettre à Rosetta de tourner sur un CPU sans SSE3), un CPU sorti en avril 2004, donc plus d'un an avant l'annonce du passage des Mac à Intel et deux ans avant le premier Mac Intel (EDIT : et même un témoignage de fonctionnement de Rosetta sur un P4 Willamette, la toute première version du P4, sortie fin 2000 !).

Et puis 15 ans plus tard, il n'y aurait toujours personne pour indiquer que c'était géré en hardware, parmi les centaines de personnes qui auraient forcément été au courant ? Et parmi les dizaines de milliers de gens qui décortiquent le fonctionnement des systèmes, personne qui n'aurait remarqué que ça repose sur une unité hardware ?

Enfin, accessoirement... pourquoi le cacher ? Pourquoi prétendre que c'est logiciel si ça ne l'est pas ?

Ce message a été modifié par SartMatt - 9 Jun 2020, 20:56.

[ericb2]

Ben moi je me souviens de l'unité de calcul en virgule flottante, que NVidia n'avait pas cru bon d'inclure dans je sais plus quel proc, et ça a mis le bord... pendant plusieurs années dans les distributions Linux, en particulier pour les applications qui avaient besoin de cette unité.

En fait, quand je parle d'unité, c'est plutôt en termes de fonctionnalités : avec une carte de développement de telle marque, tu auras du SATA, avec une autre, non etc

[SartMatt]

En fait, quand je parle d'unité, c'est plutôt en termes de fonctionnalités : avec une carte de développement de telle marque, tu auras du SATA, avec une autre, non etc

Oki. C'est pas ça qu'on appelle unité dans un CPU. Ce dont tu parles, ce sont des circuits externes au CPU (même si, comme déjà dit plus haut, ils peuvent être intégrés dans la même puce physiquement), qui sont pilotés par le CPU, il n'y a pas directement dans le flux d'instruction du programme des instructions qui sont exécutées sur ces circuits externes.

[ericb2]

@Sarmatt

"La base commune, c'est le jeu d'instructions x86 justement. Si Intel avait ajouté en douce un support du jeu d'instructions Power sur ses CPU, pourquoi AMD l'aurait-elle fait de son côté ? "

Je sais pas, mais est-ce vraiment inconcevable ?

"Aucune raison de le faire, puisqu'elle n'aurait pas été au courant (on part du principe que c'est caché, c'est toi même qui le dit), "


Quand je dis caché, c'est pour du point de vue du commun des mortels (des non-spécialistes, comme moi). Encore une fois, on ne sait pas grand chose des brevets échangés entre les boîtes. Et ce qu'il y a dedans (le processeur) n'est pas vérifiable, au moins facilement.


" et quand bien même elle aurait appris que ça existe, pourquoi donc se serait-elle fait chier à l'implémenter dans ses CPU (avec en plus du coup une licence à payer pour utiliser ce jeu d'instructions...) alors qu'Apple n'en est pas client ?"

À l'époque, c'était peut être encore possible ? Ce n'est pas Microsoft qui recevait des camions de Macs à l'époque ?


"Surtout que si on en croit les témoignages sur le forum d'osx86project, Rosetta peut notamment tourner sur l'Athlon 64 2800+ (avec juste un patch pour permettre à Rosetta de tourner sur un CPU sans SSE3), un CPU sorti en avril 2004, donc plus d'un an avant l'annonce du passage des Mac à Intel et deux ans avant le premier Mac Intel."

Donc tu veux dire que rosetta peu se contenter d'un vieux jeu d'instructions pour fonctionner (ou plutôt peut tourner quand même en émulant le jeu d'instructions SSE3) , c'est bien ça ?


Pas eu le temps de voir, alors je réponds là :


"Enfin, accessoirement... pourquoi le cacher ? Pourquoi prétendre que c'est logiciel si ça ne l'est pas ? "


1. Apple c'est la religion du secret, et il y a des gens très discrets quand même

2. ça fonctionnait vraiment bien. Après l'avoir enlevé, pourquoi ne pas le garder dans un coin, et le ressortir un jour, au cas où ?

... ça marchait tellement bien


Ce message a été modifié par ericb2 - 9 Jun 2020, 21:11.

[SartMatt]

"La base commune, c'est le jeu d'instructions x86 justement. Si Intel avait ajouté en douce un support du jeu d'instructions Power sur ses CPU, pourquoi AMD l'aurait-elle fait de son côté ? "

Je sais pas, mais est-ce vraiment inconcevable ?

Ce serait vraiment extrêmement surprenant oui. Parce que ça voudrait dire qu'AMD a intégré ça en gros juste pour les hackintosh. Mais sans le dire, donc sans pouvoir en tirer un avantage commercial...

Et ce qu'il y a dedans (le processeur) n'est pas vérifiable, au moins facilement.

C'est au contraire assez facile pour pas mal de gens d'analyser le code binaire d'une application pour voir ce qu'elle fait, et notamment y détecter l'utilisation d'instructions qui ne seraient pas publiques...

Or justement, le code de Rosetta, on sait qu'il est passé entre les mains de connaisseurs, qui l'ont notamment modifié pour le rendre non dépendant du jeu d'instructions SSE3 et permettre ainsi son exécution sur une plus vaste gamme de CPU x86, ceux se limitant au SSE2.

" et quand bien même elle aurait appris que ça existe, pourquoi donc se serait-elle fait chier à l'implémenter dans ses CPU (avec en plus du coup une licence à payer pour utiliser ce jeu d'instructions...) alors qu'Apple n'en est pas client ?"

À l'époque, c'était peut être encore possible ? Ce n'est pas Microsoft qui recevait des camions de Macs à l'époque ?

Hautement improbable. AMD était trop petit pour qu'Apple opte pour ses CPU.

Quand à des Mac chez Microsoft à l'époque, il y a là une explication tout a fait rationnelle, puisque non seulement Microsoft a toujours développé des applications Mac, donc avait besoin de Mac en interne, mais en plus le Power Mac était le kit de développement officiel pour la Xbox 360, qui date de cette époque (mais ce SDK à base de Power Mac n'avait d'Apple que le matériel, l'OS était un OS Microsoft, dérivé de l'OS Xbox 360), donc Microsoft devait se faire livrer ces Power Mac et y installer le SDK de la Xbox avant de le renvoyer aux studios de développement de jeux.

Donc tu veux dire que rosetta peu se contenter d'un vieux jeu d'instructions pour fonctionner (ou plutôt peut tourner quand même en émulant le jeu d'instructions SSE3) , c'est bien ça ?

De base, Rosetta utilise SSE3. Certains membres de la communauté hackintosh ont modifié les portions de Rosetta dépendant de SSE3 pour les faire tourner sans SSE3 (au prix bien sûr de performances légèrement réduites).

Avec ce patch, Rosetta tourne sur les CPU x86 avec SSE2 (à partir du Pentium 4, fin 2000, chez Intel et de l'Athlon 64, fin 2003, chez AMD). Donc s'il y a dans les CPU x86 une implémentation secrète du jeu d'instructions Power PC pour Rosetta, elle date d'au moins 2000, cinq ans avant l'annonce du Mac Intel, 6 ans avant sa sortie... Et même avant la sortie de Mac OS X desktop... Et encore, ces CPU sortis fin 2000, ils étaient quasi finalisés un an plus tôt...

1. Apple c'est la religion du secret, et il y a des gens très discrets quand même

Sauf que justement, le cœur de Rosetta n'a pas été développé par Apple, mais par Transitive, une start-up anglaise qui a depuis été rachetée par IBM. À noter que le logiciel de Transitive permet aussi de gérer d'autres traductions, dont le Sparc vers x86 (utilisé par Sun pour version x86 de Solaris) et le x86 vers Power (d'où le rachat par IBM, qui était intéressé par cette partie), ce qui rend encore plus compliquée l'hypothèse d'une implémentation sous-jacente en hard, puisque ça impliquerait le support des instructions Sparc par les CPU x86 et celui des instructions x86 par les CPU Power...

Et surtout, il y a une différence entre secret et mensonge... Cacher que c'est matériel, sans donner aucun détail technique, ça serait juste du secret. Prétendre que c'est logiciel et donner des détails techniques sur cette implémentation logicielle, alors que c'est du matériel, ça n'est pas du secret, c'est du mensonge...

2. ça fonctionnait vraiment bien. Après l'avoir enlevé, pourquoi ne pas le garder dans un coin, et le ressortir un jour, au cas où ?

Au cas où quoi ? Et en quoi le fait de l'enlever et de le garder dans un coin accréditerait la thèse d'une implémentation matérielle secrète ? Un logiciel, on peut pas l'enlever et le garder dans un coin ?

Et ça fonctionnait vraiment bien parce que les CPU Intel étaient beaucoup plus rapides que les PowerPC, parce que c'était pas de l'émulation (comme rappelé plus haut, c'était du JIT, le binaire était "traduit" en binaire Intel puis c'est le binaire Intel qui était exécuté directement, même si forcément du coup le code était moins bien optimisé que s'il était compilé à partir des sources, ça reste bien plus efficace que de l'émulation... c'est l'approche qu'on retrouve d'ailleurs aujourd'hui dans Windows ARM pour faire tourner des applications x86) et parce que tous les appels aux API fournies par le système étaient faits directement en natif avec du code optimisé (le même que celui utilisé par les application nativement x86).

Ce message a été modifié par SartMatt - 9 Jun 2020, 21:51.

[ericb2]

Merci beaucoup pour toutes ces précisions, c'était vraiment intéressant

[ekami]

Après quelques années de recul, et vu comment la chose s'installait, je suis prêt à parier que Rosetta est implémenté en hardware, et qu'on nous a gentiment fait croire que c'était du logiciel.

Et quel était ce hardware ? Une unité cachée dans les processeurs Intel, rien que pour Apple ? Un circuit dédié que personne n'aurait jamais découvert sur la carte mère des Mac Intel ? Ça ne tient pas debout. La vitesse de Rosetta vient du fait qu'il fonctionne sur le même principe qu'un JIT — une fois un block de code converti en x86, il est exécuté nativement.

En effet, Rosetta était strictement logiciel, on pouvait d'ailleurs choisir de l'installer ou pas lors de l'installation d'OSX.
Apple avait racheté la startup à la base du projet pour en faire le bijou de technologie logicielle que l'on a connu à l'époque.

[Sethy]

Merci beaucoup pour toutes ces précisions, c'était vraiment intéressant

Je suis bien d'accord et ... pour une fois ... sans invective !

[MixUnix]

Pour ma part, je pense qu'il y a beaucoup de fantasmes avec l'ARM.
OK, Les puces ARM ont progressé à un rythme intéressant mais ... elles n'ont fait que rattraper les puces Intel, alors qu'Intel fait visiblement face à un mur technologique.

Carrément vrai, et c'est aussi bon moyen de générer de l'obsolescence et dire "allez maintenant vous allez tous [ou presque] racheter un mac" !

Dans la même série, pourquoi n'a t on plus trouvé de mac pro 2013 sur les refurbs d'apple à partir de l'annonce du 2019 si ce n'est pour autoriser une obsolescence au plus tôt de cette machine ?

Je n'ai aucune envie de revenir à Windows.... et j'ai des gros doutes sur le niveau de Linux par rapport à MacOS... tant en OS qu'en offre soft.

Le sentiment de dépendance est de plus en plus insupportable !

C'est tout le contraire. macOS, c'est petit et replié sur soit par rapport à Linux. Apple, lui même, utilise Linux (et pas macOS) dans ses data centers. Même les lanceurs SpaceX sont animés par Linux. Question finition, logiciels, effectivement la transition peut être difficile, surtout si on est dépendant de certains softs spécifiques à la plateforme Apple ou de la suite Adobe. Autrement, t'as le matos que tu veux (ou presque), c'est performant et robuste (et reparable), ça s'installe et s'upgrade en rien de temps, docker est en natif, la suite de JetBrains et dispo, ...

J'ai fait le saut définitif vers Linux, et Windows 10 en dépannage éventuel, et je ne le regrette pas.
J'ai toute la bureautique, encodage audio, gestion photos en Raw, montage vidéo, gestion des Synology, toutes fonctions Web, et logiciels de communication les plus divers et récents, gestion à distance, vidéo-conférences diverses....
Des langages pour coder, de quoi rigoler, quoi !
Je n'ai nul besoin maintenant d'un autre OS.
J'ai un PC super performant , bien construit, et facile d'entretien, What else ?
EDIT: je zieute les minicartes à proc ARM que l'on commence a voir apparaitre, pour tester et ajouter au plaisir, Un ami en a une en Mini ITX, Ça a l'air sympa .


Ce message a été modifié par MixUnix - 9 Jun 2020, 23:21.

[SartMatt]

Apple avait racheté la startup à la base du projet pour en faire le bijou de technologie logicielle que l'on a connu à l'époque.

Non, Apple avait juste une licence sur le produit. C'est IBM qui a racheté la boîte, en 2009.

[Cochonou]

Il n'y a pas de miracle, il n'y a que des murs et des difficultés croissantes à mesures qu'on s'en approche. Et le débat sur quelle est l'approche la plus efficiente entre le RISC et le CISC n'a plus lieu d'être depuis longtemps : les processeurs performants d'aujourd'hui, il n'y en a pas un seul qui soit réellement RISC et pas un seul qui soit réellement CISC, les hautes performances passent systématiquement par un mécanisme de découpage-réordonnancement-regroupement d'instructions, avec un cœur d'exécution travaillant en réalité avec un jeu d'instructions n'ayant plus grand chose à voir avec celui exposé en externe...

Il n'y a pas de miracle, mais il y a de la technologie... car tout le monde ne joue pas tout à fait à armes égales. La situation actuelle, c'est que TSMC domine Intel depuis deux ans. Le 5 nm TSMC est déjà là, avec des PMOS en SiGe ! Et c'est Intel qui a du mal à s'en rapprocher... même si son retard reste encore relatif.

[kenzo05000]

On va donc avoir droit a des IPhones de 21 pouces ?
Bien sûr encore plus collés .....
A jailbreaker si on veut en faire quelque chose d'interdit par la Sainte Pomme ......
Je viens de finir de monter un PC, faudra que je m'habitue a Windows 10....

[Grib]

Bon, et bien si ça se confirme, je n'ai plus qu'à faire durer mes deux Hackintosh le plus longtemps possible.
Ensuite, ce sera Linux pour l'utilisation de base (Photos, mails, agenda, films, musique, bureautique), ce que je fais déjà sur mon laptop.
Et Windows pour la MAO, avec un ordi déconnecté du net, histoire d'éviter les virus (pas envie d'installer un antivirus qui va ralentir ma bécane), à moins que d'ici là les développeurs s'intéressent un peu plus à Linux.
J'avais déjà lâché le hardware Apple à cause de son prix et son manque d'évolutivité, mais bon, MacOS me manquera car c'est quand même le système le plus stable et ergonomique que je connaisse.

Ce message a été modifié par Grib - 10 Jun 2020, 00:23.

[Guest_dtb06_*]

Cool ! On pourra mettre Android sur les Macs ! Une nouvelle génération de Hackintosh arrive !!

[Bunios]

On a d'ailleurs bien vu avec les quelques tentatives d'incursion d'ARM dans le marché serveur que pour pouvoir venir titiller les performances d'un Xeon d'entrée de gamme, c'est bel et bien l'efficacité énergétique qui a dû être sacrifiée, avec en conséquence une efficacité énergétique en usage réel inférieure à celle des Xeon les mieux optimisés...

Et à l'inverse, dans l'autre sens, en simplifiant ses puces et en sacrifiant les performances, Intel a réussi à égaler l'efficacité énergétique des puces ARM mobiles.

Il n'y a pas de miracle, il n'y a que des murs et des difficultés croissantes à mesures qu'on s'en approche. Et le débat sur quelle est l'approche la plus efficiente entre le RISC et le CISC n'a plus lieu d'être depuis longtemps : les processeurs performants d'aujourd'hui, il n'y en a pas un seul qui soit réellement RISC et pas un seul qui soit réellement CISC, les hautes performances passent systématiquement par un mécanisme de découpage-réordonnancement-regroupement d'instructions, avec un cœur d'exécution travaillant en réalité avec un jeu d'instructions n'ayant plus grand chose à voir avec celui exposé en externe...

Malgré qu'ARM se soit attaqué au marché des serveurs il y a peu, il ne sait effectivement pas imposé. Donc j'ai du mal à comprendre cet engouement pour ARM à avoir un Mac ARM. De plus comme tu le soulignes aussi (Sethy aussi), on est face à un mur. La visibilité d'ARM est peut-être de l'ordre de 1 an voir 2 tout au plus....mais après !!! Le mur n'est plus très loin "à priori" pour ARM aussi. J'avoue que ça me laisse perplexe tout ça. Après on ne voit pas d'autre technologie poindre actuellement pour supplanter ces technologies de gravure. Que ce soit du côté d'ARM et surtout d'Intel. Ce dernier faisant pas mal de surplace.

J'ai bien lu un petit article sur une nouvelle technologie si je me souviens sur les nanotubes de carbone mais ce n'est pas totalement au point pour la production.

A+

Ce message a été modifié par Bunios - 10 Jun 2020, 04:39.

[martremblay]

En ce qui me concerne, je suis sur mac intel pour ces raisons :
. machines virtuelles windows
. macos

Si la transition vers ARM se concrétise, je perds la première raison.
Si Catalina n'est pas remplacé par un système stable, je perds la seconde raison.
Après avoir perdu les connecteurs standard et la possibilité de remplacer batterie, SSD et mémoire, ça fait beaucoup trop…

Bref, deux solutions possibles :
. Acheter un dernier mac intel puis me tourner vers le monde PC, en win ou en linux. mais pas sous Catalina !
. Attendre la fin de mes macs actuels puis me tourner vers le monde PC, en win ou en linux.

Les iPhones ont quitté la maison (4), les macs ne sont plus remplacés depuis 2013, apple ne veut sans doute plus de moi…

[erik]

C’est curieux personne n’émet l’hypothèse que Apple pourrait continuer sur Intel tout en ajoutant une gamme sur ARM. Car en fait, il y a énormément de gens qui utilisent leur ordinateur à des fins bureautiques, vaguement un peu d’organisation de photothèque de vacances et bibliothèque musicale. Pour ces gens qui n’ont pas besoin de faire tourner des logiciels complexes qui mettront du temps à être au point sur ARM, une machine portale avec une autonomie énorme, assez rapide et légère leur plaira sûrement.

[Herriep]

Mais pourquoi pas des macs avec du Intel (ou Amd soyons foufous) ET arm en MÊME temps???

[reversi]

J'avais fait le pari de rester en Power PC avec un PowerMac G5 et un PowerBook… Au bout de quelques années j'ai bien du céder, ne serait-ce que pour naviguer sur Internet.

Pouvoir naviguer sur Internet en affichant correctement les sites et en évitant les alertes de certificats est une des rares raisons actuellement pour utiliser une version de macOS récente.

Encore heureux que les versions relativement récentes de Google Chrome soient compatibles avec des versions de macOS d'il y a 5 ans.