(source : wikipedia)
Cela a longtemps été équivalent, mais vous savez que la fréquence de nos puces se heurte à des limites physiques (depuis ~2004 déjà), et que la solution est le "scaling out" : multiplier le nombre d'unités de calcul plutôt que d'en avoir des plus rapides, voie même avoir beaucoup de "coeurs" de (relativement) faible complexité et consommation (donc dissipation thermique). Même sur une machine grand public, il est courant d'avoir 4 ou 8 coeurs, et les CPU de serveurs en affichent parfois 128, sans parler de ce que les labs nous préparent, et cela arrive aujourd'hui également dans les appareils portatifs que sont nos smartphones (le savez-vous ? on peut même téléphoner avec !).
Twitter attire ce matin mon attention sur cet article, qui présente un transistor réalisé en labo avec un seul atome. Si cette technologie va mettre un peu de temps à arriver sur le PC de Mme Michu, c'est la première fois que l'industrie du silicium va se heurter à une limite physique infranchissable. Pendant des années, malgré les difficultés techniques et les effets de l'ultra-miniaturisation, ils ont réussi à descendre toujours plus sous le nanomètre. Cette fois-ci, il n'y aura pas d'échappatoire, et la loi de Moore s'arrêtera brutalement sur un palier définitif.
Je vous laisse imaginer la complexité de réalisation et le niveau de traitement des impuretés qui sont nécessaires à une telle réalisation ...
Note :
Définitif ... peut être pas, car les fondeurs ont plus d'un atout dans leur manche ! Mettre les pistes sur la tranche ou empiler les couches de transistors sur une même puce, à l'assault de la troisième dimension, en prévoyant soigneusement des "canaux" de dissipation des calories produites.
Définitif ... peut être pas, car les fondeurs ont plus d'un atout dans leur manche ! Mettre les pistes sur la tranche ou empiler les couches de transistors sur une même puce, à l'assault de la troisième dimension, en prévoyant soigneusement des "canaux" de dissipation des calories produites.
Et le transistor quantique ? Il pourrait prendre le relais, mais nécessite pas conception un traitement parallèle pour être utile (et sans doute tout un tas d'autres "détails" algorithmiques).
Quoi qu'il en soit, on y échappera pas, il va falloir apprendre à coder "concurrent", et ce n'est pas faute de vous avoir prévenu. Et que faisons nous, encore et toujours : du code purement séquentiel.
Le Cloud (désolé, je baigne un peu dedans en ce moment) n'échappe pas à cette règle : faire du scale-out sur des machines relativement peu puissantes / peu couteuses est très efficace si le problème est correctement pris en charge lors de la conception. Prennes l'exemple de Facebook qui a envisagé de construire un DataCenter basé sur des processeurs ARM, dont le principal intérêt est la très faible consommation.
Fork-join en Java 7, Concurrent collections prévues dans Java 8, Akka nous apporte le paradigme d'acteur pour une nouvelle conception, certains langages alternatifs intègrent de base ces concepts de parallélisme pour une plus grande efficacité.
Et vous ? Avez-vous déjà codé au moins une fois un algorithme de traitement non-séquentiel ? Pour ma part, en regardant en arrière 15 années de développement, ça a été rarissime, et je suis souvent passé pour un dangereux geek en évoquant cette option (peut être aussi pour d'autres raisons). Faites moi part de votre expérience !
1 commentaires:
Bonjour
J'ai passé les 3 premières années de ma vie professionnelle à scripter des levels de jeux vidéos via un langage orienté acteurs, interprété par le moteur de jeu, et mis au point par mon patron de l'époque.
En gros le moteur de jeu, à chaque boucle, exécutait le code de chaque acteur un par un, puis calculait la nouvelle image à afficher. Puis rebelote.
Il y avait un acteur par élément ou entité, concrètement un pour chaque personnage à l'écran, pour chaque décor ou élément de décor, les projectiles, la caméra, etc.
Les acteurs s’exécutaient dans un ordre indéterminé, on pouvait considérer qu'ils tournaient en parallèle. Chacun comportait quand même une zone de code "before" et une "after". On savait juste que le "before" d'un acteur s'exécutait avant le code principal de n'importe quel autre, la partie "after" quand à elle ...vous aurez saisi tout seuls :). Le tout était assorti d'un système de messages entre acteurs.
Je dirais que c'était beaucoup plus simple à appréhender qu'un modèle objet compliqué, d'ailleurs la boite tournait beaucoup grâce aux stagiaires (oups je l'ai pas dit). En contrepartie pas d'héritage, d'encapsulation ou de découplage !
En tout cas j'ai trouvé que cela ce prêtait plutôt bien à l'aspect évènementiel d'un jeu vidéo.
Enregistrer un commentaire