COP Version 2.0 [FR]

[sonntag benoit]

Hi,

A l'issu de discussions avec Matthieu Herrmann & Dominique Colnet,
Nous avons élargi le modèle COP... vers COP 2.0!!
- Pour la création d'espace parallèle, pas de modification...
(un petit '-' devant 'name' et c'est réglé)

- Pour la transmission inter-espace parallèle :
   * Avant: Vous pouviez transiter :
      - Les Expandeds
      - Les réfs de monde parallèle
      - Les objets non mutable
      (fixé par le programmeur via 'to_non_mutable' ou par défaut comme
       STRING_CONSTANT)

Les pbs: Trop contraignant et vérification à l'exécution de la nature
          "non mutable" d'un objet.

Solution :
   Et bien maintenant, vous transitez ce que vous voulez... :-)

C'est le compilateur qui va vous dire si il y a un pb de cohérence ou non
via un algo "made in" moi :-) (Et à 8h du mat., pour vous dire comment
je suis matinal (enfin, après une nuit blanche bien sure!))

Donc, sécurité statique (à la compile!!!) et non dynamique
(à l'exécution chez le client) !!!

Bon, en gros, le compilo va détecter automatiquement la modification d'une
variable partagée via un nouvel algo d'analyse de flot basé sur l'origine
de la création des objets et la séquence potentielle des modifications.
Alors, ici, ce n'est pas du
"data flow analisis" (ce que l'on faisait un peu),
ni du "type flow analisis" (ce que l'on faisait en particulier),
mais un "truc" ... un truc sympa! :)

Bon, la partie moins cool:
- Les messages d'erreur seront perturbant, il va vous dire que le
parallélisme n'est pas sûre, sur une affectation, qui pour nous, pauvre
humain que nous sommes, n'a rien à voir avec la choucroute...
(Les premiers tests que j'ai fait son assez perturbants)
2 raisons à cela:
   * L'imbrication d'appel sur un gros programme est difficile à appréhender
     dans sa globalité pour nous.
   * Par le fait que sa vérification est statique, il sera légèrement plus
     large que la réalité à l'exécution. (ici, c'est la qualité de l'analyse
     de flow de donnée qu'il va falloir raffiner jour après jour!)

- Il va me falloir de la mémoire, je ne compte pas pouvoir compiler un
programme important (50,000 lignes) en dessous de 1Go de mémoire vive
(mais, je travaille déjà sur une solution moins gourmande).
- Le temps de compilation va aussi en prendre un coup, si nous sommes en
dessous de la minute pour bootstrapper, ce sera un miracle!

La partie méga cool:
- J'ai déjà pensé à des optimisations importantes que l'on peut mettre en
oeuvre avec cette nouvelle "information". Même en dehors du parallélisme.
Et je pense que ce n'est que le commencement...
(Sachant que j'ai encore optimisé le code il y a 2 jours, seulement en
se servant de l'information de mon analyse de type qui date d'il y a 7 ans).

Réalisation:
J'ai commencé, mais ce n'est pas fini :-)
(Comme dirait Farzad ou Dom, il n'y a que 24h dans une day, les shootouts
attendront, ici, l'impact est trop important. C'est du parallélisme
presque sure que l'on peut atteindre.)

PS: Pour les pbs de parallélisme comme le deadlock ou l'incohérence de
donnée inter monde parallèle, j'ai des idées, mais pas de solution pour
l'instant.
Le parallélisme est véritablement un monde à conquérir, mais pas n'importe
comment. En gros, pas comme Java ou C. Je pense vraiment que nous sommes
à l'âge de pierre dans ce domaine.

A+,
Ben.