[ODK] Meeting 2019 04 24

ODK Linbox meeting 2019-07-24 CR

Alexis:

• retour sur les graphes de temps: -> reglage sur parametre (nb de primes) -> 6xNUM_THREADS pour l'instant: semble quasi optimal sur les data actuelles. A afiner plus tard si besoin.

• merge avec le Dixon classique: -> en cours bientôt fini -> permettrait de traiter les cas non-carré et non-inversible

Infographie à faire:

• trouver un seuil en sequentiel entre dixon vs rnsdixon selon n et bitsize (autotune)
• trouver un critére pour équilibrer init et lift, en utilisant evtlmnt un autotune cf plus haut

Optim: <à faire plus tard si reste du temps>

• essayer de remplacer les invin de l'init (2n^3 pour chaque prime) par des PLUQ (2/3n^3) puis dans le lift remplacer les fgemv par 2 ftrsv (2n^2 vs n^2+n^2)

Objetcif: -> plus de courbes (histo par tranches) -> grandes dimensions -> bp de coeurs (luke42, hpac, etc) -> Clement essaie de voir comment on peut être en accès exclusif sur luke42 s'ici fin aout. -> merge du code dans master

Ouverture: il faudrait ajouter une dimension distribué ou GPU à Dixon pour l'ouverture:

1. Distribué: uniquement le inv par exemple
2. GPU: simplement dpoussiérer fflas+GPU et voir ce que donne la benchsuite de fflas puis le run de DixonCRT avec fflas+GPU.

==> option 2. semble plus réaliste

BUGs dans LinBox master:

• avec MPI enabled ---> bugs test-regression (pb d'interface de CRTMPI)

TODO next: -> TODO: quand nullity>0 -> redraw a new prime

• LinBox error debug contracts: PR en WIP encore en WIP, a voir plus tard.

Zhu:

Pb: pb de config de session -> MPI pur est plus lent (ce qui explique pourquoi hybride était meilleur) -> recréé une nouvelle session -> MPI est à nouveau meilleur que Hybride MPI+Paladin Remarque: sur un noeud: 3 process spawnés (1 master et 2 slaves). Chaque slave est affecté 29 threads (32-3) ===> mauvais nombre de threads, utiliser plutôt NUM_THREADS/(nb slaves) = 16 -> probablement un pb de contention car trop de threads

Le pur MPI en local doit tourner avec NUM_CORES +1 procs (master + numcores

• Confirmer que le hybride s'améliore.
• lancer des runs en dimension moyennes, pour pouvoir extrapoler le temps que mettrait une grosse instance.
• puis essayer une grosse instance (i.e. qui ne passait pas en fullMPI)

Clément regarde si il y effectivemetn une contrainte sur le temps max d'un job (dahut était alors en mode betatest).

slaves)

Ajout de de modes dans FOR1D -> done PR en cours review

Essayer de remplacer les FORBLOCK1D + SYNCH_GROUP + TASK + for loop par un FOR1D (enlever le PAR du PARFOR1D du block #if 0) et confirmer que on ne perd pas en speedup -> pas possible à cause de MODE non-présents dans FOR1D TODO: faire une nouvelle macro (ou modifier FORD1) pour ajouter 1 parametre mode

TODO next: en vue du D5.14: adresser le point archi hétérogènes ->

1. [WIP] remettre en place le code CRAMPI et faire marcher CRA-OMP et hybride CRAMPI-CRAOMP
2. essayer de faire marcher FFLAS sur le dgemm de CUBLAS et voir si on peut sortir quelques bench. Optionel: paladin+cublas (semble bp trop ambitieux) + documenter le README.md avec les instructions pour utiliser CUBLAS

Autres:

• ChineseRemainderOMP : à refactoriser cf LIBOX_USES_OMP, etc.

faire une boucle qui lance num_threads iterations, en parallèle, puis les reconstruit pour retourner un residu modulo le produit des moduli des iterations parallèles.

• JG fflas-ffpack #265 -> test-solve sur retourdest avec openblas en parallel -> USE_THREADS=0 incompatible avec set_num_threads -> CP regarde si c'ets un bug OpenBlAS et reporte