Il arrive que quelques extraterrestres échouent sur notre planète, qui sans eux serait parfois monotone.
Il y a 20 ans déjà Henry Massalin s'est amusé à créer sa propre machine autour d'un 68000, la quamachine, en l'honneur de son compagnon koala, dont l'onomatopée lui servant de communication se résume souvent à un "Qua !".
Basée à quelques années plus tard sur deux 68030, elle disposait de 256 Ko de Rom, 2,5 Mo de Ram, 4ko de mémoire vidéo, un circuit son maison, et poussait jusqu'à 50 Mhz les deux 68030, grace à un système tordu permettant de multiplexer la mémoire.
Il a créé Synthesis, son propre OS, écrit avec amour en assembleur 68000. Synthesis est conçu comme une sorte de Noyau Mach avec des fonctionalités de type Unix.
Mais le plus intéressant est certainement la capacité de ce noyau à réécrire son code à la volée.
Henry Massalin, créateur de musique électronique souhaitait disposer d'un OS capable de tenir la charge face à ses besoins créatifs, il lui fallait donc un OS sur optimisé, disposant de fonctionalités temps réelles performantes.
L'optimisation de son code repose sur plusieurs idées.
Par exemple, il va détecter un calcul dans lequel un paramètre est un 1 ou un 0, dans ce cas
A=1
B*A+A*A devient B+1, on économise 2 multiplications.
Plus généralement, il propose le raisonnement suivant :
Suposons que l'on doive exécuter une fonction
Fbig(p1,...,pn)
On détecte que p1 est une constante.
On va donc chercher à factoriser Fbig pour écrire
F2(p1) qui renvoi une fonction Fsmall prenant (p2,..., pn) en paramètres.
Le but est que l'on ait pour m exécutions:
Cout(F2)+m*Fsmall(p2,...,pn) < m*Fbig(p1,...,pn)
Autre idée est de supprimer les jump dans le code dus à une structuration de celui-ci basée sur des spécifications. Autrement dit, il inline le code à la volée.
Le noyau est basé sur des sortes d'objets, les Quajets, ces objets ne supportent pas l'héritage, et sont codés en assembleur.
cela permet de structurer le code de belle façon.
La thèse de Massalin resselle aussi une intéressante contribution sur la concurrence et la synchronisation.
Il désirait en effet éviter de désactiver les interruptions à tout bout de champ sur son système, éviter d'utiliser des systèmes à verrou pour gérer la concurence sur sa machine dotée de deux 68030.
J'ai pas encore tout lu et donc compris, je n'en dirai donc pas plus.
Il développe aussi une conception intéressante de l'ordonancement à "gain fin", qui consiste d'après ce que j'ai compris, à ne plus baser l'ordonancement sur le temps, mais sur les interruptions. Ce qui semble être une bonne idée.
Pareil, je n'ai pas lu, je n'en dirai pas plus.
Tout cela n'est pas tout jeune, le document a été écrit en 1992.
Le lien : http://www.cs.columbia.edu/~library/TR-repository/reports/re(...)
Il y a 20 ans déjà Henry Massalin s'est amusé à créer sa propre machine autour d'un 68000, la quamachine, en l'honneur de son compagnon koala, dont l'onomatopée lui servant de communication se résume souvent à un "Qua !".
Basée à quelques années plus tard sur deux 68030, elle disposait de 256 Ko de Rom, 2,5 Mo de Ram, 4ko de mémoire vidéo, un circuit son maison, et poussait jusqu'à 50 Mhz les deux 68030, grace à un système tordu permettant de multiplexer la mémoire.
Il a créé Synthesis, son propre OS, écrit avec amour en assembleur 68000. Synthesis est conçu comme une sorte de Noyau Mach avec des fonctionalités de type Unix.
Mais le plus intéressant est certainement la capacité de ce noyau à réécrire son code à la volée.
Henry Massalin, créateur de musique électronique souhaitait disposer d'un OS capable de tenir la charge face à ses besoins créatifs, il lui fallait donc un OS sur optimisé, disposant de fonctionalités temps réelles performantes.
L'optimisation de son code repose sur plusieurs idées.
Par exemple, il va détecter un calcul dans lequel un paramètre est un 1 ou un 0, dans ce cas
A=1
B*A+A*A devient B+1, on économise 2 multiplications.
Plus généralement, il propose le raisonnement suivant :
Suposons que l'on doive exécuter une fonction
Fbig(p1,...,pn)
On détecte que p1 est une constante.
On va donc chercher à factoriser Fbig pour écrire
F2(p1) qui renvoi une fonction Fsmall prenant (p2,..., pn) en paramètres.
Le but est que l'on ait pour m exécutions:
Cout(F2)+m*Fsmall(p2,...,pn) < m*Fbig(p1,...,pn)
Autre idée est de supprimer les jump dans le code dus à une structuration de celui-ci basée sur des spécifications. Autrement dit, il inline le code à la volée.
Le noyau est basé sur des sortes d'objets, les Quajets, ces objets ne supportent pas l'héritage, et sont codés en assembleur.
cela permet de structurer le code de belle façon.
La thèse de Massalin resselle aussi une intéressante contribution sur la concurrence et la synchronisation.
Il désirait en effet éviter de désactiver les interruptions à tout bout de champ sur son système, éviter d'utiliser des systèmes à verrou pour gérer la concurence sur sa machine dotée de deux 68030.
J'ai pas encore tout lu et donc compris, je n'en dirai donc pas plus.
Il développe aussi une conception intéressante de l'ordonancement à "gain fin", qui consiste d'après ce que j'ai compris, à ne plus baser l'ordonancement sur le temps, mais sur les interruptions. Ce qui semble être une bonne idée.
Pareil, je n'ai pas lu, je n'en dirai pas plus.
Tout cela n'est pas tout jeune, le document a été écrit en 1992.
Le lien : http://www.cs.columbia.edu/~library/TR-repository/reports/re(...)
> Lire le journal (43 commentaires, moyenne: 4,2).
Vous avez demandé le commentaire #839417.
Run by 
Cette page a été générée par Templeet en 0.0624s (dont 0.0066 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Curryfication
En d'autres termes, une fonction F : <x_1, ..., x_n> → y devient une fonction F_1 : x_1 → (<x_2, ..., x_n> → y), soit une fonction prenant un argument et renvoyant une fonction prenant n-1 arguments, etc...
Ca s'appelle la curryfication, et c'est aussi ce qui explique qu'une fonction prenant deux entiers et renvoyant un entier ait usuellement le type int → int → int au lieu de (int * int) → int.
Enfin bref, functional programming rulez da world, rien de nouveau sous le soleil :-)
Vous devriez vraiment visiter Aperture First !
[+] [^]Re: Curryfication
> Enfin bref, functional programming rulez da world, rien de nouveau sous le soleil :-)
Je n'ai pas tout compris. Ça signifie que tu crois que les langages objets ce n'est que de la fumisterie amenée à domination par Sun avec Java et étendue par Microsoft avec C# ?
Citoyen moramarth
[^]Re: Curryfication
Faudrait savoir, tu parles de java/C# ou de langages objet ?
Sinon, smalltalk et ruby sont très chouettes et il y a de bonnes idées dedans, mais ça ne vaut pas haskell ou ocaml niveau élégance ou efficacité.
Quant à java et assimilés, la raison pour laquelle ils sont si répandus est la même que l'explication de pourquoi les chefs sont toujours les gens les plus médiocres.
Vous devriez vraiment visiter Aperture First !
[^]Re: Curryfication
C'est quand même aussi parceque les entreprises qui les soutiennent on réussi à fournir un framework étendu, une bonne documentation et une communauté active....
Le framework en particulier est bien plus important que les qualités intrinséques du langage à l'heure du choix.
[^]Re: Curryfication
*Splotch*
Merci d'avoir marché dedans, j'espère que c'était le pied gauche.
Vous devriez vraiment visiter Aperture First !
[^]Re: Curryfication
Tu prends tout à l'envers.
Java et C# sont des langages médiocres parce qu'ils sont répandus.
smalltak, ocaml ou haskell sont très chouettes parce qu'ils ne sont utilisé que par une poignée de vrai geek (ou nerds, je ne sais plus la différence maintenant)
[^]Re: Curryfication
J'aurais appelé cela de l'évaluation partielle. Une application directe du théorème s-n-m*. Une des 3 caractéristiques des systèmes acceptables de programmation. (les 2 autres caractéristiques étant la Turing-complétude et l'existence d'une fonction universelle).
Bref, ça n'a rien de propre aux langages fonctionnels...
*: fr.wikipedia connait ce théorème sous le nom de "théorème d'itération" de Kleene.
[^]Re: Curryfication
Oui, c'est bien la même idée. Et en effet, s-n-m nous dit que tout langage raisonnable saura le faire, mais on sait aussi qu'on peut jouer à quake sur une machine de Turing. Ce n'est pas pour autant que ce sera facile, ou même raisonnablement possible de le faire.
En l'occurence, pour que la curryfication ait un sens, il faut que les fonctions soient des objets de première classe, sinon tu n'auras même pas la notion de "renvoyer une fonction". D'où les liens avec langages fonctionnels.
Vous devriez vraiment visiter Aperture First !
[^]Re: Curryfication
Currying qui sera possible dans C# 3 actuellement en beta (puisque ça en parle en-dessous)
[^]Re: Curryfication
<troll>alors que dans n'importe quel langage décent, on peut l'ajouter soi-même en 2 minutes</troll>