Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

temps de calcul sur un multiprocesseur

10 réponses
Avatar
Kevin Denis
Bonjour,

je teste en ce moment des durees de temps de calcul.

Je dispose de machines bi-processeur dual core (donc vues comme 4 CPU).

Si je lance un calcul monoprocesseur sur une machine, je vais obtenir
une duree de mettons 15mn.
Si je lance deux fois ce calcul sur cette machine, (donc 2 CPU sur les
4) le temps de chaque calcul passe a 30mn.
Si je lance 4 fois ce calcul, le temps de chaque calcul va monter a
50mn.

Je ne comprends pas trop ce comportement. Je dois avoir un goulet
d'etranglement, mais ou le trouver?
J'ai deja bloque l'affinite de processus avec taskset, mais le
comportement reste identique.

Merci

--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.

10 réponses

Avatar
Emmanuel Florac
Le Wed, 04 Oct 2006 13:55:58 +0000, Kevin Denis a écrit :


Si je lance un calcul monoprocesseur sur une machine, je vais obtenir
une duree de mettons 15mn.



Sans plus de détails sur le type de calcul, le type et la quantité de
données concernées, impossible de se prononcer. Donnez des détails, et
aussi le résultat de "vmstat" avec 1, 2, et 4 processeurs, ça permettra
d'y voir plus clair.

--
A thing of beauty is a joy forever.
J. Keats.

Ah! Singe débotté, hisse un jouet fort et vert!
Marcel Bénabou.

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Kevin Denis
Le 04-10-2006, Emmanuel Florac a écrit :
Si je lance un calcul monoprocesseur sur une machine, je vais obtenir
une duree de mettons 15mn.



Sans plus de détails sur le type de calcul,



calcul d'ecoulement de fluide en 2d et 3d. C'est en fortran
et je n'ai pas regarde le code. C'est du calcul enormement iteratif.

le type et la quantité de
données concernées, impossible de se prononcer. Donnez des détails, et
aussi le résultat de "vmstat" avec 1, 2, et 4 processeurs, ça permettra
d'y voir plus clair.



un calcul de mandelbrot:
http://magnux.free.fr/gcc/mandelbrot.c
J'ai mis NMAX240 pour allonger le temps de calcul.
taille memoire ~5Mo
lancement unique du calcul: 3mn42
lancement en deux, trois ou 4 exemplaires: 3mn42
Le comportement correspond a ce que j'attends.

Maintenant un calcul d'inversion de matrice methode de gauss-jordan.

Sur une matrice 100x100, pas de difference notable.
Sur une matrice 3000x3000: 208Mo d'occupation RAM pour chaque process
un lancement: 61mn07
deux lancements: 110mn38 et 110mn44
trois et quatre lancements en cours de calcul

le vmstat sur la machine qui fait tourner 2 calculs:
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
3 0 276932 1383648 4648 126132 0 0 0 0 309 554 50 0 50 0
2 0 276932 1383648 4648 126132 0 0 0 0 290 538 50 0 50 0
2 0 276932 1383664 4648 126132 0 0 0 0 313 560 50 0 50 0
2 0 276932 1383664 4648 126132 0 0 0 0 301 547 50 0 50 0
2 0 276932 1383556 4648 126132 0 0 0 492 403 766 50 0 50 0
2 0 276932 1383556 4648 126132 0 0 0 0 316 559 50 0 50 0
2 0 276932 1383556 4648 126132 0 0 0 0 308 561 50 0 50 0
2 0 276932 1383556 4648 126132 0 0 0 14 303 550 50 0 50 0
2 0 276932 1383928 4648 126132 0 0 0 0 318 623 50 0 50 0
2 0 276932 1384152 4648 126132 0 0 0 107 330 693 50 1 49 0
3 0 276932 1383748 4648 126132 0 0 0 0 297 593 50 0 50 0
2 0 276932 1384764 4648 126132 0 0 0 0 337 587 50 0 49 0
2 0 276932 1384764 4648 126132 0 0 0 0 304 561 50 0 50 0
2 0 276932 1384764 4648 126132 0 0 0 22 291 546 50 0 50 0
2 0 276932 1384764 4648 126132 0 0 0 61 322 579 50 0 50 0
2 0 276932 1384764 4648 126132 0 0 0 0 308 554 50 0 50 0
2 0 276932 1384796 4648 126132 0 0 0 0 289 546 50 0 50 0
2 0 276932 1384796 4648 126132 0 0 0 0 310 549 50 0 50 0


