Record | Dr. Goulu

Encore plus vite que le vent

Sun, 16 Dec 2012 00:00:00 +0000

Vous savez peut-être que j’ai créé il y a un peu plus de 5 ans un , désormais principalement animé par d’autres passionnés. Depuis 2007, le a été franchi par des engins très différents, allant du kitesurf à . Mais le 24 novembre 2012, le record de vitesse pure a été pulvérisé par , qui a de moyenne sur 500m

Vestas Sailrocket 2 à 65 noeuds en Namibie. Cliquez pour la video !

Dans un spectaculaires, j’ai relevé que pour atteindre de telles vitesses il faut des conditions idéales : vent de 30 nœuds (voire plus pour les kite) arrivant sous le bon angle au ras d’une plage pour que les vagues ne soient pas formées. Le record absolu de vitesse a-t-il toujours un sens s’il faut attendre des semaines que ces conditions se présentent en l’un des quelques spots idéaux de la planète ? Ne devrait-on pas plutôt mettre sur pied des records relatifs à la vitesse du vent, en considérant que Sailrocket a atteint 2.4x la vitesse du vent, un kitesurf atteignant 1.8 et “BMW Oracle”, le géant de la dernière Coupe de l’America un facteur 4.5 ?

Car oui, on peut aller . Mais pas à toutes les : les bateaux munis de voiles traditionnelles ou d’ailes fixes ne peuvent remonter face au vent. Et au “vent arrière”, il sont condamnés à une vitesse inférieure à celle du vent car lorsque la vitesse du bateau augmente, le diminue jusqu’au point où la puissance extraite par les voiles compense la , et le bateau ne peut plus accélérer. *

Mais des voiles “non traditionnelles” permettent-elles de dépasser ces limites ?

La réponse est oui. Sur l’eau il existe déjà des , de s et même un propulsés par des éoliennes orientables couplées à des hélices marines, ce qui leur permet de remonter directement face au vent. Mais en l’absence d’organisme validant des records de , les navigateurs ont peu de considération pour ces travaux

Sur terre, la (Association Nord Américaine de Chars à Voile) homologue des records face au vent en vitesse absolue (C3) et relative (C4) . Ces deux records étaient tous deux détenus par le véhicule “DTU” de l’Université Technique du Danemark participant à l’édition 2011 de la . Il avait atteint 24.6 km/h et 75% de la vitesse du vent pendant les 10 meilleures secondes de son parcours sur une route de 5.3 km orientée face au vent. La course a été remportée cette année par , un engin de l’Ecole Technique Supérieure du Québec qui a .

Chinook, lauréat de l’Aeolus 2012 avec 58.5% de la vitesse du vent (cliquer pour plus d’infos)

Chinook a peut-être même ponctuellement fait mieux que les 75% de DTU, mais ça n’a plus d’importance depuis le 16 juin 2012. Car ce jour là, le “ ” de Rick Cavallaro a pulvérisé le record de vitesse absolue face au vent (C3) avec 36.6 km/h et surtout le record relatif (C4) avec 2.1 fois la vitesse du vent réel ! ,

Blackbird face au vent. Remarquez le pas variable de l’éolienne (et cliquez pour plus d’infos)

Ce record spectaculaire est cependant moins surprenant que celui qu’avait déjà réalisé Blackbird le 3 juillet 2010. Ce jour là Rick Cavallaro est devenu le premier homme “DDWFTTW” : Direct DownWind Faster Than The Wind. Il a même atteint 44.6 km/h dans 16 km/h de vent, soit presque 2.8 fois la vitesse du vent , au vent arrière !

Comme le dit Rick Cavallaro dans un article passionnant qui retrace toute l’aventure , 99% des gens pensent a priori que c’est impossible (c’était mon cas) et 99% des autres n’arrivent pas à comprendre comment ça peut marcher (c’est mon cas actuellement, mais je me soigne).

En 2008, où l’on voit un modèle réduit dépasser la vitesse du vent (à partir de 1:22) a été qualifiée de canular et suscité des commentaires très critiques voire haineux sur plusieurs forums. Même des blogs de science respectables assimilaient DDWFTTW à “mouvement perpétuel” .

Il faut dire que la première idée qui vient à l’esprit est fausse : ce n’est pas l’éolienne qui fait tourner les roues, ce qui poserait un problème lorsque le vent apparent s’annule. Ce n’est pas non plus l’inertie du rotor qui permet de passer cette vitesse critique, et il ne faut pas inverser le pas de l’hélice pour qu’elle mouline l’air venant de l’avant après avoir mouliné l’air venant de l’arrière. D’ailleurs regardez la vidéo une fois encore : l’hélice tourne dans la direction “propulsive” dès le départ, et rien de spécial ne se produit lorsque l’engin atteint la vitesse du vent

