Servo, le moteur de rendu de page web moderne, parallèle et sûr développé en langage Rust, continue d’avancer à grands pas !
Rappel ou information, Servo, publié sous licence MPL 2.0, est développé sur OS X, GNU/Linux, Android, et Firefox OS.
Plus de 120 propriétés CSS sont prises en charge (tableau récapitulatif).
Ces propriétés suffisent pour que Servo soit essentiellement opérationnel sur des sites statiques comme Wikipédia et GitHub, avec une base de code étonnamment réduite : seulement 126 000 lignes (environ) de code Rust. En comparaison, en 2014, Blink fait à peu près 700 000 lignes de code C++, et WebKit 1,3 millions de lignes.
Le nouveau projet servo-shell est très intéressant car il permet d’implémenter et de personnaliser un navigateur web uniquement en JavaScript et CSS. C’est principalement une interface qui utilise les API mozbrowser (c’est-à-dire des extensions d’iFrame) tournant sur Servo et permettant d’isoler l’interface des pages chargées, et cela a donné de bonnes performances jusqu’à maintenant.
- Servo a été porté vers Gonk (la couche bas niveau de Firefox OS).
- Le travail sur WebGL a commencé, pour l’instant on ne peut dessiner que des choses très basiques.
- Une autre fonctionnalité intéressante est la visualisation du rendu parallèle. Dans ce mode, Servo ajoute à chaque tuile une surcouche indiquant le fil d'exécution par lequel le rendu a été fait.
- Affichage d’une image de remplacement lorsque le lien d’une image est cassé.
- Les cookies et la vérification SSL sont pris en charge. Cela permet de se connecter à la plupart des sites web qui ont un système de comptes.
- La possibilité d’intégrer Servo dans des applications est très importante pour le futur. La communauté a décidé d’implémenter l’API Chromium Embedded Framework car elle est populaire et stable. Plus de détails sur le blog du groupe Open Source de Samsung. Vous pouvez la voir en action avec Miniservo sur Mac OS et GNU/Linux (GTK).
- L’API
canvass’améliore, avec la manipulation de pixels,arc(),drawImage, les rotations et les animations et autres. Afficher des SVG basiques tels que le tigre SVG est possible. - Prise en charge basique de WebSockets.
- Prise en charge de WebDriver, un projet de Selenium qui permet d’automatiser les tests d’un navigateur web.
- Et bien sûr, de nombreux ajouts de fonctionnalités mineures, améliorations de performances et corrections de bugs.
On peut voir trois exemples de pages au rendu quasi-parfait :
Le blog de développement publie régulièrement des articles très intéressants comme celui-ci sur l’environnement de développement de Servo, ou celui-ci sur le profilage et la consommation d’énergie.
Dans l’article sur l’environnement de développement de Servo, on apprend que 2/3 du code tournant dans Servo est en C/C++. Cela compte le moteur JavaScript SpiderMonkey, les pipelines 3D Skia et Azure/Moz2D, WebRTC, la prise en charge de DRM (MSE et EME) et les codecs vidéos non-libres : une immense partie du navigateur est intégrée et liée en Rust plutôt que réécrite.
Dans l’autre sens, l’intégration de bibliothèques Rust utilisées dans Servo pourra à terme se retrouver dans Firefox. Firefox peut intégrer du code Rust, un rapport de bug demande l’intégration du parseur rust-url, et la bibliothèque mp4parse-rust a été intégrée dans Firefox 41 (mais n’est pas encore utilisée). Utiliser des bibliothèques Rust permettra d’améliorer la sécurité du navigateur et d’en faciliter la maintenance.
Vous pouvez voir que Servo a très bien avancé ces derniers mois en implémentant plein de nouvelles fonctionnalités qui bénéficient aussi bien aux développeurs de Servo qu’aux futurs utilisateurs. Le projet avance vite, il implémente les fonctionnalités nécessaires aux moteurs de navigateur modernes et montre que Rust, en tant que langage de programmation système, est adapté à l’écriture d’un moteur web à partir de rien.
Samsung et Mozilla ont fait une présentation de Servo à la LinuxCon Japan. De plus, le support de présentation est disponible en ligne et est très intéressant : il explique l’historique, les buts et l’état du projet.
Si vous souhaitez contribuer ou tester Servo, venez voir la page GitHub ou discuter avec les développeuses et développeurs sur le canal IRC #servo sur le serveur IRC Mozilla.
Vous pouvez suivre le blog de Servo, qui publie régulièrement des articles mais surtout, chaque semaine, un récapitulatif de l’avancement du développement appelé « This week in Servo », ainsi que le compte Twitter ServoDev.
Aller plus loin
- Page Github du projet (359 clics)
- Page Wikipédia anglophone sur Servo (161 clics)
- Page Wikipédia francophone sur Servo (565 clics)
- Blog de Servo (284 clics)
- Profil Twitter de l’équipe de développement de Rust (125 clics)
# Fin 2015.
Posté par Kameramann . Évalué à 7.
Je m'insurge il reste encore 3 mois avant 2016, on est donc pas fin 2015. Vous trouvez que le temps passe pas assez vite encore ou bien ?
Bon sinon en fait, je suis un peu surpris de voir parler d'utilisateurs de Servo. Je pensais, naïvement sans doute, que Servo était une sorte de prototype d'expérimentation et non pas un projet destiné à être intégré (à termes) dans Firefox en remplacement de Gecko, ni même en fait à être publié en tant que bibliothèque (?) pour l'utilisation par d'autre.
J'ai raté un truc encore il semblerait ?
[^] # Re: Fin 2015.
Posté par Julien Wajsberg . Évalué à 2.
Note que ça ne parle que de "futurs" utilisateurs ;)
Servo n'est pas prêt pour naviguer sur le Web "en général", mais il peut rendre un certain nombre de sites.
[^] # Re: Fin 2015.
Posté par Xinfe (site web personnel) . Évalué à 8.
J'avais le même avis, mais vu la vitesse à laquelle ça avance et la communication autour (toujours dans le cadre de Rust), ça semble être un "Non, non, c'est un proto pour tester Rust dans la vraie vie, un genre de démo. Ça n'a pas vocation à remplacer Gecko, on n'est pas fous". Plus tard, quand on a un moteur qui tourne bien, c'est "Ah ben vous savez quoi ? On va mettre Servo dans Firefox 43 mais uniquement activable via
about:config, et ça sera le moteur par défaut pour Firefox 44".Donc au final, je trouve que ça évite de mettre une pression de fou sur l'équipe de dev' avec une montagne de critiques qui pourrait leur tomber dessus pour de bonnes et mauvaises raisons, mais s'ils arrivent à avoir un bon moteur performant, fiable et compatible avec l'existant, pourquoi s'en priver ?
[^] # Re: Fin 2015.
Posté par ariasuni . Évalué à 7.
Je préfère préciser qu’il n’y a aucun plan pour le moment pour intégrer Servo dans Firefox, par contre l’équipe de dev bosse sur une interface à Servo pour en faire un navigateur web à part entière avec barre d’URL, marque-pages et autres trucs foufous.
Notons aussi qu’il pourra être intégrer facilement en remplacement de Chromium dans les applis qui utilisent CEF comme Steam (si je ne me trompe pas), ce qui est plutôt un bon point de départ.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Fin 2015.
Posté par antistress (site web personnel) . Évalué à 2.
Si j'ai bien compris c'est moins net s'agissant de Firefox pour Android où il en est plus ou moins déjà question ?
[^] # Re: Fin 2015.
Posté par ariasuni . Évalué à 5.
Je ne crois pas avoir vu quelque part discuter d’intégrer Servo dans Firefox. Il faudrait un énorme travail pour rendre Gecko et le reste de Firefox assez indépendant pour pouvoir utiliser Servo. Bien sûr, ça n’est pas exclut que ça arrive un jour, mais ça n’est pas prévu et vu le travail que ça demande ça ne sera clairement pas demain.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Fin 2015.
Posté par antistress (site web personnel) . Évalué à 4.
J'ai retrouvé le lien : https://events.linuxfoundation.org/sites/events/files/slides/LinuxConEU2014.pdf#page=37
HA HA !
[^] # Re: Fin 2015.
Posté par ariasuni . Évalué à 3.
Ah oui maintenant je me rappelle que ça parlait de Firefox pour Android à un moment, ça devait être ces diapos que j’ai lu il y a 1 an et j’ai un peu oublié entre temps. Cependant je ne me souviens pas en avoir ré-entendu parlé récemment donc il faudrait demander aux devs si c’est toujours d’actualité et si oui où ça en est.
En tout cas merci d’avoir retrouvé l’info et la source. :)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Fin 2015.
Posté par Julien Wajsberg . Évalué à 2.
Il faut savoir que Firefox/Android n'utilise pas du tout XUL, donc ça le rend un bon candidat pour tester ça en effet :)
[^] # Re: Fin 2015.
Posté par antistress (site web personnel) . Évalué à 3.
Ben je pense que c'est déjà le cas, cf le port de LibreOffice pour Android qui se fait en pluguant le composant LibreOfficeKit sur Fennec en lieu et place de Gecko ;)
(j'en parle dans la tribune https://linuxfr.org/redaction )
[^] # Re: Fin 2015.
Posté par Framasky (site web personnel) . Évalué à 4.
Ça ne me choque pas : mon supermarché propose déjà les biscuits et gâteaux de Noël :p
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Fin 2015.
Posté par ariasuni . Évalué à 6.
WESH JE TROUVAIS PAS DE NOM POUR MA DÉPÊCHE
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Fin 2015.
Posté par RoyalPanda . Évalué à 2.
L'emploi du ou bien relève plus à mon avis du caractère non français ou frontalier du protagoniste. En effet, cette locution conjonctive a fortement cours chez les Suisses Romands et dans une moindre mesure chez les Belges Wallons.
[^] # Re: Fin 2015.
Posté par ariasuni . Évalué à 1. Dernière modification le 29 septembre 2015 à 11:44.
Je reliais plutôt ça à l’expression «bien ou bien?», bien connue des jeunes de banlieue parisienne.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Fin 2015.
Posté par BAud (site web personnel) . Évalué à 2. Dernière modification le 29 septembre 2015 à 23:22.
wesh wesh
pour autant, il a un peu raison : le « ou bien » est parfois caractéristique du « isnt'it » en english… (c'est comme cela qu'il faut l'interpréter).
Le wesh n'en est que l'écho… autres mots, mêmes caractéristiques… c'est une question de culture interprétée et mise au goût du jour. Question d'expériences, de voyages, de temporalité, de signification… le sens reste le même et s'interprête bien en transgénération :-)
[^] # Re: Fin 2015.
Posté par j_m . Évalué à 2.
Les allemands utilisent massivement ", oder ?" en fin de phrase. Ce qui se traduit par "ou bien ?" avec une demande de confirmation. Ca me semble bien plus immédiat que "isn't it" comme rapport.
[^] # Re: Fin 2015.
Posté par BAud (site web personnel) . Évalué à 2.
spa faux :-)
< mode rattrapage aux branches> si ça se trouve le "isn't it" vient de là aussite :D < /mode>
[^] # Re: Fin 2015.
Posté par Dr BG . Évalué à 8.
Ou plus usuellement, « n'est-ce pas ? ».
[^] # Re: Fin 2015.
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Officiellement oui, Servo n'est qu'un truc expérimental. Et de toute façon, il n'est pas encore prêt.
Mais.
Vu l'état d'avancement, on peut dire qu'il a dépassé le stade de prototype. Le moteur en lui même fonctionne. Au niveau architecture, je pense que ça se stabilise. Il y a encore certainement du travail à faire au niveau optimisation. Mais ce qu'il reste surtout à faire (si j'ai bien suivi) c'est implémenter des API, des propriétés CSS, HTML et j'en passe pour avoir un moteur de rendu qui soit utilisable.
Il est donc probable que d'ici un an on ait une première version que l'on peut tester en réél (dans un navigateur à l'interface minimaliste).
Cependant un navigateur, ce n'est pas qu'un moteur de rendu : gestion des bookmarks, des mots de passe, des préférences, de l'impression, des addons, en plus d'outils de dev web, du mode private, du mode offline, et plein d'autres choses etc… Donc une fois Servo terminé, il restera du boulot.
Pour Mozilla donc, la question se pose déjà. Est ce que Firefox un jour switchera vers Servo ? pour l'instant très difficile à dire, et si j'en crois les mailing-list, Mozilla ne le sait pas lui-même. Une chose est sûre, ils veulent se débarrasser de XUL, XBL, XPCOM et autres trucs (qui ne seront pas implémentés dans Servo, c'est certain). Pour ça il faut se débarrasser du système d'extension XUL (c'est en cours), il faut migrer l'interface XUL vers du HTML ou du natif (et redevelopper plein de composants interne qui sont en XPCOM). La migration de l'interface est en discussion. Certains proposent plutôt de laisser continuer Firefox comme cela, tout en le faisant évoluer de manière à ce que la transition vers un "Firefox nouvelle génération" soit douce (en clair, il faut que les extensions soient prêtes, d'où les webextensions qui arrivent dans Firefox, qui proposeront une API qui s'abstrait totalement de l'API interne du navigateur, donc de Gecko). D'autres proposent de faire le ménage au fur et à mesure et redévelopper ce qu'il y a à redevelopper pour que ce soit compatible Gecko & Servo (cela veut donc dire migrer petit à petit des bouts d'interfaces de XUL vers HTML, de redévelopper des composants XPCOM en module javascript quand c'est pertinent etc..).
Une chose est sûre : cela va prendre beaucoup de temps, quelque soit la solution.
Maintenant il n'y a pas que Firefox Desktop. Il y a aussi Firefox pour Android, et Firefox OS. Ces deux produits n'utilisent pas XUL et autres trucs "deprecated" (l'interface pour FxAndroid utilise la techno d'android, et pour FxOS, tout est en HTML). Il est donc fort possible que ces deux logiciels remplaceront Gecko par Servo quand ce dernier sera suffisamment mature. Même si ça ne se fera pas en 5 minutes, il y a à priori moins de boulot à l'heure actuelle que pour Firefox Desktop (d'ailleurs on remarquera le port de Servo vers Gonk, le système linux de FirefoxOS : c'est une première étape franchie ;-) ).
Comme autre produit phare, reste Thunderbird. Là tout est en XUL, avec beaucoup de composants XPCOM en C++ (implémentation des protocoles de messageries…). Forcément, l'avenir de Thunderbird est lié à l'avenir de Gecko. Les devs de Thunderbird étudient donc la possibilité de refaire un Thunderbird tout en HTML pour l'interface, et même de redévelopper les différents protocoles en JS. (Qui c'est, verra-t-on Thunderbird sur FirefoxOS ? ;-)
En conclusion : Servo est encore expérimental (dans les faits et officiellement), mais je pense que ça deviendra à terme une vrai brique utilisable en "production". Même si Mozilla décide un jour d'abandonner Servo (ce dont je doute), vu le nombre grandissant de contributeurs externes, c'est un truc qui finira en prod de toute façon. Chez Samsung ou ailleurs.
[^] # Re: Fin 2015.
Posté par mrr . Évalué à 0.
Je me demande si React ou une libraire similaire fonctionne déjà sous Servo. Ça serait une alternative intéressante à XUL pour développer le chrome d'un navigateur.
Envoyé depuis ma Debian avec Firefox
[^] # Re: Fin 2015.
Posté par lockidor . Évalué à 1.
Comme spécifié précedemment, Servo n'est pour le moment qu'un moteur de rendu HTML, donc sans interpréteur JS ; il n'a donc aucune chance de faire tourner React dans un futur proche.
[^] # Re: Fin 2015.
Posté par djano . Évalué à 3.
Je croyais qu'ils utilisaient Spidermonkey pour exécuter le JS?
[^] # Re: Fin 2015.
Posté par ariasuni . Évalué à 3.
En effet, d’après la dépêche:
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Fin 2015.
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
Si si, il y a bien le moteur JS de Gecko dans Servo. Sinon github, pour ne pas le citer, ne fonctionnerai pas du tout dans Servo.
[^] # Re: Fin 2015.
Posté par Dr BG . Évalué à 10.
Nadine M. fonctionne très bien sans, en revanche.
# Remarque à la c...
Posté par romu . Évalué à 10.
…mais s'il ne fait que 126 k lignes, c'est peut être parce qu'à ce stade il en fait beaucoup moins que les autres, non ?
[^] # Re: Remarque à la c...
Posté par Thomas Douillard . Évalué à 3.
Oui c'est exactement ce qui est dit dans la dépêche :) le truc que ça dit justement c'est qu'il y a beaucoup de lignes de code dans un navigateur qui ne servent parfois que sur des niches, et que le nombre de ligne de code utilisées par tous les sites est probablement relativement faible en comparaison du nombre de lignes de code totales.
[^] # Re: Remarque à la c...
Posté par G.bleu (site web personnel) . Évalué à 5.
Je n'ai pas la réponse, mais j'ai la même question pour Blink (700k) vs Webkit (1.3m). Ça me semble très étrange vu que Blink est un fork (plutôt récent ~2 ans 1/2) de Webkit…
C'était les CLUF Apple dans webkit qui faisaient 600k lignes ?
[^] # Re: Remarque à la c...
Posté par barmic . Évalué à 10.
Ça et la gestion de la balise blink.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Remarque à la c...
Posté par ariasuni . Évalué à 3.
Google a viré tout ce qui ne l’intéressaient pas.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Remarque à la c...
Posté par CrEv (site web personnel) . Évalué à 7.
C'était l'un des objectifs de Google lors du fork : nettoyer à la tronçonneuse le code de webkit, virer des archis inutiles pour Google, virer du code lié à JavascriptCore alors qu'ils utilisent V8, etc.
[^] # Re: Remarque à la c...
Posté par ariasuni . Évalué à 3.
Il fait pas mal de choses déjà: parseur HTML, parallélisation poussée, pas mal de balises CSS implantées, un début de prise en charge de canvas, etc., pour un nombre de lignes de codes un ordre de grandeur inférieur à celui de Webkit.
Après c’est sûr que ça sera intéressant de voir à quel point et à quelle vitesse le nombre de lignes de code se rapprochera de celui des autres moteurs. Pour implanter toutes les balises, animations CSS, les canvas, la prise en charge du WebGL, etc, il faudra surement encore une ou deux centaines de milliers de lignes de code. ;)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Remarque à la c...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Tu veux dire qu'il est capable de parser du HTML et faire son rendu, en utilisant correctement un grand nombre de cpu ? Ils doublent les perfs entre 4 et 8 coeurs ?
"La première sécurité est la liberté"
[^] # Re: Remarque à la c...
Posté par ariasuni . Évalué à 6.
Voir le support de présentation de LinuxCon Japan 2015, en particulier à partir de la diapo 12, un beau schéma page 20, deux beaux exemples page 22 et 23, et des graphiques et explications sur les performances de la page 24 à la page 28.
En fonction des sites web, la différence de performances entre 1 fil d’exécution et 4 est de l’ordre de 1,5 à un peu plus de 2. Et il éclate littéralement Gecko en rapidité alors qu’il fait la même chose. Cependant il y a deux choses à prendre en compte: l’ajout de fonctionnalité va forcément complexifier le code donc ça se peut que Servo soit plus lent dans le futur, d’un autre côté Servo peut sans doute être plus optimisé que ça et être encore plus rapide que ça!
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Remarque à la c...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'est bien plus rapide que gecko en mode mono core. Mais 1.5 de speed-up, c'est pas terrible du tout (en 2 threads on devrait être à x2). La tâche est complexe car les traitements sont interdépendants.
En puissance brute, c'est plus simple de faire 8 coeurs type ARM Cortex A7 (faible consommation et forte puissance cumulé). Mais pour avoir de grosses performances monocores, il faut monter la fréquence, donc, augmenter la profondeur des pipelines (ce qui implique plus de logique de gestion), il faut faire de l’exécution spéculative (qui rajoute du controle en O(n2), n était le nombre d'instruction exécuté en même temps). Bref, on a la même puissance brute avec 2 ou 4 cpu plus rapide (A9), mais qui consomment plus et qui sont plus gros.
D'ailleurs, pour les PC de bureau, on dirait qu'il y a un paliers vers 4 ou 8 cpu (4 cpu 2 threads par cpu).
"La première sécurité est la liberté"
[^] # Re: Remarque à la c...
Posté par ariasuni . Évalué à 5.
L’amélioration est déjà notable et le rendu d’un site web n’est certainement pas facile à paralléliser. D’ailleurs les performances en lançant deux fils d’exécution sont très bonnes, seulement la version 4 fils n’est pas (encore?) beaucoup plus rapide. De plus, la diapo 26 indique :
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Remarque à la c...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je ne connais pas le langage, mais est-ce que les optimisations type openMP sont possibles ? (en gros parallélisation des "map", voir encore mieux l'équivalent du map/reduce de google mais pour le même ordinateur), ce genre de construction peut être facilement utilisé, à condition que le système de gestion derrière soit ultra-light. ( https://fr.wikipedia.org/wiki/MapReduce )
"La première sécurité est la liberté"
[^] # Re: Remarque à la c...
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 6.
Je pense pas qu'après c'est pas tant une question de langage que d'algorithmes ? Rust fournit des mécanismes pour garantir une relative sécurité quand tu fais de la concurrence, mais après il en reste pas moins que c'est compliqué de considérer tous les éléments d'une page comme des éléments parfaitement indépendants (typiquement la taille d'un élément risque de dépendre de celle des autres éléments, donc il faut faire plusieurs «passes» si j'ai bien compris la présentation que j'avais vue).
Après j'avoue que je suis un peu sceptique sur l'intérêt de l'optimisation du rendu des pages webs, au moins sur PC. Personellement quand Firefox galère, j'ai l'impression que 90% du temps ça vient du Javascript, ce qui sort du coup du cadre de Servo.
[^] # Re: Remarque à la c...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Disons que c'est plus une question du futur concernant les mobiles. Augmenter le nombre de coeur est le moyen le moins couteux en terme de surface de silicium et de consommation électrique.
Le browser sur un téléphone est le truc qui tournent à 100% du cpu pour offrir le maximum de fluidité, il n'a pas un framerate à respecter comme un film, il prend tout. Donc, si il n'est pas possible d'avoir des perfs linéaire avec le nombre de coeur, l'utilité d'avoir plus de 4 coeurs dans un SoC mobile, devient très discutable.
"La première sécurité est la liberté"
[^] # Re: Remarque à la c...
Posté par ariasuni . Évalué à 5.
D’après ce que j’avais compris le JavaScript tourne en parallèle également. C’était mon interprétation des trois boites Renderer, Script et Layout sur les diapos 14 à 16, et basé sur des souvenirs de lectures d’il y a assez longtemps. Dans tous les cas il y a beaucoup de pages sans ou avec peu de JavaScript, ou qui ne bloque pas l’affichage. Pour compléter le commentaire au-dessus, je dirais qu’être plus rapide et consommer moins d’énergie même sur PC c’est quand même plutôt appréciable. :)
On peut imaginer un futur avec des pages plus interactives et plus complexes avec de bonnes performances, ou des jeux en HTML5 qui poutrent en terme de performances.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Remarque à la c...
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 5.
Ben que ce soit en parallèle du reste du navigateur, oui sans doute, mais vu que c'est la reprise de SpiderMonkey, l'interprétation en elle-même du javascript doit être à peu près similaire à Firefox, je suppose…
En soit oui, c'est toujours appréciable (et plus sûr aussi, ce qui je pense peut pour le coup être un net avantage de Rust par rapport au C++), mais disons que je m'attends pas non plus à ce que ça change radicalement mon expérience, quoi.
(Pour ce qui est de consommer moins d'énergie j'ai un doute quand même, mais peut-être que c'est une question bête : est-ce que ça consomme vraiment moins d'énergie d'avoir deux procs qui tournent moins longtemps, qu'un proc qui tourne deux (probablement un peu moins en pratique) fois plus longtemps ?)
[^] # Re: Remarque à la c...
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
2 proc identiques vs un seul qui tourne 2 fois plus longtemps revienne presque au même. La différence sera sur les périphériques. Typiquement, l'interface DRAM utilisera 2 fois plus d'énergie dans le 2ième cas, idem pour une mémoire cache partagé (L3). Donc, le deuxième cas est le plus consommateur d'énergie.
"La première sécurité est la liberté"
[^] # Re: Remarque à la c...
Posté par tatrefthekiller . Évalué à 2.
Il me semble que d'après leurs tests, il vaut mieux avoir 2 cores à 50% que 1 à 100%. Les dev rust sortent des benches de temps à autres, mais la gestion de l'energie est primordiale pour eux, puisque l'une des cibles est les mobiles de dernières (et futures) générations avec >4 coeurs.
http://blog.servo.org/2015/09/11/timing-energy/
D'autre part, concernant le rendu parallèle de pages web, j'ai lu dans un article ou une conf (je ne retrouve pas la ref…) qu'ils sont "state of the art", au sens où aucun autre moteur n'est capable de gérer du rendu parallèle + avec les garanties offertes par le language.
[^] # Re: Remarque à la c...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
J'imagine que cela dépend de la plateforme. Il y a plusieurs choses contradictoires :
- une très grosse portion de la consommation est statique. Donc, 50% ou 100% de la clocks ne fait pas une grosse différence (inclus la réduction de la tension), sur la puissance instantanée, mais propose une consommation d'énergie par instructions plus élevées.
- Les caches et les bus internes n'ont souvent que 2 points de fonctionnement (on ou off), donc 25 ou 100% de la vitesse, ils consomment la même chose.
- Un cpu est optimisé à sa synthèse pour fonctionner à sa vitesse nominal (ex:2hz). Si le but est de le faire fonctionner à 50%, il sera bien plus petit, si on le synthétise pour qu'il tourne à 1Ghz. Allez vite implique plus de pipeline, ce qui prend de la place, aussi.
J'imagine donc que l'optimal doit être 100% à 2 cpus avec des plages ou tout est coupé (genre 50 ms allumé, 50 ms éteint), avec une baisse de la fréquence/tension sur la DRAM si la charge est cpu bound.
"La première sécurité est la liberté"
[^] # Re: Remarque à la c...
Posté par cedric . Évalué à 7.
Le "truc" amusant actuellement, c'est que le noyau Linux est tres mauvais a estime la bonne frequence et le nombre de CPU au bon moment. Les systemes de cpu idle et de cpu freq etant decouple du scheduler qui lui meme perd tout l'historique des qu'il bouge une tache sur un nouveau coeur. Le resultat actuel, c'est que le CPU se retrouve dans les taches graphiques souvent a la mauvaise frequence au mauvais moment.
La raison est simple, vous avez une serie de tache globalement plutot seriel, qui enchaine une etape IO bound, MEM bound, CPU bound, MEM bound, pour retourner en IO bound. Le tout par cycle de 16ms.
Le probleme est connu, et c'est pour cela qu'il y a du travail sur la gestion d'energie et le scheduler en cour. Mais cela affecte aussi l'user space. Le noyau n'a des statistiques que par process, il ne sait pas si un bout de code est IO, MEM ou CPU bound. Par contre, un process, a terme, il saura quel est potentiellement la frequence ideal de fonctionnement. Cela n'est vrai bien entendu que si dans un meme process ne tourne que des taches qui ont les meme proprietes !
Donc il faut bien s'orienter vers du multi thread, mais les mesures actuelles de consomation ne sont probablement pas tres pertinente tant que le noyau n'aura pas ete corrige.
Pour une explication potentielle du pourquoi, 2 * 50%, c'est mieux que 1 * 100%, c'est probablement lie a la disponibilites de plus de bande passante memoire du cache L1 (un par core) qui permet d'eviter des acces dans les sous systemes memoire plus lointain et plus couteux en energie pour y acceder (Acceder un registre etant moins energivore qu'un acces en L1, un L1 moins qu'un L2 et un L2 moins qu'un acces en RAM). C'est potentiellement une explication que je vois, surtout si la frequence des core est alors adapte a la consommation de bande passante memoire offert par le cache.
[^] # Re: Remarque à la c...
Posté par Julien Wajsberg . Évalué à 1.
Une comparaison peut-être à la c…:
Pour une voiture, ça coûte plus d'énergie de passer de 50 à 100 km/h que de 0 à 50 km/h…
Aucune idée de si la comparaison est adéquate :)
Cependant on sait que les procs récents ont un "turbo": celui-là est peut-être plus coûteux en énergie ? J'en sais rien, je demande :)
[^] # Re: Remarque à la c...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Non, rien à voir. L'énergie cinétique est en m*v², donc l'énergie est proportionnel au carré de la vitesse.
Avant le 0.18µm, les puce avaient une consommation surtout dynamique en c*f*v², donc consommation proportionnel à la fréquence. Or la tension nécessaire dépend aussi de la fréquence, donc en baissant les 2, on baissait l'énergie par cycle d'horloge. Aujourd'hui, la consommation est surtout statique (fuite).
"La première sécurité est la liberté"
[^] # Re: Remarque à la c...
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 1.
Et puis deux processeurs qui fonctionneraient à 50% au lieu d'un à 100%, a priori c'est dans le cas où y'a pas de gain de vitesse final. Le but si tu veux accélérer le rendu ce serait plutôt que les deux processeurs fonctionnent à 100% pendant deux fois moins longtemps.
[^] # Re: Remarque à la c...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Le seul cas ou cela pourrait être faux, c'est si le traitement est memory bound, ce qui fait que les cpu se tournent les pouces.
J'avais lu qu'une des optimisations de consommation possible était la modulation de la vitesse de l'interface DRAM selon la charge. Dans le cas, CPU bound, il pouvait baisser la vitesse de l'interface de 20% et gagner en consommation.
"La première sécurité est la liberté"
[^] # Re: Remarque à la c...
Posté par BAud (site web personnel) . Évalué à 2.
I/O bound en général :-) (incluant les traitements sur disque)
[^] # Re: Remarque à la c...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Dans le cas IO bound, les cpu peuvent être coupé, donc, niveau énergie, 1 ou 2 cpu ne devrait pas changer grand chose.
"La première sécurité est la liberté"
[^] # Re: Remarque à la c...
Posté par lasher . Évalué à 3. Dernière modification le 13 octobre 2015 à 17:03.
Il y a aussi des chercheurs qui montrent qu'en exploitant le DCM (Duty-Cycle Modulation) on peut « suspendre » l'horloge pour quelques cycles lorsque tu as des latences longues (accès mémoire, E/S), et effectivement réduire la conso d'énergie des cœurs sans pour autant à avoir à passer par du DVFS (dynamic voltage and frequency scaling), qui prend trop de temps si la latence est longue, mais pas trop longue.
[^] # Re: Remarque à la c...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3. Dernière modification le 13 octobre 2015 à 17:21.
Cette info date de quand ? Il me semblait que tous les design low power fonctionnait ainsi. Je me rappelle de mon stage en 2000, sur un tout petit cpu, qui avait un gros banc de registres en flip-flop dont la clock était masqué par le signal de write.
Mais depuis, la conso dynamique est devenu négligeable devant la consommation de fuite. Tu as donc 2 choix : couper le courant ou baisser le courant. Le problème est toujours que rétablir le courant "prend du temps", "quelques cycles" n'étaient pas pensable. Pour baisser la tension, j'ai vu un design, où il mettait en série une diode avec l'alimentation, cela faisait une chute de tension de 0.6V très rapide, ce qui permettait aussi de conserver l'état des registres.
Le DVFS, j'ai l'impression que c'est la fausse bonne idée. A la limite, si tu as un bon sample, vu que la vitesse du chip est mesuré (par ring oscillateur), la tension peut être plus basse que prévu, et donc l'autonomie plus importante. Je pense que tout couper est plus efficace (horloge et alimentation).
"La première sécurité est la liberté"
[^] # Re: Remarque à la c...
Posté par lasher . Évalué à 4.
DCM est utilisable sur les derniers x86 d'Intel (Haswell & co). Il faut écrire un driver parce qu'au moins pour le moment, l'instruction nécessite un accès ring0. Si tu coupes tout (power gating), tu perds l'état du processeur. Avec DCM, tu suspends le proc, sans pour autant perdre les données du L1. C'est quand même 'achement plus pratique.
Ce papier explique comment ils utilisent DCM pour les synchros entre thread et certaines opérations à latence longue mais pas forcément « inconnue »:
Wei Wang, Allan Porterfield, John Cavazos, Sridutt Bhalachandra, "Using Per-Loop CPU Clock Modulation for Energy Efficiency in OpenMP Applications,” at 2015 International Conference on Parallel Processing (ICPP 2015), Beijing, China, 2015.Les slides de sa présentation sont aussi dispo
[^] # Re: Remarque à la c...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je suis un peu déconnecté du truc. Mais en 2009, je bossais pour TI. Intel faisait uniquement du DVFS pour éviter de bruler sa puce et non pour la gestion d'énergie. Quand Intel a sorti Atom pour tabletPC, il proposait un cpu qui consommait en veille, autant qu'un Omap au max.
Intel utilisait une techno MOS dynamique (logique domino?) rapide sur ces cpu de bureau, mais qui consomme beaucoup plus que du cmos classique. Donc, couper l'horloge doit avoir un vrai effet. Je ne sais pas si ils sont passés au CMOS depuis.
"La première sécurité est la liberté"
[^] # Re: Remarque à la c...
Posté par lasher . Évalué à 4.
Je ne connais pas bien la techno derrière DCM sur Haswell (je veux dire, au niveau micro-électronique), mais le papier que j'ai donné en référence confirme plus ou moins ce que tu dis à propos de DVFS: c'est tros « gros grain » pour être utile dans des cas de calcul intensif avec des changements de « phase » trop rapprochés. Par exemple, si des threads attendent tous à une barrière, utiliser DVFS et baisser la fréquence/la tension risquent de ne rien apporter, vu que le temps passé à basculer d'une fréquence à l'autre est grosso-modo celui passé dans la barrière. Par contre, en passant par DCM, vu qu'on n'a qu'à attendre, c'est plus ou moins logique de faire une boucle d'attente active qui suspend l'horloge.
J'ai parlé avec les auteurs du papier en question, et ils ont des applications même pour les comms entre nœuds de calcul, genre des nœuds connectés avec de l'Infiniband (et donc de courtes latences).
Intel a vraiment fait beaucoup de progrès niveau gestion d'énergie et puissance. Pas seulement avec les P-state, C-state, etc., mais aussi avec les « boutons » qu'on peut utiliser en tant que root (ou avec un driver). C'est juste qu'ils doivent composer avec des aspects sécurité difficiles à gérer (genre timing attacks, tout ça). Leurs cœurs sont de plus en plus indépendants en termes de gestion de fréquence, tension, et gestion de l'horloge. Ils ont aussi développé tout un tas de trucs pour permettre de n'activer que les fils qui sont intéressants même pour des opérations flottantes (genre instruction FMA qui n'active que 16, 32, ou 64 fils et les composants associés en fonction de la précision voulue pour l'opération). Je ne sais pas s'ils l'ont déjà intégrée pour les instructions SSE/AVX/blah, mais en tout cas ils avaient un papier en 2012 pour expliquer le principe, avec les chiffres concernant la réduction en conso d'énergie statique et dynamique.
Si tu lis le manuel d'Intel, section 14.5.1, ils décrivent les instructions pour utiliser la DCM. D'après cette thèse on a une notion de modulation de cycle d'horloge depuis au moins le Pentium 4, mais l'utilisation des « C-States » est récente.
[^] # Re: Remarque à la c...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Concernant la gestion d'horloge et de tensions, il ne faut pas mélanger les choix pour une techno et ce qui est possible de faire.
Pour couper une horloge, il suffit de mettre une porte devant. Pour en changer la fréquence, il faut modifier la pll qui peut mettre un certain temps à se stabiliser. Le pire est de couper la pll pour la rallumer (~100ms de mémoire).
Concernant la tension, tu peux couper des power domaine entier. Mais selon la taille des fils, rallumer un secteur prend un "certain temps" (celui des capa parasites le long de tout les fils d'alim). Baisser la tension avec une diode en série, prend un peu moins de temps car le delta de tension est plus faible. En plus, cela évite d'avoir 2 power domain, avec l'un dédié au registre pour conserver "l'état" du module.
Un DVFS, c'est accorder la tension nécessaire pour une fréquence donnée. Dans l'exemple que j'ai vu, c'est une commande I2C à 3.5Mhz qui sort du Soc pour aller dans la puce de gestion d'énergie pour donner une nouvelle tension. La communication est donc lente, et ensuite, il faut que l'alim à découpage varie sa tension sans autre perturbation (surtout aucune oscillation par exemple). Les points tensions/fréquence peuvent être fixe ou asservi. Dans le cas d'un asservissement, il y a un "ring oscillateur", une série d'inverseurs mis en anneaux, qui oscille, la fréquence dépend de la vitesse de chaque inverseurs qui est proportionnel à la tension d'alimentation. Ainsi, si la vitesse des oscillateurs est plus grande que nécessaire, la tension peut être baissée. Si la tension baisse trop, le SoC plante, il ne faut pas oublier. Ainsi, le cycle de mesure/ajustement se fait en plusieurs fois. Ce qui prend encore plus de temps. En général, on allait à un point de fonctionnement, puis on laissait le truc en automatique. L'automatisme permet de s'ajuster à chaque puce. Donc, les samples les plus rapide consommaient moins, car avec une tension plus faible en moyenne.
Souvent les points de fonctionnement à 100, 50 ou 25 % de la clock max ne concernait que le cpu et non les caches (omap3). Ainsi, l'énergie nécessaires par instructions ne baissait pas comme le prévois la formule linéairement à la tension. Donc, les points de fonctionnement à 50 et 25%, si on tient compte de la puce entière ne consomme pas forcément moins. Il faut donc mieux jouer sur allumer et éteindre le chip (avec nettoyage du cache si nécessaire).
Intel a fait des progrès, je n'en doute pas. Surtout qu'ils ont récupérer l'équipe low power de TI, après leur fermeture à Sophia Antipolis en 2009.
J'avais entendu parler aussi des gains de puissance, si on jouait sur le rapport entre la vitesse de la DRAM et la vitesse du cpu. En général, ils sont au max tous les 2, à 100% de l'horloge. Mais les taches peuvent être cpu bound ou memory bound. Cela permet de baisser une fréquence par rapport à l'autre sans perte de performance ou presque, le papier citait 20% de gain d'énergie sur le mode 100%.
"La première sécurité est la liberté"
[^] # Re: Remarque à la c...
Posté par lasher . Évalué à 3.
Nous sommes bien d'accord. :-)
Oui.
Oui, aussi. Jusqu'à il y a ~1 an, mon labo bossait avec une équipe d'Intel qui fait de la recherche pour les processeurs de machines « exascale » (voir ici par exemple : http://extremescale.cs.illinois.edu/thrifty/PUBLICATIONS/iacoma-papers/hpca13_1.pdf). L'un des principes de base de la machine est que le processeur sera « sur-provisionné ». En d'autres termes : « les calculs seront gratuits comparés à l'énergie dépensée en transferts de données ». Un block de 8+1 cœurs (1 cœur de contrôle, et 8 cœurs de calcul) aurait plusieurs domaines de puissance, où on pourrait commuter plus ou moins facilement. Le tout repose sur des technos de tension au seuil (et à l'époque, une partie de la recherche portait sur les « soft errors » qui en résulteraient).
Dans la puce « théorique » Runnemede (maintenant c'est « Traleika Glacier » parce que le projet est passé de DARPA à DOE), le principe est que tu pouvais couper les unités fonctionnelles individuelles, faire du clock gating sur un cœur de calcul (y compris son scratchpad), faire du power gating (avec les latences que ça engendre quand tu le rallumes, ainsi que le besoin de sauver/restaurer les données) sur des cœurs, passer un bloc de cœurs en NTV, ou bien changer le domaine de puissance parmi un sous-ensemble de domaines prédéfinis par bloc de cœurs, voire faire du power gating sur des bancs mémoire du « L2 » (la mémoire locale au bloc de cœurs, un plus gros scratchpad en gros).
De plus, les ordres de grandeur qu'on nous avait donnés étaient : à fréquence/tension « nominale », la fuite/leakage est de ~20% (pour une fréquence de ~4 GHz). En NTV, on passe à ~50% (pour une fréquence de ~500 MHz).
À côté de ça, Intel bosse/bossait sur le réseau d'inter-connexion entre les blocs, avec la notion de « bandwidth tapering » (« bande passante dégressive »), où la combinaison HW/SW décideraient de quand désactiver les composants de l'interconnect, mais aussi de quel besoin de bande-passante serait satisfait (c-à-d que la BP théorique pourrait être énorme, mais pour des raisons d'enveloppe thermique/conso de puissance, on pourrait limiter la BP dans certains endroits du chip, entre différents blocs).
Toujours pour la puce Runnemede/TG :-), comme on avait 256 blocs de 8 cœurs de calcul chaque, c'est plus ou moins ce qu'on considérait : au minimum, on « suspend » (clock-gate) tout le bloc, voire on l'éteint (power gate). Possiblement, on éteint les cœurs, mais on laisse la mémoire de bloc allumée, comme ça les autres blocs qui ont besoin des données stockées dedans peuvent toujours piocher.
Mais l'idée était qu'effectivement avec les problèmes de « dark silicon » etc., la majorité du chip serait en mode basse tension/fréquence, avec juste quelques parties qui seraient en haute tension/fréquence (principalement pour faire tourner les parties du code qui sont peu parallèles). De même, l'idée était que le réseau d'interconnexion devrait être coupé le plus souvent possible. Il y aurait aussi une barrière matérielle par bloc, histoire d'automatiquement suspendre les cœurs qui l'utilisent, et automatiquement reprendre le calcul une fois que tous les cœurs ont atteint la barrière (chépassichuiclair).
Comme je bossais avec Intel Research, je ne sais pas si ces ingés étaient là-bas ou bien en prod. :-)
Oui, il y a pas mal de travail autour du DVFS avec une analyse des « phases » d'un programme : si tu peux déterminer (par profilage ou autre méthode) qu'une phase dans un programme est memory-bound, tu peux passer en tension/fréquence plus basse sans perte de perf, vu que le goulot d'étranglement est la mémoire ou les I/O. Le problème survient lorsque les phases sont entrelacées et trop courtes pour tenir les 100ms dont tu parlais. C'est en particulier problématique avec les codes dont les motifs d'accès aux données sont irréguliers et difficilement prévisibles (typiquement, les codes itératifs à base d'équations différentielles partielles et codes de maillage adaptatif, où tu te retrouves à faire du
a[ b[i] ]sans savoir si tu as un stride/pas d'avancement régulier dans le tableau). Du coup, p'tet que tu vas avoir une super localité et tes caches seront super utiles, ou bien p'tet que tu vas avoir une localité de merde, et tu vas passer ton temps à résoudre des cache misses.[^] # Re: Remarque à la c...
Posté par Julien Wajsberg . Évalué à 1.
Et tu sais comment ça marche pour le mode Turbo ? C'est surtout un moyen de chiper de la puissance aux autres coeurs ?
[^] # Re: Remarque à la c...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'est juste une augmentation de la fréquence qui se limite à quelques cœurs pour limiter la puissance total consommée. Ici, la limite est thermique.
"La première sécurité est la liberté"
# code server ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3. Dernière modification le 29 septembre 2015 à 10:28.
Est-ce qu'il existe une lib rust pour faire un serveur applicatif http ? Je cherche un langage moderne, rapide, avec des types sommes (enum en rust). go semble rapide, mais niveau typage, il est l'air plus simple (pas de type somme ? http://www.jerf.org/iri/post/2917).
"La première sécurité est la liberté"
[^] # Re: code server ?
Posté par Xinfe (site web personnel) . Évalué à 4.
Are we web yet?
[^] # Re: code server ?
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 4.
Iron, peut-être ? https://github.com/iron/iron
[^] # Re: code server ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
iron a l'air le plus au point.
"La première sécurité est la liberté"
[^] # Re: code server ?
Posté par Benoît Laurent (site web personnel) . Évalué à 1.
Il y a cette page qui recense les lib autour de http en rust:
Are we web yet? Getting there.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.