Version imprimable
est plus rapide queCode:
2
3
4
5
6
Pourtant on a une instruction en plus, on appelle le destructeur de JSValue.Code:
2
3
4
5
Comment se fait-il que c'est plus rapide?
Merci
Noe,
Le compilateur a sans doute vu que tu détruis immédiatement le pointeur, et il est probable qu'en fait il ne fasse rien (à vérifier en allant voir le code généré).
D'autre part, réserver toute cette mémoire (2ème code) sans la libérer est une mauvaise idée, même si c'est pour un test (stocker les pointeurs initialisés dans un tableau, et faire une boucle pour les libérer). :)
je pense pas que le compilo n'alloue rien.
car la difference de temps entre les 2 n'est pas enorme.
C'est un peu plus rapide avec le delete, et je comprend pas pourquoi.
c'est peut l'algo du new pour trouver la place memoire ou allouer.
Quand on fait le delete il trouve plus facilement la place ou allouer.
dans le cas ou tu appelles delete, new réutilise le bloc que tu viens juste de libérer, et remet l'objet exactement au meme endroit. c'est basiquement gratuit.
Si tu ne le liberes pas, new doit d'abord allouer la mémoire, ce qui es tres lent
comment est-tu sur que l'os alloue au meme endroit?
Et puis quand tu fait delete, la memoire est liberée, donc doit etre aussi réallouée, non?
Je saisi pas vraiment
je le sais parce que je travaille avec des allocateurs mémoire.
l'allocation de la mémoire se fait en plusieurs etapes. disons que tu veux allouer un bloc. En appelant new, toute une batterie de choses vont etre faites.
new maintient une liste chainée de blocs de memoire libres. lorsque tu alloues, il commence par verifier dans la liste si un bloc de cette taille existe. SI il existe quelque part dans la liste, le bloc est detaché de la liste et renvoyé.
Sinon, si il y a un gros bloc dans la liste, new va d'abord le couper en deux, un bloc de la bonne taille a renvoyer, et un autre bloc (le reste, dont on a pas besoin) qu'il met de coté.
Si il n'y a pas de gros bloc a couper, alors new demande un gros bloc de mémoire a l'OS (mettons un meg). il coupe ce gros bloc de memoire en deux, un tout petit bout de la taille qui convient (pour le donner a l'appelant) et un gros bout qu'il garde pour plus tard, qu'il met dans la liste.
Lorsque tu liberes de la memoire, tout ce que new fait c'est mettre ce bloc en tete de liste, et c'est tout.
Lorsque tu fais donc new, delete, new, delete, etc
potentiellement le premier new va etre tre couteux (il faut demander de la memoire a l'os, couper le bloc, etc)
puis tu liberes ce bloc, qui est placé en tete de liste
puis tu demandes un nouveau bloc de la meme taille, et la c'est fastoche, tu viens de mettre un bloc qui convient exactement en tete de liste. c'est quasi gratuit.
Dans le cas ou tu fais new, new, new, etc
alors le premier new est long, le deuxieme, il coupe un gros bloc, le troisieme, coupe un troisieme bout dans le gros bloc, etc etc, c'est plus couteux que de juste renvoyer la tete de liste.
"Lorsque tu liberes de la memoire, tout ce que new fait c'est mettre ce bloc en tete de liste, et c'est tout."
tu veux dire tout ce que fais delete, c'est bien ca?
oui pardon (chuis fatigué moi...)
ok, donc cela veut dire que faire new, new, new, delete, delete, delete, (ce que fait un garbage collector), est plus lent que new, delete, new, delete, new, delete...
C'est bien intriguant tout ca.
Ben non, c'est pas intriguant, on t'as expliqué comment était géré l'allocateur en interne. Je vois pas ce qu'il reste d'intrigant...
Ce qui est intriguant est que tu peux lire dans des FAQs sur les garbage collector qu'un GC n'est pas plus lent qu'un code ordinaire sans GC, ou la tu fais les new, delete a ta guise.
Et puis la je m'apercois que c'est nécessairement plus lent.
J'ai trouvé un GC sur internet en c++, qui fait GC_NEW au lieu de new, il fait toujours new, new, new, jusqu'a ce qu'on atteigne un seuil, dans ce cas le GC se met en marche et delete tous les pointeurs qu'il trouve.
Cela equivaut a new, new, new, delete, delete, delete.
Tout dépend comment fonctionne la gestion mémoire.
A mon avis fait le test suivant :
1/ Alloue tes 500000 objets d'un coup.
2/ détruit les
3/ fait tes séquences allocations/delete ou allocation seulement puis delete à la fin.
J'ai l'intuition que l'écart entre les 2 va grandement diminuer.
Ensuite, c'est vraiment le mécanisme de gestion mémoire qui joue. Dans un temps assez reculé, j'avais bossé sur une plateforme où les allocations étaient faites dans des pools de blocs préalloués et de taille dépendant du pool avec une liste vers les blocs libres. Faire des séries de new+delete ou faire des série new puis de delete prenait le même temps.
J'en arrive donc a la question suivante, est ce qu'avec un pool 500.000 new est plus rapide que 500.000 new sans pool manager?
La question ne se pose pas vis à vis du new ou du malloc mais de savoir comment fonctionne ton gestionnaire de mémoire.Citation:
Envoyé par kaiser92
oui en fait je pose plein de question car je crée 500.000 objets et je voudrais que ca aille le plus vite possible.
Avoir un pool manager permet d'eviter que la VAS soit fragmentée, mais est-ce que oui ou non cela augmente la vitesse d'allocation plutot que 500.000 new fait avec l'operateur new sans pool.
Merci
Du point de vu du C++, la bonne optimisation que tu pourrais avoir serait d'utiliser un allocateur plus performant si t'es objets sont de petites tailles.
C'est une collection d'objet que t'alloue?
Oui c'est des objets de tres petite taille, ou pourrais-je trouver un bon allocateur tu penses?
C'est gentil de m'aider en tout cas.
Merci
Je connais que celui de loki qui est vraiment bien pensé amha. Il y'a un gain considérable de mémoire sur l'allocation de plein de petits objets. (celui par défaut est pas performant sur les petits objets).
Je crois qu'il y'en a aussi du côté de boost, mais j'avoue ne pas les connaitre et donc ne pas pouvoir les comparer, quelqu'un ayant déjà utilisé la solution de boost pourra peut être t'aider plus.
ps : c'est boost.pool la bibliothèque concernée.
sans aller jusqu'a bidouiller l'allocateur, un new Class[500000] va te créer 500000 objets prets a l'emploi en un minimum de temps, ca ne suffit pas ?
sinon, un gros malloc, et des "placement new" dedans
Justement je lui est demandé si c'est une collection ou si c'est indépendant. Si c'est une collection tout d'un bloc c'est ta solution la plus rapide sans aucun soucis. Sinon il peut utiliser un allocateur adapté (et c'est pas une bidouille)
et qui est loki aujuste? ou pourrais-je trouver son code?
Boost mes managers veulent pas l'utiliser.
Merci
Je craint alors que Loki, ce ne soit pas mieux. Cf pages bibliothèques C++.Citation:
Envoyé par kaiser92
Sinon, j'aurais tendance à regarder la piste de screetch : un new de 500000 ou un reserve/resize de 500000 s'il s'agit d'un vecteur ou d'une liste.
Ouai, surtout que j'ai un chercher dans mes archives de la ML de boost, semblerait que boost.pool est assez contreversé. (notamment au niveau de la complexité de free()), bref pas forcément recommandé. Donc +1 pour tout alloué d'un coup si tu le peux.
Directement inspiré des entrailles de MFC (il y a longtemps...)Mais le small object allocator de Loki est certainement plus universel et dans l'esprit STL.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
A propos des différences de performances constatées dans le tout premier post, le code en apparence plus "complexe" est plus rapide car il utilise beaucoup moins de mémoire (on l'a dit, c'est sans doute la même zone qui est réallouée). Les caches mémoires du processeur peuvent jouer un rôle important.
Salut,
Une question que j'aimerais poser, moi, c'est "as tu réellement besoin en permanence de 500 000 objets :question:"
Je ne dis pas que tu n'en a jamais besoin, loin de là, mais, si tu veux en avoir 500 000 simplement "par sécurité" mais que tu passe une grande partie de ton temps à n'en gérer réellement qu'un nombre largement inférieur (une centaine, voire un millier ou deux), tu gagnera surement (au niveau de l'occupation mémoire, en tout cas) à n'allouer l'espace qu'à la demande, quitte à ce que cela se fasse par coup de 1000 éléments pour éviter les réallocations successives et massives :P
En fait, mon code est une machine virtuelle Javascript.
Donc si dans ton script tu a une boucle avec disons 50.000 elements tu va te retrouver avec un nombre enorme de JSValue crées, disons 150.000.
Je benchmark ma VM avec 500.000 valeurs, il se peut qu'avec un script x ou y un nombre enorme de jsvalue soient créees.
Je ne peux pas savoir a l'avance ce qu'il y a dans le script, donc je dois anticiper une potentielle utilisation enorme de JSValues. Je pense qu'il faut se diriger vers un mempool pour accelerer les allocations, et eviter la fragmentation memoire.
Vous en pensez quoi?
+1 pour le mempool
mais c'est beaucoup plus simple lorsque tu donnes le probleme dans son entier :)
le mempool a beaucoup d'avantages, il est rapide et thread-safe assez facilement (dépendant de la plate-forme, mais sur chaque CPU il y a moyen d'implémenter le mempool en multithread avec des opérations lock-free)
et c'est ce qui te donnera les meilleurs perfs.
Tous tes JSValue font la meme taille ? c'est la condition pour utiliser un mempool.
Je suis d'accord sur le principe d'utiliser un mempool, mais, je suis plus réservé quant à la quantité de données que notre ami s'apprête à lui faire gérer...
En effet, il part du principe de réserver mettons 500 000 éléments "pour être sur d'avoir assez", mais, si on suit le raisonnement jusqu'au bout, alors, pourquoi se "limiter" à 500 000 éléments, et ne pas partir sur 1 000 000, ou un milliard... ou deux :question:
La conséquence ne se fera pas attendre: en fonction du nombre d'éléments choisi à la base et de leur taille, tu risque d'encombrer très sérieusement la mémoire pour... finalement pas grand chose.
J'aurais personnellement tendance à partir sur un pool plus "restreint" (mettons, un petit millier d'éléments), quitte à doubler cette taille lorsque l'on en atteint la limite.
On perdra, sans doute, un peu de temps à retravailler le pool lorsque l'on atteint la limite, mais, au moins, tu n'en viens pas à affréter un cargo entier pour un kilo de cacahuètes :D
tout la est la question, comment savoir la taille du mempool. J ai jamais travailler avec un mempool en fait, je comprend juste le principe, peut etre que quelqu un de plus eclaire pourrait m expliquer comment dans les applications commerciales on gere la taille de ce mempool, en fonction de quel critere, ...
Merci
l'avantage des mempools c'est qu'ils sont redimensionnable.
Le principe, c'est simplement une liste chaînée de blocs libres, on prend la tete quand on en a besoin et on remet en tete de liste lorsqu'on en libère.
Au milieu du programme, si le besoin se fait sentir, rien ne t'empeche de réallouer un gros bloc, le couper en petits morceaux et le mettre dans la liste. Le fait qu'il y a duex gros blocs mémoire au lieu d'un est invisible aux yeux de l'appelant.
Le bout de code proposé en #24 fait exactement ce que tu décris screetch, sauf que la taille des gros blocks est définie une fois pour toute lors de l'instantiation du pooler. Ce code est modifiable afin de pouvoir changer cette taille en cours de route.
ok c est plus clair la, je vais essayer ce code decrit en #24 et voir ce que cela donne.
Merci encore, on avance bien dans ce forum
Tu vas avoir besoin de ceci dans un .h:Et ceça dans un .cpp:Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Aussi, il faut comprendre le template dans #24. C'est assez bas niveau comme code. Il ne fait qu'allouer et désallouer de la mémoire dans le pooler. Il doit rester en vie tant que des fragments de mémoire sont actifs.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
Tu dois par ailleurs gérer toi-même la construction (avec displacement new) et la destruction (via appel explicite de destructeur e.g. p->~Object()) de tes instances de classe.
Solution : utiliser un mempool.
Merci a tous