La solution est beaucoup plus simple, mais aussi beaucoup plus perturbante que ça : ce sont les roues qui actionnent l’hélice, qui fonctionne comme un propulseur ! Ca pue le mouvement perpétuel, mais ça n’en est pas un parce que le vent réel est toujours présent, le problème étant de pouvoir utiliser son énergie.

Dans leur article “ ” paru dans “Pour La Science” cet été, et Édouard Kierlik utilisent l’analogie du yoyo : quand un yoyo est posé au sol et qu’on tire doucement sur la ficelle, il se rapproche en enroulant la ficelle autour de son axe, donc plus vite que le déplacement de la ficelle. Ce comportement ne se produit cependant que si entre le rapport de transmission (le rapport entre le périmètre de l’axe et le périmètre du yoyo) entre le coefficient de frottement du yoyo au sol sont satisfaites.

Sur “Blackbird”, c’est le vent réel arrière qui joue le rôle de la ficelle et l’hélice celui de l’axe. Avec un rapport de transmission entre le périmètre des roues et le pas de l’hélice bien choisi et des coefficients de frottement avec la route et avec l’air suffisants, le véhicule exploite avec une sorte de bras de levier la différence de vitesse relative entre les deux milieux, différence qui reste d’amplitude et de direction constante lorsque le véhicule accélère.

La possibilité théorique d’un tel véhicule avait déjà été établie en 1969 . Il a fallu 40 ans de travail de passionnés pour arriver à dépasser la vitesse du vent sous toutes les allures, mais pour l’instant à terre, et avec des véhicules différents ou nécessitant une adaptation. Qui arrivera à rouler sur un cercle complet plus vite que le vent réel ? Et qui arrivera à le faire sur l’eau ?

Note * ajoutée le 2.3.15 : En , les voiliers modernes comme Oracle peuvent atteindre une supérieure à celle du vent tant en le remontant qu’en le descendant.

Références

" ", 2012
Rick Cavallaro ” 25 June 2012
Bob Dill and Kimball Livingston “ ”, NALSA, Novembre 2012
(slides sur la conception d’un véhicule de la compétiton)
Rick Cavallaro “ ", 12 July 2010
Bob Dill and Kimball Livingston “ ”, NALSA 2010
Rick Cavallaro, “ ”, Wired, 27 August 2010
Rhett Allain ” , Scienceblogs, décembre 2008
Jean-Michel Courty et Édouard Kierlik “ ", Pour la Science N°417 - juillet 2012
Andrew B. Bauer “ ”, 1969

Google trie 1 PetaByte de données !

Sat, 22 Nov 2008 00:00:00 +0000

Pour trier un jeu de 72 cartes, je prends une carte de mon jeu mélangé, et je la pose sur la table. J’en prends une seconde, et je la place sur la table avant ou après la première selon l’ordre que je souhaite. La troisième carte peut aller avant ou après les deux premières, ou être insérée entre les précédentes, et ainsi de suite jusqu’à ce que toutes les cartes soient triées dans l’ordre sur la table, ce qui me prend un peu plus d’une minute.

Un TeraByte pour commencer

Dans le même temps de 68 secondes, , améliorant d’un facteur 3 le obtenu plus tôt cette année. Suivant les règles du “ ” proposé par en 1998, les cartes contenaient 100 bytes, ce qui représente au total un TeraByte, l’équivalent, grosso-modo, d’un annuaire qui inclurait tous les habitants de la planète.

Un TeraByte, c’est la capacité d’un gros disque dur actuel, mais on ne peut y lire ou écrire “que” 300 MegaByte par seconde : il faudrait au mieux une heure pour lire les donner à trier dans une mémoire de 1000 GigaByte (qui n’existe pas…) et une autre heure pour réécrire la liste triée, sans compter le temps du tri proprement dit . Google a donc utilisé 1000 ordinateurs, et au moins autant de disques durs formant une partie du “Google File System” , le gigantesque système de stockage de Google.

Trions en parallèle

Mais comment trier les mêmes données à plusieurs? Reprenons le jeu de 72 cartes et divisions le en 2 tas de 36 cartes mélangées, un pour toi, un pour moi. Nous pourrions placer nos cartes sur une seule ligne sur la table et espérer le faire 2 fois plus vite, mais problème peut survenir si nous voulons simultanément insérer nos cartes au même endroit : comment les placer dans le bon ordre dans ce cas ? Soit on doit alors comparer nos deux cartes et éventuellement les intervertir avant de les insérer, soit on doit convenir d’insérer les cartes à tour de rôle, ce qui ralentit considérablement l’opération. Avec 1000 ordinateurs, on ne va pas s’en sortir beaucoup mieux car c’est visiblement l’accès à la table (=mémoire), unique, qui forme un goulot d’étranglement : pas efficace.

