Donc je bosse dans un collège, et la saison des subvention permet
d'acheter des poste. Et ceux de PS étant intéressant niveau prix/config,
ce sont ceux qu'on a acheté.
Résultat : Le Mandrake linux Discovery annoncé est en fait un Linpus
Linux, distribution basée Mdk, sur laquelle je n'ai pas réussit à faire
un chti urpmi, ni même à trouver un outil graphique pour maj.
Bref, moi qui espérait un peu là-dessus pour convaincre de faire migrer
la salle info sous linux, pas de pot avec cette config à 2 sous...
Ouais, je sais, on en a pour son argent. Mais quand même...
La fin de l'aventure, totalement HS ici, mais bon, c'est que j'ai tout
viré pour refoutre win98 dessus (et ouais, je sais :-(). Ai pour ça
utilisé une knoppix, et QTParted, en 2 fois (obligation de redémarrer au
milieu), pour pouvoir supprimer les partitions et préparer/formater en
fat32. Et le fin du fin, aucun pilote fourni. Heureusement qu'il y a un
site.
En bref, le prix, 350 l'UC pour 80Go, Celeron D et 512 Mo Ram se justifie.
bien incapable de me rappeler qui avait signé ces publications. Maintenant, après plus de dix ans et maints déménagements, je n'ai aucune idée d'ou sont ces archives...
en fin de compte cela tombe plutot bien
cela evite les prises de tete et /ou migraine
par contre je peux te dire le principe de mon gene il est base sur la fct de repartition des nbs premiers
en gros
p0-p1=dif et je fais la somme modulo 2 des chiffres de la difference l'ecart entre p0 et p1 est defini par l'utilisateur ainsi que le point d'entree
en une nuit de calcul cela donne en gros140k aucun cycle detecte et taux de compression impressionnant comparaison entre deux sorties differentes toutes ausi impressionnantes
par contre je ne suis vraiment pas sur que le principe ne soit pas deja connu mais comme l'implementation est liee a une autre prise de tete je pense que cela doit etre relativement nouveau
Effectivement, c'est pas mal et bien gourmant en temps de calcul ;-)
Ce dont je me souviens de la méthode utilisée, c'est qu'on se servait de propriétés du calcul flottant IEEE (la génération du bit de poids faible) lors de calculs intrinsèquement peu précis (je veux dire par là, en n'utilisant pas des opérations qui sont spécifiées "bits exacts") pour générer les nombres finaux, ce qui est finalement assez proche du modulo 2 dans l'esprit.
Heureusement pour mes neurones, on n'avait fait qu'implémenter une méthode connue (enfin, pas par moi avant ce projet, en tout cas !) qui nous avait été indiquée par la personne qui supervisait le projet. Je pense que si j'avais eu à développer une méthode de ce genre avec mon petit cerveau, je m'en souviendrais ;-)
On Mon, 23 May 2005 10:22:42 +0200, remy wrote:
bien incapable de me rappeler qui avait signé ces publications.
Maintenant, après plus de dix ans et maints déménagements, je n'ai
aucune idée d'ou sont ces archives...
en fin de compte cela tombe plutot bien
cela evite les prises de tete et /ou migraine
par contre je peux te dire le principe de mon gene il est base
sur la fct de repartition des nbs premiers
en gros
p0-p1=dif
et je fais la somme modulo 2 des chiffres de la difference
l'ecart entre p0 et p1 est defini par l'utilisateur ainsi que le point
d'entree
en une nuit de calcul cela donne en gros140k aucun cycle detecte
et taux de compression impressionnant
comparaison entre deux sorties differentes toutes ausi impressionnantes
par contre je ne suis vraiment pas sur que le principe
ne soit pas deja connu
mais comme l'implementation est liee a une autre prise de tete
je pense que cela doit etre relativement nouveau
Effectivement, c'est pas mal et bien gourmant en temps de calcul ;-)
Ce dont je me souviens de la méthode utilisée, c'est qu'on se servait
de propriétés du calcul flottant IEEE (la génération du bit de poids
faible) lors de calculs intrinsèquement peu précis (je veux dire par
là, en n'utilisant pas des opérations qui sont spécifiées "bits
exacts") pour générer les nombres finaux, ce qui est finalement assez
proche du modulo 2 dans l'esprit.
Heureusement pour mes neurones, on n'avait fait qu'implémenter une
méthode connue (enfin, pas par moi avant ce projet, en tout cas !) qui
nous avait été indiquée par la personne qui supervisait le projet. Je
pense que si j'avais eu à développer une méthode de ce genre avec mon
petit cerveau, je m'en souviendrais ;-)
bien incapable de me rappeler qui avait signé ces publications. Maintenant, après plus de dix ans et maints déménagements, je n'ai aucune idée d'ou sont ces archives...
en fin de compte cela tombe plutot bien
cela evite les prises de tete et /ou migraine
par contre je peux te dire le principe de mon gene il est base sur la fct de repartition des nbs premiers
en gros
p0-p1=dif et je fais la somme modulo 2 des chiffres de la difference l'ecart entre p0 et p1 est defini par l'utilisateur ainsi que le point d'entree
en une nuit de calcul cela donne en gros140k aucun cycle detecte et taux de compression impressionnant comparaison entre deux sorties differentes toutes ausi impressionnantes
par contre je ne suis vraiment pas sur que le principe ne soit pas deja connu mais comme l'implementation est liee a une autre prise de tete je pense que cela doit etre relativement nouveau
Effectivement, c'est pas mal et bien gourmant en temps de calcul ;-)
Ce dont je me souviens de la méthode utilisée, c'est qu'on se servait de propriétés du calcul flottant IEEE (la génération du bit de poids faible) lors de calculs intrinsèquement peu précis (je veux dire par là, en n'utilisant pas des opérations qui sont spécifiées "bits exacts") pour générer les nombres finaux, ce qui est finalement assez proche du modulo 2 dans l'esprit.
Heureusement pour mes neurones, on n'avait fait qu'implémenter une méthode connue (enfin, pas par moi avant ce projet, en tout cas !) qui nous avait été indiquée par la personne qui supervisait le projet. Je pense que si j'avais eu à développer une méthode de ce genre avec mon petit cerveau, je m'en souviendrais ;-)
Richard Delorme
Des gens pensent que c'est en effet une perte de temps :
Et à la lecture de ces transparents, on voit que l'argumentation est incroyablement stupide.
Tu l'as sans doute mal lu.
Apparemment l'une des rares choses qui le préoccupe est "comment améliorer l'évaluation des papiers sur le sujet". A vrai dire les papiers sur le sujet on s'en fout comme de sa première chemise, tandis que l'amélioration effective de la vitesse d'exécution intéresse à peu prés tout le monde.
Quelle est la frontière entre les papiers et la mise en pratique de ce qu'ils proposent ?
Qui plus est il y a des gens qui y travaillent et obtiennent des résultats tout à fait significatifs, par exemple les ingénieurs d'Intel pour le compilateur Intel et même les ingénieurs que Suse a mis sur gcc.
Bof, entre gcc 2.95 et gcc 4.0 il y a 6 ans d'écart pour quelle différence de performances ?
Finalement l'alpha et l'omega de son argument c'est que la vitesse des processurs double tous les deux ans, et bien il y a un bon moment que ceci n'est plus vrai.
Entre les CPU 64 bits/dual-core qui sortent en ce moment et les processeurs qui régnaient en 1999 (pentium III 500 Mhz), il y a un gouffre de performance autrement plus important qu'entre les compilateurs des deux époques.
-- Richard
Des gens pensent que c'est en effet une perte de temps :
Et à la lecture de ces transparents, on voit que l'argumentation
est incroyablement stupide.
Tu l'as sans doute mal lu.
Apparemment l'une des rares choses qui le
préoccupe est "comment améliorer l'évaluation des papiers sur le sujet".
A vrai dire les papiers sur le sujet on s'en fout comme de sa première
chemise, tandis que l'amélioration effective de la vitesse d'exécution
intéresse à peu prés tout le monde.
Quelle est la frontière entre les papiers et la mise en pratique de ce
qu'ils proposent ?
Qui plus est il y a des gens qui y
travaillent et obtiennent des résultats tout à fait significatifs, par
exemple les ingénieurs d'Intel pour le compilateur Intel et même
les ingénieurs que Suse a mis sur gcc.
Bof, entre gcc 2.95 et gcc 4.0 il y a 6 ans d'écart pour quelle
différence de performances ?
Finalement l'alpha et l'omega
de son argument c'est que la vitesse des processurs double tous les deux
ans, et bien il y a un bon moment que ceci n'est plus vrai.
Entre les CPU 64 bits/dual-core qui sortent en ce moment et les
processeurs qui régnaient en 1999 (pentium III 500 Mhz), il y a un
gouffre de performance autrement plus important qu'entre les
compilateurs des deux époques.
Et à la lecture de ces transparents, on voit que l'argumentation est incroyablement stupide.
Tu l'as sans doute mal lu.
Apparemment l'une des rares choses qui le préoccupe est "comment améliorer l'évaluation des papiers sur le sujet". A vrai dire les papiers sur le sujet on s'en fout comme de sa première chemise, tandis que l'amélioration effective de la vitesse d'exécution intéresse à peu prés tout le monde.
Quelle est la frontière entre les papiers et la mise en pratique de ce qu'ils proposent ?
Qui plus est il y a des gens qui y travaillent et obtiennent des résultats tout à fait significatifs, par exemple les ingénieurs d'Intel pour le compilateur Intel et même les ingénieurs que Suse a mis sur gcc.
Bof, entre gcc 2.95 et gcc 4.0 il y a 6 ans d'écart pour quelle différence de performances ?
Finalement l'alpha et l'omega de son argument c'est que la vitesse des processurs double tous les deux ans, et bien il y a un bon moment que ceci n'est plus vrai.
Entre les CPU 64 bits/dual-core qui sortent en ce moment et les processeurs qui régnaient en 1999 (pentium III 500 Mhz), il y a un gouffre de performance autrement plus important qu'entre les compilateurs des deux époques.
-- Richard
Richard Delorme
C'est grâce à des raisonements comme celà que Microsoft propose des plates formes multi-média "qui nécéssitent un CPU à au moins 2 Ghz" et coute 2000 euros alors qu'on sait fait des cartes embedded qui coutent moins de 300 euros, avec des CPU < 500 Mhz (voire < 300 Mhz) qui font la même chose... Par contre, les compilations (et le code) doivent être légèrement optimisés... Mais ça n'a, bien sur, aucun intérêt...
1) Microsoft propose un des meilleurs compilateur C/C++ du marché, entre autre en terme de performance du code compilé. 2) Une carte mère avec un CPU à 2 GHz, ça ne vaut pas 100 Euros. 3) 300 Euros pour une carte embarqué avec un CPU à 300 Mhz, c'est du vol. 4) Les compilateurs optimisant pour les cartes embarquées... ça n'existe pas. 5) Tu trolles mal.
-- Richard
C'est grâce à des raisonements comme celà que Microsoft propose des
plates formes multi-média "qui nécéssitent un CPU à au moins 2 Ghz" et
coute 2000 euros alors qu'on sait fait des cartes embedded qui coutent
moins de 300 euros, avec des CPU < 500 Mhz (voire < 300 Mhz) qui font la
même chose... Par contre, les compilations (et le code) doivent être
légèrement optimisés...
Mais ça n'a, bien sur, aucun intérêt...
1) Microsoft propose un des meilleurs compilateur C/C++ du marché, entre
autre en terme de performance du code compilé.
2) Une carte mère avec un CPU à 2 GHz, ça ne vaut pas 100 Euros.
3) 300 Euros pour une carte embarqué avec un CPU à 300 Mhz, c'est du vol.
4) Les compilateurs optimisant pour les cartes embarquées... ça n'existe
pas.
5) Tu trolles mal.
C'est grâce à des raisonements comme celà que Microsoft propose des plates formes multi-média "qui nécéssitent un CPU à au moins 2 Ghz" et coute 2000 euros alors qu'on sait fait des cartes embedded qui coutent moins de 300 euros, avec des CPU < 500 Mhz (voire < 300 Mhz) qui font la même chose... Par contre, les compilations (et le code) doivent être légèrement optimisés... Mais ça n'a, bien sur, aucun intérêt...
1) Microsoft propose un des meilleurs compilateur C/C++ du marché, entre autre en terme de performance du code compilé. 2) Une carte mère avec un CPU à 2 GHz, ça ne vaut pas 100 Euros. 3) 300 Euros pour une carte embarqué avec un CPU à 300 Mhz, c'est du vol. 4) Les compilateurs optimisant pour les cartes embarquées... ça n'existe pas. 5) Tu trolles mal.
-- Richard
Nicolas George
Richard Delorme , dans le message <4291eb2d$0$4710$, a écrit :
1) Microsoft propose un des meilleurs compilateur C/C++ du marché, entre autre en terme de performance du code compilé.
En revanche, il semblerait que ce soit une bouze pour ce qui est de l'implémentation des fonctionnalités avancées du c++.
(Source : différents membres d'un gros projet de bibal de géométrie algorithmique.)
Richard Delorme , dans le message
<4291eb2d$0$4710$7a628cd7@news.club-internet.fr>, a écrit :
1) Microsoft propose un des meilleurs compilateur C/C++ du marché, entre
autre en terme de performance du code compilé.
En revanche, il semblerait que ce soit une bouze pour ce qui est de
l'implémentation des fonctionnalités avancées du c++.
(Source : différents membres d'un gros projet de bibal de géométrie
algorithmique.)
Richard Delorme , dans le message <4291eb2d$0$4710$, a écrit :
1) Microsoft propose un des meilleurs compilateur C/C++ du marché, entre autre en terme de performance du code compilé.
En revanche, il semblerait que ce soit une bouze pour ce qui est de l'implémentation des fonctionnalités avancées du c++.
(Source : différents membres d'un gros projet de bibal de géométrie algorithmique.)
remy
"Richard Delorme" a écrit dans le message de news:4291eb2d$0$4710$
C'est grâce à des raisonements comme celà que Microsoft propose des plates formes multi-média "qui nécéssitent un CPU à au moins 2 Ghz" et coute 2000 euros alors qu'on sait fait des cartes embedded qui coutent moins de 300 euros, avec des CPU < 500 Mhz (voire < 300 Mhz) qui font la même chose... Par contre, les compilations (et le code) doivent être légèrement optimisés... Mais ça n'a, bien sur, aucun intérêt...
1) Microsoft propose un des meilleurs compilateur C/C++ du marché, entre autre en terme de performance du code compilé. 2) Une carte mère avec un CPU à 2 GHz, ça ne vaut pas 100 Euros. 3) 300 Euros pour une carte embarqué avec un CPU à 300 Mhz, c'est du vol. 4) Les compilateurs optimisant pour les cartes embarquées... ça n'existe pas.
j'en connais un qui fct pas trop mal je dirais meme bien http://blackfin.uclinux.org/ pour le prix je suis bien d'accord avec toi je me suis achete un kit backfin en promo pour 100 $ de memoire
mais l'on peut aller plus vite mais la attention a la tirelire http://www.enseirb.fr/~kadionik/embedded/linux_SoC/linux_SoC9.html
mon seul pb c'est que je ne sais pas a quoi cela peut bien servir
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
"Richard Delorme" <abulmo@nospam.fr> a écrit dans le message de
news:4291eb2d$0$4710$7a628cd7@news.club-internet.fr...
C'est grâce à des raisonements comme celà que Microsoft propose des
plates formes multi-média "qui nécéssitent un CPU à au moins 2 Ghz" et
coute 2000 euros alors qu'on sait fait des cartes embedded qui coutent
moins de 300 euros, avec des CPU < 500 Mhz (voire < 300 Mhz) qui font la
même chose... Par contre, les compilations (et le code) doivent être
légèrement optimisés...
Mais ça n'a, bien sur, aucun intérêt...
1) Microsoft propose un des meilleurs compilateur C/C++ du marché, entre
autre en terme de performance du code compilé.
2) Une carte mère avec un CPU à 2 GHz, ça ne vaut pas 100 Euros.
3) 300 Euros pour une carte embarqué avec un CPU à 300 Mhz, c'est du vol.
4) Les compilateurs optimisant pour les cartes embarquées... ça n'existe
pas.
j'en connais un qui fct pas trop mal je dirais meme bien
http://blackfin.uclinux.org/
pour le prix je suis bien d'accord avec toi
je me suis achete un kit backfin en promo pour 100 $ de memoire
mais l'on peut aller plus vite mais la attention a la tirelire
http://www.enseirb.fr/~kadionik/embedded/linux_SoC/linux_SoC9.html
mon seul pb c'est que je ne sais pas a quoi
cela peut bien servir
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
remy
"Richard Delorme" a écrit dans le message de news:4291eb2d$0$4710$
C'est grâce à des raisonements comme celà que Microsoft propose des plates formes multi-média "qui nécéssitent un CPU à au moins 2 Ghz" et coute 2000 euros alors qu'on sait fait des cartes embedded qui coutent moins de 300 euros, avec des CPU < 500 Mhz (voire < 300 Mhz) qui font la même chose... Par contre, les compilations (et le code) doivent être légèrement optimisés... Mais ça n'a, bien sur, aucun intérêt...
1) Microsoft propose un des meilleurs compilateur C/C++ du marché, entre autre en terme de performance du code compilé. 2) Une carte mère avec un CPU à 2 GHz, ça ne vaut pas 100 Euros. 3) 300 Euros pour une carte embarqué avec un CPU à 300 Mhz, c'est du vol. 4) Les compilateurs optimisant pour les cartes embarquées... ça n'existe pas.
j'en connais un qui fct pas trop mal je dirais meme bien http://blackfin.uclinux.org/ pour le prix je suis bien d'accord avec toi je me suis achete un kit backfin en promo pour 100 $ de memoire
mais l'on peut aller plus vite mais la attention a la tirelire http://www.enseirb.fr/~kadionik/embedded/linux_SoC/linux_SoC9.html
mon seul pb c'est que je ne sais pas a quoi cela peut bien servir
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
talon
Richard Delorme wrote:
Bof, entre gcc 2.95 et gcc 4.0 il y a 6 ans d'écart pour quelle différence de performances ?
Sur un exemple j'avais un facteur > 2 entre gcc-2.95 et le compilateur Intel, sur le même exemple je n'ai plus qu'un écart de 10 ou 20% entre gcc-3.4 et le compilateur Intel. Je trouve qu'il y a eu de gros progrés.
Finalement l'alpha et l'omega de son argument c'est que la vitesse des processurs double tous les deux ans, et bien il y a un bon moment que ceci n'est plus vrai.
Entre les CPU 64 bits/dual-core qui sortent en ce moment et les processeurs qui régnaient en 1999 (pentium III 500 Mhz), il y a un gouffre de performance autrement plus important qu'entre les compilateurs des deux époques.
J'espère que tu ne crois pas qu'un processeur dual core, ou même un biproc calcule 2 fois plus vite qu'un monoproc sur un problème donné. Il y a au contraire toute probabilité qu'il calcule *beaucoup* moins vite, à cause de tous les verrous qu'il faut si on multithreade le programme. On a essayé ici la vectorisation automatique du compilateur Intel sur de vrais biprocs, avec des résultats désastreux (sous Linux). Pour obtenir un gain, il faut, soit qu'on ait des processus trés indépendants, soit que le multithreading ait été énormément bien étudié. Tes Athlons 64 tournent royalement à 2 Ghz et les Pentium à 3Ghz et on ne voit pas ces chiffres augmenter fortement dans les années à venir, en tout cas certainement pas doubler tous les deux ans. Donc les progrés de la compilation, et par exemple, de la vectorisation automatique, et des OS (comment minimiser les pertes dues aux verrous) seront certainement les bienvenus.
--
Michel TALON
Richard Delorme <abulmo@nospam.fr> wrote:
Bof, entre gcc 2.95 et gcc 4.0 il y a 6 ans d'écart pour quelle
différence de performances ?
Sur un exemple j'avais un facteur > 2 entre gcc-2.95 et le compilateur Intel,
sur le même exemple je n'ai plus qu'un écart de 10 ou 20% entre gcc-3.4 et le
compilateur Intel. Je trouve qu'il y a eu de gros progrés.
Finalement l'alpha et l'omega
de son argument c'est que la vitesse des processurs double tous les deux
ans, et bien il y a un bon moment que ceci n'est plus vrai.
Entre les CPU 64 bits/dual-core qui sortent en ce moment et les
processeurs qui régnaient en 1999 (pentium III 500 Mhz), il y a un
gouffre de performance autrement plus important qu'entre les
compilateurs des deux époques.
J'espère que tu ne crois pas qu'un processeur dual core, ou même un biproc
calcule 2 fois plus vite qu'un monoproc sur un problème donné. Il y a au
contraire toute probabilité qu'il calcule *beaucoup* moins vite, à
cause de tous les verrous qu'il faut si on multithreade le programme.
On a essayé ici la vectorisation automatique du compilateur Intel sur de vrais
biprocs, avec des résultats désastreux (sous Linux). Pour obtenir un gain,
il faut, soit qu'on ait des processus trés indépendants, soit que le
multithreading ait été énormément bien étudié. Tes Athlons 64
tournent royalement à 2 Ghz et les Pentium à 3Ghz et on ne voit pas ces
chiffres augmenter fortement dans les années à venir, en tout cas certainement
pas doubler tous les deux ans. Donc les progrés de la compilation, et par
exemple, de la vectorisation automatique, et des OS (comment minimiser les
pertes dues aux verrous) seront certainement les bienvenus.
Bof, entre gcc 2.95 et gcc 4.0 il y a 6 ans d'écart pour quelle différence de performances ?
Sur un exemple j'avais un facteur > 2 entre gcc-2.95 et le compilateur Intel, sur le même exemple je n'ai plus qu'un écart de 10 ou 20% entre gcc-3.4 et le compilateur Intel. Je trouve qu'il y a eu de gros progrés.
Finalement l'alpha et l'omega de son argument c'est que la vitesse des processurs double tous les deux ans, et bien il y a un bon moment que ceci n'est plus vrai.
Entre les CPU 64 bits/dual-core qui sortent en ce moment et les processeurs qui régnaient en 1999 (pentium III 500 Mhz), il y a un gouffre de performance autrement plus important qu'entre les compilateurs des deux époques.
J'espère que tu ne crois pas qu'un processeur dual core, ou même un biproc calcule 2 fois plus vite qu'un monoproc sur un problème donné. Il y a au contraire toute probabilité qu'il calcule *beaucoup* moins vite, à cause de tous les verrous qu'il faut si on multithreade le programme. On a essayé ici la vectorisation automatique du compilateur Intel sur de vrais biprocs, avec des résultats désastreux (sous Linux). Pour obtenir un gain, il faut, soit qu'on ait des processus trés indépendants, soit que le multithreading ait été énormément bien étudié. Tes Athlons 64 tournent royalement à 2 Ghz et les Pentium à 3Ghz et on ne voit pas ces chiffres augmenter fortement dans les années à venir, en tout cas certainement pas doubler tous les deux ans. Donc les progrés de la compilation, et par exemple, de la vectorisation automatique, et des OS (comment minimiser les pertes dues aux verrous) seront certainement les bienvenus.
--
Michel TALON
Richard Delorme
Richard Delorme , dans le message
1) Microsoft propose un des meilleurs compilateur C/C++ du marché, entre autre en terme de performance du code compilé.
En revanche, il semblerait que ce soit une bouze pour ce qui est de l'implémentation des fonctionnalités avancées du c++.
Herb Sutter a été embauché par Microsoft courant 2002 pour corriger cela et la version actuelle (visual c++ 2005) respecterait plutôt bien la norme.
-- Richard
Richard Delorme , dans le message
1) Microsoft propose un des meilleurs compilateur C/C++ du marché, entre
autre en terme de performance du code compilé.
En revanche, il semblerait que ce soit une bouze pour ce qui est de
l'implémentation des fonctionnalités avancées du c++.
Herb Sutter a été embauché par Microsoft courant 2002 pour corriger cela
et la version actuelle (visual c++ 2005) respecterait plutôt bien la norme.
1) Microsoft propose un des meilleurs compilateur C/C++ du marché, entre autre en terme de performance du code compilé.
En revanche, il semblerait que ce soit une bouze pour ce qui est de l'implémentation des fonctionnalités avancées du c++.
Herb Sutter a été embauché par Microsoft courant 2002 pour corriger cela et la version actuelle (visual c++ 2005) respecterait plutôt bien la norme.
-- Richard
Khanh-Dang
Bof, entre gcc 2.95 et gcc 4.0 il y a 6 ans d'écart pour quelle différence de performances ?
Sur un exemple j'avais un facteur > 2 entre gcc-2.95 et le compilateur Intel, sur le même exemple je n'ai plus qu'un écart de 10 ou 20% entre gcc-3.4 et le compilateur Intel. Je trouve qu'il y a eu de gros progrés.
Oui, il y a pour ma part une grande différence de performances entre les deux versions de gcc. Par contre, je n'ai récemment testé que pour architecture sparc.
Bof, entre gcc 2.95 et gcc 4.0 il y a 6 ans d'écart pour quelle
différence de performances ?
Sur un exemple j'avais un facteur > 2 entre gcc-2.95 et le compilateur Intel,
sur le même exemple je n'ai plus qu'un écart de 10 ou 20% entre gcc-3.4 et le
compilateur Intel. Je trouve qu'il y a eu de gros progrés.
Oui, il y a pour ma part une grande différence de performances entre les
deux versions de gcc. Par contre, je n'ai récemment testé que pour
architecture sparc.
Bof, entre gcc 2.95 et gcc 4.0 il y a 6 ans d'écart pour quelle différence de performances ?
Sur un exemple j'avais un facteur > 2 entre gcc-2.95 et le compilateur Intel, sur le même exemple je n'ai plus qu'un écart de 10 ou 20% entre gcc-3.4 et le compilateur Intel. Je trouve qu'il y a eu de gros progrés.
Oui, il y a pour ma part une grande différence de performances entre les deux versions de gcc. Par contre, je n'ai récemment testé que pour architecture sparc.
Richard Delorme
Richard Delorme wrote:
Bof, entre gcc 2.95 et gcc 4.0 il y a 6 ans d'écart pour quelle différence de performances ?
Sur un exemple j'avais un facteur > 2 entre gcc-2.95 et le compilateur Intel, sur le même exemple je n'ai plus qu'un écart de 10 ou 20% entre gcc-3.4 et le compilateur Intel. Je trouve qu'il y a eu de gros progrés.
Moi sur d'autres exemples, j'ai moins de 10% d'écart entre tous ces compilateurs. J'espère aussi que ta différence ne s'explique pas un meilleur support du processeur (du genre utilisation de sse2) de la part du compilateur d'Intel, sinon ça ne prouverais rien sur le compilateur mais tout sur le processeur.
Finalement l'alpha et l'omega de son argument c'est que la vitesse des processurs double tous les deux ans, et bien il y a un bon moment que ceci n'est plus vrai.
Entre les CPU 64 bits/dual-core qui sortent en ce moment et les processeurs qui régnaient en 1999 (pentium III 500 Mhz), il y a un gouffre de performance autrement plus important qu'entre les compilateurs des deux époques.
J'espère que tu ne crois pas qu'un processeur dual core, ou même un biproc calcule 2 fois plus vite qu'un monoproc sur un problème donné.
Si. Sur un exemple donné il va même 120% plus vite, le test CPU righmark représenté ici : http://www.pcinpact.com/articles/a/127/0.htm?pge
Il y a au contraire toute probabilité qu'il calcule *beaucoup* moins vite, à cause de tous les verrous qu'il faut si on multithreade le programme. On a essayé ici la vectorisation automatique du compilateur Intel sur de vrais biprocs, avec des résultats désastreux (sous Linux). Pour obtenir un gain, il faut, soit qu'on ait des processus trés indépendants, soit que le multithreading ait été énormément bien étudié.
Tout est dans le "bien étudié" et c'est sur ce point qu'insiste la présentation que j'avais citée précédemment. Les compilateurs apportent bien peu par rapport à ce que peut faire le programmeur en choisissant les bons algorithmes.
Tes Athlons 64 tournent royalement à 2 Ghz et les Pentium à 3Ghz et on ne voit pas ces chiffres augmenter fortement dans les années à venir, en tout cas certainement pas doubler tous les deux ans.
Ce n'est pas la fréquence qui double, mais le nombre de transistors...
-- Richard
Richard Delorme <abulmo@nospam.fr> wrote:
Bof, entre gcc 2.95 et gcc 4.0 il y a 6 ans d'écart pour quelle
différence de performances ?
Sur un exemple j'avais un facteur > 2 entre gcc-2.95 et le compilateur Intel,
sur le même exemple je n'ai plus qu'un écart de 10 ou 20% entre gcc-3.4 et le
compilateur Intel. Je trouve qu'il y a eu de gros progrés.
Moi sur d'autres exemples, j'ai moins de 10% d'écart entre tous ces
compilateurs. J'espère aussi que ta différence ne s'explique pas un
meilleur support du processeur (du genre utilisation de sse2) de la part
du compilateur d'Intel, sinon ça ne prouverais rien sur le compilateur
mais tout sur le processeur.
Finalement l'alpha et l'omega
de son argument c'est que la vitesse des processurs double tous les deux
ans, et bien il y a un bon moment que ceci n'est plus vrai.
Entre les CPU 64 bits/dual-core qui sortent en ce moment et les
processeurs qui régnaient en 1999 (pentium III 500 Mhz), il y a un
gouffre de performance autrement plus important qu'entre les
compilateurs des deux époques.
J'espère que tu ne crois pas qu'un processeur dual core, ou même un biproc
calcule 2 fois plus vite qu'un monoproc sur un problème donné.
Si. Sur un exemple donné il va même 120% plus vite, le test CPU righmark
représenté ici :
http://www.pcinpact.com/articles/a/127/0.htm?pge
Il y a au
contraire toute probabilité qu'il calcule *beaucoup* moins vite, à
cause de tous les verrous qu'il faut si on multithreade le programme.
On a essayé ici la vectorisation automatique du compilateur Intel sur de vrais
biprocs, avec des résultats désastreux (sous Linux). Pour obtenir un gain,
il faut, soit qu'on ait des processus trés indépendants, soit que le
multithreading ait été énormément bien étudié.
Tout est dans le "bien étudié" et c'est sur ce point qu'insiste la
présentation que j'avais citée précédemment. Les compilateurs apportent
bien peu par rapport à ce que peut faire le programmeur en choisissant
les bons algorithmes.
Tes Athlons 64
tournent royalement à 2 Ghz et les Pentium à 3Ghz et on ne voit pas ces
chiffres augmenter fortement dans les années à venir, en tout cas certainement
pas doubler tous les deux ans.
Ce n'est pas la fréquence qui double, mais le nombre de transistors...
Bof, entre gcc 2.95 et gcc 4.0 il y a 6 ans d'écart pour quelle différence de performances ?
Sur un exemple j'avais un facteur > 2 entre gcc-2.95 et le compilateur Intel, sur le même exemple je n'ai plus qu'un écart de 10 ou 20% entre gcc-3.4 et le compilateur Intel. Je trouve qu'il y a eu de gros progrés.
Moi sur d'autres exemples, j'ai moins de 10% d'écart entre tous ces compilateurs. J'espère aussi que ta différence ne s'explique pas un meilleur support du processeur (du genre utilisation de sse2) de la part du compilateur d'Intel, sinon ça ne prouverais rien sur le compilateur mais tout sur le processeur.
Finalement l'alpha et l'omega de son argument c'est que la vitesse des processurs double tous les deux ans, et bien il y a un bon moment que ceci n'est plus vrai.
Entre les CPU 64 bits/dual-core qui sortent en ce moment et les processeurs qui régnaient en 1999 (pentium III 500 Mhz), il y a un gouffre de performance autrement plus important qu'entre les compilateurs des deux époques.
J'espère que tu ne crois pas qu'un processeur dual core, ou même un biproc calcule 2 fois plus vite qu'un monoproc sur un problème donné.
Si. Sur un exemple donné il va même 120% plus vite, le test CPU righmark représenté ici : http://www.pcinpact.com/articles/a/127/0.htm?pge
Il y a au contraire toute probabilité qu'il calcule *beaucoup* moins vite, à cause de tous les verrous qu'il faut si on multithreade le programme. On a essayé ici la vectorisation automatique du compilateur Intel sur de vrais biprocs, avec des résultats désastreux (sous Linux). Pour obtenir un gain, il faut, soit qu'on ait des processus trés indépendants, soit que le multithreading ait été énormément bien étudié.
Tout est dans le "bien étudié" et c'est sur ce point qu'insiste la présentation que j'avais citée précédemment. Les compilateurs apportent bien peu par rapport à ce que peut faire le programmeur en choisissant les bons algorithmes.
Tes Athlons 64 tournent royalement à 2 Ghz et les Pentium à 3Ghz et on ne voit pas ces chiffres augmenter fortement dans les années à venir, en tout cas certainement pas doubler tous les deux ans.
Ce n'est pas la fréquence qui double, mais le nombre de transistors...
-- Richard
Emmanuel Florac
Le Mon, 23 May 2005 16:15:26 +0000, Michel Talon a écrit :
Sur un exemple j'avais un facteur > 2 entre gcc-2.95 et le compilateur Intel, sur le même exemple je n'ai plus qu'un écart de 10 ou 20% entre gcc-3.4 et le compilateur Intel. Je trouve qu'il y a eu de gros progrés.
Et encore une fois, merci de tenir compte aussi du fait que GCC a fait certainement plus de progrès sur certaines plate-formes. MIcrosoft C, combien de plate-formes supportées?
-- on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement. Loi de Myers.
Le Mon, 23 May 2005 16:15:26 +0000, Michel Talon a écrit :
Sur un exemple j'avais un facteur > 2 entre gcc-2.95 et le compilateur
Intel, sur le même exemple je n'ai plus qu'un écart de 10 ou 20% entre
gcc-3.4 et le compilateur Intel. Je trouve qu'il y a eu de gros progrés.
Et encore une fois, merci de tenir compte aussi du fait que GCC a fait
certainement plus de progrès sur certaines plate-formes. MIcrosoft C,
combien de plate-formes supportées?
--
on passe la moitié de son temps à refaire ce que l'on n'a pas eu le
temps de faire correctement.
Loi de Myers.
Le Mon, 23 May 2005 16:15:26 +0000, Michel Talon a écrit :
Sur un exemple j'avais un facteur > 2 entre gcc-2.95 et le compilateur Intel, sur le même exemple je n'ai plus qu'un écart de 10 ou 20% entre gcc-3.4 et le compilateur Intel. Je trouve qu'il y a eu de gros progrés.
Et encore une fois, merci de tenir compte aussi du fait que GCC a fait certainement plus de progrès sur certaines plate-formes. MIcrosoft C, combien de plate-formes supportées?
-- on passe la moitié de son temps à refaire ce que l'on n'a pas eu le temps de faire correctement. Loi de Myers.
