Troy McClure a écrit 2213 commentaires

comme dit plus haut faut taper dans le c++.

Et je recommande chaleureusement l'usage de l'option -finline-limit=3000 (par défaut c'est 600) -> sur mes sources, avec g++ 3.2, ça fait passer le temps de compil (par fichier) de quelques minutes à plus de trois heures :°)

Je te laisse l'ornithorynque mais je VEUX la garde de la limule, au moins pendant les vacances.

I love you, Sam :)

C'est d'autant plus dommage que la tribune venait de trouver son Grand Timonnier, le modérateur ultime, pétri de glaise et de bon sens, à savoir Samouille et son pistolet à trolls.

un ptit [:totoz] pour la route

pas tout, juste les programmes qui dépendent d'une lib c++ autre que libstdc++

;;; ça c'est pour rendre moins laide la modeline (set-face-font 'modeline "-*-courier-bold-r-*-*-11-*-*-*-*-*-iso8859-*") (set-face-font 'modeline-buffer-id "-*-courier-bold-r-*-*-11-*-*-*-*-*-iso8859-*") (set-face-font 'modeline-mousable "-*-courier-medium-r-*-*-11-*-*-*-*-*-iso8859-*") (set-face-font 'modeline-mousable-minor-mode "-*-courier-medium-r-*-*-11-*-*-*-*-*-iso8859-*") (set-face-background 'modeline "#537182") (set-face-foreground 'modeline "#ff8000") (set-face-background 'modeline-buffer-id "#537182") (set-face-background 'modeline-mousable "#537182") (set-face-background 'modeline-mousable-minor-mode "#537182") ;; roxor! la vilaine barre verticale devient jolie! (set-specifier modeline-shadow-thickness 1) (set-specifier vertical-divider-shadow-thickness 0) (set-specifier vertical-divider-line-width 2) (set-face-background 'vertical-divider "#ff8000"); et dans le .Xdefaults, quelques couleurs correspondantes, et virage du relief tout pourri des widgets de xemacs: Emacs*XlwMenu*shadowThickness: 1 Emacs*XlwScrollBar*shadowThickness: 1 Emacs*XlwScrollBar*Width: 9 Emacs*XlwScrollBar*Height: 9 Emacs*dialog*Command*beNiceToColormap: false Emacs*menubar*Background: #537182 Emacs*dialog*Background: #537182 Emacs*XlwScrollBar.Background: #537182 Emacs*XmScrollBar.Background: #537182 Emacs*XlwScrollBar*knobStyle: dimple Emacs*cursorColor: #ff8000 Emacs*toolBarShadowThickness: 1 Emacs*backgroundToolBarColor: #537182 et le résultat: http://hules.free.fr/xemacs.png (yaaaaaisse la jacky-touch avec la barre orange :°)

deurns

SmartEiffel sort sa 1.0

et il la montre à tout le monde ?

les sources (png et xcf) des curseurs: http://cvsweb.xfree86.org/cvsweb/xc/programs/xcursorgen/redglass/(...)

euh non c'est pas drôle.

et alors ?

Qu'est-ce qui te choque là dedans ?

chais pas pourquoi j'ai cette chanson dans la tête : http://www.paroles.net/texte/10329(...) ;-)

oui je confirme l'authenticité ;) c'est un des mails échangés sur la liste linuxfr-www-dev (malheureusement il n'y a pas d'archives publiques)

TOTOZZZ

ça commence a me foutre en rogne ..

y'avait pas eu un sondage sur pour ou contre conserver la tribune (entre autres) ? c'était quoi le résultat au final ?

Pour convertir les accents en entités avec emacs, tu peux utiliser le package x-symbol http://x-symbol.sourceforge.net/(...) ça marche aussi bien pour du html que du latex, et les 'é' 'à' etc sont affichés tels quels mais sauvés sous forme d'entités. C'est vraiment un mode qui roxor.
(Je ne l'ai testé que sous xemacs mais ça doit rester valable avec emacs)

beuh !? je croyais qu'ils avaient dit que cette fois c'était sur et certain, gcc-3.2 devait enfin avoir une ABI c++ stable et conforme qui bouge plus ... ils ont changé d'avis ? y'a autre chose ? t'as une url ?

pareil j'ai la flemme d'autant qu'en divisant tous tes chiffres par 1,000,000 (pile poil la valeur de CLOCKS_PER_SEC) on retombe sur des resultats tout à fait vraisemblables (quoique pas très glorieux pour bcc, mais il n'a pas non plus la réputation de produire un code ultra-rapide)

Bientôt en vente sur .kid: http://talkingpresidents.com/ ... quoique .. c'est pas vraiment plus con que les GI Joe

effectivement c'est un peu gros avec bcc ;-) J'opterai pour un problème avec la mesure du temps (un melangeage entre CLOCKS_PER_SEC , CLK_TCK et sysconf(_SC_CLK_TCK) , je dis ça parce que je me suis déjà embrouillé dans ces trucs)

un mail pas trop vieux à ce sujet: http://gcc.gnu.org/ml/gcc/2002-03/msg01661.html(...)

J'avais essayé odinmp il y a un bout de temps et ce n'était pas concluant du tout (force tendance au crash). Je ne pense pas qu'il y ait d'histoire de royalties, les specifications sont librement disponibles http://www.openmp.org/specs/index.cgi(...) . La principale raison pour l'absence d'openmp doit être que finalement il y a très peu de demande là dessus (ce que je comprends)

> un PPC a frequence egale avec un x86, va etre beaucoup plus puissant .... !

Tiens, j'aimerais bien qu'un possesseur de PPC aillent faire le bench de la news au-dessus ( http://linuxfr.org/comments/155866.html(...) ) . Bien sûr c'est très biaisé mais ça m'interesserait bien de voir le genre de chiffres qu'on obtient.. Car il semble quand même que les x86 aient pris une longueur d'avance en terme de puissance brute en virgule flottante (exploitable, cad celle qu'on peut obtenir avec gcc, je parle pas de la puissance indiquée par le constructeur ni de celle obtenue avec des filtres ultra-optimisés pour photoshop ;)

euh ben moi aussi j'ai un peu de mal à interpreter sur la fin :) visiblement sur les plus hautes fréquences les perfs s'équilibrent entre l'athlon et le p4, j'imagine qu'il doit y avoir un goulet d'etranglement genre le débit du cache de niveau 2.

Il faudrait voir aussi si icc peut apporter un gain significatif sur des pentiums 4.. c'est ptet le cas, c'est ptet du flan.

De toute manière c'est un bench qui reste très spécialisé (donc biaisé si on cherche à l'interpreter comme une mesure globale des perfs des processeurs) , la plupart des pc ne passent pas leur temps à factoriser des matrices, et il est certain qu'on peut trouver des implementation plus efficaces. Mais ça reste interessant de voir les performances qu'on peut obtenir sur un code simple en fonction du couple (gcc + processeur) . Il serait sans doute interessant de confronter ça à un bench similaire mais utilisant des procedures ultra-optimisées pour chaque processeur (intel founit ses propres versions des BLAS/lapack, qui font entre autre les factorisations LU, malheureusement elles sont payantes)

merci, ça c'est plutot interessant, même si ta version de gcc est un peu vieille.. t'as bien compilé avec -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math ?
parce que si c'est le cas, ça veut quand même dire que pour du calcul brut, le couple gcc+athlon est très nettement plus performant que gcc+p4, à fréquences égale (je m'étais gourré plus haut, c'est pas un athlon xp 1400 mais un 1600, qui tourne à 1400MHz)

ah oui, et si quelqu'un avec un pentioume-4 pouvait lancer le bench (les sources C sont là http://math.nist.gov/scimark2/scimark2c.zip(...) ), ça m'interesserait de connaitre les resultats, que ce soit avec gcc ou icc (ou même bcc, le compilateur de borland est dispo sous linux, non?)

Les bench ça vaut ce que ça vaut mais bon, les perf affichées pour le scimark me paraissent vraiment mauvaises pour un pIII-600 qui est censé savoir faire 42 choses à la fois tout en accelerant l'internette: 100MFlops pour une factorisation LU (juste une série d'additions multiplications bien bourrine) c'est vraiment pas terrible. D'autant qu'il ne fait pas trop intervenir le cache puisque la matrice en question est 100x100 soit 80ko d'occupation mémoire ça loge à peu près dans n'importe quel cache L2.