En fait mon probleme n'est pas tant de supprimer cet etat de fait, mais
de savoir si c'est la faute de linux (la, il faut corriger) ou si c'est
la faute du materiel. Si c'est la faute du materiel, il faut que je trouve
un banc-test qui donne des points de mesures. Si vous connaissez?
Merci
--
<CRLF>dot<CRLF>

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Emmanuel Florac
Le Fri, 06 Oct 2006 19:17:29 +0000, Kevin Denis a écrit :


Sur une matrice 100x100, pas de difference notable.
Sur une matrice 3000x3000: 208Mo d'occupation RAM pour chaque process



C'est donc assez intensif en RAM, apparemment. Normal, avec des matrices.

un lancement: 61mn07
deux lancements: 110mn38 et 110mn44
trois et quatre lancements en cours de calcul

le vmstat sur la machine qui fait tourner 2 calculs:
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
3 0 276932 1383648 4648 126132 0 0 0 0 309 554 50 0 50 0
2 0 276932 1383648 4648 126132 0 0 0 0 290 538 50 0 50 0
2 0 276932 1383664 4648 126132 0 0 0 0 313 560 50 0 50 0



Le système est idle à 50%, donc il y a deux cpus qui travaillent à fond
et deux qui attendent, c'est bien ce qu'on attend. Cependant, quel est le
type exact de CPU? est-ce un dual core, ou plutôt un P4 HT? Quel noyau
est utilisé?
Je soupçonne que vous utilisez un noyau 2.4 ou un 2.6 assez ancien avec
un processeur HT (HyperThreading), non? Que donne "cat /proc/cpuinfo"?

--
L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas
en avant.
Aït Ahmed.

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Michel Arboi
On Fri Oct 06 2006 at 21:17, Kevin Denis wrote:

calcul d'ecoulement de fluide en 2d et 3d. C'est en fortran
et je n'ai pas regarde le code. C'est du calcul enormement iteratif.



Je soupçonne que le matériel est limité par le débit mémoire.

IIRC, à l'époque héroïque des bipros Pentium, où les procs se
partageaient du cache L2 sur la carte mère, les performances des
programmes très intensifs en mémoire (comprendre accès quasi
aléatoire) s'écroulaient en bipro car tout se passait comme si la
taille du cache L2 était divisée par 2. Par exemple, si le calcul
prenait 5 minutes en monopro, il allait en prendre 2*10 en bipro.

Ici, chaque proc a du cache, mais s'il est débordé, les processeurs se
partageront laborieusement le bus mémoire et on ne gagnera rien en
multipro.

Est-ce qu'il est envisageable (= en un temps raisonnable) de faire
tourner ce logiciel sous cachegrind ?
valgrind --toolÊchegrind

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Emmanuel Florac
Le Sat, 07 Oct 2006 14:15:23 +0000, Michel Arboi a écrit :


Je soupçonne que le matériel est limité par le débit mémoire.



Il faudrait voir ce que donne "vmstat -a" peut-être.

--
In girum imus nocte ecce et consumimur igni

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Kevin Denis
Le 06-10-2006, Emmanuel Florac a écrit :
Sur une matrice 3000x3000: 208Mo d'occupation RAM pour chaque process



C'est donc assez intensif en RAM, apparemment. Normal, avec des matrices.

un lancement: 61mn07
deux lancements: 110mn38 et 110mn44
trois et quatre lancements en cours de calcul





