Pour le décodage de l’ADS-B, ça m’intéresse de savoir les softs qui ne passent pas. Chez un de mes clients ou c’est le boulot, il n’y a pas de problèmes avec tous les softs (développés en interne comme sur des logiciels du CENA, STNA ou Thales) sur toutes les versions ADS.
Je soupçonne que les problèmes que tu soulèves sont plutôt des erreurs de programmation (probablement dans la parallélisation, la gestion des évènements ou les timers), avec un code qui se base sur un type d’architecture, mais dans ce cas, la compatibilité n’est pas restreinte à une marque, mais plutôt à un type de processeur.
1 « J'aime »
C’est relativement compliqué de tester équitablement des machines si différentes.
En jeu, il n’y a quasiment que le processeur et la carte graphique qui jouent sur les perfs et ce n’est déjà pas évident de comparer.
Pour le reste, tous les composants du PC ont une influence et changent complètement les ressentis suivant l’utilisation (la mémoire, la mémoire de masse, le CPU, le GPU, les différents caches, le refroidissement, …).
Il y a quand même quelques tests lors des sorties des nouveaux CPUs basse conso et des GPUs dédiés au portables qui sont intéressants.
Il faut remettre les choses dans leur contexte :
Pendant longtemps, Intel a imposé ses jeux d’instruction à toute l’industrie et donc l’applicatif. AMD (et les ex-autres compétiteurs) suivait le mouvement en les reprenant.
Pire, lorsqu’Intel a sorti son jeu d’instruction MMX avec les Pentium, AMD a décidé de les implanter dans ses K6. Et… Intel a porté plainte (et a perdu).
En outre, cela ne signifiait pas que ces jeux d’instructions étaient justifiés, bien adaptés, bien pensés, ou facile à utiliser. C’est pourquoi AMD a aussi créé ses propres jeux d’instruction concurrents (comme 3DNow! pour ceux qui s’en souviennent).
Le seul problème réel vécu a été à l’époque du SSE4. Une guerre de tranchées entre Intel et AMD :
- SSE4
- SSE4.1
- SSE4.2
- Streaming SIMD Extensions 4
- SSE4a
Le SSE4 créé par Intel a eu plusieurs ajouts poussées par AMD et Intel. Avec un résultat simple : aucun CPU de l’époque n’intégraient alors tous les sous-jeux développés…
Pire. Par la suite, AMD a proposé le SSE5 que Intel a gentiment envoyé boulet en mettant en place l’AVX. Les 2 n’étant pas vraiment compatibles. Chacun prétextant être meilleur que l’autre. SSE5 particulièrement décrié à l’époque à cause de son nom, car celui-ci ne reprenait pas la totalité des sous-instructions SSE4 (la continuité de la guerre de l’époque).
Heureusement, les générations successives autant AMD que Intel ont remis les pendules à l’heure. Elles utilisent tous les mêmes jeux d’instruction (et au complet). Et au passage, l’AVX a gagné.
Conclusion :
L’incompatibilité réelle n’est présente que pour les processeurs AMD des années 2007 à 2011, soit la génération des processeurs K-10 sous AM2+. Cela touche de nos jours peu de machines. Et même à l’époque, cela était lié seulement à des outils très spécifiques (aéronautique, navigation, communication, etc.). Le grand public n’a jamais perçu ce problème.
Mais c’est vieux cela! Ca date d’avant les Intel Sandy bridge il me semble !
Actuellement tous les CPU AMD supportent toutes les instructions « standards », les extensions type AVX 512 d’Intel elles-mêmes ne sont pas supportées par tous les CPU Intel. Ce sont des instructions très particulières même pour Intel qui ne sont pas comptées dans le TDP de la même façon et ont tendance à faire surconsommer/surchauffer les CPU.
Il faut ajouter que l’incompatibilité est uniquement due à la flemme des développeurs (ou des contraintes marketing), car il est très facile de faire une version du soft utilisant certains jeux d’instruction et d’autres pas (options de compilation), ça double juste les tests et si ils sont automatisés, ça ne coute rien.
2 « J'aime »
Le future RISK vs CISC intel a du retard on vas vers du ARM du RISK simple instruction set … Intel a plomber l’innovation avec son monopole vive AMD.
En quoi un programme qui ne sait pas s’adapter à son hôte est un bon programme?
C’est peut-être une formation pour leurs dévs qu’il faudrait.
1 « J'aime »
La limite entre CISC et RISK n’a plus de sens depuis longtemps. Si tu regardes le nombre d’instructions de chaque type de proc (enfin le type que revendique le concepteur), c’est tout à fait équivalent! 
Cela fait longtemps que les ARM ont un jeu d’instruction étendu et intègrent un paquet d’instructions SIMD.
Les ARM sont surtout optimisés conso et ne se trimbalent pas une compatibilité lourde (tous les proc « x86 » font tourner du code 32bits d’il y a 20 ans, c’est déjà plus compliqué pour du code ARM d’il y a 5 ans). La complexité du proc s’en ressent.
Pour les performances, c’est le même problème. Un vieux programme tournera au moins aussi vite (et très souvent plus vite) sur une nouvelle génération de x86, alors qu’une nouvelle génération d’ARM demande une recompilation pour avoir les mêmes perfs (voir juste pour pouvoir s’exécuter).
@jdupons, tu aurait des liens vers les versions des programmes que tu indiques comme incompatibles ?
Parce que cela fait un moment que je te vois parler de ça, mais j’ai du mal à trouver de quels programmes / versions il s’agit.
En revanche, ce qui est certain, c’est que je suis passé sur de l’AMD depuis six mois et je n’ai rencontré aucun problème (mais il est vrai que je ne suis pas radio-amateur).
Mais encore une fois, c’est un problème avant tout de l’éditeur (logiciel).
Il y a 3 cas possibles :
- set d’instruction Intel exclusif sans equivalent AMD
- set d’instruction Intel avec equivalent AMD
- set d’instruction Intel compatible avec le set d’instruction AMD
Donc dans le seul cas vraiment probablématique (le 1), pour une application cela signifie prévoir ce scénario :
- privilégier le jeu d’instruction Intel
- si aucun équivalent trouvé, basculé sur le jeu d’instruction générique
Si cela est fait, la seule différence sera au niveau de la performance applicative. Mais il n’y a plus d’incompatibilité logicielle. Dans le cas des applications que vous citez (et que je ne connais pas), il ne faut pas se leurrer, c’est parce que ce cas de figure n’a pas été implanté. C’est pourquoi 99.99% des applications n’ont pas ce problème.
Et en toute franchise, plutôt qu’une erreur de conception logicielle, c’est probablement un choix délibéré pour la vente d’outils/machines. En gros : je conçois un logiciel qui sera garanti operationnel avec le produit que je vends à côté. Circuit fermé. C’était un procédé à la mode par Intel dans les années 90 et un peu en 2000. Vite arrêté car évidemment… anti-concurrentiel.
1 « J'aime »
@jdupons Et sinon, donner des liens de programmes concernés par le problème que tu indiques, ce serait possible ou non ?
D’accord, c’est plus des logiciels métiers du coup, mais merci de l’info, c’est bon a savoir 
Il ne faut pas prendre le problème à l’envers. Intel a fait du forcing envers certains éditeurs pour utiliser un jeu d’instructions qu’ils sont les seuls à implémenter (il y en eu aussi coté AMD des jeux propriétaires comme les instructions 3dnow).
Le problème vient bien des éditeurs qui ont sciemment décider d’utiliser ces instructions sans faire le pendant pour l’autre constructeur. C’est pourtant ce que l’on fait en général (optimisations particulières pour certaines architectures ou génération de processeurs car les jeux d’instruction et leurs performances évoluent dans le temps).
Vous seriez étonné du nombre de programmes qui testent le type de matériel pour exécuter un « code path » spécifique pour optimiser les calculs et avoir une compatibilité optimale avec toutes les machines. C’est même tellement courant que certains compilateurs et certains framework le font même automatiquement sans demande du programmeur (options de compilation par exemple).
Et tout ça est aussi vrai (voir même encore plus :-P) pour les cartes vidéo ou seulement un sous-ensemble des fonctionnalités est implémenté, et les architectures sont différentes et il faut faire plusieurs version du code GPU.
Edit: Et pour les processeurs de type x86, ils sont compatibles, un ancien soft tourne sur les nouveaux processeurs, ce ne sont que les nouveaux programmes qui choisissent d’utiliser un nouveau jeu d’instruction et de garder un code qui ne les utilise pas (ou pas pour les mauvais éditeurs) si un ancien proc est détecté.
Ce n’est par contre pas vrai pour les processeur ARM comme dans les portables, ou là effectivement, les éditeurs doivent fournir une version recompilée pour tourner sur les nouveaux modèles.
Et c’est là où vous avez tort puisque AMD n’a eu ce problème que lors de la génération des CPU Barcelona (c’est vieux) avec des sous-jeux d’instructions très spécifiques (et pas bien nombreux). Ils se sont faits tappés sur la main par la presse spécialisée et certaines communautés informatiques. Intel n’a rien dit (ils avaient fait la même chose par le passé). Et cela a finalement aidé l’industrie a harmonisé certaines directions de jeu d’instruction.
Ainsi, depuis cette période, les CPU AMD - comme ceux d’Intel - proposent les mêmes types de jeux d’instructions : identiques ou compatibles. Il n’y a donc « plus » de logiciels incompatibles.
Prenez une meilleure analogie par exemple avec les GPU :
- Nvidia propose le Ray-Tracing : meilleur rendu mais difficile à implanter par des éditeurs
- AMD n’a pas cette technologie (propriété Nvidia)
Un jeu développé peut décider d’être optimisé pour le Ray-Tracing et donc l’exploiter. Mais si le jeu décide de ne pas l’utiliser, il sera tout de même fonctionnel. Il ne profitera simplement pas de cette optimisation. L’analogie avec vos voitures et vos routes n’est donc pas bonne. Ce serait plutôt :
- La voiture A a l’option tableau de bord écran-GPS intégré compatible Google Auto.
- La voiture B n’a pas d’écran intégré et n’est pas compatible Google Auto.
- Les 2 voitures sont tout à fait fonctionnels pour rouler sur l’autoroute.
De même avec les jeux d’instruction de CPU. Un éditeur peut décider d’optimiser son logiciel avec un jeu d’instruction spécifique (ex : AVX-512 qui n’existe pas chez AMD). Mais si le jeu d’instruction n’est pas trouvé, le logiciel fonctionnera tout de même car il basculera sur le jeu d’instruction générique (AVX).
Ce n’est donc plus de l’incompatibilité, c’est simplement une non-optimisation. Le CPU est parfaitement fonctionnel.
Enfin, pour finir, et ce sera mon dernier message sur ce sujet ici, un autre constat s’impose :
- AMD est présent dans 30-40% du parc informatique (grosso-modo)
- AMD est présent sur la scène informatique depuis les années 70
- Si une incompatibilité logicielle existait ou était toujours présente, cela se saurait depuis longtemps. On ne garde pas ce genre de chose secrète.
Bien sûr que si, AMD a cette technologie (depuis l’annonce des RX 6800).
Et non, le Ray Tracing n’est pas une technologie nVidia (ce n’est pas le cas sur les générations précédentes, je te l’accorde).
Voir l’introduction.
Direct X 12 Ultimate propose des fonctions pour exploiter le RT avec les Gpus compatibles Direct X Ray Tracing.