Re: CilkPlus

Oui, il y a des limites avec le Cilk « classique ». Ce qui fait sa force (la notion de fully strict) est en partie sa faiblesse. Cela dit, si j'ai un code fortement récursif (comme le fib de mon exemple), je vais rapidement créer assez de boulot pour le système: chaque fonction appelante est suspendue pour laisser la fonction appelée s'exécuter, mais du coup peut être utilisée par un autre processeur pour continuer le code jusqu'au prochain sync. Donc là où avec OpenMP tu écrirais un truc du genre :

#pragma omp for schedule(static, SEUIL) // SEUIL est le nombre d'itérations à filer par thread
for (int i = 0; i < N; ++i) 
{
 do_something(i);
}

... et en Cilk, on ferait plutôt un truc du genre :

cilk void do_something(int lo, int hi)
{
 if (hi-lo < SEUIL) {
 serial_do_something(lo,hi); // le vrai travail est effectué ici
 } else {
 spawn do_something(lo, hi/2);
 spawn do_something(hi/2, hi);
 sync;
 }
}

L'approche diviser-pour-regner est inhérente à la programmation pour Cilk. Après, avec Cilk++

Le gros « problème » de Cilk (et ses potes Cilk++ et CilkPlus) selon moi, c'est le fait qu'il nécessite de repenser un partie de ses algorithmes, là où avec OpenMP, on peut prendre du code déjà écrit séquentiellement, et « juste » rajouter un pragma au-dessus d'une boucle (en pratique si tu ne fais pas gaffe, tu vas sans doute avoir des perfs pourries, mais ça ne coûte en tout cas pas grand chose d'essayer pour voir, même si tu n'es pas un expert en optimisation de perfs).