trois lancements:
165mn13, 165mn51, 166mn4
quatre lancements:
194mn56, 207mn50,212mn4,214mn17

Le système est idle à 50%, donc il y a deux cpus qui travaillent à fond
et deux qui attendent, c'est bien ce qu'on attend. Cependant, quel est le
type exact de CPU?



vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 2.80GHz
stepping : 8
cpu MHz : 2800.125
cache size : 2048 KB

est-ce un dual core,



Bi-pro, chacun dual-core, donc 4 CPU "vus" depuis linux.

ou plutôt un P4 HT?



Hyperthreading desactive.

Quel noyau est utilisé?



Linux m1 2.6.16-2-em64t-p4-smp #2 SMP Fri Jun 2 17:35:07 UTC 2006
x86_64 GNU/Linux

Les noyaux 2.6.17 et 18 ont des problemes a priori avec la carte reseau
de la machine.

Que donne "cat /proc/cpuinfo"?



C'est identique au numero de "processor" pres:

processor : 3
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Xeon(TM) CPU 2.80GHz
stepping : 8
cpu MHz : 2800.125
cache size : 2048 KB
physical id : 1
siblings : 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
nx lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm
bogomips : 5600.42
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:

--
Fin

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Emmanuel Florac
Le Mon, 09 Oct 2006 10:51:36 +0000, Kevin Denis a écrit :


Hyperthreading desactive.



Bon, je ne vois que le cache ou la RAM être cause du problème. Je pense
qu'il n'y a qu'un seul cache L2 par processeur, partagé entre les deux
coeurs.
Malheureusement ce n'est pas facile à déterminer... La RAM c'est
de la DDR2 en dual channel, ou autre chose ? Il serait intéressant
d'évaluer la quantité de lectures/écritures en RAM pour la taille de
matrice donnée, on pourrait peut-être trouver si le problème vient d'un
cache miss, ou simplement que le débit du bus mémoire est trop faible.

--
A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders, give
orders, cooperate, act alone, solve equations, analyze a new problem,
pitch manure, program a computer, cook a tasty meal, fight efficiently,
die gallantly. Specialization is for insects.
Robert A. Heinlein

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Kevin Denis
Le 07-10-2006, Michel Arboi a écrit :
Est-ce qu'il est envisageable (= en un temps raisonnable)
de faire tourner ce logiciel sous cachegrind ?
valgrind --toolÊchegrind



La doc dit:
It doesn't account for other process activity (although this is probably
desirable when considering a single program).
donc je risque de ne pas avoir l'info:
-quand je lance un process, que se passe t'il
-quand je lance deux process, ou se situe le goulet d'etranglement.

Quoi qu'il en soit, apres une vingtaine de minutes d'execution:
9560== I refs: 346,583,633,745
9560== I1 misses: 34,816,407
9560== L2i misses: 775
9560== I1 miss rate: 0.01%
9560== L2i miss rate: 0.00%
9560==
9560== D refs: 222,751,980,017 (209,158,880,192 rd + 13,593,099,825 wr)
9560== D1 misses: 25,090,854,354 ( 25,078,591,517 rd + 12,262,837 wr)
9560== L2d misses: 1,566,862,749 ( 1,565,356,173 rd + 1,506,576 wr)
9560== D1 miss rate: 11.2% ( 11.9% + 0.0% )
9560== L2d miss rate: 0.7% ( 0.7% + 0.0% )
9560==
9560== L2 refs: 25,125,670,761 ( 25,113,407,924 rd + 12,262,837 wr)
9560== L2 misses: 1,566,863,524 ( 1,565,356,948 rd + 1,506,576 wr)
9560== L2 miss rate: 0.2% ( 0.2% + 0.0% )

--
Kevin

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Michel Arboi
On Mon Oct 09 2006 at 21:06, Emmanuel Florac wrote:

Bon, je ne vois que le cache ou la RAM être cause du problème. Je pense
qu'il n'y a qu'un seul cache L2 par processeur, partagé entre les deux
coeurs.



