Bonjour,
Vous savez Apple va passer l'ensemble des Macs sous son "propre" processeur ARM Apple Sillicon.
Intel devrait être supporté par son système encore un moment.
Pour aider la transition x86 vers ARM elle va "aider" les projets suivants :
- Chromium
- V8
- Electron
- gestionnaires de paquet Homebrew et MacPorts
- .NET Mono
- Python 3 (avec l’extension NumPy)
- Go
- QT
- Nginx
- Node.js
- Bgfx
- Blender
- Boost
- Skia
- Zlib-Ng
- cmake
- FFmpeg
- Halide
- Pixar USD
- Swift Shader
- nmap
- OpenCV
- OpenEXR
- OpenJDK
- SSE2Neon
- Redis
- Cineform CFHD
Ceci va-t-il aider ces projets dans le monde ARM en général ?
plus d'infos ici :
# Hum ?
Posté par barmic 🦦 . Évalué à 10.
J'ai du mal à comprendre.
Si je prends nginx, redis, cmake,… et probablement d'autres. Ils sont déjà portés sur arm. Je me doute que l'archi qu'ils vont utilisé n'est pas tout à fait arm64 ou armel, mais une fois que gcc et clang/llvm supporteront leur archi ça ne devrait pas nécessité tant de travail que ça, non ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Hum ?
Posté par Maclag . Évalué à 10.
Entre "porté" et "testé et certifié au même niveau que la version x86", je suppose qu'il peut y avoir un certain différentiel.
Peut-être qu'ils veulent aussi réécrire des pans spécifiques à l'archi pour justement les rendre génériques et faciliter ainsi la maintenance du projet.
Et finalement, peut-être que c'est surtout une annonce pour rassurer les utilisateurs en garantissant que ces logiciels seront bien fonctionnels et le resteront après la transition.
[^] # Re: Hum ?
Posté par abriotde . Évalué à 3.
Il y a 2 choses:
1) Peut-être qu'il ont des outils écris spécifiquement pour Intel et qu'il est trop compliquer de les migrer, ils veulent utiliser des outils existant Open-Source. Mais pour ce faire ils ont besoin de leurs ajouté des fonctionnalité pour leur besoin.
2) Quand tu écris un programme, tu le test sur une archi. Et il y a toujours des spécificité non prises en compte même quand le language est cencé abstraire ces problème. L'exemple classique est le programme C entre BigEndian et LittleEndian. Même les programme JavaScript (comme NodeJS) ont souvent des connecteurs écris en C.
[^] # Re: Hum ?
Posté par barmic 🦦 . Évalué à 3.
J'ai pas compris le premier point pour le second, c'est justement des outils qui sont utilisé depuis longtemps sur de l'arm. À part grosse spécificité chez Apple, leur code est déjà portable. Si je regarde nginx, il est supporté par debian sur amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el et s390x. Je pense qu'ils ont déjà passé tous les cas de problème de portabilité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# QT
Posté par Anonyme . Évalué à 10.
Ils vont libérer QuickTime avant de le porter à ARM ?
[^] # Re: QT
Posté par bunam . Évalué à 0.
https://www.qt.io ;)
[^] # Re: QT
Posté par Anonyme . Évalué à 5.
Non, ça c’est Qt.
[^] # Re: QT
Posté par David Demelier (site web personnel) . Évalué à -2.
Oui mais tu as nommé le titre de ton commentaire « QT » ce qui porte à confusion avec la boîte à outil de ce nom là.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: QT
Posté par guppy . Évalué à 4.
QT : QuickTime, Qt : le framework. La casse compte.
[^] # Re: QT
Posté par bunam . Évalué à 2.
Je pense qu'Apple s'est trompé dans l'image, je pense donc que c'est bien de Qt dont il s'agit.
[^] # Re: QT
Posté par Anonyme . Évalué à 7. Dernière modification le 25 juin 2020 à 15:31.
Oui, y a peu de doute là dessus. Mon commentaire initiale était une blague (qui était assez courante sur DLFP y a quelques années d’ailleurs).
# Contexte
Posté par Tarnyko (site web personnel) . Évalué à 10. Dernière modification le 23 juin 2020 à 15:47.
Comme la news est lapidaire, j'étoffe un coup ; Apple Silicon sera un dérivé de ça.
Soc Apple A12Z (ou +), jeu d'instructions ARMv8.3, donc. Comme le dit @barmic, la plupart des projets supportent déjà ARM en général ; on peut imaginer que le coup de pouce vise l'optimisation.
Dans Chromium p.ex., il y a différents codes assembleur suivant le niveau de jeu d'instructions ARM ciblé ; sauf que bien sûr, les jeux en question correspondent surtout aux CPUs des téléphones Android.
Vu à quel point ARM reste encore en retrait d'x86 sur la performance brute, avec ou sans optim' ça fait un monde de différence.
[^] # Re: Contexte
Posté par Anonyme . Évalué à 4.
Carrément. Puis ayant une licence "architecte" chez ARM, ils ont certainement ajouté des instructions maison et fait quelques délestages de circuits historiques donc tout intérêt pour eux d'avoir des binaires optimisés.
[^] # Re: Contexte
Posté par bunam . Évalué à 3.
Pas sûr que ce soit l'Apple A12Z au final… Je suppose une grosse évolution de l'A12.Je suppose aussi que les fonctions intégrées au SOC différeront de plus en plus de ce que propose ARM.
Pour le moment on ne sait pas grand-chose.
Ça fait 30 ans qu'Apple bricole des trucs dans les processeurs, pour le coup elle va pouvoir montrer à tous son savoir-faire ;)
Elle a trouvé un bon fondeur depuis des années : TSMC.
Samsung arrête de faire ses processeurs.
Qualcomm va continuer.
Dans ma boulle de cristal, je vois que Huawei va être obligé de trouver autre chose qu'ARM comme base, ça va être dur.
[^] # Re: Contexte
Posté par Anonyme . Évalué à 3.
j'aimerais beaucoup un https://openrisc.io/, la marche est un peu haute pour arriver au niveau d'arm aujourd'hui, a moins que huawei parte sur un truc tout nouveau fait en interne pour ne pas subir plus tard d'autre pression.
et pourquoi pas non plus un linux avec python au lieu de java sur les telephones openrisc \o/
[^] # Re: Contexte
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Openrisc peut être une bonne base de départ car l'écosystème existe déjà. Pas besoin de réécrire un port linux ou gcc.
D'expérience, l'horreur est dans les détails : comment tu fais les setting de DRAM au boot ou celle de l'horloge pour sortir une bête console série ? Si c'est dans le code de boot de la plateforme, est-il encore possible d'utiliser un linux générique pour démarrer une telle plateforme (comme pour un x86) ? Dans le monde ARM, jusqu'à présent, il n'y avait pas de notion de kernel "générique ARM". Idem pour la découverte des périphériques, la norme PCI était faite pour ça, je crois que rien n'existe encore de standard pour ARM (ce qui pourrait être aussi bête que la définition d'une table en adresse mémoire fixe, avec un numéro de série + une adresse de base pour chaque périphérique).
Je ne sais pas jusqu'où va la définition de la norme openrisc, mais le fonctionnement de la MMU, de la IOMMU, doit être standard, sinon c'est le bazard (cf l'arm9/10 et les multiples implémentation de fpu que personne n'utilisait au final).
"La première sécurité est la liberté"
[^] # Re: Contexte
Posté par 2PetitsVerres . Évalué à 5.
Je n'en suis pas sûr à 100%, mais à mon avis il y a aussi un deuxième sujet : le don/prêt/prix réduits de machines. Parce que pour tester son code sur une plateforme, c'est plus simple d'avoir accès à cette plateforme.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# futurologie
Posté par farib . Évalué à 10.
Apple va pouvoir cesser de payer Intel, et se mettra la différence dans la poche.
Les prix des macs augmenteront justifiés par la diminution de l'épaisseur de 50% et l'augmentation de l'autonomie de 10%
et les derniers macs x86 seront vénérés comme le macpro 2008
[^] # Re: futurologie
Posté par Sufflope (site web personnel) . Évalué à -1.
J'ai toujours un petit regret d'avoir été trop jeune pour me payer un Powerbook de dernière génération. A la limite le proco je m'en cogne (passer sur x86 était même sûrement une bonne chose) mais la machine chiait la classe.
[^] # Re: futurologie
Posté par Psychofox (Mastodon) . Évalué à 5.
Il faut toujours faire gaffe avec la nostalgie.
[^] # Re: futurologie
Posté par farib . Évalué à 4.
J'avais acheté un powerbook G5 au printemps 2005 (tarif étudiant)
Puis j'avais pas accroché, je l'avais revendu au meme prix donc zéro perte.
Puis j'ai acheté un T42 que j'ai mis sous linux.
puis Apple a annoncé la transition.
J'ai pas spécialement pleuré le powerbook.
[^] # Re: futurologie
Posté par Prosper . Évalué à 8. Dernière modification le 25 juin 2020 à 16:13.
il n'y a jamais eu de powerbook G5 (En dehors des possibles prototypes chez apple), tu voulais dire un G4 j'imagine.
[^] # Re: futurologie
Posté par benoar . Évalué à 3.
Ebay et leboncoin sont tes amis, mais avec le Web d'aujourd'hui, le CPU va effectivement faire la gueule.
[^] # Re: futurologie
Posté par David Demelier (site web personnel) . Évalué à 2.
Ou peut-être seront ils moins cher justement.
L'avantage principal d'avoir sa propre puce est d'optimiser chaque partie à un petit module indépendant. Par exemple, au lieu d'avoir un processeur générique qui fait tout, Apple va faire un module indépendant juste pour la gestion de l'ACPI (voir la vidéo du keynote).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: futurologie
Posté par Nicolas Boulay (site web personnel) . Évalué à 9.
C'est la mode lancée par intel de rajouter des processeurs de gestion de plateforme. Le problème est que le code est fermé, et comme pour les nouveaux BIOS UEFI, ils seront plein de bugs non correctible. Linus est furieux contre ces machines sur lequel Linux ne peut pas avoir la main, dont ils dépendent malgré la mauvaise qualité du code.
"La première sécurité est la liberté"
# Mais pourquoi donc ?
Posté par potate . Évalué à 5.
Je ne savais pas.
Par conséquent je me suis demandé "Mais pourquoi donc ?".
Et une rapide recherche (me menant ici) m'a apporté deux réponses à cette question :
[^] # Re: Mais pourquoi donc ?
Posté par bunam . Évalué à 1.
Aussi à terme il faut penser, dans 2 ans mini, a l'intégration dans la SOC d'un module 5G car Apple a racheté la division Mobile d'Intel (qui lui-même avait racheté la division mobile d'Infineon)
[^] # Re: Mais pourquoi donc ?
Posté par Sufflope (site web personnel) . Évalué à 3.
Oui clairement comme nous le montrent les benchmarks ARM vs Intel/AMD.
:rolling_eyes:
Ils veulent juste tuer MacOs et que tout soit uniformisé iOS et notamment les 30% de taxe. C'est la seule raison.
[^] # Re: Mais pourquoi donc ?
Posté par Anonyme . Évalué à 2. Dernière modification le 24 juin 2020 à 06:40.
Des benchs qui sont comparables quand on teste les SoC ARM sur des devboards ou des serveurs qui peuvent faire tourner le même test sur un Linux.
Contrairement aux autres fabricants de SoC pour mobiles, Apple ne propose rien de tout ça.
On peut uniquement supposer qu'ils soient au niveau des grosses puces mobiles de Qualcomm, ce qui effectivement n'est pas vraiment glorieux si on compare à du x86 mobile pour laptop.
[^] # Re: Mais pourquoi donc ?
Posté par groumly . Évalué à 10.
heu, ben s’ils veulent 30% de « taxe » ils peuvent tout simplement imposer 30% de taxe. C’est leur store. Pas besoin de se faire chier à sortir un nouveau cpu pour ça.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Mais pourquoi donc ?
Posté par bunam . Évalué à 4. Dernière modification le 25 juin 2020 à 08:06.
Les problèmes de l'architecture skylake remontés par Apple, auraient été les problèmes de trop :
https://9to5mac.com/2020/06/24/former-intel-engineer-says-skylake-problems-were-turning-point-for-apples-arm-mac-transition/
[^] # Re: Mais pourquoi donc ?
Posté par YBoy360 (site web personnel) . Évalué à 2. Dernière modification le 28 juin 2020 à 11:00.
Tout est dans le potentiel. Le turfu quoi, pas la situation actuelle.
La situation actuelle n'est pas non plus désespérante. En performance par Watt, si tu ne te limite pas aux benchmarks orienté FLOPS, t'obtiens quelque chose de déjà compétitif, avec une consommation moindre.
Or les performance per watt, c'est capital pour le potentiel de progression d'une plateforme. Faut pas oublier que tous les correctifs appliqués pour juguler les failles des procos Intel les ont aussi bien ralentis.
[^] # Re: Mais pourquoi donc ?
Posté par Nico7as . Évalué à 2.
Pour continuer à faire du sur-mesure en fonction de ce qu'ils développent. GPU+Métal, Neural Engine, etc…
[^] # Re: Mais pourquoi donc ?
Posté par cedric . Évalué à 1.
Les design des laptop Mac sont principalement sans ventilo et Intel n'a pas fait beaucoup d'effort dans cette direction. Du coup, Apple a eu tendance a reduire la frequence des CPU qu'ils utilisent pour pouvoir tenir des temperatures correctes. Avec un passage a ARM, surtout les dernieres generations 64bits, il y a largement moyen d'avoir suffisament de performance pour faire tourner un usage laptop classique.
Apres, c'est pas mal la faute a Intel qui a beaucoup pousser sur des briques hardware quasiment pas utilise par le soft, car ecrire de l'assembleur pour faire de l'AVX512 partout ou une architecture specific pour utiliser les blocs de decompression hw, c'est pas franchement ideal pour grand monde. Du coup, on se retrouve avec du soft qui chauffe l'air ambiant alors qu'on pourrait etre nettement plus efficace si ils avaient un rien investit dans l'infrastructure logiciel de leur ecosysteme. Du coup, ca chauffe et on n'en tire meme pas avantage.
[^] # Re: Mais pourquoi donc ?
Posté par Strash . Évalué à 6.
Tous les laptops Apple sont équipés de ventilos à l'exception du Macbook 12" (qui n'est plus vendu aujourd'hui, il avait fait assez de vague à sa sortie car il n'avait qu'un seul port USB-C et rien d'autre). Ce n'est pas parce qu'ils sont fin qu'ils sont fanless.
[^] # Re: Mais pourquoi donc ?
Posté par Anonyme . Évalué à 6.
D'ailleurs Louis Rossmann peste régulièrement contre les réparateurs certifiés Apple qui sur certains modèles réinstallent une nappe à l'envers, venant couvrir l'entrée d'air du ventilo.
C'est ça aussi Apple: un SAV pas à la hauteur.
# RISC-V
Posté par Benjamin Henrion (site web personnel) . Évalué à 2.
Apple aurait mieux fait de passer sur RISC-V.
[^] # Re: RISC-V
Posté par claudex . Évalué à 4.
Pourquoi ? Ça fait 10 ans qu'ils font des processeurs ARM, je ne vois pas l'intérêt, pour eux, de passer à RISC-V.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: RISC-V
Posté par jyes . Évalué à 10.
Pour leur éviter un autre changement d’architecture d’ARM vers RISC-V dans 10 ans, quand Linux/Systemd/RISC-V sera prêt pour le desktop.
[^] # Re: RISC-V
Posté par Anonyme . Évalué à 2.
10 ans ça leur laissera pas énormément de temps pour faire la transition complète vers ARM. Intel, comme ARM Holdings, ne laissera pas partir facilement un si gros client.
[^] # Re: RISC-V
Posté par Sufflope (site web personnel) . Évalué à 3.
Ils vont faire quoi Intel, se déguiser en livreur et leur filer des x86 dans des cartons d'ARM ? Et Apple va laisser des sales reviews à Shenzen, je mets une étoile parce que j'ai pas reçu le bon processeur ?
Ils ont mis 10 ans à passer de PPC à x86 ?
[^] # Re: RISC-V
Posté par Anonyme . Évalué à 1.
Tu surinterprètes mes propos. Bien évidemment je n'ai pas dit que ça leur prendrait 10 ans, je dis que ça va leur prendre quelques années de migration, en particulier dans leur gamme station de travail, et que de ce fait il ne restera plus beaucoup d'années avant ce dixième anniversaire ce qui pourrait ne pas les motiver à changer aussi tôt d'architecture.
Tu sembles aussi oublier que x86 était déjà mature avec une large gamme lors de leur précédente migration depuis PPC, ARM n'est pas encore à ce niveau et Apple a la tâche supplémentaire de concevoir ses puces. Il n'y avait aucun défi hardware, la comparaison n'a pas lieu d'être.
[^] # Re: RISC-V
Posté par flan (site web personnel) . Évalué à 2.
Ce n'est pas totalement vrai ; iOS est très proche de macOS, beaucoup de logiciels sont disponibles sur ces deux plates-formes, et fonctionne sur ARM depuis plus de 10 ans.
Je pense qu'Apple a bien plus d'expérience sur ARM qu'il n'en avait sur Intel en 2005.
[^] # Re: RISC-V
Posté par groumly . Évalué à 8. Dernière modification le 25 juin 2020 à 23:11.
Leur toolchain a aussi sacrement évolué depuis, ils ont passe les 10 dernières années a converger leurs APIs, et je serais très surpris que le portage de macOS sur arm n'ait pas commence la minute ou apple a commencé a sortir ses propres CPU pour iPhone. Ca fait 10 ans que c'est écrit sur le mur, comme ils disent ici.
Rien que la compat binaire a 100% sur les applis iPhone et le port de UIKit pour macOS, ca implique que leurs plans etaient finalisés ya au moins 2-3 ans deja. Idem avec le cycle de release des CPU.
Tout comme MacOS X tournait sur x86 en 2001, plus de 5 ans avant qu'apple ne lance officiellement leur machines x86.
Sauf que cette fois, effectivement, ils ont 10 ans d'experience a très large échelle avec leur propre CPUs, sur plusieurs OS très proches de macOS (iOS, watchOS, tvOS, et maintenant meme iPadOS).
Ils sont reputes pour etre des control freaks de premiere, j'ai du mal a croire qu'ils bossent pas la dessus depuis des lustres, ou qu'ils aient la moindre intention de repartir sur une autre architecture dans les 20 prochaines années.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: RISC-V
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
Cette phrase reste toujours vraie pour les ordinateurs :
Apple maîtrise très bien le hardware désormais, mais il n’est pas dit que ce hardware soit prêt pour tenir la route sur le plan des performances face au hardware x86 actuel de leur haut de gamme.
Alors qu’au moment de la migration PPC vers x86, Intel proposait des CPUs qui tenaient largement la route pour le besoin de performance haut-de-gamme.
Bref, je vois bien Apple commencer à vendre des macs mini ou des laptops requérant de faible puissance avec ses processeurs ARM, et basculer les gammes requérant plus de performances au fur et à mesure des années, de manière beaucoup plus lissée et plus étendue dans le temps qu’à l’époque de la migration PPC vers x86.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: RISC-V
Posté par barmic 🦦 . Évalué à 1.
Ils ont l'expérience Rosetta/Universal binaries pour gérer ça de manière plutôt sympa pour leurs utilisateurs en plus.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: RISC-V
Posté par groumly . Évalué à 3.
Même la dessus, c’est loin d’être plié.
Ça fait 10 ans qu’Intel stagne niveau performance, et 1 ou 2 ans déjà que les Ax d’Apple sont au niveau des xeons en single thread.
Certes, il reste du boulot en multithread, mais la encore, vu la durée des cycles de release des cpus, je pense que le problème de perf est résolu par un A13 ou A14 qui va sortir dans les 2 prochaines années.
apple a prouvé à maintes reprises qu’ils bossent sur le long term, et qu’ils ne font pas leur annonces à la légère (ok, à part air power). De ce que j’en comprends, ça sent le roussi pour Intel.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: RISC-V
Posté par nonas . Évalué à 4.
Tu aurais des liens pour ça ?
On pourrait dire que c'est bien fait pour eux mais n'oublions pas que ça a été dit à propos d'AMD à maintes reprises et aujourd'hui ils font de nouveau des bénéfices avec leurs très bons produits.
[^] # Re: RISC-V
Posté par Anonyme . Évalué à 1. Dernière modification le 27 juin 2020 à 11:02.
Il y a suffisamment de bons articles comparant les Sandy Bridge aux processeurs plus récents qui contredisent ton affirmation. Intel n'a pas stagné, ils se sont concentré sur l'économie d'énergie et, n'ayant pas de concurrents, ils ont levé le pied sur l'amélioration de performance brute.
Si leur 10nm n'était pas aussi mauvais en montée en fréquence, ils seraient encore leaders.
C'est faux car impossible de faire un comparatif concluant entre les deux architectures. Je te renvois à mes commentaires sous le journal précédent.
[^] # Re: RISC-V
Posté par groumly . Évalué à 2.
Tu m’expliques la différence concrete entre les deux?
En pratique les gain de perf sur les cpus intel cette dernier décennie ont été très petits.
La palanquée de benchmarks disponibles ne montrent pas qu’un a13 est comparable à un xeon en single thread?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: RISC-V
Posté par Anonyme . Évalué à 4.
C'est ce qu'on appelle un ralentissement, pas une stagnation.
+10% à chaque génération, en 10 ans ça finit par être conséquent. Tu oublies aussi qu'il y a 10 ans c'était pas encore Sandy Bridge, c'était le i7 875K.
Tous biaisés.
Dans un test rigoureux on écarte toute différence autre que l'élément qu'on veut comparer, c'est la base d'un protocole sérieux.
Étant donné que les proco ARM d'Apple sont livrés avec un OS particulier, dans un seul agencement matériel, il est impossible de les tester correctement même face à d'autres SoC ARM donc encore moins face à une ISA totalement différente.
[^] # Re: RISC-V
Posté par barmic 🦦 . Évalué à 1.
Dans un protocole scientifique orienté recherche oui. Ici Apple s'intéresse à l'ensemble ISA comprise. Globalement le CPU, ils s'en foutent c'est la plate-forme qu'ils testent. Donc ce genre de protocole ont un sens, mais ce sens ce n'est pas de tester la puissance mono thread d'un CPU par rapport à un autre, mais une plate-forme entière (y compris OS, compilateur, etc on le protocole choisi).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: RISC-V
Posté par Anonyme . Évalué à 5.
Sauf que là on parle pas d'Apple qui fait ses tests en interne pour voir où ils en sont par rapport au reste du monde et dans sa grande bonté partage ces données, ici je réfute des affirmations sourcées avec des tests synthétiques du type Geekbench procurant un score qui ne veut rien dire et des présentations marketings.
À partir du moment où rien n'est vérifiable car la plate-forme n'est pas sortie, ce n'est que du vent. On verra quand des reviewers feront des encodages sur Premiere, Blender, x264 si effectivement cette plate-forme atteint ses promesses.
[^] # Re: RISC-V
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
Dans le même temps, AMD a multiplié la performance de ses processeurs sur certaines tâches par 20 en moins de 7 ans (cf. benchmark Phoronix) :
En juillet 2013 le FX 9590 était ce qu’AMD avait de mieux à offrir pour le marché « desktop » (avec un TDP de 220W). En février 2020 le meilleur qu’AMD propose pour le même marché est le ThreadRipper 3990X (avec un TDP de 280W).
Si tu linéarises la progression, ça fait du +300% par an. D ’ici 2021/2022 AMD aura atteint les 4nm dans sa gravure en production et pourra offrir plus encore. En 10 ans ça va finir par être conséquent.
Alors oui c’est un benchmark favorable, mais même avec un benchmark pensé pour être défavorable car n’utilisant qu’un seul thread (et le point fort du TR 3990X est d’être le CPU avec le plus de cœurs/threads du marché), t’as plus de 200% de gain en moins de 7 ans.
Je n’ai pas de ThreadRipper 3990X, mais j’ai des tâches qui ont la même progression sur le matos AMD que le raytracer testé par Phoronix (j’utilise un autre raytracer) et j’ai un FX 9590 sous la main pour comparer. Si j’extrapole les performances que j’ai pu tester sur d’autres processeurs actuels d’AMD, une tâche que met près de 2 jours (1 jour et 18 heures avec tous les cœurs à 100%) à produire un rendu sur un FX 9590 mettrait 15 minutes sur un TR 3990X.
Et si tu ne peux pas acheter « le meilleur qu’AMD a à offrir » (qui est grave cher, ne le nions pas, 4000€) mais que tu te contentes d’acheter un processeur qui est dans la gamme de prix où était le FX 9590 à l’époque comme un Ryzen 9 3900X (400€), tu multiplies facilement par 5 les performances. Sur un test réel, un rendu qui mettait 5h ne dure plus qu’une heure. Et le TDP du Ryzen 9 3900X c’est 105W.
Donc, comparons 7 heures de calcul avec un CPU à 220W de TDP contre 1 heures de calcul à 105W de TDP… ou 42 heures de calcul avec un CPU à 220W de TDP et 15 minutes avec un CPU à 280W de TDP… La progression d’AMD est énorme, Intel ne suit pas.
Ironiquement, le fait qu’Apple intègre du Intel réduit énormément le gap entre ce que leurs processeurs ARM sont capable de faire et ce qu’un client Apple attend d’eux.
Certaines personnes font de très grand écarts pour ne pas voir le problème, exemple d’un parfait anonyme qui m’a fait bondir:
Certaines personnes en sont là pour ne pas se confronter au réel : « le Mac Pro à base de Xeon n’est pas rendu obsolète par la sortie des AMD ThreadRipper parce que de toute façon HP et Dell ne te vendront pas de machine avec un ThreadRipper », et paies-toi l’argument très Apple-compatible : « ils ne te vendront pas du ThreadRipper parce qu’ils vendent du haut de gamme, tu vois ». 🙈
Pour être honnête, la personne donne ensuite un vrai argument avec un exemple de cas d’usage à grande mémoire qui est actuellement réservé à l’offre processeur de serveur d’AMD (Epyc). En gros aujourd’hui le seul argument pour mettre un Xeon dans un ordinateur de bureau c’est si tu as besoin de plus de 256 Go de RAM. Si tu n’as pas besoin de plus de mémoire vive, prendre du Xeon c’est une perte d’argent et un renoncement de puissance insensés. Cela ne fait donc aucun sens (autre que des contrats d’exclusivité) si de grands constructeurs n’intègre pas des offres avec ThreadRipper dans leur haut de gamme pour tout ceux qui n’ont pas de besoin spécifique en mémoire, à côté des offres minoritaires avec Xeon pour ceux qui ont des besoins spécifique en mémoire.
Bref, le fait qu’Apple intègre du Intel dans son haut de gamme et le fait qu’Intel soit à la traîne réduit fortement le chemin à parcourir par Apple pour apporter à ses clients une architecture ARM qui ne soit pas inférieure, non pas à ce que propose le marché, mais à leurs offres précédentes. La captivité de la clientèle rend ce genre de manœuvre plus aisée.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: RISC-V
Posté par Anonyme . Évalué à 1.
Alors comment te dire…
L'affirmation était sur 10 ans et pareil il y a 10 ans AMD c'était pas vraiment ça.
Ensuite, le FX9590 était le pire processeur que AMD a fait, vraiment la pire bouse. Déjà Bulldozer était une archi à peine meilleure que K10, GloFo était à la bourre niveau process de gravure, et en plus c'est un FX8350 avec un OC d'usine donc totalement aberrant. Donc ouai pas étonnant qu'à TDP égal la différence soit aussi importante.
Bah oui, t'as toujours de base un processeur complètement moisi. Fais la même chose entre un PhenomII ou un FX8350 face à un R5 1600 ou 3600 (ou même un 3300X étant donné qu'il y a à peine 4 ans les FX était bien bradés et que AMD n'avait toujours rien d'autre à offrir) ce sera un poil plus réaliste.
En même temps AMD revient de très loin. Ils ont petit à petit perdu du terrain depuis l'Athlon64 et je le répète il y a encore 4 ans ils ne vendaient que du FX en 28nm. Compare ça à ce que Intel vendait en face et tu verras que la conjoncture Zen avec Meltdown et Intel bloqué au 14nm a beaucoup aidé AMD à revenir dans la course.
il faudrait déjà que TSMC commence à entrer en production de son 5nm, pour l'instant ce ne sont que des précommandes. À ce moment on verra aussi ce que donne le 7nm maison de Intel, la riposte est en préparation.
Ça montre surtout l'erreur d'Apple de ne pas être passé chez AMD et d'avoir vendu très cher des ordis inférieurs. Sans oublier que comme dit précédemment, leur design de laptop a un refroidissement insuffisant qui fait que ces procos Intel sont en thermal throttling dès qu'il y a un peu de tâches lourdes. On peut même se demander si ce sabordage n'était pas prémédité par la firme pour faire passer la pilule du changement d'archi.
Bref les clients Apple ne devraient pas se réjouir, ils devraient se sentir floués des décisions d'Apple. Mais comme tu le montres, c'est difficile pour eux de se confronter au réel.
[^] # Re: RISC-V
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
J’ai tout à fait conscience qu’AMD était vraiment pas au top il y a 10 ans. C’est pourquoi l’écart entre les AMD actuels et les Intel d’avant n’est pas aussi énorme qu’entre les AMD actuels et les AMD d’avant… Mais c’est indéniable, AMD a fait une progression extra-ordinaire. Intel ne peut pas se vanter de progresser autant. Aujourd’hui j’ai l’impression de voir Intel comme AMD était il y a 10 ans… raboter dans les coins pour ne pas trop perdre de place. Cet exemple du FX 9590 était un bon exemple de « faire feu de tout bois » pour réussir à placer des produits dans certains rayons quoi qu’il en coûte. Intel use d’autres manœuvres qu’un OC d’usine, mais c’est un peu la même logique : garder une place dans le rayonnage quoi qu’il en coûte.
Peut-être y-a-t-il une clause d’exclusivité dans un contrat ? Sur le plan des GPU, Apple n’a aucun problème à intégrer du AMD.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: RISC-V
Posté par Anonyme . Évalué à 2.
Ils ont rattrapé leur retard, comme quand l'archi Core a été crée par Intel. Ce sont des choses qui restent exceptionnelles et qui le seront d'autant plus que la technologie devient de plus en plus complexe, miniaturisée et donc chère à faire évoluer.
Intel n'a pas eu de concurrent sérieux pendant des années donc évidemment qu'ils se sont reposé sur leurs lauriers. Toutes les entreprises font ça.
Du coup les clients ont le pire des deux mondes. Pas que Radeon soit loin derrière mais Nvidia a très souvent une longueur d'avance. Ça aurait été intéressant d'avoir des APU Ryzen dans leurs laptops d'entrée de gamme mais pour le reste ça n'a pas d'intérêt de mettre du GPU AMD, surtout quand on a le poids pour avoir les pilotes directement du constructeur pour son OS proprio.
[^] # Re: RISC-V
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Je ne serai pas surpris si la non-ouverture des pilotes NVidia était la cause du choix d’Apple en faveur d’AMD pour les GPUs.
Parce que macOS distribue lui-même les pilotes, et généralement il semble qu’Apple semble vouloir avoir la main sur le code qu’ils distribuent eux-même, ce qui est tout à fait rationnel même quand on fait du propriétaire.
Sur console c’est pareil, la seule console actuelle qui a du NVidia c’est la Switch, ce qui récompense probablement plus leur positionnement sur le marché des cartes intégrées ARM + GPU (AMD semble avoir abandonné son expérience ARM) que les conditions de collaborations avec les autres industriels. Si la Xbox première du nom et la PlayStation 3 ont eu un GPU NVidia, la GameCube, la Wii, la Xbox 360, PlayStation 4, Xbox One, et les consoles à venir Atari VCS, Xbox Series X et PlayStation 5 sont toutes sous AMD (les autres consoles non-citées ont eu du SGI, du PowerVR et autres marques minoritaires sur ce marché). Il est connu qu’AMD développe ses pilotes Linux sur la base d’un tronc commun interne, commun à « 4 ou 5 architectures ». Et AMD est très enclin à documenter ses architectures et à montrer son code, si AMD le fait en libre, rien ne les empêche de le faire sous NDA.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: RISC-V
Posté par Renault (site web personnel) . Évalué à 3.
Mais quel est le rapport ?
Ils peuvent largement négocier avec nVidia pour que macOS distribue des pilotes sur mesure pour macOS. Pour un gros client, nVidia sait s'adapter. ;)
Le problème n'est clairement pas là.
Mais nVidia peut largement collaborer avec des constructeurs. Ce n'est pas parce qu'ils agissent sans se préoccuper des linuxiens qu'ils agissent pareil avec des entreprises qui peuvent générer des milliards de revenus.
Si AMD a raflé la mise sur les consoles, c'est une histoire de gros sous. Une console de jeux vidéo c'est un PC standard optimisé pour le jeu qui est raisonnablement pas cher. Le constructeur d'une console doit trouver le meilleur ratio performance / prix tout en évitant de dépasser la barre des 400-500€ lors du lancement. La marge dans cette industrie n'est pas sur la console mais sur les jeux, les accessoires et autres services associés.
Les volumes de ventes permettent de baisser les coûts de production pour les jeux vidéo (plus simple à optimiser que sur PC) mais aussi sur le matériel car les composants seront vendus pendant 5-7 ans à des dizaines de millions d'exemplaires.
Pour les constructeurs, AMD fait le job, ils n'ont pas besoin du haut de gamme d'Intel ou de nVidia qui est trop cher pour le besoin. Et pour AMD, rafler un tel marché est intéressant, cela apporte un peu de revenus et de publicité en faisant tourner ses usines. AMD avait besoin de contrats, ils étaient capables de faire des offres avec des marges plus faible que la concurrence pour remporter la mise. C'était parfait pour les constructeurs de console, et Intel et nVidia n'étaient pas prêt à faire autant d'efforts pour si peu de revenus.
Le reste est un non sujet, ce n'est pas un secteur où la meilleure performance absolue est le critère principal, et dans ce genre de boulot même nVidia sait collaborer avec les autres industriels.
[^] # Re: RISC-V
Posté par Psychofox (Mastodon) . Évalué à 2.
On peut le voir sous un autre angle, que Intel a "triché" avec la sécurité et s'en est pris plein la gueule ce qui lui a fait perdre pas mal d'avantage et rentrer un peu dans le rang.
[^] # Re: RISC-V
Posté par Anonyme . Évalué à 2.
Je n'ai aucun problème avec ce que tu dis, seulement j'évoquais la conception hardware qui ici est AMHA le défi de cette migration.
Actuellement le catalogue n'est pas complet pour satisfaire les usages de leur matériel, ce qui n'était pas le cas il y a quinze ans et ce qui a permis une migration rapide et complète sur du Intel. Cette nouvelle migration leur prendra fort probablement plusieurs générations de machines avant d'être terminée.
[^] # Re: RISC-V
Posté par YBoy360 (site web personnel) . Évalué à 0.
ils ont annoncé 2 ans pour mener la migration, tout en précisant que des machines Intel sortiraient. En tout cas, la présentation WWDC était vraiment impressionnante en ce qui concernait la migration ARM : il y a déjà Office et Adobe, le tout semblait fonctionner dans une machine au format Mac mini, y compris Premier en 4K, avec tout un tas de filtres.
Il ne faut pas oublier qu'Apple côtoie ARM depuis Newton, Arm Holdings (Advanced RISC Machines) est une joint venture entre Acorn et Apple. Si on regarde la progression des performances en l'espace de 10 ans des puces Apple sur leurs téléphones, on est dans un autre registre que les puces x86 (c'est vrai que les procédés de fabrication y sont en partie responsable).
Donc potentiellement, Apple peut avoir des performances par thread suffisantes pour leurs besoins rapidement, d'ici 2 ans.
[^] # Re: RISC-V
Posté par Anonyme . Évalué à 2.
Même réponse qu'à groumly ou que sur le journal précédent : impossible de tester de manière rigoureuse les perfs des SoC ARM d'Apple.
Sinon il y a souvent un fossé entre les annonces et présentations technologiques gérées par le département marketing et la réalité, peu importe la boite.
[^] # Re: RISC-V
Posté par Fulgrim . Évalué à 2.
Si les soc sont comparables à ce qu'on trouve dans un ipad haut de gamme d'aujourd'hui, c'est déjà très performant pour l'usage de la plupart des clients d'Apple (ceux qui comptent pour eux en vrai).
Tu feras sans doute pas de deep learning ou de taches hyper gourmandes dessus, mais les laptop deviennent de plus en plus des terminaux vers des applications tournant sur des gros serveurs, et pour ça silence, consommation, prix, poids, qualité du matos, intégration avec l'OS sont des composantes beaucoup plus importantes que la puissance brute pour beaucoup de clients.
Adobe et sa suite se déporte de plus en plus dans le cloud, VSCode va aussi vers un mode à distance, la compilation c'est la CI/CD qui la fait (y a des boites ou tu n'as juste pas le droit d'avoir le code source sur ton laptop), les rendus 3D se font sur une ferme de calcul (tu as juste besoin d'une carte graphique un peu pêchue en local, et vu la définition des écrans "retina" les cartes graphiques actuelles ne doivent déjà pas être dégeux).
Bref, je pense que ça sera moins puissant qu'une bonne grosse tour optimisée, mais que ça se vendra quand même comme des petits pains et j'arrive pas à donner tord aux gens qui en achèteront, ça ne sera pas que un succès de leur équipe marketing (qui va avoir son rôle, évidement).
# Mise en page
Posté par passant·e . Évalué à 3.
C'est moi où l'aperçu a un bug et la mise en page ne coupe pas les listes?
En comparaison des autres, ce journal m'a l'air anormalement haut
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: Mise en page
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Peut-être que ça coupe en fonction du nombre de mots indépendamment des sauts de lignes…
ce commentaire est sous licence cc by 4 et précédentes
# Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: RE: Transition ARM : Apple assistera certains projet open source
Posté par Benjamin Henrion (site web personnel) . Évalué à 1.
"valider des app en CI pour MacOS est 10x plus chers que Linux"
J'ai vu un gars qui faisait du CI OSX avec une image hackintosh vagrant dans docker:
https://github.com/zoobab/vagrant-inside-docker
https://app.vagrantup.com/AndrewDryga/boxes/vagrant-box-osx
Ca fonctionnait.
[^] # Re: RE: Transition ARM : Apple assistera certains projet open source
Posté par Thomas Debesse (site web personnel) . Évalué à 8. Dernière modification le 26 juin 2020 à 23:36.
Ça fonctionne, mais c’est (au moins) 10 fois plus cher.
Plus cher ne signifie pas forcément acheter des licences ou du matériel, plus cher en coût caché, en temps passé à s’arracher les cheveux. Et quand ça marche, tu ne peux pas parier sur le futur, c’est toujours du court-terme.
Pour essayer de faire sentir du doigt l’incertitude sur le futur de n’importe quelle technologie Apple, relis le fait que la vidéo annonçant la migration vers ARM prend aussi soin de montrer que Linux est toujours bootable dans une machine virtuelle depuis un macOS de bureau et de signifier par là qu’ils en prendront soin. C’est important pour Apple de montrer cela pour faire taire les craintes de ceux qui craindraient qu’un ordinateur sous macOS devienne aussi fermé qu’un iBidule où seul iOS est installable. Problème : certaines personnes faisaient plus que démarrer Linux dans une machine virtuelle sur un mac, mais démarrer Linux sur un mac. Que faut-il en penser ? Les craintes sont-elles infondées ? Saurons-nous démarrer Linux sur un mac ARM directement sans virtualisation ?
Saurons-nous virtualiser un mac ARM ? Faudra-t-il émuler des périphériques spécifiques et introuvable ailleurs que dans un mac ARM ?
Bref, ça marche mais faut toujours garder en tête qu’il faut considérer par défaut que c’est du no future.
Et mon témoignage personnel c’est que sur les logiciels libres auxquels je contribue, prendre soin de la plate-forme d’Apple ce sont des mois de travail pour un nombre d’utilisateur qui se compte sur les doigts d’une seule main (parfois sur un seul doigt).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: RE: Transition ARM : Apple assistera certains projet open source
Posté par flan (site web personnel) . Évalué à 2.
Il y a déjà des périphériques spécifiques : le clavier, sa TouchBar et son lecteur d’empreinte, par exemple.
[^] # Re: RE: Transition ARM : Apple assistera certains projet open source
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
Oui mais à ce que je sache, pour le moment ne pas les avoir rend les fonctionnalités indisponibles, je pensais plus à des périphériques sans lequel le système ne peut pas démarrer.
Je pourrais donner comme exemple la différence entre une Xbox première du nom et un PC. Cette machine avait beau être très proche d’un PC, elle n’est toujours pas émulée correctement même en reprenant 90% de qemu… Un Mac me semble aussi spécifique qu’une console de salon.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: RE: Transition ARM : Apple assistera certains projet open source
Posté par nonas . Évalué à 4.
J'ai assez peu de doutes que quelqu'un y arrive un jour par contre Apple ne veut pas : https://linuxfr.org/nodes/120881/comments/1816028
# Plus de Linux ou Windows sur Mac?
Posté par ted (site web personnel) . Évalué à 4.
Ça va pas faciliter la migration vers un autre système. Déjà les systèmes ARM n'utilisent pas de BIOS/UEFI, et en plus il faut que tous les logiciels soient compilés pour leur architecture.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Plus de Linux ou Windows sur Mac?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Beaucoup de machines à base de ARM utilisent UEFI maintenant. U-Boot implémente aussi de quoi lancer les binaires EFI. Ce n'est donc pas un problème technique. On verra si Apple utilise ça ou choisit un bootloader fermé ne laissant pas la possibilité de démarrer autre chose que MacOS…
[^] # Re: Plus de Linux ou Windows sur Mac?
Posté par barmic 🦦 . Évalué à 4.
Ça ne veux évidement pas dire grand chose, mais je pense qu'ils n'ont pas grand chose à y perdre. À part quelques bourrins comme nous personne n'installera autre chose que OSX sur mac. Les gens qui achètent un Mac le font généralement pour le duo hard/soft qui sont très bien intégrés. Ceux qui s'achètent ces machines pour faire tourner autre chose restent marginaux.
Le seul point qui peut être bloquant c'est s'ils veulent garantir une chaine de sécurité complète. C'est possible avec uefi, mais empêche l'utilisation d'autre chose si on a pas la possibilité d'insérer nos propres clefs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Plus de Linux ou Windows sur Mac?
Posté par Benjamin Henrion (site web personnel) . Évalué à 3.
J'avais installé Linux sur mon iBook g3, la license d'oSX disait qu'on pouvait se faire rembourser le logiciel si on ne l'utilisait pas.
Apple Belgique n'a jamais voulu me rembourser.
[^] # Re: Plus de Linux ou Windows sur Mac?
Posté par Pierre Tramo (site web personnel) . Évalué à 4.
C'est confirmé, il faudra virtualiser: https://www.reddit.com/r/linux/comments/hfkdlg/craig_federighi_confirms_apple_silicon_macs_will/
[^] # Re: Plus de Linux ou Windows sur Mac?
Posté par Benjamin Henrion (site web personnel) . Évalué à 1.
Cela veut dire qu'on ne pourra pas booter Linux sur son ordinateur Mac?
[^] # Re: Plus de Linux ou Windows sur Mac?
Posté par benoar . Évalué à 4.
J'ai l'impression, oui.
# Quelques info sur le DTK
Posté par bunam . Évalué à 1.
https://www.macg.co/mac/2020/06/apple-silicon-le-dtk-fait-quasiment-aussi-bien-quun-macbook-air-malgre-rosetta-115031
Geekbench 5 n'est pas encore compilée pour l'ARM d'Apple sur macOS, mais convertie avec Rosetta 2.
Il faudrait compter sur un A14 à 12 cœurs pour la sortie commerciale.
La partie graphique a l'air d'assurer dès maintenant sur ce Frankenstein de Mac.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.