[Dans la suite je fais un blocage sur les perf du bench LU, qui est représentatif de la puissance du processeur et de la capacité du compilo à bien optimiser des petites boucles assez simples de calcul en virgule flottante -- je n'ai pas regardé les autres résultats]

Du coup j'ai essaye sur mon celeron-450 (un bon vieux celeron avec juste le mmx)
Composite Score: 70.06
FFT Mflops: 65.28 (N=1024)
SOR Mflops: 108.50 (100 x 100)
MonteCarlo: Mflops: 17.16
Sparse matmult Mflops: 52.35 (N=1000, nz=5000)
LU Mflops: 107.00 (M=100, N=100)
(gcc-3.2.1 -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math)

(on notera que j'ai viré l'option -mcpu)

ah ben c'est con, les perfs sont les mêmes que sur le pIII du gars! peut-être que le test ne tire pas partie du SSE puisque si je ne m'abuse celui-ci travaille en simple précision et le bench est en double-prec. Passons.

Pour continue à voir, je vais sur un celeron-600 (qui doit avoir le SSE, enfin j'en sais trop rien)

rebelote:
Composite Score: 82.21
FFT Mflops: 94.39 (N=1024)
SOR Mflops: 101.21 (100 x 100)
MonteCarlo: Mflops: 35.32
Sparse matmult Mflops: 44.16 (N=1000, nz=5000)
LU Mflops: 135.99 (M=100, N=100)
(gcc-3.2.1 -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -march=pentium2)

Flute alors, son bi-pIII est vraiment pas fougueux, un céléron-600 est 33% plus véloce... on va mettre ça sur le compte du SMP :-/

Sur la machine en question, il y a aussi icc-6.0 alors autant faire la comparaison:
Composite Score: 122.48
FFT Mflops: 88.27 (N=1024)
SOR Mflops: 157.43 (100 x 100)
MonteCarlo: Mflops: 89.48
Sparse matmult Mflops: 72.82 (N=1000, nz=5000)
LU Mflops: 204.39 (M=100, N=100)
(icc -O3 -ipo -axK)

Mazette ! sur ce coup, icc est 60% plus performant que gcc ! Bon, on va dire que c'est parce que c'est du intel, allons voir sur un athlon.

La machine en question est un athlon-XP 1400, une machine bas de gamme d'assembleur.
Composite Score: 345.81
FFT Mflops: 320.63 (N=1024)
SOR Mflops: 324.40 (100 x 100)
MonteCarlo: Mflops: 112.32
Sparse matmult Mflops: 327.68 (N=1000, nz=5000)
LU Mflops: 644.03 (M=100, N=100)
(gcc-3.2.1 -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -march=pentium2)


Composite Score: 436.18
FFT Mflops: 339.35 (N=1024)
SOR Mflops: 448.13 (100 x 100)
MonteCarlo: Mflops: 267.10
Sparse matmult Mflops: 409.60 (N=1000, nz=5000)
LU Mflops: 716.71 (M=100, N=100)
(icc -O3 -ipo -axK)

Alors là je suis plus qu'impressionné! Les perf sont vraiment bluffantes à croire qu'il y a un bug dans le bench. La bonne nouvelle c'est que gcc n'est pas tellement à la rue. Par contre j'ai pas de p4 sous la main pour faire la comparaison..


A titre d'info j'ai aussi lancé le bench sur une Bi-Alpha (21264A à 667MHz). A côté de l'athlon elle fait plutot pâle figure (là aussi je suis plus que surpris)

Composite Score: 194.86
FFT Mflops: 214.46 (N=1024)
SOR Mflops: 236.93 (100 x 100)
MonteCarlo: Mflops: 48.22
Sparse matmult Mflops: 175.55 (N=1000, nz=5000)
LU Mflops: 312.68 (M=100, N=100)
(cc -O3 -arch ev67 -fast)
A sa décharge, il faut dire que la machine est assez chargée (load = 2.7) et que le test n'évalue que la puissance brute du processeur, il ne tire pas partie du cache assez gros de cette machine.

Par contre on peut comparer le compilateur compaq avec gcc (3.2):


Composite Score: 155.17
FFT Mflops: 199.73 (N=1024)
SOR Mflops: 167.08 (100 x 100)
MonteCarlo: Mflops: 50.65
Sparse matmult Mflops: 220.92 (N=1000, nz=5000)
LU Mflops: 137.46 (M=100, N=100)
(gcc -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -mcpu=ev67 -mtune=ev67)

... mouaif vraiment pas convainquant, sur le LU le compilo compaq a été plus de 2 fois plus performant que gcc.. je n'ai peut-être pas utilisé les bonnes options pour gcc :-/ (en particulier pour les histoires d'aliasing mais j'ai la flemme de chercher)


Allez, un dernier coup sur une Origin 2000 pas très fraiche (à base r12k à 400MHz):

Composite Score: 148.34
FFT Mflops: 129.78 (N=1024)
SOR Mflops: 242.08 (100 x 100)
MonteCarlo: Mflops: 64.22
Sparse matmult Mflops: 108.86 (N=1000, nz=5000)
LU Mflops: 196.73 (M=100, N=100)
(cc -Ofast -OPT:alias=restrict:roundoff=3)


et avec gcc (3.0.4):
Composite Score: 114.10
FFT Mflops: 124.23 (N=1024)
SOR Mflops: 155.90 (100 x 100)
MonteCarlo: Mflops: 20.97
Sparse matmult Mflops: 102.08 (N=1000, nz=5000)
LU Mflops: 167.32 (M=100, N=100)
(gcc-3 -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -mips3)

bon, gcc n'est pas trop ridicule sur ce coup il s'en sort bien :)


au final c'est bien dur de tirer des conclusions .. mis à part que je ne comprends comment l'auteur du bench a obtenu des performances bien plus mauvaise que celles que j'ai sur un celeron-600.