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 :  
 

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

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

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...

Ouais, 2GB pardon.

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.

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 ?

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

Logiquement oui  

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 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

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)

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.
 

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.

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.

Bin écoute t'as raison, t'es champion du monde, les autres sont des cons, tu détiens la vérité
 
(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 . En clair, je ferais plutôt des transferts répétés de 64 ou 128 Mo, pas besoin d'allouer des Go.

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.

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.

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

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

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.

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

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

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:

Combien de mémoire physique a le PC ?

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.

 
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 ...

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.

Merci à tous pour vos réponses    
 

 
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 ?!  
 

 
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  
 
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.
 

 
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

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 ?

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

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).

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

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)

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)

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

 
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.
 

 
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.
 

 
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.
 

 
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.

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 ).
 
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 (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.

C'était pas méchant.

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.