Skip to content

[ODK] Meeting 2019 07 10

Jump to bottom Edit New page
A. Breust edited this page Jul 12, 2019 · 1 revision

ODK Linbox meeting 2019-07-10 CR

Alexis:

  • CR des fonctionnalités: tout marche sauf

    • les cas non-carré
    • ou rang-déficients
    • Pb de design: lifting container vs multi-mod-CRT-RR simultané ... -> faisalbe sans doute avec une classe englobante

  • 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) -> sur 4 coeurs, 32 premiers semble intéressant ? à confirmer sur plus de coeurs (luke42 en cours)
  • 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:

  • DONE: 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: make check sur master avec MPI enabled ---> bugs test-det

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:

MPI+Paladin est meilleur ! https://github.com/linbox-team/linbox/wiki/Validation-through-benchmarks-over-Dahu TODO: comprendre car paladin tout seul est plus lent ???? TODO: tester MPI+Paladin sur 1 seul noeud

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

Pb de hybride: tracer (gdb) le segfault et comprendre d'où il vient (vector<vector<>>[i].resize modifie-t'il le vecteur?) DONE: pb du commentator non THREAD-SAFE --> DISABLE_COMMENTATOR

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

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
Add a custom footer
Add a custom sidebar
Clone this wiki locally