Discussion :

[transgohan]

Bonjour à toutes et à tous,

travaillant sur un logiciel de benchmark je me suis étonné de certains résultats retournant un temps nul.
J'ai donc pris un cas parmi ceux qui posent problèmes et je tente de lui tirer les vers du nez.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
t1 = get_time();
mem = (char*)malloc(sizeof(size));
t2 = get_time();
free(mem);
t3 = get_time();

En gros voilà ce qui est fait, la fonction get_time() travaille avec le Time Stamp Counter ce qui nous donne une information à la nanoseconde. Du coup je m'étonne assez de voir 0ns pour l'allocation de 1048576 octets...
Les sources sont compilées avec g++ (plus la version sous la main et un peu la flemme de refaire un allez retour jusqu'au labo...) en O2.

Est-ce que je m'avance de trop en supposant que vu que le pointeur n'est pas utilisé le compilateur évince ces instructions durant l'optimisation ?

Cordialement,
xTG.

[Bktero]

As-tu essayé de ne pas mettre d'optimisation pour vérifier cette hypothèse que je trouve crédible ?

[transgohan]

Faudra que j'essaie, c'est juste qu'un peu la flemme ce matin étant donné que la compilation met environ 2h...
Mais sinon je vais rapatrier le code que j'ai besoin pour un test dans un pauvre petit main tout simple.

[phi1981]

La taille de l'allocation n'a que peu d'influence, parce que malloc() ne fait que réserver des adresses, pas de la mémoire. Et dans ton cas, ça signifie peut-être faire un appel à sbrk qui ne fait que déplacer un pointeur.
Si par contre tu t'amuses à ECRIRE sur ces 1048576 octets, tu vas voir que c'est différent.
Je ne me souviens plus le nom de cette fonction C qui fait un peu comme malloc() mais qui initialize la mémoire à 0. Elle devrait être bcp plus lente.

[Bktero]

Tu as essayé l'option -j de make pour accélérer la compilation (si tu utilises make) ? Regarde ici : http://gradot.wordpress.com/2012/01/...pour-compiler/

[pfeuh]

Salut,

Je ne me souviens plus le nom de cette fonction C qui fait un peu comme malloc() mais qui initialize la mémoire à 0.

calloc?

A+

Pfeuh

[plxpy]

Je ne me souviens plus le nom de cette fonction C qui fait un peu comme malloc() mais qui initialize la mémoire à 0.

c'est void *calloc(size_t nmemb, size_t size)

La taille de l'allocation n'a que peu d'influence,...

Je pense que la seule différence est dûe au fait de trouver n bytes contigus disponibles. Si la taille demandée est importante, cela peut prendre un peu plus de temps que si l'on demande l'allocation d'une petite zone, mais sinon ...

[phi1981]

Salut,



calloc?

A+

Pfeuh

Exact, merci.

[transgohan]

Bon j'ai un peu avancé dans les tests.
Avec O2 ou sans on obtient la même chose, à savoir 0ns.

J'ai modifié un peu le code (tout en l'exportant dans un petit main pour ne pas attendre après la compilation ) pour lui faire comprendre que je l'utilise ce maudit pointeur mémoire.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
t1 = get_time();
mem = (char*)malloc(sizeof(size));
t2 = get_time();
mem[0] = 'A';
cout << mem[0] << endl;
free(mem);
t3 = get_time();

Aucune différence cependant, toujours le vide. Que je le lance en monocoeur ou bien sur 8 coeurs fortement multithreadés (et même en forçant tout ça sur un coeur)...

parce que malloc() ne fait que réserver des adresses

C'est justement ce temps là qui m'intéresse, on a une nette différence normalement entre un fonctionnement monocoeur et un multicoeur en raison des accès concurrentiels.

Cela m'étonne quand même que ce temps soit inférieur à la nanoseconde... Je sens que je vais m'enregistrer les différentes valeurs récupérées dans le Timer Stamp Counter pour en avoir le coeur net...

@Bktero > Ah sympatoche, je connaissais pas faudra que je teste.

[matafan]

Ce n'est pas parce que get_time() renvoie un nombre de nanosecondes, qu'il est précis à la nanoseconde.

[kwariz]

Bonjour,

plusieurs remarques :

* le TSC ne semble plus être fiable sur les architectures modernes surtout multiprocessorisées (?) et multithreadées (cf par exemple http://stackoverflow.com/questions/4...-stamp-counter). Obtenir une précision fiable de l'ordre de la nanoseconde me semble irréaliste, mais bon je ne suis pas un pro du benchmarking.

* je suppose que dans ton exemple size est quelquechose qui fait 1Mo et non une variable qui contient 1048576 (auquel cas sizeof te renverra 4 ou 8 suivant l'OS)

* avec ton code légèrement modifié :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
int main()
{
  char* mem = (char*)malloc(1024*1024*1024);
  free(mem);
 
  return 0;
}

si tu desassemble le code avec objdump par exemple
en compilant avec gcc -g : main est généré, malloc et free sont appelés
en compilant avec gcc -g -O2 : main n'est pas généré du tout

* allouer de la mémoire ne coûte rien (ou presque) en temps car, comme le fait remarquer phi1981, du point de vue process, toute la mémoire est disponible. Le gestionnaire de mémoire va mettre une structure à jour (en gros, pour les détails cf http://en.wikipedia.org/wiki/Malloc#Implementations ou ftp://g.oswego.edu/pub/misc/malloc.c)

[transgohan]

Ce n'est pas parce que get_time() renvoie un nombre de nanosecondes, qu'il est précis à la nanoseconde.

Je n'ai jamais dit le contraire. Sauf qu'un malloc de cette taille qui met moins d'une nanoseconde c'est pas possible quand on connait les ordres de grandeurs de sa machine...

J'ai fini par trouver l'erreur, qui venait en fait de la lecture des registres.
Lorsqu'on tente de lire le registre RAX on n'obtient en fait que 32bits du RDTSC. Je n'ai par contre trouvé aucune information expliquant le pourquoi...
Donc du coup j'ai modifié le code de mes collègues pour lire EAX et ADX et les assembler sur 64bits.
Je m'étonne que le problème ne se soit pas posé en deux ans... Ils ont pas du faire tourner ce logiciel sur ce type d'architecture à mon avis.