Une autre approche serait que je trie mes 36 cartes et toi tes 36 cartes indépendamment, puis que nous réunissions nos deux piles triées, ce qui est très rapide : je pose mes cartes une à une tant qu’elles viennent avant celle que je vois sur le haut de ta pile, et quand je ne peux plus en poser, tu poses les tiennes tant qu’elles viennent avant celle que je ne pouvais plus poser etc.

On peut faire même mieux en échangeant astucieusement nos cartes plutôt que de reformer une seule pile. Si je trie les carreaux et coeur, et toi les trèfles et pique, plus besoin de reformer une pile unique à la fin : commençons par nous échanger les cartes qui n’ont pas la bonne couleur, puis trions nos tas chacun sur notre table, et voilà !

Animation de l’algorithme de tri "quicksort".

QuickSort

Voilà qui ressemble furieusement à l’ illustré ci-contre : on commence par échanger les données plus grande qu’un pivot (seuil bleu) de la première moitié contre celles plus petites que le seuil de la 2ème moitié. Puis on peut répéter l’opération entre le premier quart et le second d’une part, et le 3ème et le 4ème d’autre part, et ainsi de suite. Si on a un nombre de données qui est une puissance de 2, on peut tout trier par simples échanges, et si on dispose aussi d’un nombre de processeurs qui soit une puissance de deux, on peut répartir le travail très efficacement. A quelques variations près, c’est cet algorithme qui est utilisé pour trier de très grosses quantités de données.

MapReduce

S’il y a un sujet sur lesquel j’aurais du me documenter avant d’ , c’est . Le principe est tout simple :

le programmeur écrit :
- une fonction “map” qui sera appliquée à chaque donnée et produira un résultat intermédiaire
- une fonction “reduce” qui regroupera les résultats intermédiaires de “map” pour produire le résultat final
on donne ces deux fonctions à MapReduce, qui se charge de les exécuter de façon efficace sur beaucoup de donnée sur beaucoup de disques durs et beaucoup d’ordinateurs.

Le MapReduce de Google contient en fait un algorithme de partitionnement qui répartir les résultats des “map” sur les “reduce”, et un algorithme de tri incorporé à la partie “Reduce”, car les fonctions “reduce” peuvent presque toujours être rendues plus efficaces si leurs données sont triées. De ce fait, il semblerait que le record du tri ait été obtenu avec une fonction “map” triviale, et une “reduce” qui ne l’est pas moins!

MapReduce est probablement la plus géniale idée des ingénieurs de Google, et une contribution majeure à l’informatique du futur. Le code n’est pas public, mais . D’autre part la fondation Apache a un , qui se base sur , leur équivalent du Google File System. C’est en utilisant ce système + 1000 lignes de Java seulement que Yahoo! a pu trier le TeraByte en 209 secondes . 3x moins bien que Google, c’est quand même pas mal du tout…

Pour en savoir plus sur MapReduce vous pouvez lire la référence , et/ou :

regarder cette vidéo
consulter ces , plus techniques, avec exemple de code et performances

Et un , un !

Une fois qu’on a un stockage distribué (GFS), un système de traitement parallèle massif (MapReduce) et quelques milliers d’ordinateurs, pourquoi se limiter à trier un TeraByte ? Comme ils le disent dans , Google était “curieux de voir ce qui arrive si on essaie avec un PetaByte”. 1000x plus quoi. Juste pour voir…

Ca a pris 6 heures et 2 minutes, soit 21720 secondes sur 4000 ordinateurs. Ramené au même nombre d’ordinateurs, ça a donc pris “seulement” 1277x plus de temps pour trier 1000x plus de données. C’est assez efficace si l’on considère que la complexité d’un algorithme comme QuickSort est O(N.log N) : sur un seul ordinateur, trier 1000x plus de données prend théoriquement 1000x10 = 10'000x plus de temps. Mais en répartissant le tri sur 4 fois plus d’ordinateurs, on divise ce temps par 4 et en plus on divise par 4 la taille des données : on devrait se retrouver avec 250x8/4 = environ 500x plus de temps. Un facteur 1277 c’peut sembler nettement plus, mais c’est normal en raison des communications supplémentaires entre les ordinateurs.

Le tri du PetaByte pose une autre problème intéressant : les données étaient réparties sur 48'000 disques durs et statistiquement, en 6 heures de calcul, au moins un des disques tombe en panne ! Il faut donc que les données triées soient redondantes pour que l’on puisse remplacer le disque fautif sans interrompre l’exécution du tri, ce qui illustre une autre fonctionnalité remarquable du Google File System …

