Un développeur accuse Intel de brider son compilateur : seriez-vous prêt(e) à en changer ?

Version imprimable

04/01/2010, 16h14
Gordon Fowler

Un développeur accuse Intel de brider son compilateur : seriez-vous prêt(e) à en changer ?

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

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 :

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

:fleche: La rubrique Hardware de Développez

Et vous ?

:fleche: Pensez-vous que le CPU dispatcher du compilateur d'Intel soit biaisé ?
04/01/2010, 16h58
viking1404

Et alors ?

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 :(
04/01/2010, 17h19
shidosh

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.
04/01/2010, 17h35
Gordon Fowler

Salut shidosh,

Citation:

Envoyé par shidosh

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

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
06/01/2010, 10h28
Emmanuel Deloget

Citation:

Envoyé par Gordon Fowler

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...
06/01/2010, 16h20
Gil01

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 !)
14/01/2010, 14h46
Mac LAK
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.