Benoit Jacob a écrit 217 commentaires

Ah oui, celui-la on le connaissait avec le driver libre radeon sur cartes ATI:
https://bugzilla.mozilla.org/show_bug.cgi?id=589546

Je ne savais pas qu'il existait aussi avec le driver fglrx.

Ben regarde, justement, dans ce repertoire, toutes les videos sont aussi disponibles en webm:

http://videos.mozilla.org/serv/firefox4beta/

Pour voir une video WebM, il faut une beta de firefox 4 ou une version de developpement de chromium, donc c'est un peu tot.... ceci dit, youtube est deja en train de passer a webm, clique sur leur bouton 'html5 beta'.

Interessant; ici (linux x86-64 nvidia 195.36.31) le panorama marche bien, meme avec cette variable d'environnement. Si tu te decides a faire un rapport de bug, je suggererais le composant Core:Graphics, vu que ce n'est probablement pas la faute de Panorama. C'est soit un bug dans Core:Graphics, soit un bug du driver nvidia.

(rien a voir avec mon post ci-dessus sur OpenGL)

Si ca vous interesse de tester le canvas WebGL, tapez about:config dans la barre d'addresse et changez l'option webgl.enabled_for_all_sites en true. On espere l'activer par defaut dans la prochaine beta.

Apres ca, si vous avez des pilotes OpenGL 2.1+ ou OpenGL ES 2.0 decents, vous devriez pouvoir faire joujou avec toutes les demos WebGL, par exemple cette carte Quake 3: http://media.tojicode.com/q3bsp/

Si vous n'avez pas de matos OpenGL, on ne vous a pas oublies: le web devrait continuer de fonctionner aussi bien que possible sans GPU! Donc on supporte le rendu purement logiciel par OSMesa. Installez le paquet OSMesa de votre distribution, et definissez l'option webgl.osmesalib avec le nom de fichier de la bibliotheque .so, par exemple libOSMesa.so.6

Si ca vous interesse de tester l'acceleration par OpenGL (utilise votre carte graphique pour l'affichage final des differentes couches (layers) la page web) definissez la variable d'environnement suivante:


export MOZ_ACCELERATED=1


Voila, pour l'instant ca marche tres bien avec certains drivers (ici le driver proprio nvidia), ca crashe avec d'autres (par exemple le driver libre radeon). Tous vos retours d'experiences sont les bienvenus!

Je plussoie (et là je ne prêche pas pour ma paroisse, je suis chercheur). Dans mon expérience, une bonne partie des développements de logiciels libres dans une université peuvent venir de non-chercheurs non-étudiants. Exemples:
- les informaticiens / sysadmins
- les ingénieurs (dans les sciences expérimentales où il y en a pour gérer les équipements)

Et Pierre Tramo, il ne peut pas venir?

Oui c'est bon, mais faut pas passer à côté du point important qui est, je le répète, que ce benchmark n'est pas réaliste!

Ben maintenant, l'écart de performance est déjà resserré; si tu as obtenu ce résultat avec -fno-exceptions, alors ma dernière idée est que je me souviens que delete accepte le pointeur nul contrairement à free(), donc si ça se trouve il y a un if(...) dans l'implémentation de delete.

Bon bref il faut vraiment concocter un benchmark pas réaliste comme celui-là pour voir apparaître une différence! Pas réaliste, parce que de toute façon, même avec un GC, créer et détruire des millions de petits objets ça n'est pas efficace donc lorsque la vitesse est importante, on évite (par exemple en allouant un millier d'objets d'un coup).

J'avais pas regardé de près le contenu de ton benchmark.

Maintenant tout s'explique: c'est le bench dont tu parlais plus haut, qui crée et détruit un million de petits objets.

Comme je te l'ai déjà dit, oui, bien sûr que sur un benchmark comme ça le GC permet d'aller plus vite. Je pensais que tu avais compris que dans toute situation on peut toujours trouver le benchmark sur mesure qui prouve ce qu'on veut. C/C++ restent plus rapides que n'importe quel langage à GC, parce qu'avec eux on peut utiliser un GC si l'on veut tout en pouvant aussi de _pas_ en utiliser un si ce n'est pas utile.

