jeudi 10 avril
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | O'Reilly | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Liens connexes

Dépêche modérée par

Développeur : Compilateur C++ et Fortran

Posté par joye pa (). Modéré le 27 août 2001.
Commercial
Intel a porté ses compilateurs C++ et Fortran (v5) sur Linux en collaboration avec Caldera. Ils sont compatibles avec gcc (implémentation C et linker), cependant l'implémentation C++ étant différente, il ne pourra pas utiliser des objets crées avec g++.
A noter également que toutes les extensions GNU C ne sont pas encore supportées et ne le seront pas lors de lors de la première sortie.
Plus d'info sur le site.
Il me parait important de signaler que ces produits sont des produits propriétaires se basant sur des implementations libres, qu'en est-il réellement des gains en performances avec ces compilateurs ? Et donc l'intérêt de les utiliser en lieu et place des outils GNU ? L'orientation qu'a pris Caldera au niveau de sa distribution ne m'inspire pas un avenir libre pour ce genre de produits.

> Lire la dépêche (39 commentaires, moyenne: 0,2).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Et hop

Posté par Jak () le 27/08/2001 à 12:17. (lien). Évalué à 1.

Surtout qu'à $400 le compilo, ya intérêt à ce que ça accélère sacrément la sortie.
http://www.tomshardware.com/technews/technews-20010824.html#0103(...)
Cela dit, il semblerait que les binaires optimisés de la sorte profitent également aux Athlon/Duron, enfin, c'est une autre histoire.

--
« Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
- Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)

Fortran 95 Rox !

Posté par Julien Perrot () le 27/08/2001 à 12:18. (lien). Évalué à 1.

Même si ce n'est pas libre, je pense que certains vont être contents d'avoir un compilateur fortran 95.

l'interet

Posté par Troy McClure (page perso, ) le 27/08/2001 à 12:21. (lien). Évalué à 1.

l'interet c'est peut être tout ce qui va autour du compilo, entre autre vtune pour faire du profiling, les librairies mathématiques ultra-optimisées (pour les proc intel)

d'ailleurs y'a un bench sur les perf obtenues (dgemm = multiplication matrice x matrice ) -> celles de l'itanium sont assez impressionnantes. c'est ici:

http://developer.intel.com/software/products/mkl/mkl51w/mklspecs.ht(...)
mais bon, c'est pas libre et certainement pas très AMD-friendly... et pour l'itanium y'a aussi le compilo de sgi, qui est au moins open-source.

Bizarre pour la compatibilite binaire C++

Posté par reno () le 27/08/2001 à 12:42. (lien). Évalué à 1.

Je croyais que la nouvelle version de gcc 3+ utilisait justement une ABI commune a tous les compilateurs sur x86 au moins.

Et que c'etait meme LE point fort de cette version de gcc..

Quelqu'un a un compte pour lire la FAQ?

Ecoeuré

Posté par Orphée () le 27/08/2001 à 12:59. (lien). Évalué à 1.

'Tain, ch'uis dégouté d'la vie, là... J'avais proposé cette nouvelle y a 3 jours, dès réception du communiqué en avant première d'Intel, mais les modéros préfèrent attendre que tous les autres sites en aient parlé avant de passer l'actu.
Dég', j'vous dis...

GCC 3.xx

Posté par Anonyme () le 27/08/2001 à 14:13. (lien). Évalué à 0.

Il est prevu chez intel d'apporter des optimisations p4/SSE2 dans de futures release de GCC. Pas de date par contre...

Intel comme microsoft?

Posté par Anonyme () le 27/08/2001 à 14:29. (lien). Évalué à 0.

Le gros interêt pour intel est de cacher les recettes de cuisine pour obtimiser l'utilisation de leur cpu.

Leures craintes étant d'être presque obligé de les montrer (via gcc) si Linux devient une plateforme incontournable.

