L'intérêt de ce genre de chose, c'est que pour des grosses boucles, on peut carrément demander au compilateur, de paralélliser le code, et de créer n threads (en lui donnant les primitives de gestion de threads), ce qui permet d'optimiser le code pour n cores...
Je recopie un mail que j'ai envoyé à nicO
"
Imagine qu'on ait un gros calcul de ce type à optimiser sur plusieurs cores.
On peut carrément imaginer de réorganiser la mémoire du tableau in et out de sorte à les couper en n portions, et mettre à la suite les octets de in espacés de n octets, en intercalant in et out
Genre
Zone 1
in[1], out[1],in[n+1],out[n+1]
Zone 2
in[2],out[2],in[n+2],out[n+2]
etc... n fois
Là en fonction des paramètres qu'on lui donne à la compil (lié à l'organisation de la mémoire ainsi que la capacité pour les cores d'y accéder), on lui fait mener, sur n threads, n calculs paralèlles.
On somme à la fin.
Ça torche.
"
Pour généraliser et conclure : un compilateur avec un nombre minimum de primitive , couplé à une bonne analyse de flot permet de remonter très facilement à la sémantique et d'optimiser énormément de choses : on peut imaginer un moteur de pattern matching (reconnaissance de structure dans le graphe du code) et ses règles de transformations.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
C'est vrai que c'est une optimisation de très bas niveau.
On est en train de réfléchir à des optimisations plsu haut niveau, comme le déroulement et la paraléllisation de grosses boucles. Du genre transformer
http://www.haypocalc.com/wiki/Image:Graphe_s%C3%A9quentiel.j(...)
en
http://www.haypocalc.com/wiki/Image:Graphe_paral.jpg
L'intérêt de ce genre de chose, c'est que pour des grosses boucles, on peut carrément demander au compilateur, de paralélliser le code, et de créer n threads (en lui donnant les primitives de gestion de threads), ce qui permet d'optimiser le code pour n cores...
Je recopie un mail que j'ai envoyé à nicO
"
Imagine qu'on ait un gros calcul de ce type à optimiser sur plusieurs cores.
On peut carrément imaginer de réorganiser la mémoire du tableau in et out de sorte à les couper en n portions, et mettre à la suite les octets de in espacés de n octets, en intercalant in et out
Genre
Zone 1
in[1], out[1],in[n+1],out[n+1]
Zone 2
in[2],out[2],in[n+2],out[n+2]
etc... n fois
Là en fonction des paramètres qu'on lui donne à la compil (lié à l'organisation de la mémoire ainsi que la capacité pour les cores d'y accéder), on lui fait mener, sur n threads, n calculs paralèlles.
On somme à la fin.
Ça torche.
"
Pour généraliser et conclure : un compilateur avec un nombre minimum de primitive , couplé à une bonne analyse de flot permet de remonter très facilement à la sémantique et d'optimiser énormément de choses : on peut imaginer un moteur de pattern matching (reconnaissance de structure dans le graphe du code) et ses règles de transformations.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker