"Intel bride son compilateur pour porter préjudice à AMD"
Accuse un développeur : changeriez-vous de compilateur si c'était le cas ?

Le , par Gordon Fowler, Expert éminent sénior
Le compilateur d'Intel est reconnu par beaucoup de programmeurs comme un, si ce n'est le, meilleur compilateur actuellement disponible.

Son utilisation pour de nombreuses applications critiques, notamment scientifiques, confirme cette impression qui s'appuie par ailleurs grandement sur des librairies constamment optimisées et améliorées par le fondeur.

Mais certains des fans du compilateur d'Intel auraient levé un lièvre.

"Les logiciels [ainsi] compilés montrent des performances inférieures s'ils tournent avec des microprocesseurs AMD ou VIA", affirme ainsi Agner For.

Cet état de fait serait parfaitement volontaire. Le compilateur d'Intel détecte le CPU sur lequel l'application devra tourner puis choisit la librairie appropriée pour optimiser la compilation. Mais cette phase d'analyse du proc irait jusqu'à identifier la marque.

Dans le cas d'une puce AMD, le compilateur choisirait volontairement une librairie non-optimisée à la place d'une librairie, pourtant présente, qui le serait. Pire, le compilateur choisirait la version la plus lente.

Cette fonction d'analyse du CPU et de choix de librairie qui en découle s'appelle le "CPU dispatcher".

"Si Intel disait que son compilateur n'est compatible qu'avec ses puces, il n'y aurait strictement rien à redire", souligne Agner Fog, "le problème c'est qu'ils essayent de cacher la vérité. Beaucoup de développeurs pensent que ce compilateur est compatible avec les produits AMD – ce qu'il est effecitvement – mais ce qu'ils ne savent pas toujours c'est qu'il embarque un CPU dispatcher complètement biaisé qui choisira de faire tel ou tel code selon que le processeur sera un Intel ou pas."

Et de conclure : "si les programmeurs savaient cela, ils choisiraient certainement de changer de compilateur".

Allez-vous changer de compilateur ?

Source : Le billet et les accusations de Agner Fog

Lire aussi :

Poursuites engagées contre Intel accusé de "corruption" par la Federal Trade Commission, malgré l'accord de non-agression avec AMD
Pour un compilateur intelligent : les propositions de l’Union Européenne et IBM Research
Programmation : Le pire bout de code que vous ayez vu : Qui l'a fait ? Pourquoi ? Pourquoi était-il si horrible ?

La rubrique Hardware de Développez

Et vous ?

Pensez-vous que le CPU dispatcher du compilateur d'Intel soit biaisé ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de viking1404 viking1404 - Membre régulier https://www.developpez.com
le 04/01/2010 à 16:58
Pour moi c'est tout à fait logique !

Intel connait sur le bout des doigts son matos, c'est normal que si le compilateur détecte un proc intel il l'utilise au maximum de ses capacités.
Donc, qu'il y ai des baisses de perfs. sur d'autres proc me semble logique.

C'est un peu comme si on compile sa gentoo pour un proc Intel mais qu'on la fait tourner sur un AMD.

Après si il y a un réel bridage volontaire contre les processeur concurent d'Intel là c'est pas terrible en effet
Avatar de shidosh shidosh - Membre du Club https://www.developpez.com
le 04/01/2010 à 17:19
Pour moi cela est tout à fait normal, et cette info date de 4 ans au moins :
http://techreport.com/discussions.x/8547
Lors du processus du back end, le compilateur optimise le placement des données dans les registres du CPU, afin d'avoir les meilleures performances.
Il est normal que les compilateurs INTEL utilisent au mieux les CPUs (ainsi que les instructions supplémentaires) de sa marque.
D'ailleurs, à ma connaissance, beaucoup de performances sur des bench tel que CPUSpec ou SpecMPI sont validées sur processeur AMD via gcc ou pgi.
Avatar de Gordon Fowler Gordon Fowler - Expert éminent sénior https://www.developpez.com
le 04/01/2010 à 17:35
Salut shidosh,

Citation Envoyé par shidosh  Voir le message
Pour moi cela est tout à fait normal...
Il est normal que les compilateurs INTEL utilisent au mieux les CPUs (ainsi que les instructions supplémentaires) de sa marque.