S'il cache un maximum de recettes, leur compilateur sera nettement plus performant que gcc. Donc incontournable.
=> ils vont ce faire plein de pognon et rien donné au free software.

Microsoft fait du pognon avec leur compilateur (visual C++) sous windows. Là c'est Intel sous Linux...

Il ne faut pas utiliser ce compilo. Intel sera en concurrence avec AMD. Le "gagnant" sera celui qui offre les meilleurs performances avec gcc (Intel sera contraint de fournir des infos s'il veut rester dans la course).

Ca fait pas de mal

Posté par Yann Droneaud (page perso, ) le 27/08/2001 à 14:30. (lien). Évalué à 1.

Ca derange personne personne si il y a different compilateur sous linux (ou autre systeme libre).
Du moment que le compilateur Intel n'est utiliser que pour comparaison (voir reverse engeenering si c'est legal;): ABI,Generation de code,Optimisation
Si personne ne l'utilise en production y'aura pas de probleme.
Et de toute facon le compilateur intel reste pour systeme intel: x86, itanium (voire ARM)

un message d'une mailling list gcc concernant des perfs de compilo

Posté par Anonyme () le 27/08/2001 à 15:28. (lien). Évalué à 0.

> I have tested a scientific benchmark with several compilers, under both
> windows 98 and two flavors of linux. So far, the performance of
> _executables_
> generated by gcc 2.95.2 (-O2|-O3|-O6 -malign-double -
> fomit-frame-pointer -funroll-loops
> -fstrict-aliasing -ffloat-store -fexpensive-optimizations ...etc.) seems
> pretty dismal:
>
> (higher is better:)
> gcc / linux 0.47
> MS6/win98 1.98
> Intel5/win98 2.33
> MS6/win98/SIMD 3.78
> Intel5.01/win98/SIMD 5.72
> Intel5.01/linux/SIMD 5.72
>
> All run on the same P4 system, 1 GB RDRAM. The benchmark is both
> memory-and float-intensive, uses large dynamic arrays of floats, and has
> heavy
> pointer traffic. The time-critical function was hand-optimized to
> eliminate most pointer traffic. Almost all the operations are basic math;
> the
> dependence on libm should be minimal. For similar codes on the
> alphas, we found gcc to be nearly as good as DEC C, and hand
> pointer optimizations were adequate.
>
> I haven't used gcc or egcs in several years. What should I consider
> (options, gcc/egcs version) to improve gcc performance?
> Of all the options I tried for gcc, only -fstrict-aliasing
> made any difference, upping performance from a pitiful 0.31 to 0.47.
> I've been searching dejanews and gcc development for hints,
> and haven't found much. So far, this looks like a good
> advertisement for the Intel linux compiler, given the factor
> 12 performance improvement.
>
> Thanks; please fork replies to my e-mail as well as this newsgroup,
> as I read news on 6 different systems, with different groups selected.


You have chosen the most unfavorable areas for GCC. It is horribly lame
with floating point (my own observations confirm your worst suspicisions).
It also is not as good as some others with pointer manipulations at times.
There are areas where GCC shines (e.g. string operations, bitwise
operations).

Suggestion #1:
Try the options one at a time. Keep the ones that improve performance, and
discard those that harm performance. (In the end, there is simply no way
you are going to beat the Intel compiler on floating point operations
anyway).

Suggestion #2:
Post GCC questions to the GCC help groups. The experts there will know far
better how to solve your queries.

mouais, trop nouveau

Posté par Dugland Bob (page perso, ) le 27/08/2001 à 16:01. (lien). Évalué à 1.

T'est gentil, je l'ai essayé début juillet déjà.

"u'en est-il réellement des gains en performances avec ces compilateurs ?"
Il déchire ça race ('inter-files', 'profile guided optimisation' et je fout les fonctions dans l'ordre pour que le cache fonctionne)

Revenir en haut de page

Run by Team LinuxFr

Cette page a été générée par Templeet en 0.1413s (dont 0.0146 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.