impossible de créer un vecteur de 32000 * 32000 short

impossible de créer un vecteur de 32000 * 32000 short - C++ - Programmation

Marsh Posté le 11-04-2012 à 18:22:13    

Bonjour,  
 
J'aimerais créer un vecteur très grand (1 024 000 000 éléments) afin de faire des tests avec beaucoup de données en CUDA.  
Seulement lorsque je déclare mon vecteur comme ceci :  
 

Code :
  1. vector<short> test (32000*32000);


 
j’obtiens une erreur à l’exécution, "std::bad_alloc ... "  
 
Qu'ai-je fait de mauvais ?  

Reply

Marsh Posté le 11-04-2012 à 18:22:13   

Reply

Marsh Posté le 11-04-2012 à 18:41:11    

LOL
Tu retardes, le 1er avril, c'était y'a 10 jours. :o


---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
Reply

Marsh Posté le 11-04-2012 à 18:48:29    

Et du coup ? Pourquoi on peut pas allouer un vecteur de 4GB ? (partant du principe qu'on travaille en 64 bits)

Reply

Marsh Posté le 11-04-2012 à 19:07:46    

hephaestos a écrit :

Et du coup ? Pourquoi on peut pas allouer un vecteur de 4GB ? (partant du principe qu'on travaille en 64 bits)


 
Si je résume, 4 Go = 4 294 967 296 octets
     
je veux allouer 1 024 000 000 shorts donc une taille de 2 octets par elements, la taille que j'aimerais est alors 2 * 1 024 000 000 = 2 048 000 000 octets (2Go)
 
Je ne vois toujours pas où est le problème...

Reply

Marsh Posté le 11-04-2012 à 19:09:38    

Ouais, 2GB pardon.

Reply

Marsh Posté le 11-04-2012 à 19:19:43    

Si t'es sur du Windows 32 bits, la taille max d'un process c'est dans les 2 Go, donc boum. En général, t'en chies même lorsque le process dépasse 1.2 Go.
 
Si c'est sur Unix et/ou du 64 bits en revanche, je sais pas.


---------------
Everyone thinks of changing the world, but no one thinks of changing himself  |  It is the peculiar quality of a fool to perceive the faults of others and to forget his own  |  Early clumsiness is not a verdict, it’s an essential ingredient.
Reply

Marsh Posté le 11-04-2012 à 19:31:50    

Taiche a écrit :

Si t'es sur du Windows 32 bits, la taille max d'un process c'est dans les 2 Go, donc boum. En général, t'en chies même lorsque le process dépasse 1.2 Go.

 

Si c'est sur Unix et/ou du 64 bits en revanche, je sais pas.

 

Je suis sous windows seven en 64 bits, en effet, ça plante au bout d'1 Go approximativement.

 

Bon donc ya pas moyen de faire un énorme tableau ? Il n'existe pas des classes spécifiques pour ça en C++ ?

 

edit : c'est bon j'ai trouvé une pseudo-solution à mon problème : j'utilise des char (1 octets) à la place des short (2 octets) et je peux monter beaucoup plus haut.

Message cité 1 fois
Message édité par freeskate63 le 11-04-2012 à 19:36:04
Reply

Marsh Posté le 11-04-2012 à 19:35:30    

Ben fais-en un plus petit, t'façon si l'OS gère pas plus d'environ 1Go, c'est un cas à écarter, non ?


---------------
Perhaps you don't deserve to breathe
Reply

Marsh Posté le 11-04-2012 à 19:38:52    

freeskate63 a écrit :


edit : c'est bon j'ai trouvé une pseudo-solution à mon problème : j'utilise des char (1 octets) à la place des short (2 octets) et je peux monter beaucoup plus haut.


 
quelque chose me dit que ca va être très précisément deux fois plus haut [:klem3i1]


---------------
last.fm
Reply

Marsh Posté le 11-04-2012 à 19:47:30    

theshockwave a écrit :

 

quelque chose me dit que ca va être très précisément deux fois plus haut [:klem3i1]

 

Logiquement oui  :D

 

Mais il se passe quelque chose de curieux : lorsque je crée un vecteur inférieur ou égale à une taille de 2^30, cela fonctionne (le processus utilise bien 1.002 Go de ram) mais lorsque je passe à 2^31, le processus n'utilise plus que 932 Ko [:canaille] mais le programme ne plante pas

 

edit : j'utilise bien un long int pour définir la taille

 

edit2 : ah non j'ai rien di, ca plante ^^   effectivement theshockwave, c'est bien 2x plus haut

Message cité 1 fois
Message édité par freeskate63 le 11-04-2012 à 19:50:12
Reply

Marsh Posté le 11-04-2012 à 19:47:30   

Reply

Marsh Posté le 11-04-2012 à 19:53:13    

ton build il est 64 ou 32bits ?
si tu fais un build 32bits et que tu veux y rester, active le flag "large address aware" t'aura droit à 4Go sous un win64.

Message cité 1 fois
Message édité par bjone le 11-04-2012 à 19:53:45
Reply

Marsh Posté le 11-04-2012 à 19:55:29    

bjone a écrit :

ton build il est 64 ou 32bits ?
si tu fais un build 32bits et que tu veux y rester, active le flag "large address aware" t'aura droit à 4Go sous un win64.


 
Build 32.  merci pour cette astuce, mais serait-il pas non plus préférable que je mette en build 64 ? (sachant que c'est une appli qui tournera uniquement sur ma machine)

Reply

Marsh Posté le 11-04-2012 à 20:11:22    

C'est une mauvaise habitude d'allouer de si larges plage d'adresses.
Même si ca te semble plus pratique, tu le payeras nécessairement en terme d'accès.
Si tu as besoin de traiter des données adjacentes par exemple, par blocs de n'importe quelle taille, ton processeur te remerciera sans doute de changer ta structure pour que ca évite de mettre son cache en pièces.
 


---------------
last.fm
Reply

Marsh Posté le 11-04-2012 à 21:44:39    

Ouais, et pour faire un test, est-ce que les conditions "beaucoup de données" sont représentatives d'une appli réelle ? J'ai un gros doute.


Message édité par el muchacho le 11-04-2012 à 21:46:17

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
Reply

Marsh Posté le 11-04-2012 à 21:51:12    

Mais un gros doute de quoi ? Tout ce qui est appli vidéo ça peut avoir un sens et, en finance, je parlais encore cet après-midi avec un collègue qui a eu des calculs à effectuer de 1000 scénarios sur 36 dates différentes pour 50 000 deals ; je te laisse faire la multiplication.
Idem pour la génétique ou l'astronomie.


---------------
Everyone thinks of changing the world, but no one thinks of changing himself  |  It is the peculiar quality of a fool to perceive the faults of others and to forget his own  |  Early clumsiness is not a verdict, it’s an essential ingredient.
Reply

Marsh Posté le 11-04-2012 à 21:52:58    

Taiche a écrit :

Mais un gros doute de quoi ? Tout ce qui est appli vidéo ça peut avoir un sens et, en finance, je parlais encore cet après-midi avec un collègue qui a eu des calculs à effectuer de 1000 scénarios sur 36 dates différentes pour 50 000 deals ; je te laisse faire la multiplication.
Idem pour la génétique ou l'astronomie.


Donne moi une seule appli qui alloue 1 ou 2 Go d'un seul coup dans un vecteur. Une seule.  
C'est simple, ça n'existe pas, parce que c'est une très mauvaise idée.


---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
Reply

Marsh Posté le 11-04-2012 à 21:56:46    

Bin écoute t'as raison, t'es champion du monde, les autres sont des cons, tu détiens la vérité :jap:
 
(sinon je le fais dans une appli perso en .Net, c'est pas une allocation d'un coup mais j'ai une grosse List qui contient 4.8M de struct. Mais c'est une très mauvaise idée, fouyaya, surtout n'utilisons pas les 6 ou 8 Go de mémoire qu'ont les PC persos, c'est mal)


---------------
Everyone thinks of changing the world, but no one thinks of changing himself  |  It is the peculiar quality of a fool to perceive the faults of others and to forget his own  |  Early clumsiness is not a verdict, it’s an essential ingredient.
Reply

Marsh Posté le 11-04-2012 à 22:00:25    

Taiche a écrit :

Bin écoute t'as raison, t'es champion du monde, les autres sont des cons, tu détiens la vérité :jap:

 

(sinon je le fais dans une appli perso en .Net, c'est pas une allocation d'un coup mais j'ai une grosse List qui contient 4.8M de struct. Mais c'est une très mauvaise idée, fouyaya, surtout n'utilisons pas les 6 ou 8 Go de mémoire qu'ont les PC persos, c'est mal)


Houla, une Liste, ça n'a RIEN à voir avec un vecteur, parce que ça n'est pas de la mémoire contigüe, c'est une suite de pointeurs, ils pointent n'importe où dans la mémoire, et l'allocation n'a strictement rien à voir avec un malloc.
Pour ce qui est de CUDA, je verrais plutôt de gros transferts de données entre la RAM CPU et la RAM GPU, mais je m'avance bcp parce que je ne me suis pas intéressé à ce type d'architecture, j'extrapole donc :o. En clair, je ferais plutôt des transferts répétés de 64 ou 128 Mo, pas besoin d'allouer des Go.


Message édité par el muchacho le 11-04-2012 à 22:15:04

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
Reply

Marsh Posté le 11-04-2012 à 22:22:17    

Mais tes 64/128 Mo, tu les lis depuis où ? Perso je lis depuis une DB, c'est le gros bouchon en termes de perfs. Je sais pas si t'as vu la vitesse de traitement des GPU, mais tes 64/128 Mo, ils seront consommés beaucoup plus vite qu'ils ne seront lus depuis la base. Déjà avec un CPU quad-core "classique", j'ai testé l'approche de lecture par bouts et qui refile les données à calculer aux autres threads, ba y a starvation. Et ce en tapant sur une base SQLite qui envoie quand même en termes de perfs (32s pour 1 seul thread pour lire 4.8M de lignes avec 4 doubles, 2 strings et 1 int par ligne, sur un CPU 2.67 GHz).
 
Dans tous les cas, ta CG bouffe du tableau de types primitifs en entrée, donc faudra bien les allouer à un moment. Je dis pas que c'est la meilleure solution ou quoi que ce soit, je dis juste que contrairement à ce que tu dis, il ne me semble pas anormal que ce type de dev survienne de plus en plus fréquemment, notamment dans des applis très consommatrices comme on en voit de plus en plus. La parallélisation des tâches + le 64 bits, ça ouvre des portes qu'on n'imaginait pas "récemment" ; la plupart des devs se cantonnent encore à une approche "mono-thread + 1 Go max par process" mais je trouve que c'est con quand on a des serveurs avec 16 ou 32 cores (ou des CG avec des putains de GPU) et 16 Go de RAM.


---------------
Everyone thinks of changing the world, but no one thinks of changing himself  |  It is the peculiar quality of a fool to perceive the faults of others and to forget his own  |  Early clumsiness is not a verdict, it’s an essential ingredient.
Reply

Marsh Posté le 11-04-2012 à 22:24:50    

Non mais il fait un test, il peut les générer à la volée, ses données, c'est pas un problème, ça.


---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
Reply

Marsh Posté le 11-04-2012 à 22:28:35    

Je m'en fous, je répondais à ton assertion

Citation :

est-ce que les conditions "beaucoup de données" sont représentatives d'une appli réelle ? J'ai un gros doute.


Perso je pense que ça peut être représentatif, oui ; une bonne idée j'en sais rien.


---------------
Everyone thinks of changing the world, but no one thinks of changing himself  |  It is the peculiar quality of a fool to perceive the faults of others and to forget his own  |  Early clumsiness is not a verdict, it’s an essential ingredient.
Reply

Marsh Posté le 11-04-2012 à 22:40:04    

el muchacho a écrit :


Donne moi une seule appli qui alloue 1 ou 2 Go d'un seul coup dans un vecteur. Une seule.

 

Ca ne m'étonnerait pas qu'on fasse ça quand on traite des données de clients. Et je ne parle pas de pool de mémoire qui sont redivisés après, parce qu'alors ça m'étonnerait qu'on ne le fasse pas.

 
Citation :

C'est simple, ça n'existe pas, parce que c'est une très mauvaise idée.

 

1G ce n'est jamais que 128 millions d'objets de 8 bytes. C'est quoi ton alternative.


Message édité par Un Programmeur le 11-04-2012 à 22:40:49

---------------
The truth is rarely pure and never simple (Oscar Wilde)
Reply

Marsh Posté le 11-04-2012 à 22:48:22    

En général, des traitements par lots, ou un pool de mémoire, justement.


---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
Reply

Marsh Posté le 11-04-2012 à 22:53:43    

Taiche a écrit :

Mais tes 64/128 Mo, tu les lis depuis où ? Perso je lis depuis une DB, c'est le gros bouchon en termes de perfs. Je sais pas si t'as vu la vitesse de traitement des GPU, mais tes 64/128 Mo, ils seront consommés beaucoup plus vite qu'ils ne seront lus depuis la base. Déjà avec un CPU quad-core "classique", j'ai testé l'approche de lecture par bouts et qui refile les données à calculer aux autres threads, ba y a starvation. Et ce en tapant sur une base SQLite qui envoie quand même en termes de perfs (32s pour 1 seul thread pour lire 4.8M de lignes avec 4 doubles, 2 strings et 1 int par ligne, sur un CPU 2.67 GHz).
 
Dans tous les cas, ta CG bouffe du tableau de types primitifs en entrée, donc faudra bien les allouer à un moment. Je dis pas que c'est la meilleure solution ou quoi que ce soit, je dis juste que contrairement à ce que tu dis, il ne me semble pas anormal que ce type de dev survienne de plus en plus fréquemment, notamment dans des applis très consommatrices comme on en voit de plus en plus. La parallélisation des tâches + le 64 bits, ça ouvre des portes qu'on n'imaginait pas "récemment" ; la plupart des devs se cantonnent encore à une approche "mono-thread + 1 Go max par process" mais je trouve que c'est con quand on a des serveurs avec 16 ou 32 cores (ou des CG avec des putains de GPU) et 16 Go de RAM.


Pour ton exemple, on prend des fermes de calcul et on fait du map/reduce: N serveurs de BD --> M serveurs de calcul et on ajuste N et M pour qu'il n'y ait pas starvation. Sur un seul serveur, tu seras forcément limité par les accès disque.
 
Sinon, pour le problème initial, l'hypothèse qui me semble la plus vraisemblable est celle avancée ici:

Citation :

The address space wouldn't have any issues. But the available memory won't necesarilly fill the address space. AFAIK, memory can't be initially allocated in virtual memory, so if there isn't a way to page out the physical memory to have a 10gb contiguous block, the malloc will fail. Even if this wasn't the case there's only addressable memory in 12gb and 32gb, not the full 64 bit space available. – workmad3


Combien de mémoire physique a le PC ?


Message édité par el muchacho le 11-04-2012 à 23:17:17

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
Reply

Marsh Posté le 11-04-2012 à 23:16:04    

Mais pourquoi ajouter une infra serveur avec les latence réseaux quand on peut juste tout charger en ram ?  
J'ai eu des calcul de simultanéité d'evenements  ( qui ont une durée variables ) a faire en fonction de filtres, et au final, j'ai fini par tout charger en ram : un arbre pour les evenement, et une grose hashmap pou rles données qui vont avec .
Rien que la hasmap dépassait le Go


---------------

Reply

Marsh Posté le 11-04-2012 à 23:21:16    

flo850 a écrit :

Mais pourquoi ajouter une infra serveur avec les latence réseaux quand on peut juste tout charger en ram ?
J'ai eu des calcul de simultanéité d'evenements  ( qui ont une durée variables ) a faire en fonction de filtres, et au final, j'ai fini par tout charger en ram : un arbre pour les evenement, et une grose hashmap pou rles données qui vont avec .
Rien que la hasmap dépassait le Go


Le problème initial, ça n'est pas d'avoir des Go de données en RAM (moi aussi j'ai fait des traitements dépassant le Go de RAM en Python), le problème, c'est de demander des Go de RAM contigüe (parce qu'avec une carte GPU, si on veut vectoriser efficacement, il faut de la RAM contigüe). Et pour ça, je ne suis pas convaincu que tester avec un énorme vecteur soit super pertinent, surtout que manifestement, chez lui ça pose aléatoirement des problèmes d'allocation.
Là, on dérive sur la question s'il faut ou non cacher les données en RAM. Oui bien sûr, on peut. Mais ça n'est pas le pb initial.

Message cité 2 fois
Message édité par el muchacho le 11-04-2012 à 23:24:50

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
Reply

Marsh Posté le 11-04-2012 à 23:56:46    

el muchacho a écrit :


Le problème initial, ça n'est pas d'avoir des Go de données en RAM (moi aussi j'ai fait des traitements dépassant le Go de RAM en Python), le problème, c'est de demander des Go de RAM contigüe (parce qu'avec une carte GPU, si on veut vectoriser efficacement, il faut de la RAM contigüe). Et pour ça, je ne suis pas convaincu que tester avec un énorme vecteur soit super pertinent, surtout que manifestement, chez lui ça pose aléatoirement des problèmes d'allocation.  
Là, on dérive sur la question s'il faut ou non cacher les données en RAM. Oui bien sûr, on peut. Mais ça n'est pas le pb initial.


 
je monte de 1 ...
 
La plupart du temps, les traitements que tu vas faire sur un ensemble de données titanesque, tu peu les faire par sous ensemble.
Et tu peux souvent t'appuyer sur des statistiques sur tes données pour trouver de meilleures façons de les organiser et/ou de les traiter (cf matrices creuses)
 
Et effectivement, parler de problématiques d'accès à une base SQL quand on parle d'allouer de la ram pour alimenter un GPU, c'est complètement hors sujet ...


---------------
last.fm
Reply

Marsh Posté le 12-04-2012 à 08:26:45    

De façon générale, je pense que les très grosses allocations (disons au pifomètre > 10% de la RAM dispo) sont à éviter parce qu'elles dépendent du bon vouloir de l'OS, ce qui rend le programme non portable: je pense qu'une alloc d'1 Go qui passera sous Linux 64 ne passera pas forcément sous un autre OS. Et un malloc qui foire, c'est un programme qui quitte immédiatement (ou il crashe dans la seconde).
Pour ce qui est des langages avec GC, je pense ça rajoute en plus des contraintes sur le GC qui sont assez néfastes parce que le GC passe son temps à déplacer des objets en mémoire. S'il doit pour une raison quelconque de déplacer 1 Go d'un coup, la réponse va s'en ressentir. Bref, pour moi, ça n'est pas un truc à faire.
Maintenant, pour être sûr, il suffit de faire des tests avec des milliards de malloc de diverses tailles de 2 octets à 1Go et de voir ce qui se passe sur chaque OS/config cible.

Message cité 2 fois
Message édité par el muchacho le 12-04-2012 à 08:40:06

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
Reply

Marsh Posté le 12-04-2012 à 08:37:38    

Merci à tous pour vos réponses  :)  
 

el muchacho a écrit :


Le problème initial, ça n'est pas d'avoir des Go de données en RAM (moi aussi j'ai fait des traitements dépassant le Go de RAM en Python), le problème, c'est de demander des Go de RAM contigüe (parce qu'avec une carte GPU, si on veut vectoriser efficacement, il faut de la RAM contigüe).


 
Je ne savais pas que la classe vector en C++ stockais ses éléments de façon contigue.(à vrai dire je ne m'était jamais renseigné, mais pensais que le but de cette classe était justement de permettre le stockage d'un grand nombre d'éléments, de façon plus efficace qu'un tableau)  A ce stade la je n'est même pas besoin d'utiliser la classe vector mais un simple tableau suffirait ?!  
 

theshockwave a écrit :


La plupart du temps, les traitements que tu vas faire sur un ensemble de données titanesque, tu peu les faire par sous ensemble.
Et tu peux souvent t'appuyer sur des statistiques sur tes données pour trouver de meilleures façons de les organiser et/ou de les traiter (cf matrices creuses).


 
Oui c'est ce que j'ai de mieux à faire. Ce que je code c'est l'algorithme de disjktra en cuda afin de comparer les perfs executé sur GPU et CPU. Après quelques renseignements, la librairie cusparse devrais me convenir  [:thesphinx]
 
Voila la raison pour mon immense tableau : il me faut beaucoup, beaucoup d'éléments (de noeuds) pour que le GPU se montre plus efficace que le CPU dans cet algorithme.
 

Reply

Marsh Posté le 12-04-2012 à 08:40:23    

el muchacho a écrit :


Pour ce qui est des langages avec GC, je pense ça rajoute en plus des contraintes sur le GC qui sont assez néfastes parce que le GC passe son temps à déplacer des objets en mémoire. S'il doit pour une raison quelconque de déplacer 1 Go d'un coup, la réponse va s'en ressentir.


 
Pas dans mon cas, la CG copie ses valeurs une seul fois au démarrage du programme. Sinon c'est cler que je n'aurais pas fait comme ça, après avoir fait des mesures de temps de transfert mémoire je me suis vite rendu compte que le transfert de donnée RAM -> GRAM était coûteux

Reply

Marsh Posté le 12-04-2012 à 08:48:51    

Oui, je comprends bien le problème, mais dans ce message je répondais à Taiche, ici GC signifie garbage collector, pas graphic card.
Pour ton test, tu peux p-ê faire une boucle de N mesures en microsecondes et moyenner ?

freeskate63 a écrit :


Je ne savais pas que la classe vector en C++ stockais ses éléments de façon contigue.(à vrai dire je ne m'était jamais renseigné, mais pensais que le but de cette classe était justement de permettre le stockage d'un grand nombre d'éléments, de façon plus efficace qu'un tableau)  A ce stade la je n'est même pas besoin d'utiliser la classe vector mais un simple tableau suffirait ?!


Non, c'est un tableau générique.

Message cité 1 fois
Message édité par el muchacho le 12-04-2012 à 08:51:03

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
Reply

Marsh Posté le 12-04-2012 à 09:04:32    

Par contre une fois que tu passes en CUDA, pense justement à le copier en tant qu'array 2D pour ne pas forcer une allocation en mémoire linéaire dans la mémoire GPU (et si c'est un tableau constant, le lier à une texture 2D pour pouvoir activer les fonctions de cache et accélérer l'accès).

Reply

Marsh Posté le 12-04-2012 à 09:05:43    

el muchacho a écrit :

je répondais à Taiche, ici GC signifie garbage collector, pas graphic card.

Autant pour moi, ça collais parfaitement avec ma problématique  :lol:  

el muchacho a écrit :

Pour ton test, tu peux p-ê faire une boucle de N mesures en microsecondes et moyenner ?


Oui, je peux, et je l'es fait, mais avec des petits tableaux ( environ < 16000*16000 éléments ) le CPU se montre plus performant que le GPU, donc ce n'est pas intéressent. (Mon but étant de montrer le speed-up apporté par le GPU sur ce type d'algorithme)

Reply

Marsh Posté le 12-04-2012 à 09:07:55    


Ah oui bonne remarque Hephaestos, je vais essayer en utilisant la texture memory. Qu'entends-tu par "array 2D" ?  (je suis débutant en CUDA)

Reply

Marsh Posté le 12-04-2012 à 09:23:52    

Au lieu d'allouer la mémoire avec cudaMalloc, tu l'alloues avec cudaMallocArray : http://developer.download.nvidia.c [...] 40349.html

Reply

Marsh Posté le 12-04-2012 à 09:30:53    

freeskate63 a écrit :

Mais il se passe quelque chose de curieux : lorsque je crée un vecteur inférieur ou égale à une taille de 2^30, cela fonctionne (le processus utilise bien 1.002 Go de ram) mais lorsque je passe à 2^31, le processus n'utilise plus que 932 Ko [:canaille] mais le programme ne plante pas
 
edit : j'utilise bien un long int pour définir la taille


 
Vu que la valeur maximale dans un long en 32 bits est de 2^31-1, ca ne m'etonne pas qu'il  y a des problemes.
 

freeskate63 a écrit :


 
Build 32.  merci pour cette astuce, mais serait-il pas non plus préférable que je mette en build 64 ? (sachant que c'est une appli qui tournera uniquement sur ma machine)


 
Si tu as reellement besoin d'allouer autant de memoire -- surtout si c'est de maniere contigue -- il vaut vraisemblablement mieux passer a des executables 64 bits. On peut s'en sortir sans mais je doute que ca en vaille la peine.
 

el muchacho a écrit :

De façon générale, je pense que les très grosses allocations (disons au pifomètre > 10% de la RAM dispo) sont à éviter parce qu'elles dépendent du bon vouloir de l'OS, ce qui rend le programme non portable: je pense qu'une alloc d'1 Go qui passera sous Linux 64 ne passera pas forcément sous un autre OS. Et un malloc qui foire, c'est un programme qui quitte immédiatement (ou il crashe dans la seconde).


 
Approcher de la taille maximale du process, surtout avec des allocations contigues, je veux bien que c'est problematique.
 
Mais limiter les allocations -- meme uniquement les allocations contigues -- a 10% de la RAM pour des process 64 bits, j'ai du mal a voir pourquoi. La pagination est la depuis au moins les annees 70 pour eviter que la contrainte de contiguite dans l'espace virtuel se traduise par la meme contrainte sur la memoire physique (ou la c'est problematique, les systemes qui avaient cette contrainte passaient un temps fou a deplacer les choses pour la respecter). Et un OS 64 bits qui a du mal a donne 1G de memoire a un process 64 bit, je veux des noms.
 

Citation :

Pour ce qui est des langages avec GC, je pense ça rajoute en plus des contraintes sur le GC qui sont assez néfastes parce que le GC passe son temps à déplacer des objets en mémoire. S'il doit pour une raison quelconque de déplacer 1 Go d'un coup, la réponse va s'en ressentir. Bref, pour moi, ça n'est pas un truc à faire.
Maintenant, pour être sûr, il suffit de faire des tests avec des milliards de malloc de diverses tailles de 2 octets à 1Go et de voir ce qui se passe sur chaque OS/config cible.


 
Quand je me suis occupe d'allocateurs, on avait des techniques differentes pour les petites, moyennes et grosses allocations, je ne vois pas pourquoi ca ne se ferait plus. Utiliser un algo qui a besoin de deplacer la memoire avec des allocations d'1G, c'est en effet pas sense.


---------------
The truth is rarely pure and never simple (Oscar Wilde)
Reply

Marsh Posté le 12-04-2012 à 10:25:47    

theshockwave a écrit :

Et effectivement, parler de problématiques d'accès à une base SQL quand on parle d'allouer de la ram pour alimenter un GPU, c'est complètement hors sujet ...


En effet ; je suis parti sur ce sujet car je n'avais pas pris en compte que vector allouait les éléments de façon contigüe, donc je pensais que le problème se situait dans le "aucune application réelle n'a besoin d'allouer autant de mémoire d'un coup", ce qui me semblait très discutable (au passage, much, tu te plains de la façon dont certains membres du forum se foutent de ta gueule, mais on peut pas dire que tu aies été beaucoup plus classe sur ce coup [:dawao]).
 
Ensuite oui, tu peux faire des traitements par sous-ensembles, mais étant donné la puissance (croissante) des GPU et, dans une moindre mesure, l'augmentation du nombre de cores sur les CPU, tu ne sais pas vraiment où tu peux situer la barrière. Pour revenir sur mon exemple, mes 4.8M de lignes représentant grosso-modo 700 Mo en 64 bits sont traitées en parallèle sur 4 cores (+ HT, donc au final 8 processeurs) en 7s environ. Comme c'est des opérations de base (sommes, moyennes, etc...), j'imagine même pas les perfs sur une carte graphique récente :D (je m'intéresse au sujet CUDA et je testerai le bordel sur ma 560 Ti dans les semaines à venir) Dans mon cas, il faut que les données soient ordonnées avant de les charger et, comme dit plus haut, la DB fait goulot d'étranglement. La solution la plus performante que j'ai trouvée pour l'instant est de coller toutes les données en RAM puis de les traiter ensuite ; tout découpage que j'ai tenté a un impact sur les perfs rien qu'avec des CPU pour traiter les données, donc avec des GPU j'imagine même pas. D'où mon "besoin" de tout stocker en bloc en RAM.


---------------
Everyone thinks of changing the world, but no one thinks of changing himself  |  It is the peculiar quality of a fool to perceive the faults of others and to forget his own  |  Early clumsiness is not a verdict, it’s an essential ingredient.
Reply

Marsh Posté le 12-04-2012 à 13:41:07    

Taiche a écrit :


En effet ; je suis parti sur ce sujet car je n'avais pas pris en compte que vector allouait les éléments de façon contigüe, donc je pensais que le problème se situait dans le "aucune application réelle n'a besoin d'allouer autant de mémoire d'un coup", ce qui me semblait très discutable (au passage, much, tu te plains de la façon dont certains membres du forum se foutent de ta gueule, mais on peut pas dire que tu aies été beaucoup plus classe sur ce coup [:dawao]).


C'était pas méchant.:o

Un Programmeur a écrit :


Quand je me suis occupe d'allocateurs, on avait des techniques differentes pour les petites, moyennes et grosses allocations, je ne vois pas pourquoi ca ne se ferait plus. Utiliser un algo qui a besoin de deplacer la memoire avec des allocations d'1G, c'est en effet pas sense.


Je pensais à la phase de compaction des GC, qui consiste à défragmenter la mémoire après avoir fait la collection. Mais pour un vecteur d'un Go, si l'algo n'est pas débile, je suppose qu'on ne touche pas trop aux gros objets. Mais normalement, le choix de déplacement est basé si je ne m'abuse sur l'âge de l'objet et des références vers lui (algos générationnels), pas spécialement sur leur taille.


Message édité par el muchacho le 12-04-2012 à 13:49:57

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed