Besoin d'aide ! Je ne peux pas résoudre le problème, je me heurte à des limitations matérielles. - page 2

Nouveau commentaire
 
ALXIMIKS:

Je me suis souvenu d'un site où un problème similaire et des variantes de sa solution en C++ étaient discutés.

Merci, je vais le lire.

Ivan Ivanov:
Je suis désolé, et si j'essaie 64 bit ou mt ne tournera que 32
Je pensais naïvement qu'une chose aussi hautement mathématique devait tourner sur 64 bits.
Prenez les logiciels de calcul aérodynamique, ils ne fonctionnent pas sur 32 bits.
en ce qui concerne l'argument principal selon lequel le 32x fait tourner l'ordinateur plus vite, je sais, mais c'est un problème de matériel, je pense.

Le passage à x64 ne fait que repousser le plafond, et pas très loin. Je n'aurai pas à courir acheter 16 Go de mémoire. ;)

 
anonymous:

1. Naturellement, utilisez un système x64.

2. louer une machine plus puissante dans le nuage Amazon EC2 et effectuer les calculs sur celle-ci.

3. utiliser des données compressées, décompresser en mémoire à la volée. Les données réelles sont mieux compressées si vous les divisez en flux (signe/mantisse/exposant) ; vous pouvez utiliser des flottants 12 bits (au détriment de la précision).

4 : faire un calcul hors conseiller avec quelque chose qui peut gérer de grandes données (Matlab/R/etc).

1,2 : il s'agit de repousser le plafond, et vous voulez résoudre le problème sans être lié à un chiffre spécifique.

3. Le problème n'est pas la quantité de données sur le disque, mais plutôt la quantité en mémoire. Je peux le compresser de 10 à 20 % supplémentaires, mais là encore, cela ne résoudra pas le problème.

4. Je garde l'espoir de rester dans le bac à sable pour le moment. Pour que les copieurs/synchronisateurs ultérieurs n'aient pas à écrire...

Merci de votre participation !

 
komposter:
Passer en x64 ne ferait que repousser le plafond, et pas très loin. Je n'ai pas besoin de courir acheter 16 Go de mémoire supplémentaires, n'est-ce pas ? ;)

Vous ne travaillez pas tout le temps avec ce genre de données, n'est-ce pas ? Écrivez pour x64 et exécutez-la sur amazon quand c'est nécessaire. Vous pouvez également y déboguer sur une micro instance.

Si, toutefois, vous êtes confronté à ce problème en permanence, vous pouvez acheter une mémoire de 64 Go pour environ 1 000 dollars, par exemple. Corsair Vengeance Pro CMY64GX3M8A2133C11.

soit repenser la conception de l'algorithme afin qu'il puisse fonctionner en un seul passage sur les données

p.s. Vous pouvez également stocker des données compressées en mémoire, et les décompresser si nécessaire, le temps de les traiter.

 
komposter:

Merci, je vais le lire.

Passer en x64 ne fera que repousser le plafond, et pas très loin. Je ne peux pas courir acheter 16 Go de mémoire supplémentaires, n'est-ce pas ? ;)

Vous devez vous moquer de moi :-)
je suis un idiot avec 8gig pour jouer avec
 

Option 1 : Coupez le dossier en morceaux.

Option 2 : Découper le dossier en morceaux, mais aussi le systématiser. Comme un mot dans le dictionnaire. Commence par "A" et cherche "A.txt". De cette façon, vous pouvez organiser les données sous forme d'arbre (similaire au dictionnaire : dossiers A, B... dans le dossier A dossiers AA, AB, etc.), la recherche sera très rapide.

 
komposter:

Donc tu devras lire beaucoup de fois, et c'est.. :

  • très, très lentement.
  • fera un trou dans le lecteur.

un disque RAM virtuel sera utile ;)

et vous n'aurez pas de trou et vous aimerez la vitesse.

et l'ensemble du volume est disponible immédiatement.

ne pas couper en morceaux, car les morceaux ne conviennent pas pour la tâche à accomplir

 
J'essaierais de découper le fichier en morceaux et de charger chaque morceau en fonction des besoins (c'est-à-dire comme le suggère Dima). C'est difficile à dire exactement, car cela dépend de la tâche spécifique. Mais le problème est intéressant, tenez-moi au courant de vos découvertes.
 
komposter:

1. C'est le cache... Ou je ne comprends pas ce que vous voulez dire. Mon option de lire constamment les morceaux nécessaires ?

Eh bien... lire le fichier à travers son wrapper, le wrapper va garder une petite partie du fichier en mémoire et le substituer sans le lire. Je veux dire que vous savez comment le fichier est utilisé, donc le wrapper devrait être assez efficace.

komposter:

Oh, merde...

Les mêmes œufs, mais de côté. La lecture peut s'accélérer, mais elle ne résout pas le problème de manière globale.

Je pensais à des actions répétitives à petite échelle.

L'utilisation du mapping consiste à utiliser le cache de Wind au lieu d'écrire le vôtre. Charger le morceau, le lire, le décharger. Si le morceau est utilisé souvent, les vents le garderont en mémoire.

anonyme:

3. utiliser des données compressées, décompresser à la volée. Les données réelles sont mieux compressées si vous les divisez en flux (signe/mantisse/exposant) ; vous pouvez utiliser des flottants 12 bits (au détriment de la précision).

4. faire un calcul hors conseiller avec quelque chose qui peut gérer de grosses données (Matlab/R/etc).

Ou alors (c).
 
Sans connaître les spécificités de la structure de données et des opérations à effectuer, il n'est possible de donner que des conseils généraux. L'une des options consiste à convertir les données brutes en métadonnées de plus petite taille - les mêmes 4 Go - en une ou plusieurs passes (mais sans effacer le disque), puis à travailler avec les métadonnées (valeurs agrégées, coupes par un paramètre quelconque, etc.). Si cela ne fonctionne pas, chargez les données dans le SGBD.
 
komposter:

Il y a une grande quantité d'informations (environ 20 Go dans un fichier texte).

...

Et si ce fichier est compressé avec un archiveur, quelle est sa taille (car le texte doit être très bien compressé) ?

123456789...21
Nouveau commentaire