Les options d’optimisation agressives sont-elles inutiles ?

Dans une page de leur wiki les développeurs de Mozilla Firefox et des outils associés déclarent, je cite :

For Firefox 3 builds, please use –enable-optimize without flags.

Our testing has shown that different parts of Mozilla run faster at different optimization levels. For example, cairo, pixman and sqlite are compiled at -O2 because they are fastest at that level while the JS engine is fastest at -Os. [3] Don’t use –enable-optimize as a place to pass in random compile flags. That’s a global setting that sets optimization levels throughout the source tree and is different depending on the module being compiled.

If you still need to pass in other non-optimization flags to the compile, please use CFLAGS and CXXFLAGS instead of passing them to –enable-optimize.

Ce qui donne traduit :

Pour la compilation de Firefox 3, veuillez utiliser –enable-optimize sans options.

Nos tests nous ont montrés que les différentes parties de Mozilla sont plus rapides à différents niveaux d’optimisation. Par exemple, cairo, pixman et sqlite sont compilé en -O2 car ils sont plus rapide à ce niveau tandis que le moteur JS est plus rapide avec -Os. N’utilisez pas –enable-optimize comme un endroit pour insérer des options de compilations divers. C’est un réglage global qui définit les niveaux d’optimisation tout au long du code source et il diffère en fonction du module qui est compilé.

Si vous avez toujours besoin de passer des options de non optimisation au moment de la compilation, veuillez utiliser CFLAGS et CXXFLAGS au lieu d’utiliser la ligne –enable-optimize.

Or, un « dérivé » de Firefox, nommé Swiftfox est connu pour, au contraire, proposer des compilations optimisées en fonction du processeur utilisé.

Comme déclaré sur leur page d’accueil, je cite :

Swiftfox is an optimized build of Mozilla Firefox. Swiftfox has builds for both AMD and Intel processors and is based on the most cutting edge Firefox source code available.

Ce qui donne traduit :

Swiftfox est une compilation optimisée de Mozilla Firefox. Swiftfox a des compilations pour à la fois les processeurs AMD et Intel et se base sur le code source de Firefox le plus récent disponible.

D’ailleurs, en fouillant un peu sur le forum, on apprend que ce sont des compilations uniquement en 32 bits, même pour les processeurs 64 bits, comme les Athlon64 d’AMD ou les Core2Duo d’Intel.

J’ai pu lancer – et récupérer les options de compilation en installant temporairement le méta-paquet flashplugin-nonfree qui propose des bibliothèques 32 bits indispensable.

Liste assez impressionnante soit dit en passant…

Options de compilation de Swiftfox

Le score de Swiftfox 3 (qui est basé sur le code source de Firefox d’une préversion de la 3.0.3 du logiciel, la 3.0.2 étant déjà gelée et prévue pour très bientôt) au test V8 est quand même assez faible : 106 points seulement. Et un peu moins que le Firefox 3.0.1 fourni avec la distribution Ubuntu Linux 8.04.1 LTS

106 points au test V8 pour Swiftfox

106 points au test V8 pour Swiftfox

Pour mémoire, le résultat d’une compilation faite maison en suivant les recommandations des codeurs est de 129 points.

129 points pour Minefield avec les optimisations de Swiftfox

Ayant recopié les options de compilation de Swiftfox« >swiftfox, j’en ai tiré le .mozconfig suivant, pour recompiler une version du code de Shiretoko, en sachant que les options d’extensions font planter la compilation dès le début :

#
# See http://www.mozilla.org/build/ for build instructions.
#

. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-fx

# Options for ‘configure’ (same as command-line options).
ac_add_options –enable-optimize= »-O3 -march=athlon64 -freorder-blocks -fno-reorder-functions -msse2 -mmmx -m3dnow -mfpmath=sse -D_FORTIFY_SOURCE=2″
ac_add_options –disable-debug
ac_add_options –disable-tests
ac_add_options –enable-default-toolkit=cairo-gtk2
ac_add_options –disable-freetype2
ac_add_options –enable-extensions=default
ac_add_options –enable-xinerama
ac_add_options –enable-libxul
ac_add_options –enable-webservices
ac_add_options –enable-xft
ac_add_options –enable-crypto
ac_add_options –enable-svg
ac_add_options –enable-canvas
ac_add_options –enable-update-packaging
ac_add_options –disable-installer
ac_add_options –disable-profilesharing
ac_add_options –enable-single-profile
ac_add_options –with-pthreads

A part certaines options devenue inutiles comme « –disable-freetype2 » ou encore « –enable-crypto », la compilation se lance. Le résultat montrera-t-il un gain de vitesse, même minimal ?

Une fois la compilation terminée – ce qui a pris près de 50 minutes, j’ai lancé le minefield « optimisé »… Et le résultat a été de 129 points…

129 points pour Minefield avec les optimisations de Swiftfox

Gain ? Aucun.

Et que nous dirait alors SunSpider ? Le résultat est sans appel : 6311 ms au lieu d’un peu plus de 6100 ms lors d’un article précédent sur que j’avais rédigé sur TraceMonkey.

6311 ms au test Sunspider avec les optimisations de Swiftfox

Ce qui tend à prouver une chose : le gain de vitesse d’un logiciel ne se fait pas par l’utilisation d’options de compilations « agressive » mais par une meilleure gestion du code à compiler.

Autant dire que je m’attends à des discours incendiaires de la part des partisans de Swiftfox 😉