http://www.intel.com/cd/channel/reseller/asmo-na/eng/products/server/processors/xeon_proc/149831.htm
me laisse penser le contraire. Ils disent bien "2 MB per core" pour
les proc 64 bits.

On Mon Oct 09 2006 at 22:27, Kevin Denis wrote:

It doesn't account for other process activity (although this is probably
desirable when considering a single program).
donc je risque de ne pas avoir l'info:



Ça aurait pu donner une indication. Si tu avais eu un cache hit
déplorable, on aurait su que tu étais limité par le débit mémoire avec
un processus, donc a fortiori pour plus de deux.

9560== L2d miss rate: 0.7%



Ça me paraît bien faible...
Il y a quelque chose que je ne pige pas avec cachegrind. Je viens
d'écrire un petit programme qui tape plus ou moins au hasard dans la
mémoire, et j'ai un cache hit curieusement élevé. Quand je monte la
taille de l'espace balayé, le cache miss sur L1 grimpe (jusqu'à
environ 50%) mais sur L2, il reste à un niveau ridicule. Mais si on le
fait tourner tout seul, on voit bien le débit mémoire s'écrouler (le
programme calcule le nombre de Mo brassé par seconde)

Kévin, ça vaudrait peut-être le coup que tu essaies ce gadget sur ta
machine multipro. Si en en lançant plusieurs en parallèle avec un
buffer de taille respectable (> 2 Mo) tu n'observes pas le même
phénomène qu'avec ton programme, c'est que l'hypothèse sur le goulet
d'étranglement au niveau de la mémoire est fausse.


Le programme prend deux arguments. Le premier est la taille qu'on veut
allouer, le second le nombre de passe que l'on fait sur le buffer.

-----------------------------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <sys/time.h>

int
main(int argc, char * argv[])
{
int sz = atoi(argv[1]), n = atoi(argv[2]), i, j, x = 0;
unsigned char *p = malloc(sz);
struct timeval t1, t2;

for (i = 0; i < sz; i ++) p[i] = i & 0xFF;

printf("n = %d * %d = %dn", sz, n, sz * n);

#ifdef TEST_RAND48
srand48(time(NULL));
#endif
gettimeofday(&t1, NULL);
for (i = 0; i < n; i ++)
for (j =0; j < sz; j ++)
{
#ifndef TEST_RAND48
x += 8193;
while (x > sz) x -= sz;
p[x] ++;
#else
p[lrand48() % sz] ++;
#endif
}

gettimeofday(&t2, NULL);
printf("%g Mo / sn",
(double) sz * n / (t2.tv_sec - t1.tv_sec + 1e-6 * (t2.tv_usec - t1.tv_usec)) / (1024. * 1024.));
return 0;
}
-----------------------------------------------------------------------------

--
PGP key ID : 0x0BBABA91 - 0x1320924F0BBABA91
Fingerprint: 1048 B09B EEAF 20AA F645 2E1A 1320 924F 0BBA BA91

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Kevin Denis
Le 10-10-2006, Michel Arboi a écrit :
Kévin, ça vaudrait peut-être le coup que tu essaies ce gadget sur ta
machine multipro. Si en en lançant plusieurs en parallèle avec un
buffer de taille respectable (> 2 Mo) tu n'observes pas le même
phénomène qu'avec ton programme, c'est que l'hypothèse sur le goulet
d'étranglement au niveau de la mémoire est fausse.



Je constate le cas.

Le programme prend deux arguments. Le premier est la taille qu'on veut
allouer, le second le nombre de passe que l'on fait sur le buffer.



suite a quelques mails avec MA, j'ajoute pour ceux que ca interesse:

Il est conseille de compiler avec
gcc -DTEST_RAND48 -O3 -g -Wall essai.c -o essai

Le programme sans l'option RAND48 donne des resultats _tres_ differents
pour des tailles de tableaux a un octet pres.
--
"Aya de Yopougon" M.Abouet, C.Oubrerie.

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.