助けてください問題が解決できない、ハードウェアの限界にぶつかる

 

情報量が多い(テキストファイルで20GB程度)。

情報は同じような配列で構成されており、その数は約100万個。

すべての配列を繰り返し見て、計算する必要があります。

まず思いつくのは、ファイルの内容をすべて読み込んで、構造体の配列に詰め、メモリ上で作業することです。

しかし、うまくいかず、次のリサイズでMTは「Memory handler: cannot allocate 5610000 bytes of memory」と悪態をついた。

Dispatcherによると、terminal.exeは3.5GB RAMを使用しています(16物理のうち)。これは、プロセスが4GBしか取得できないからだと推測されます。

始める前に

2%を読む

6%を読む

12%を読む。

15%を読む

みんな...

EAが「メモリが足りない 使用量4007Mb、使用可能量88Mb、合計4095Mb)!!」と言い出した。

しかも、これは必要額の15.3%に過ぎない(将来的にはもっと増やしたい)。


オプション2 - 毎回ファイルを読み込む。必要なピースを探す→構造体に保存→次のピースを読む→結果を比較する→構造体を上書きする。

そして、もし私がこれらのシークエンスを一度経験するとしたら、それはそれでいいと思うのです。しかし、そのたびに少しずつ前にずらしながら何度も通わなければならない。

だから、何度も読まないといけない、ということです。

  • とても、とても遅い。
  • ネジの穴を拭き取る
結果が出るまで数日待つのはちょっと...。

情報量の多さも悔しいが...。10GiGだったら、RAM-diskに移して(実際はメモリに移して)読み放題にします。はい?

それしか思い浮かばないんです。

これらの配列を、その時々に必要な情報のみを含んだ多数の断片になるように再コンパイルしてみたらどうだろう。

また、データを圧縮してみる(すでにできる限りchar型でfloatに変換しています)?でも、せいぜい10%~20%増えるくらいで、体積は一桁減らさないといけないし......。

何かアドバイスはありますか、友人たち?買ってくるよ )

 

komposter:

何かアドバイスはありますか、友人たち?任せてください)

オプションとして...

1.自分でキャッシュを作る この場合、メモリにあるものを自分でコントロールできる。 アルゴリズムがわかっているので、キャッシュを効率的に作ることができる。

2.ファイルのマッピングを使用する。 Windは必要なものをキャッシュし、ハードディスクを消去することはない。

 
TheXpert:

オプションとして...

1.自分でキャッシュを作る。 この場合、すべてのコンテンツを自分で管理することができる。

2. ファイルにマッピングを使用する。vin自身が必要なものをキャッシュするので、ディスクを上書きすることはない。

1.これがキャッシュ...あるいは意味がわからない。必要なチャンクを常に読み続けるという私の選択肢?

2.もう少し詳しく教えてください。マッピングは何をするのか、どのようにアプローチするのか。

 
マッピングのコツがわかってきた。もっとマナを勉強してから鉱山に行こう)
 

ああ、くそ...

32-битные архитектуры (Intel 386, ARM 9) не могут создавать отображения длиной более 4 Гб

同じ卵でも、横から見ると読むスピードは上がるかもしれませんが、グローバルに問題が解決するわけではありません。

 

もう一つのアイデアは、すべてをデータベース(MySQL?)に移して作業することです。データベースは、そのようなボリュームと一定の掘り下げを想定して設計されているということです。

専門家の方はいらっしゃいますか?何か言いたいことがある人は?

 

1) アルゴリズムをやり直す方法はないのでしょうか?ブロック(2GB)をロードし、処理し、結果を保存し(短く)、メモリを解放し、次のブロックをロードする ...。

そして最後に、すべての結果をもう一度処理します。

2) メモリを使った作業が多い場合、ハッシュベースのソリューション、B-tree(およびその修正)、データベースへのオフロードなどが関連します。

 
ALXIMIKS:

1) アルゴリズムをやり直す方法はないのでしょうか?ブロック(2GB)をロードし、処理し、結果を保存し(短く)、メモリを解放し、次のブロックをロードする ...。

そして最後に、すべての結果をもう一度処理します。

2) メモリを使った作業が多い場合、ハッシュベースのソリューション、B-tree(およびその修正)、データベースへのオフロードが関連する。

1.書いたことがある - できるが、データを複数回処理する必要があるのが問題。非常に遅くなります。

2.明日は自分でググってみます、短い説明でありがたいです。

 
komposter:

1.書いたことがある - できるが、データを複数回処理する必要があるのが問題。とても遅いでしょう。

2.明日、自分でググってみますので、簡単な説明を頂けるとありがたいです。

C++で似たような問題とその解決法のバリエーションが議論されているサイトが あったのを思い出した。

Отсортировать строки в файле размером 3GB | FulcrumWeb
Отсортировать строки в файле размером 3GB | FulcrumWeb
  • www.fulcrumweb.com.ua
Необходимо написать алгоритм, который бы смог отсортировать строки в файле большого размера (от 2-х до 4-х Gigabytes). Результатом выполнения должен быть другой файл. За хорошую реализацию гарантированный приз – флешка для хранения таких файлов и, возможно, предложение работы в нашей компании.
 
申し訳ないが、64bitを試すか、mtが32しか動かない場合はどうすればいいのか
このような高度に数学的なものは64ビットで動くはずだと素朴に思っていたのですが
航空機の空気力学の計算を例にとると、32xでは全く動作しません。
32倍速の方がマシンを動かすのが速いという基本的な議論については、私も知っていますが、実際にはハードウェアの問題だと思います。
 

1.当然ながら、x64システムを使用します。

2. Amazon EC2クラウドでより高性能なマシンを借り、その上で計算を行う。

3.圧縮データを使用し、オンザフライでメモリ内に解凍する。実データはストリーム(符号/仮数/指数)に分けると圧縮しやすくなる。12ビットフロートを使えばよい(精度は犠牲になる)。

4.ビッグデータを扱えるもの(Matlab/Rなど)でオフアドバイザーの計算をする。

理由: