2010-04-06 18 views
4

J'ai un grand tableau de Boost.MultiIndex environ 10Gb. Afin de réduire la lecture, je pensais qu'il devrait y avoir un moyen de garder les données dans la mémoire et d'autres programmes clients seront en mesure de lire et d'analyser.Boost.MultiIndex: existe-t-il un moyen de partager un objet entre deux processus?

Quelle est la bonne façon de l'organiser?

Le tableau ressemble à:

struct particleID 
    { 
    int   ID;// real ID for particle from Gadget2 file "ID" block 
    unsigned int IDf;// postition in the file 
    particleID(int id,const unsigned int idf):ID(id),IDf(idf){} 
    bool operator<(const particleID& p)const { return ID<p.ID;} 
    unsigned int getByGID()const {return (ID&0x0FFF);}; 

    }; 

struct ID{}; 
struct IDf{}; 
struct IDg{}; 

typedef multi_index_container< 
    particleID, 
    indexed_by< 
     ordered_unique< 
      tag<IDf>, BOOST_MULTI_INDEX_MEMBER(particleID,unsigned int,IDf)>, 
     ordered_non_unique< 
      tag<ID>,BOOST_MULTI_INDEX_MEMBER(particleID,int,ID)>, 
     ordered_non_unique< 
      tag<IDg>,BOOST_MULTI_INDEX_CONST_MEM_FUN(particleID,unsigned int,getByGID)> 
    > 
> particlesID_set; 

Toutes les idées sont les bienvenues.

Cordialement Arman.

EDIT: La RAM et le nombre de cœurs ne sont pas limités. Actuellement, j'ai un 16Gb et 8cores.

Mise à jour

La même question que je posais dans le forum de Boost.Users Je suis une réponse de Joaquín López Muñoz M (développeur de Boost.MultiIndex). L'aswer est Oui. On peut partager le multi_index entre les processus en utilisant Boost.Interprocess. Pour plus de détails, vous pouvez voir dans this link

+0

Ops, le fil de votre lien pointe à été supprimé ... – Pietro

+0

@Pietro: Il est vraiment étrange :( – Arman

Répondre

3

Avez-vous regardé Boost.Interprocess?

+1

Merci, c'est probablement la façon de le faire. Pourriez-vous s'il vous plaît un message un exemple comment partager l'objet avec Boost.Interporcess? merci – Arman

+1

Il faudra écrire un allocateur personnalisé, bien que la bibliothèque puisse le proposer directement (ne pas l'avoir regardé pendant un moment) .Méfiez-vous cependant que quelle que soit la stratégie que vous utilisez (multi threads ou multi processus), vous aurez à synchroniser vos accès –

+0

Pourquoi est-ce que je devrais me soucier de la lecture d'accès? Différents processus peuvent lire de multindex en parallèle.Est-ce pas? – Arman

2

Avez-vous pensé à le couper en morceaux?

L'accès simultané est difficile. Difficile à obtenir, difficile à maintenir, difficile à raisonner. D'autre part, 10 Go est très grand, et je me demandais si vous pouviez regrouper vos données. Gardez la même structure index mais dépêchez-la en 10 (ou plus) objets indépendants en fonction de certaines conditions (le big id par exemple). De cette façon, vous pouvez naturellement traiter chaque segment séparément l'un de l'autre sans avoir à faire face à un accès concurrent en premier lieu.

+0

Les données contiennent 2000 fichiers avec des données, je les lis dans à la mémoire, il s'agit d'une série de données de temps, le multi-index est bien adapté pour trave rse it. Pourquoi pensez-vous que le 10 Go est grand? J'ai un Ram de 16Go. Je me demandais est-il possible de partager le pointeur du tableau juste à un autre processus? L'autre processus est déjà multithread, Il s'exécute sur les différents ID. Je voudrais me débarrasser de la partie lecture qui prend le plus de temps. – Arman

+0

Je n'ai pas été clair. Il n'y a rien de mal à occuper 10 Go de RAM. C'est juste que si vous avez tellement de données, il pourrait être plus facile de les traiter si vous pouviez paralléliser le travail, et il est plus facile de paralléliser si vous pouvez couper les données en morceaux plutôt que de mettre en place un mécanisme de synchronisation.Vous dites que vous avez 8 cœurs, donc ce ne serait pas génial si vous aviez 8 morceaux, chacun étant traité indépendamment des autres, de sorte que les 8 cœurs sont des données croquantes au lieu de seulement 1? Ce serait plus rapide à coup sûr :) –

+0

Oh, oui, vous avez raison! Cette approche est la plus rapide. J'ai un code parallèle qui utilise Boost.Threads pour lire les données et plusieurs outils d'analyse (je dirais des modules). Actuellement le goulot d'étranglement est la lecture, je voudrais garder mes données toujours dans la mémoire et analyser avec beaucoup de discussions. – Arman