タグ

programmingとmemoryに関するmanabouのブックマーク (7)

  • Pythonで省メモリに大量の文字列を扱う工夫 - MNTSQ Techブログ

    たくさんの文字列(や離散的な符号列)をメモリに載せないといけないんだけど、いろんな制約があって通常のList[str]では載らない…ということありませんか?(まぁあんまりなさそうですね) たまたまそういうことがあったので、その際に検討した内容をまとめておきます TL;DR メモリをもっと増やしましょう 富豪的に解決できるならいつでもそれが最高です しかし、世の中それでなんとかならんこともたくさんあります 用途があうのであれば専用のデータ構造を採用する 例えばもし共通のprefixやsuffixが存在し、順序に興味がなければtrie treeなどが使えます 例えば、弊社であれば、法人名をメモリに持ちたいなんてときもあります。そういうときに法人名の辞書をtrieで持ったりすることがあります 「株式会社」「一般財団法人」や「銀行」といった共通語がたくさんでてくるのでtrie treeでごりごり削

    Pythonで省メモリに大量の文字列を扱う工夫 - MNTSQ Techブログ
  • メモリのビット反転エラーとセキュリティの話|Rui Ueyama

    ハードウェアのエラーでメモリの内容が化けてしまうことが稀にある。大抵のDRAMエラーはせいぜいプログラムがクラッシュする結果になるだけだが、データ破壊になることもありえるし、悪意のある使い方をすればセキュリティ破りに使うこともできてしまう。ここではメモリエラーとセキュリティの話をしようと思う。 メモリのエラー率は意外なほど高い。データセンターで大規模なマシン群を対象に実際に観測したところ、1年間に1回以上のエラーが発生したDIMMモジュールは全体の8%にのぼったそうだ。DIMM 1枚に数百億個のメモリセルが実装されているといっても、このエラー率はちょっとびっくりするくらい大きな数字ではないだろうか? サーバでは普通はエラー訂正付きのDIMMを使うので1ビットのエラーは問題にならないが、エラー訂正のないコンシューマ機器ではこれは実際的な問題になりえる。 メモリエラーを利用したセキュリティ破り

    メモリのビット反転エラーとセキュリティの話|Rui Ueyama
  • 「プログラミングの常識」を時々見直す必要性について|Rui Ueyama

    自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindowsの初期の頃に設計されたデータ構造には、メモリをバイト単位ででもいいから節約したいという意図の痕跡がいまでも多く見受けられる。DRAMの次に速い記憶装置はHDDだったので、メモリが足りなくなればHDDにデータを保存せざるを得ないのだが、DRAMとHDDのランダムアクセスの速度差は、机の上のの開いているページを見るのと、そのAmazonで注文して到着するのを待つのと同じくらいのスケールで違うの

    「プログラミングの常識」を時々見直す必要性について|Rui Ueyama
  • メモリとスタックとヒープとプログラミング言語 | κeenのHappy Hacκing Blog

    κeenです。 今回の話は別にRustに限ったものではないのですが、よくRustを始めたばかりの人がスタックとヒープが分からないと言っているのをみかけるので少しメモリの話をしますね。 厳密な話というよりは雰囲気を掴んで欲しいという感じです。 メモリは配列 プログラム(プロセス)のメモリには実行するプログラム(機械語)やグローバル変数/定数、関数の引数やローカル変数、その他プログラムで使うデータ領域などを置きます。 プロセスに割り当てられるメモリというのは、1つの巨大なのっぺらな配列みたいなものです。サイズも決まってます。64bit OSなら2^64 byteです。 0 2^64 +--------------- ----+ | | | | | ~~ | | +--------------- ----+ これは仮想的なメモリなので実際の物理メモリに2^64 byteの配列がドンと確保される訳

    メモリとスタックとヒープとプログラミング言語 | κeenのHappy Hacκing Blog
  • データ指向設計

    こんにちは、Cygames Research の多胡です。これまで10年以上コンソールゲーム開発を行ってきていて、最近ではハイエンドゲームエンジンを制作しておりました。Cygames でもハイエンドゲームエンジンの開発に携わることになりました。 ゲームエンジン開発を行う上で重要な考え方にデータ指向設計 (Data Oriented Design) というものがあります。今回はこのデータ指向設計を例を交えながら紹介させていただきます。 背景 データ指向設計の考え方は 2009年頃から有名になりました。 この 30年で CPU の性能は1万倍以上になりましたが、メモリの転送速度は10倍にもなっていません。そのため、プログラムのボトルネックはメモリ帯域となることが多くなりました。ゲームにおいても CPU はほとんどの時間がメモリからのデータの転送待ちになっています。CPU の性能を引き出すために

    データ指向設計
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • プログラミング :: 高速なプログラムを書く為に :: メモリ

    3. メモリ さて、プログラムの最適化で一番重要になってくるのは、メモリです。 はっきり言って、数値計算をするプログラムの一番のボトルネックはメモリアクセスです。 下手なプログラムを書くと、計算時間の殆どがメモリアクセスの時間という事になりかねません。 昔は、メモリの動作速度は高速でその様な事はなかったのですが、 最近では CPU の性能向上が激しく、メモリに追いつき追い越し物凄い差を付けてしまいました。 CPU の動作について行ける様な速さで動作するメインメモリは高価になってしまい作れません。 まあ、値段の問題は抜きにしたとしても、CPU の動作は速すぎます。 これは、少し計算してみれば直ぐに分かります。 今売られている CPU では、コアのクロック周波数が高い物では 4GHz になります。 例えば 4GHz の CPU で 1 clock の間に光が進む距離を考えると、 3×1010

  • 1