multiplieur

[adud]

Pour avoir une multiplication de matrices un peu plus sérieuse, il faut un programme capable de faire r2 <- r2 + r0*r1 où r0 r1 r2 sont des entiers relatifs (pas de gestion de l'overflow pour l'instant) pour 64 bits

[lephe]

L'addition 64-bits devrait être triviale dans l'archi, pour la multiplication 64 bits vous avez des trucs dans prog/mul*.s :

• Multiplication 64 × 64 → 64 non signée
• Multiplication 64 × 64 → 64 signée
• Multiplication 64 × 64 → 128 signée

[fdedinec]

Le probleme c'est que cette instruction prend plusieurs cycles (jusqu à 7 dans les procs modernes), alors que toutes les instructions qu'on a jusque là se font en 1 cycle.

Mais ce qui prend du temps c'est la mult, donc si on entre d'abord les deux multiplicandes on peut commencer la multiplication le temps d'avoir l'addende

[adud]

Par contre la multiplication fait foirer complètement mes stats : en même temps, si je tire une matrice uniforme sur Z/2^(64)Z, j'ai une probabilité de 1/2 de devoir faire 64 tours de boucle par multipliande. Et comme la multiplication se fait en peu d'opérations, le nombre d'instructions explose. D'un autre côté, si on a une multiplication élémentaire, le calcul matriciel devient un programme très particulier, qui passe son temps à lire et écrire en faisant vraiment très peu de calculs.

[lephe]

D'un autre côté, si on a une multiplication élémentaire, le calcul matriciel devient un programme très particulier, qui passe son temps à lire et écrire en faisant vraiment très peu de calculs.

Dans les sytèmes réels, sauf erreur de ma part, on voit facilement la taille du cache se manifester en fonction de la taille de la matrice (et de l'algo utilisé).

Pour nous en termes de temps, ça ne doit pas changer grand-chose. Après rendre la multiplication plus lente ne va pas forcément arranger le fait qu'une quantité définie de bits doit être échangée avec la mémoire pour réaliser le calcul.

[fdedinec]

Voui. Dans ce papier on compte les bits échangés.