Déjà, tu pars du principe que C et C++ sont les deux langages les plus rapides. Notre cher LupusMic objecterait que tu confond langage et implémentation, et il aurait raison.

Non: indépendamment du compilateur utilisé, il reste vrai que le C et le C++ ne forcent pas le compilateur à rajouter du code en plus de ce que le programmeur a écrit. Contrairement aux langages à ramasse-miettes.

Il y a une toute petite exception avec certaines fonctionnalités du C++ (classes virtuelles etc) mais ces fonctionnalités ne sont pas obligatoires, on ne les utilise que si on en a l'usage, et même alors ça reste minimaliste de sorte qu'on ne pourrait pas obtenir la fonctionnalité équivalente à moins de frais.

Par défaut g++ n'optimise rien, il produit consciemment du code super lent pour que le résultat soit plus débuggable et que la compilation prenne moins longtemps.

Donc ton makefile devrait dire à g++ d'optimiser:

g++ -O2 newbench.cxx -o newbench_cxx

Maintenant si tu te renseignais sur le C++ tu verrais que question performances il est strictement à égalité avec le C, donc le résultat de ton benchmark aurait pu te mettre la puce à l'oreille !

C++ ne fournit aucun "memory allocator" de son propre cru.

L' "operator new" fourni par C++ n'est qu'une enveloppe autour de la routine malloc() fournie par le système d'exploitation. C'est exactement la même chose que malloc().

Alors ensuite oui on peut surcharger "operator new", oui l'une des utilisations est d'avoir un allocateur de mémoire spécialisé, quoique c'est loin d'être la seule utilisation. Moi par exemple je l'utilise surtout pour avoir un "new" qui renvoie des pointeurs alignés sur 128 bits pour des données traitées par des instructions SIMD.

La différence de fond, c'est que C et C++ sont des langages où "Tu ne paies que pour ce que tu utilises". Alors que les langages qui tiennent la main du programmeur, ajoutent un surcoût constant, que ce soit utile ou non.

Pour ce qui est des fuites mémoire, le problème a largement disparu depuis l'apparition d'outils tels que valgrind. Franchement, tu fais "valgrind ./mon_programme", et bloum, tu vois toutes les fuites avec référence vers la ligne de code source fautive. C'est même beaucoup plus puissant que tout ce qu'un GC intégré à un langage peut espérer couvrir, parce que ça couvre non seulement ton programme mais aussi les librairies qu'il utilise, or une certaine partie des fuites mémoire ont lieu à cause d'un malentendu avec une librairie utilisée.

On ne parle pas de la même chose.

Bien sûr que l'on peut trouver des cas où avoir un GC améliore les performances. Dans ces cas-là on peut aussi utiliser un GC en C ou en C++: c'est quelque chose qui peut être fourni par une librarie, quoique bien entendu l'utilisation d'un GC fourni par une librarie ne soit pas aussi transparente que si le GC est fourni par le langage lui-même.

En revanche, si l'on utilise un langage qui utilise automatiquement un GC, alors on est coincé: pour certaines utilisations, il peut n'y avoir aucun moyen d'obtenir un niveau optimal de performances et d'utilisation de la mémoire.

Plus généralement il y a une différence de fond entre d'une part les langages qui laissent le programmeur coder "octet par octet de code machine", sans que le compilateur se permette de rajouter des opcodes à droite à gauche --- c'est le cas de l'assembleur, du C, et de l'essentiel du C++ --- et d'autre part les langages qui vont rajouter leur sauce pour simplifier la vie du programmeur dans "99% des cas" tout en rendant sous-optimal le 1% restant.

Je relève ce qui me semble être une petite contradiction dans la dépêche. Tu dis qu'OOC a la rapidité du C, mais ensuite tu dis qu'il utilise un ramasse-miettes.

Or ça c'est une contradiction: un ramasse-miettes ça a un coût en termes de performances et d'utilisation de la mémoire. Ce n'est pas sans raison que les langages orientés performance, ayant une philophie "aucun surcoût par rapport à l'assembleur", tels que le C et le C++, n'utilisent pas de ramasse-miettes.

http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc(...)