Donc t'a pas besoin des flottants 64 bits pour ton job et les cartes NVidia un peu anciennes te suffisent ?

Sinon le KERS ça va ? Y'aura pas de mécano électrocuté en Australie ?

[ Répondre ]

Oui mais ces téraflops issus de cartes graphiques ne portent que sur des nombres 32 bits. La très grande majorité des applications scientifiques exigent des calculs sur 64 bits et dans ce cas les cartes graphiques actuelles sont beaucoup moins performantes.

[ Répondre ]

>>> je pense qu'il y a sûrement un GNU de trop

Oui à la réflexion je crois que tu a raison. Je retiens la remarque pour le prochain classement ;-)

[ Répondre ]

Pour les organisations gouvernementales (type NSA) je partage ton point de vue et il est évident qu'elles possèdent des très grosses machines qui ne sont pas soumises au top 500.
En revanche sur ta phrase "Une partie des industriels qui produisent autrechose que des benchmarks préfèrent garder secret l'existence de ces machines" quel serait l'intérêt de ces industriels de cacher ainsi leurs produits ?
A mon avis le Top 500 leur fait une bonne pub donc cela me semblerait bizarre qu'un fabricant cache délibérément les performances de ses produits non ?

[ Répondre ]

C'est malin ! Je viens de perdre 2 heures de ma très précieuse vie à m'esclaffer en lisant tous les strips.
Vraiment excellentissime !

[ Répondre ]

Oui mais LLVM compile plus vite et les scores de performances qu'il obtient ne sont pas loin de GCC (sauf sur le test 176.gcc ou il se crashe ce qui oblige à compiler en -O0).
Moi je dis pas mal du tout.

[ Répondre ]

En plus, vu le bench de Makarov dont je donne l'url plus haut, les perfs de LLVM semblent vraiment bonnes.

[ Répondre ]

Ici une comparaison qui a l'air assez sérieuse : http://vmakarov.fedorapeople.org/spec/llvmgcc.html

[ Répondre ]

>>> Sinon, PCC est 13% moins performant que GCC 3.3.5 au benchmark bytebench, ce n'est pas 10% certes, mais ce n'est pas ridicule, surtout à ce stade de son développement

C'est vrai que cela n'est pas ridicule sur ce benchmark.
N'oublions pas toutefois que GCC 3.3.5 est loin, très loin, d'être une version récente. Depuis ce vénérable ancêtre de 2004 il y a quand même eu un paquet de versions de GCC :

GCC 3.3.6
GCC 3.4.0
GCC 3.4.1
GCC 3.4.2
GCC 3.4.3
GCC 3.4.4
GCC 3.4.5
GCC 3.4.6
GCC 4.0.0
GCC 4.0.1
GCC 4.0.2
GCC 4.0.3
GCC 4.0.4
GCC 4.1.0
GCC 4.1.1
GCC 4.1.2
GCC 4.2.0
GCC 4.2.1
GCC 4.2.2
GCC 4.2.3
GCC 4.3.0
GCC 4.3.1
GCC 4.3.2

