[ODK] Meeting 2019 07 04

ODK Linbox meeting 2019-07-04 CR

Alexis:

• CR des fonctionnalités: tout marche sauf

  • les cas non-carré
  • ou rang-déficients

• Compte rendu des bench

• en séquentiel: meilleur que Dixon std dès que la taille devient suffisement gde (500)
• perfs varient selon le nombre de primes: -> trouver une formule qui dépend de n, b, + éventuellement du nombre de threads)
• impact de la stratégie de parallélisation: pas clair laquelle est la meilleure -> faire d'autres benchs sur des n plus gros (entre 500-1000)

Infographie à faire:

• histogrammes décomposé en section de couleurs différentes pour montrer la décomposition du temps total entre init, lift et crt pour n=500 (800?) b=100, primes =1,2,4,...128 en faire 2: un en séquentiel, un en parallèle (si possible sur luke42 avec 32 ou 64 coeurs).

• 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:

• 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)

• planning -> puis

• benchmarks
• intégration dans le framework général (matrices non-inversibles, rectangulaires, etc)

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

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

-> autotune crash n'est pas reporté -> done

Zhu:

-> note pour plus tard: nettoyer le mécanisme des noefd dans sage vue que ça n'existe plus dans LinBox

PR pour pfgemv-rns

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 next: en vue du D5.14: adresser le point archi hétérogènes ->

1. 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

Pb de hybride: tracer (gdb) le segfault et comprendre d'où il vient (vector<vector<>>[i].resize modifie-t'il le vecteur?)

pour debugger, se limiter au début avec juste la version OMP avant d'attaquer le hybride.

Autres:

• refacto ZRing et IntegerDom -> review en cours

• 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