Je n'ai jamais utilisé Xcode, mais en quoi l'éditeur de code est impliqué ?
Xcode fait pas mal de choses, y compris permettre de compiler plusieurs architectures sans se prendre la tête (en gros : un binaire unique avec plusieurs architectures) et balancer le tout sur leur AppStore. Ils ont déjà l'expérience (PowerPC à x86_64).
Surtout, le monde a changé, et de nos jours on a de plus en plus d'outils pour gérer le multi-arch (merci les smartphones), et Intel devient un concurrent comme les autres et non plus la référence, ils vont devoir se rebouger les fesses (et non je ne dirai pas adieu à Intel, c'est souvent quand il y a de la concurrence que la boite se réveille).
Les portages ne semblent pas triviaux vu qu'Apple a annoncer vouloir aider les projets open source à faire leur portage.
Le portage est trivial quand tu fais du code générique ("standard", genre avec du C, C++, etc, sans coder en assembleur).
En dehors du soucis de codage à l'arrache (genre scripts qui imaginent une seule arch, ou lancer l'assembleur x86_64 sans vérifier que c'est du x86_64) le soucis est la perf car le logiciel va basculer du code assembleur x86_64 avec optimisation (SSE est obligatoire sur x86_64, souvent utilisé) à du code générique qui n'utilise pas les fonctions d'optimisation spécifique au CPU. Rien de vraiment nouveau (pour les smartphones ARM il faut déjà remplacer le code SSE par NEON pour le calcul vectoriel) mais c'est à faire, et Apple peut d'une fournir de la doc sur l'usage de son CPU en assembleur, mais surtout payer des développeurs pour implémenter les optimisations et ainsi pouvoir afficher de jolie perfs.
[^] # Re: Questions
Posté par Zenitram (site web personnel) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 8.
Xcode fait pas mal de choses, y compris permettre de compiler plusieurs architectures sans se prendre la tête (en gros : un binaire unique avec plusieurs architectures) et balancer le tout sur leur AppStore. Ils ont déjà l'expérience (PowerPC à x86_64).
Surtout, le monde a changé, et de nos jours on a de plus en plus d'outils pour gérer le multi-arch (merci les smartphones), et Intel devient un concurrent comme les autres et non plus la référence, ils vont devoir se rebouger les fesses (et non je ne dirai pas adieu à Intel, c'est souvent quand il y a de la concurrence que la boite se réveille).
Le portage est trivial quand tu fais du code générique ("standard", genre avec du C, C++, etc, sans coder en assembleur).
En dehors du soucis de codage à l'arrache (genre scripts qui imaginent une seule arch, ou lancer l'assembleur x86_64 sans vérifier que c'est du x86_64) le soucis est la perf car le logiciel va basculer du code assembleur x86_64 avec optimisation (SSE est obligatoire sur x86_64, souvent utilisé) à du code générique qui n'utilise pas les fonctions d'optimisation spécifique au CPU. Rien de vraiment nouveau (pour les smartphones ARM il faut déjà remplacer le code SSE par NEON pour le calcul vectoriel) mais c'est à faire, et Apple peut d'une fournir de la doc sur l'usage de son CPU en assembleur, mais surtout payer des développeurs pour implémenter les optimisations et ainsi pouvoir afficher de jolie perfs.