Et la toute nouvelle version 4.4 est sur le point de sortir. Comparer les perfs de PCC avec GCC 3.3.5 est donc biaisé (mais on est d'accord que c'est la version présente dans l'arbre des ports d'OpenBSD donc c'est ça qui compte pour eux).

[ Répondre ]

Ici la critique est généralisée. Mandriva se fait démonter, Ubuntu se fait ratiboiser et ne parlons même pas de Novell/Suse. Tout le monde participe joyeusement à ces discussions critiques sauf les BSDistes qui semblent avoir un attachement religieux à leur OS et qui ne supportent pas la moindre remise en question de leur système.
Faudrait cesser de jouer les calimero et avoir le cuir un peu plus épais !

[ Répondre ]

>>> Pour fournir des binaires de qualité, OpenBSD décide de compiler les sources directement sur une machine de l'architecture cible (pas de cross-compilation).

Effectivement c'est un bon argument et on comprends la nécessité d'un compilateur rapide. Personnellement ça m'énerverai de constater que mon binaire x86 est tout lent parce qu'il a été généré par un compilo rapide de façon à être compatible VAX....mais bon c'est un choix. Tu penses qu'il y a beaucoup de versions d'OpenBSD qui tournent actuellement sur du VAX dans le monde ?

>>> Tu as déjà comparé gcc à sun studio sur sparc ? Tu as déjà comparé gcc à mipspro sur mips ?

Excuse-moi de ne prendre en compte que les logiciels libres. Je sais c'est bizarre mais c'est comme ça.

[ Répondre ]

Un objectif qui n'est pas atteint aujourd'hui. Donc, pour l'utilisateur d'aujourd'hui ayant besoin du C99, PCC n'est pas une alternative.

[ Répondre ]

Pour les 3 premières raisons GCC convient parfaitement (cross-compilation pour les machines peu puissantes, compile tout le système et capable de bootstrap, gère toutes les archis cibles d'OpenBSD).
En revanche les 2 dernières raisons sont parfaitement légitimes et je comprends pourquoi les devs d'OpenBSD cherchent une alternative à GCC

[ Répondre ]

>>> Un compilo C/C++ qui se focaliserait sur la rapidité de compilation ça serait génial.

Pourquoi ne pas opter pour la solution évidente : quand on écrit le programme et qu'on fait pleins de cycles compilation/modifs/compilation alors n'optimise pas du tout le code pour que la compilation soit rapide (-O0) et à la fin de l'écriture du programme on n'a plus qu'a optimiser à fond (-O3).

[ Répondre ]

T'avais lu le PS du post je présume ?

[ Répondre ]

>>> si tu avais regardé avant de dégainer, tu aurais vu que j'ai fait quelques dépeches/journaux autour d'OpenBSD

J'ai regardé avant d'écrire mon post et c'est parce que j'ai vu que tu avais fait la news d'OpenBSD 3.8 que je me suis dit que tu pouvais continuer au lieu de critiquer.

>>> je laisse ce boulot à d'autres qui ont beaucoup plus de patience et de tact que moi :)

J'ai fais les news OpenBSD 3.9 et OpenBSD 4.0...est-ce à dire que j'ai beaucoup plus de patience et de tact ? Ou bien est-ce parce que ton accusation de baveur anti -BSD à mon encontre est finalement mal fondée ?

[ Répondre ]

Non tu n'a pas compris (ou je me suis mal exprimé). Si on avait eu un GCC modulaire alors Apple aurait gardé pour elle (sous licence propriétaire) son analyseur de source Objective-C et l'aurait "branché" sur la partie génératrice de binaire de GCC.
C'est ça que veut éviter Stallman : le fait pour une entreprise de garder des plugins proprios qu'on peut brancher sur GCC.
Stallman préfère, et on le comprends, que le code contribué soit sous licence libre et pour cela il oblige à contribuer directement à GCC.

[ Répondre ]

>>> Stallman justifie des abérations techniques en invoquant des raisons politiques

Y'a quand même un bel avantage technique qui est sorti de la position de Stallman : Apple a contribué au support d'Objective-C dans GCC alors que si il était possible d'avoir un GCC très modulaire il est fort probable (euphémisme pour "plus que certain") que le support d'Objective-C serait resté purement dans le giron d'Apple.

[ Répondre ]

>>> Je sens une certain dénigrement de PCC

Mais en quoi le fait de dire que PCC ne pourra pas remplacer GCC tant qu'il ne supportera pas d'autres langages que le C est un dénigrement ? Pour moi c'est juste le rappel d'un fait.
Si l'utilisateur peut se contenter du C (antérieur à C99) alors PCC est effectivement une alternative, sinon non.

En quoi le fait de dire que l'argument selon lequel GCC ne serait pas maintenu est faux est un dénigrement de PCC ? Pour moi c'est juste le rappel d'un fait. Cet argument du manque de développement upstream ne doit pas être utilisé car il est faux.

En quoi le fait de dire que l'écart de 10% de performances n'est pas soutenu par des benchmarks est un dénigrement ? Pour moi c'est juste le rappel d'un fait. Tant que nous n'aurons pas des benchs comparatifs il est normal et sain d'être quelque peu sceptique au sujet des performances car, de l'aveu même de son mainteneur, PCC n'est pas optimisé.

Dire que je bave systématiquement sur les BSD est absurde. J'ai écrit pas mal de news sur les OS BSD, sur PC-BSD et j'ai même écrit la news sur LLVM 2.2 qui est un compilateur sous licence BSD : http://linuxfr.org//2008/02/18/23723.html

[ Répondre ]