Ce n'est pas ce qu'il dit.

Il dit que le compilateur de Intel sait optimiser l'utilisation des CPUs AMD mais que volontairement il fait ce qu'il y a de plus mauvais pour que le code soit lent sur les procs de la concurrence

Citation Envoyé par shidosh  Voir le message
D'ailleurs, à ma connaissance, beaucoup de performances sur des bench tel que CPUSpec ou SpecMPI sont validées sur processeur AMD via gcc ou pgi.

D'après l'auteur des accusations et juste pour infos (cf. son billet que j'ai mis en source), une très lourde suspicion planerait sur ces benchmarks.

Très cordialement,

Gordon
Avatar de Emmanuel Deloget Emmanuel Deloget - Expert confirmé https://www.developpez.com
le 06/01/2010 à 10:28
Citation Envoyé par Gordon Fowler  Voir le message
Salut shidosh,

Ce n'est pas ce qu'il dit.

Il dit que le compilateur de Intel sait optimiser l'utilisation des CPUs AMD mais que volontairement il fait ce qu'il y a de plus mauvais pour que le code soit lent sur les procs de la concurrence

D'après l'auteur des accusations et juste pour infos (cf. son billet que j'ai mis en source), une très lourde suspicion planerait sur ces benchmarks.

Très cordialement,

Gordon

Ce qui est, au final, parfaitement anormal, puisque cela empêche d'utiliser le compilateur d'Intel pour réaliser des produits qui sont largement distribués sur une architecture hétérogène.

Ce qui revient, pour Intel, à se tirer une balle dans le pied.

Ceci dit, le nombre de personnes qui utilisent le compilateur d'Intel est très inférieur au nombre de personnes qui utilisent gcc ou le compilateur de Microsoft...
Avatar de Gil01 Gil01 - Membre à l'essai https://www.developpez.com
le 06/01/2010 à 16:20
Rien de neuf sous le soleil en effet... Hélas pour les entreprises ayant des réseaux hétérogènes.
Je n'utilise pas le compilateur Intel, simplement parce-que j'ai commencé avec un autre et que je ne programme presque plus à ce niveau (changement d'orientation professionnelle involontaire suite à des coupures !)
Avatar de Mac LAK Mac LAK - Inactif https://www.developpez.com
le 14/01/2010 à 14:46
Faut voir aussi l'effet inverse : Intel n'est pas maître du microcode des CPU AMD, c'est évident.

Cas concret : grosse application bien lourde développée par une société et déployée chez des clients sur matériel spécifique. On développe avec ICC pour gagner des perfs, et on vends à l'économie avec une machine basée sur un AMD.

ICC utilise / active une optimisation lourde sur un CPU AMD, qui crashe un jour pour cause de microcode légèrement différent de celui d'Intel. Machine plantée, application crashée, données perdues, contrat de la Mafia sur la tête du poisson rouge et tout et tout, on cherche un bouc émissaire.

On tape sur qui, au final ?
  • Intel, qui n'a pas dépensé plein de sous (et risqué trois tonnes de procès pour reverse-engineering) pour adapter son compilateur au produit d'un concurrent ?
  • AMD, qui n'a pas suffisamment bien copié le produit d'Intel ?
  • Les développeurs, qui ont utilisé le compilateur Intel ?
  • Le fournisseur de l'application, qui n'a pas spécifié une plate-forme matérielle adaptée ?
Au moins, Intel se prémunit du premier cas. Le code produit au final ne doit pas être moins bon que celui produit par Visual, je pense, même s'il n'est pas aussi performant que celui exécuté sur un CPU Intel.

Reste à dire que rien n'empêche AMD de sortir son propre compilateur suroptimisé pour ses CPU... Et que l'on peut se demander pourquoi ce n'est pas le cas.

Pour ma part, en tout cas, ça ne me choque pas, et ça ne me dérange pas non plus. Et je continue de tanner ma hiérarchie pour avoir les sous pour des licences ICC.
Offres d'emploi IT
Architecte sécurité des systèmes d'information embarqués H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY
Responsable protection des données H/F
Safran - Ile de France - Magny-les-Hameaux (78114)
Architecte systèmes études & scientifiques H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil