COP Version 2.0 [FR]

[Nicolas Boulay]

Les deadlock ce n'est pas justement le principale souci à gérer entre
les threads ?

Serait-il possible d'avoir un git à jour ? Il n'y a toujours pas
l'équivalent de la rc1 dedans. C'est difficile de travailler avec de
vieille version.

Nicolas

Le 29 janvier 2010 02:50, sonntag benoit <sonntag at icps.u-strasbg.fr> a écrit :
> 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.
>
> _______________________________________________
> Lisaac-devel mailing list
> Lisaac-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/lisaac-devel
>