je voudrais savoir ce qu'il faut passer a gcc dans l'option -march pour un processeur intel centrino.
info gcc, chercher Centrino ? Dans les docs que j'ai (3.4 et 4.0), ce mot apparaît exactement une fois, exactement à l'endroit où se trouve la réponse à la question.
Moi wrote in message <dib2of$efh$1@utcnews.utc.fr>:
je voudrais savoir ce qu'il faut passer a gcc dans l'option -march pour
un processeur intel centrino.
info gcc, chercher Centrino ? Dans les docs que j'ai (3.4 et 4.0), ce mot
apparaît exactement une fois, exactement à l'endroit où se trouve la réponse
à la question.
je voudrais savoir ce qu'il faut passer a gcc dans l'option -march pour un processeur intel centrino.
info gcc, chercher Centrino ? Dans les docs que j'ai (3.4 et 4.0), ce mot apparaît exactement une fois, exactement à l'endroit où se trouve la réponse à la question.
Jérémy JUST
On Sun, 09 Oct 2005 14:35:32 +0200 Moi wrote:
je voudrais savoir ce qu'il faut passer a gcc dans l'option -march pour un processeur intel centrino.
Je pense qu'il est encore mieux d'utiliser ICC (le compilateur Intel), pour un processeur Intel.
Quand il marche. Et puis bon, pour la différence que ça fait pour la plupart des applications...
Moi
info gcc, chercher Centrino ? Dans les docs que j'ai (3.4 et 4.0), ce mot apparaît exactement une fois, exactement à l'endroit où se trouve la réponse à la question.
Je dois pas avoir la bonne alors...
Fouiller pour la chaîne [Centrino]: [Return] Fouille infructueuse.
info gcc, chercher Centrino ? Dans les docs que j'ai (3.4 et 4.0), ce mot
apparaît exactement une fois, exactement à l'endroit où se trouve la réponse
à la question.
Je dois pas avoir la bonne alors...
Fouiller pour la chaîne [Centrino]: [Return]
Fouille infructueuse.
info gcc, chercher Centrino ? Dans les docs que j'ai (3.4 et 4.0), ce mot apparaît exactement une fois, exactement à l'endroit où se trouve la réponse à la question.
Je dois pas avoir la bonne alors...
Fouiller pour la chaîne [Centrino]: [Return] Fouille infructueuse.
Rémi Moyen
info gcc, chercher Centrino ? Dans les docs que j'ai (3.4 et 4.0), ce mot apparaît exactement une fois, exactement à l'endroit où se trouve la réponse à la question.
Je dois pas avoir la bonne alors...
Fouiller pour la chaîne [Centrino]: [Return] Fouille infructueuse.
Bah, je sais pas quelle version tu utilises, moi aussi j'ai cette info sans problème. Et comme personne ne veut te répondre : -march pentium-m
(gcc 4.0.1) -- Rémi Moyen
info gcc, chercher Centrino ? Dans les docs que j'ai (3.4 et 4.0), ce mot
apparaît exactement une fois, exactement à l'endroit où se trouve la
réponse
à la question.
Je dois pas avoir la bonne alors...
Fouiller pour la chaîne [Centrino]: [Return]
Fouille infructueuse.
Bah, je sais pas quelle version tu utilises, moi aussi j'ai cette info
sans problème. Et comme personne ne veut te répondre :
-march pentium-m
info gcc, chercher Centrino ? Dans les docs que j'ai (3.4 et 4.0), ce mot apparaît exactement une fois, exactement à l'endroit où se trouve la réponse à la question.
Je dois pas avoir la bonne alors...
Fouiller pour la chaîne [Centrino]: [Return] Fouille infructueuse.
Bah, je sais pas quelle version tu utilises, moi aussi j'ai cette info sans problème. Et comme personne ne veut te répondre : -march pentium-m
(gcc 4.0.1) -- Rémi Moyen
Moi
Bah, je sais pas quelle version tu utilises, moi aussi j'ai cette info sans problème. Et comme personne ne veut te répondre : -march pentium-m
Merci ;) J'avais vu ca dans la doc de gcc 3.4 (http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options). Apparement cette option n'est pas dispo sur la version 3.3 (celle que j'utilise, je l'avais mis dans mon premier post ;) ), mais on m'a dit qu'avec les options -march=pentium3 -msse2 ca revient a peu pres au meme.
Merci quand meme.
Bah, je sais pas quelle version tu utilises, moi aussi j'ai cette info
sans problème. Et comme personne ne veut te répondre :
-march pentium-m
Merci ;)
J'avais vu ca dans la doc de gcc 3.4
(http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options).
Apparement cette option n'est pas dispo sur la version 3.3 (celle que
j'utilise, je l'avais mis dans mon premier post ;) ), mais on m'a dit
qu'avec les options -march=pentium3 -msse2 ca revient a peu pres au meme.
Bah, je sais pas quelle version tu utilises, moi aussi j'ai cette info sans problème. Et comme personne ne veut te répondre : -march pentium-m
Merci ;) J'avais vu ca dans la doc de gcc 3.4 (http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options). Apparement cette option n'est pas dispo sur la version 3.3 (celle que j'utilise, je l'avais mis dans mon premier post ;) ), mais on m'a dit qu'avec les options -march=pentium3 -msse2 ca revient a peu pres au meme.
Merci quand meme.
Jérémy JUST
On Sun, 9 Oct 2005 20:45:31 +0000 (UTC) Nicolas George <nicolas$ wrote:
Je pense qu'il est encore mieux d'utiliser ICC Quand il marche.
Bah, ce n'est pas de sa faute si tant de code repose sur les particularités de GCC (sans le dire, en plus, alors que le noyau Linux l'annonce explicitement).
Et quand tu envoies un patch pour qu'un programme compile avec autre chose que GCC (avec le compilo Sun, par exemple), tu te fais plus ou moins répondre que « je ne vois pas de quoi vous parlez ».
Et puis bon, pour la différence que ça fait pour la plupart des applications...
Sur des ultraSPARC II, avec un programme qui travaille essentiellement sur des chaînes de caractères, j'ai constaté une différence de 6% à 10% en faveur du compilateur Sun, entre le meilleur temps obtenu avec GCC et le meilleur temps obtenu avec Sun CC (la détermination du meilleur temps ayant été faite en essayant 10 à 20 combinaisons d'options sensées).
Je me dis que pour des calculs pour lesquels certains processeurs ont des circuits dédiés (entiers ou flottants), la différence entre le compilateur du fabricant et GCC peut être encore plus importante (même si globalement, GCC se débrouille plutôt bien sur énormément de plate-formes).
-- Jérémy JUST
On Sun, 9 Oct 2005 20:45:31 +0000 (UTC)
Nicolas George <nicolas$george@salle-s.org> wrote:
Je pense qu'il est encore mieux d'utiliser ICC
Quand il marche.
Bah, ce n'est pas de sa faute si tant de code repose sur les
particularités de GCC (sans le dire, en plus, alors que le noyau Linux
l'annonce explicitement).
Et quand tu envoies un patch pour qu'un programme compile avec autre
chose que GCC (avec le compilo Sun, par exemple), tu te fais plus ou moins
répondre que « je ne vois pas de quoi vous parlez ».
Et puis bon, pour la différence que ça fait pour la plupart des
applications...
Sur des ultraSPARC II, avec un programme qui travaille essentiellement
sur des chaînes de caractères, j'ai constaté une différence de 6% à 10% en
faveur du compilateur Sun, entre le meilleur temps obtenu avec GCC et le
meilleur temps obtenu avec Sun CC (la détermination du meilleur temps
ayant été faite en essayant 10 à 20 combinaisons d'options sensées).
Je me dis que pour des calculs pour lesquels certains processeurs ont
des circuits dédiés (entiers ou flottants), la différence entre le
compilateur du fabricant et GCC peut être encore plus importante (même
si globalement, GCC se débrouille plutôt bien sur énormément de
plate-formes).
On Sun, 9 Oct 2005 20:45:31 +0000 (UTC) Nicolas George <nicolas$ wrote:
Je pense qu'il est encore mieux d'utiliser ICC Quand il marche.
Bah, ce n'est pas de sa faute si tant de code repose sur les particularités de GCC (sans le dire, en plus, alors que le noyau Linux l'annonce explicitement).
Et quand tu envoies un patch pour qu'un programme compile avec autre chose que GCC (avec le compilo Sun, par exemple), tu te fais plus ou moins répondre que « je ne vois pas de quoi vous parlez ».
Et puis bon, pour la différence que ça fait pour la plupart des applications...
Sur des ultraSPARC II, avec un programme qui travaille essentiellement sur des chaînes de caractères, j'ai constaté une différence de 6% à 10% en faveur du compilateur Sun, entre le meilleur temps obtenu avec GCC et le meilleur temps obtenu avec Sun CC (la détermination du meilleur temps ayant été faite en essayant 10 à 20 combinaisons d'options sensées).
Je me dis que pour des calculs pour lesquels certains processeurs ont des circuits dédiés (entiers ou flottants), la différence entre le compilateur du fabricant et GCC peut être encore plus importante (même si globalement, GCC se débrouille plutôt bien sur énormément de plate-formes).
-- Jérémy JUST
Jérémy JUST
On Wed, 12 Oct 2005 11:28:21 +0200 Jérémy JUST wrote:
Sur des ultraSPARC II, avec un programme qui travaille essentiellement sur des chaînes de caractères, j'ai constaté une différence de 6% à 10% en faveur du compilateur Sun, entre le meilleur temps obtenu avec GCC et le meilleur temps obtenu avec Sun CC
J'allais oublier: grosse différence entre les résultats de ces deux compilateurs: Sun CC produit un binaire 64 bits, alors que GCC n'est qu'en 32 bits.
-- Jérémy JUST
On Wed, 12 Oct 2005 11:28:21 +0200
Jérémy JUST <jeremy_just@netcourrier.com> wrote:
Sur des ultraSPARC II, avec un programme qui travaille essentiellement
sur des chaînes de caractères, j'ai constaté une différence de 6% à 10%
en faveur du compilateur Sun, entre le meilleur temps obtenu avec GCC et
le meilleur temps obtenu avec Sun CC
J'allais oublier: grosse différence entre les résultats de ces deux
compilateurs: Sun CC produit un binaire 64 bits, alors que GCC n'est qu'en
32 bits.
On Wed, 12 Oct 2005 11:28:21 +0200 Jérémy JUST wrote:
Sur des ultraSPARC II, avec un programme qui travaille essentiellement sur des chaînes de caractères, j'ai constaté une différence de 6% à 10% en faveur du compilateur Sun, entre le meilleur temps obtenu avec GCC et le meilleur temps obtenu avec Sun CC
J'allais oublier: grosse différence entre les résultats de ces deux compilateurs: Sun CC produit un binaire 64 bits, alors que GCC n'est qu'en 32 bits.
-- Jérémy JUST
Nicolas George
Jérémy JUST wrote in message <434cd735$0$4331$:
Bah, ce n'est pas de sa faute si tant de code repose sur les particularités de GCC
Peut-être, mais je pensais plus à un bon paquet d'internal compiler error qu'il m'a pondues il y a quelques années. Depuis, je n'utilise plus -- et de toutes façons ma machine principale est un Athlon.
Sur des ultraSPARC II, avec un programme qui travaille essentiellement sur des chaînes de caractères, j'ai constaté une différence de 6% à 10% en faveur du compilateur Sun, entre le meilleur temps obtenu avec GCC et le meilleur temps obtenu avec Sun CC (la détermination du meilleur temps ayant été faite en essayant 10 à 20 combinaisons d'options sensées).
Je me dis que pour des calculs pour lesquels certains processeurs ont des circuits dédiés (entiers ou flottants), la différence entre le compilateur du fabricant et GCC peut être encore plus importante (même si globalement, GCC se débrouille plutôt bien sur énormément de plate-formes).
Le truc, c'est que la plupart des programmes qui font l'utilisation courante d'une distribution Linux sont limités par d'autres facteurs que la vitesse du CPU : la bande passante mémoire, les entrées-sorties.
Jérémy JUST wrote in message <434cd735$0$4331$626a54ce@news.free.fr>:
Bah, ce n'est pas de sa faute si tant de code repose sur les
particularités de GCC
Peut-être, mais je pensais plus à un bon paquet d'internal compiler error
qu'il m'a pondues il y a quelques années. Depuis, je n'utilise plus -- et de
toutes façons ma machine principale est un Athlon.
Sur des ultraSPARC II, avec un programme qui travaille essentiellement
sur des chaînes de caractères, j'ai constaté une différence de 6% à 10% en
faveur du compilateur Sun, entre le meilleur temps obtenu avec GCC et le
meilleur temps obtenu avec Sun CC (la détermination du meilleur temps
ayant été faite en essayant 10 à 20 combinaisons d'options sensées).
Je me dis que pour des calculs pour lesquels certains processeurs ont
des circuits dédiés (entiers ou flottants), la différence entre le
compilateur du fabricant et GCC peut être encore plus importante (même
si globalement, GCC se débrouille plutôt bien sur énormément de
plate-formes).
Le truc, c'est que la plupart des programmes qui font l'utilisation courante
d'une distribution Linux sont limités par d'autres facteurs que la vitesse
du CPU : la bande passante mémoire, les entrées-sorties.
Bah, ce n'est pas de sa faute si tant de code repose sur les particularités de GCC
Peut-être, mais je pensais plus à un bon paquet d'internal compiler error qu'il m'a pondues il y a quelques années. Depuis, je n'utilise plus -- et de toutes façons ma machine principale est un Athlon.
Sur des ultraSPARC II, avec un programme qui travaille essentiellement sur des chaînes de caractères, j'ai constaté une différence de 6% à 10% en faveur du compilateur Sun, entre le meilleur temps obtenu avec GCC et le meilleur temps obtenu avec Sun CC (la détermination du meilleur temps ayant été faite en essayant 10 à 20 combinaisons d'options sensées).
Je me dis que pour des calculs pour lesquels certains processeurs ont des circuits dédiés (entiers ou flottants), la différence entre le compilateur du fabricant et GCC peut être encore plus importante (même si globalement, GCC se débrouille plutôt bien sur énormément de plate-formes).
Le truc, c'est que la plupart des programmes qui font l'utilisation courante d'une distribution Linux sont limités par d'autres facteurs que la vitesse du CPU : la bande passante mémoire, les entrées-sorties.
Jérémy JUST
On Wed, 12 Oct 2005 14:31:48 +0000 (UTC) Nicolas George <nicolas$ wrote:
Peut-être, mais je pensais plus à un bon paquet d'internal compiler error qu'il m'a pondues il y a quelques années. Depuis, je n'utilise plus -- et de toutes façons ma machine principale est un Athlon.
J'utilise la version 8.1 et je n'ai encore jamais rencontré de problèmes internes. Par contre, du code C qui ne respecte pas la norme, oui, j'en vois souvent.
Le truc, c'est que la plupart des programmes qui font l'utilisation courante d'une distribution Linux sont limités par d'autres facteurs que la vitesse du CPU : la bande passante mémoire, les entrées-sorties.
Pour un usage personnel, je suis bien d'accord. Mais pour un usage personnel, on se contente aussi de mettre un « -O3 » à GCC et on ne cherche pas à optimiser plus avant.
Donc quand un contributeur demande comment il pourrait optimiser ses exécutables, j'indique l'existence du compilateur du fabricant.
-- Jérémy JUST
On Wed, 12 Oct 2005 14:31:48 +0000 (UTC)
Nicolas George <nicolas$george@salle-s.org> wrote:
Peut-être, mais je pensais plus à un bon paquet d'internal compiler
error qu'il m'a pondues il y a quelques années. Depuis, je n'utilise
plus -- et de toutes façons ma machine principale est un Athlon.
J'utilise la version 8.1 et je n'ai encore jamais rencontré de
problèmes internes.
Par contre, du code C qui ne respecte pas la norme, oui, j'en vois
souvent.
Le truc, c'est que la plupart des programmes qui font l'utilisation
courante d'une distribution Linux sont limités par d'autres facteurs
que la vitesse du CPU : la bande passante mémoire, les
entrées-sorties.
Pour un usage personnel, je suis bien d'accord. Mais pour un usage
personnel, on se contente aussi de mettre un « -O3 » à GCC et on ne
cherche pas à optimiser plus avant.
Donc quand un contributeur demande comment il pourrait optimiser ses
exécutables, j'indique l'existence du compilateur du fabricant.
On Wed, 12 Oct 2005 14:31:48 +0000 (UTC) Nicolas George <nicolas$ wrote:
Peut-être, mais je pensais plus à un bon paquet d'internal compiler error qu'il m'a pondues il y a quelques années. Depuis, je n'utilise plus -- et de toutes façons ma machine principale est un Athlon.
J'utilise la version 8.1 et je n'ai encore jamais rencontré de problèmes internes. Par contre, du code C qui ne respecte pas la norme, oui, j'en vois souvent.
Le truc, c'est que la plupart des programmes qui font l'utilisation courante d'une distribution Linux sont limités par d'autres facteurs que la vitesse du CPU : la bande passante mémoire, les entrées-sorties.
Pour un usage personnel, je suis bien d'accord. Mais pour un usage personnel, on se contente aussi de mettre un « -O3 » à GCC et on ne cherche pas à optimiser plus avant.
Donc quand un contributeur demande comment il pourrait optimiser ses exécutables, j'indique l'existence du compilateur du fabricant.
