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

新しいコメント
 
ALXIMIKS:

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

ありがとうございます、読んでみます。

イワン・イワノフ
すみません、64ビットで試したらどうでしょうか、mtは32ビットしか回りません。
このような高度に数学的なものは、64ビットで回転させるべきだと素朴に考えていました。
空気力学の計算ソフトを例にとると、32bitでは動きません。
32倍速の方がコンピュータの動作が速いという本筋の議論については、私も知っていますが、それはハードウェアの問題だと思います。

x64に切り替えると、天井が押し戻されるだけで、それほど遠くありません。16Gbのメモリを買いに行かなくて済みます。;)

 
anonymous:

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

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

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

4：ビッグデータを扱えるもの（Matlab/R/など）で顧問外計算をする。

1,2：これは天井を押し返すということで、特定の数字に縛られずに問題を解決したいということですね。

3.問題は、ディスク上のデータ量ではなく、メモリ上のデータ量です。さらに10〜20％圧縮することは可能ですが、やはりそれでは解決しません。

4.今のところ、サンドボックスの中にいたいという希望を抱いています。そうすれば、後のコピー機/同期機が書く必要はない...

ご参加ありがとうございました。

 
komposter:
x64に変えても、天井を押し戻すだけで、それほど遠くありません。もう16Gbのメモリーを買いに行く必要はないですよね？;)

こんなデータをいつも扱っているわけではないのでしょう？x64用に書いて、必要な時にamazonで実行する。また、マイクロインスタンスでは、そこでデバッグを行うことができます。

しかし、この問題にいつも直面するのであれば - 64GBのメモリは約1000円で購入できます、例えば。Corsair Vengeance Pro CMY64GX3M8A2133C11。

アルゴリズムの設計を見直し、データに対して1回のパスで動作するようにする。

p.s. 圧縮したデータをメモリに保存し、処理に必要な時間だけ解凍することも可能です

 
komposter:

ありがとうございます、読ませていただきます。

x64に変えても、天井を押し戻すだけで、それほど遠くありません。もう16GBのメモリーを買いに走ることはないですよね？;)

冗談だろう:-)
私は8ギガで遊べるダミーです。
 

オプション1：ファイルを切り分ける。

オプション2：ファイルを切り分けるだけでなく、システム化する。辞書に載っているような言葉。A "で始まり、"A.txt "を検索する。この方法では、ツリー形式でデータを配置することができます（辞書に似ている：フォルダA、B...フォルダAフォルダAA、ABなど）、検索は非常に高速になります。

 
komposter:

だから、何度も読まないといけないし、それはそれで。

  • とてもとてもゆっくり
  • はドライブの穴をふさいでしまいます。

仮想RAMディスクを使用することで）

を使えば、穴も開かないし、スピードも気に入るはずです。

で、全巻一度に入手可能です。

切り刻んではいけない。切り刻むと作業に適さないからだ。

 
私なら、ファイルをチャンクに切り分け、それぞれのチャンクを必要に応じてロードするようにします（つまり、Dimaが提案するように）。具体的な課題によって異なるので、一概には言えません。でも、この問題は面白いですね、これからもご報告ください。
 
komposter:

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

さて...そのラッパーを通してファイルを読むと、ラッパーはファイルのごく一部をメモリに保持し、読まずに代用します。つまり、ファイルがどのように使用されるかを知っているので、ラッパーは非常に効率的に仕上がるはずです。

komposter

やばい...

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

そうですね......小さい規模での繰り返しを考えていました。

マッピングの使い方は、自分で書くのではなく、windのキャッシュを使うことです。チャンクをロードし、それを読み、それをアンロードする。もしそのチャンクが頻繁に使われるなら、windsはそのチャンクをメモリに残しておくでしょう。

匿名

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

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

あるいは、そう（C）。
 
データ 構造と実行される操作の詳細が分からないと、一般的なアドバイスしかできない。オプションの1つは、生データを1回または数回のパスで、同じ4Gbという小さいサイズのメタデータに変換し（ただしディスクは消去しない）、その後メタデータを扱う（値の集約、あるパラメータによるカットなど）ことである。これがうまくいかない場合は、DBMSにデータをロードしてください。
 
komposter:

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

...

また、このファイルをアーカイバで圧縮した場合、どのくらいの大き さになるのでしょうか（テキストはかなり圧縮されているはずなので）。

123456789...21
新しいコメント
理由: