[ODK] Meeting 2019 05 29

ODK Linbox meeting 2019-05-29 CR

Alexis:

• pb: pour s'intégrer dans le système de lifting container, il faut pouvoir resortir à chaque itération un digit. Mais dans un Dixon multimodulaire, la reconstruction CRT de chaque chiffre n'a pas de sens -> on sort du design actuel. [D1a]

• question synchro: faut-il synchroniser au niveau du fgemm: [D2]

  1. option 1: t Dixon en parallele qui se synchronisent avant un pfgemm fait par tout le monde
  2. option 2: parfor(l) sur les residus, chacun faisant un Dixon sequentiel, fgemm ou fgemv selon si les modulo sont premiers ou RNS

• pour l'instant:

• RNS-dixon ecrit pour des matrices inversibles carrées.
• Ne fait pas encore de fgemm,
• ni les optims RNS.

TODO next:

• confirmer l'absence de bug sur l'algo

• implanter la base RNS pour l'update (en utilisant les FFLAS::rns_double). et un fgemm(RNSDomain)

• Dixon refacto:

• toujours ready for review

• remarques de JG addressées. -> enlève checkBlasPrime, et le if !checkBlasPrime (FFLAS support maintenant les primes >= 2^26-1)

• JG mergera -> L1 done

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

Zhu:

• becnhmarks -> pas bp de speedup sur 32 coeurs -> regarder avec moins de coeur, -> essayer de tuner pour avoir un meilleur speed-up (comprendre où est le blocage). -> paralleliser les finit_rns and fconvert_rns (existe dejà , vérifier si il sont bien appelés)

• SG1:

• mergé #26932 (nvelles releases) dans #27444 (parallel fflas dans sage)

• debug en cours -> a faire

• pb pDet ne set pas se numthreads dans PAR_BLOCK -> soit fflas-1.6.1 avant avant que #26832 soit mergé, soit patch dans #27444. fixé upstream

• wrapper pDet, pRank, pRedudecEchelon, (pSolve)

dans le benchmark ajouter une

• regarder où on passe selon les appels

• fixer si besoin le code pour que les routines passent bien le bon nombre de threads aux appels internes

• mettre les données en tableau (1 tableau par valeur fixée de n et bitsize)