Et après ?

Peu de groupes au monde disposent d’assez de ressources pour tenter de faire mieux que Google. Mais heureusement, les sont ouverts à d’autres catégories:

la catégorie “penny” consiste à trier le plus de nombres possibles pour un “cout” d’un penny, environ 1.3 centimes d’Euro. Le record actuel a été obtenu sur un PC doté d’un AMD 64 sous Linux, mais surtout de 4 disques dur SATA, qui a trié 1'812'000 enregistrements de 100 bytes en 2.408 secondes
la catégorie “Minute” limite le temps de calcul à 60 secondes. Une machine parallèle du MIT a trié 2.140 Milliards d’enregistrements de 100 bytes toujours en 2007.
la catégorie “ ” me semble plus intéressante au niveau du matériel que du logiciel : il s’agit de trier un maximum de nombres par d’énergie consommée par l’ordinateur. Le record appartient à un ordinateur portable utilisant un processeur intel Mobile Core 2 Duo doté de 13 (!) disques durs, et qui trie environ 11'300 enregistrements par Joule . Si les machines de Google avaient la même efficacité énergiétique, le tri du PetyBytes aurait consommé 0.885 GigaJoule, soit 246KWh. Répartis sur 6 jours, ça donne une puissance de 1.7 KW seulement. . Mais avec 4000 gros PC et 48'000 disques durs, Google est probablemet autour de 20x plus.

Et les spaghetti dans tout ça ?

Je ne peux me résoudre à terminer un article sur le tri sans parler du qui m’avait émerveillé il y a près de 25 ans déjà .

Comme on l’a vu plus haut, les meilleurs algorithmes de tri existant ont une complexité O(N.Log N) : le temps de calcul augmente plus vite que le nombre des données, et malgré quelques progrès dus à la parallélisation, il n’existe pas de tri informatique général* en O(N).

Pourtant, des spaghettis pourraient réussir là où les patinent :

on coupe un spaghetti à une longueur représentant le premier enregistrement à trier ramené à un nombre. On coupe un autre spaghetti à la longueur du second nombre, et ainsi de suite pour tous les nombres, et en un temps O(N) on obtient N spaghettis.
on pose verticalement la botte de spaghettis sur une table plane de façon à tasser tous les spaghettis contre la table. Ceci prend un temps constant, très court et indépendant de N et ne compte donc pas dans la complexité globale
En posant une planche enduite de colle sur la botte, on extrait le spaghetti le plus long, on le mesure, on retransforme le nombre en une donnée qu’on écrit au bas de la liste triée et on recommence N fois, pour chaque spaghetti.

Voilà, les spaghettis permettent de trier nos enregistrements en un temps proportionnel à N ! Trier 1000x plus de spaghettis prendra exactement 1000x plus de temps. En fait, si on disposait d’une machine capable de couper puis de mesurer 150 millions de spaghetti à la seconde, elle aurait égalé la machine de Google sur le TeraByte, et l’aurait battu sur le PetaByte, en 18.8 heures seulement :-)

Plus sérieusement, si on a besoin de trier des objets physiques (des grains de sable, des protéines, des ADN ?), il pourrait être intéressant de ne pas oublier la leçon des spaghetti : certains dispositifs physiques peuvent être plus rapides que les plus puissants ordinateurs

Références

Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung “ ”, 19th ACM Symposium on Operating Systems Principles, Lake George, NY, October, 2003.
Jeffrey Dean and Sanjay Ghemawat, “ ” OSDI'04: Sixth Symposium on Operating System Design and Implementation, San Francisco, CA, December, 2004.
Jim Wyllie, “ ”, IBM, February 4, 1999
Owen O’Malley, “ ”, Yahoo!, May 2008
: records de tri de données depuis 1987
“ “ Datamation, V 31.7, April 1985, pp 112-118.
Eduardo Pinheiro, Wolf-Dietrich Weber and Luiz André Barroso, “ ”, Google Inc. Proceedings of the 5th USENIX Conference on File and Storage Technologies (FAST’07), February 2007.
Suzanne Rivoire et al. “ ",SIGMOD’07, June 11–14, 2007, Beijing, China
Dewdney, A. K.“On the spaghetti computer and other analog gadgets for problem solving”, Scientific American, (June 1984), 250 (6): 19-26
Niall Murphy et al. “ ”, ,2008, Vol 4 nr 1, pages 3-12

Note* : il existe des algorithmes de tri de complexité linéaire sur des données satisfaisant certaines hypothèses, comme Hervé me l’a fait remarquer dans un commentaire