C#におけるヒープVSスタック問題、あるいはUnityにおけるスクリプト高速化。 - Radium Software
個人的にC#はグルー言語であるという認識が強くて、パフォーマンスを意識したプログラミングの経験が無い。しかしUnityのスクリプトをC#で書いていると、そこを意識しなくてはならないケースに出くわすことがある。 最近あったのは、テンポラリな配列のアロケーションが大きなオーバーヘッドを生み出しているという状況だった。これは結局、配列の使用をやめてstructのメンバー変数にパックするよう変更したところ、パフォーマンスは著しく改善された。言い換えれば、テンポラリオブジェクトの所在をヒープ上からスタック上へと移すことによってオーバーヘッドが解消された、という格好だ。 問題となっていたのは、まあざっくりとこんな感じの、ゲームステートを保持するクラスだった。 public class State { byte[] cells = new byte[16]; public State() {} publ
平方根のアルゴリズム
平方根である。sqrtである。私の数学知識は非常に乏しく、かろうじて平方根の何たるかを解するばかりであるが、ふと、平方根を計算するアルゴリズムが知りたくなった。理由は、constexprなsqrtを実装してみたくなったからだ。 日本語では、いい情報がWeb上に存在しないので、ここに書いておく次第。この説明は、私のように数学の知識を持たない人間にも理解できるはずである。 ここで使うのは、バビロニア人の方法（Babylonian method）と呼ばれている、歴史あるアルゴリズムである。この方法は、手動でも、プログラミングでも、非常に簡単に計算できる、大変便利で汎用的なアルゴリズムである。しかも、速度もそれほど遅くない。 √Sに対して、 任意の正の整数を初期値X0と定める（できるだけ平方根に近い値が望ましい） Xn+1を、Xnと S / Xnの平均値とする（平均値は相加平均で求める） 必要な精
アンダーバー命名規則
■_ なぜRを使うのか? Why Use R? | (R news & tutorials) Why Use R? December 14, 2010 By Joshua Ulrich I use R very frequently and take for granted much that it has to offer. I forget how R is different from similar tools, so I have trouble communicating the benefits of using R. The goal of this post is to highlight R's main strengths, but first... my story. How I got started with R わたしが R をどのように始めたか I was
開発メモ: トップNソートの検討
上位N件をソートした状態で取り出すという、いわゆる「トップNソート」の効率的な実装について検討してみた。 背景 データベースに対して、ある順序でソートした時の最初の何件かが欲しいというクエリを投げることはよくあるだろう。SNSで言えば、誰かのコンテンツの最新10件を表示するとかいう場合だ。SQLだと "ORDER BY xxx LIMIT yyy" とかいう感じ。同じような操作は全文検索システムのスコアリングでも定番である。俺もよく自分で実装するわけだが、その度に適当な試行錯誤をして時間がもったいないので、今回は入念に調べて決定版を出そうじゃないか。 全体をソートして上位を取り出せば目的は満たせるのだが、それだと無駄な計算が多い。100万件の中から上位10件だけ欲しい場合に、残りの99万9990件まで律儀にソートする必要はない。ということで、上位N件をソートして取り出すという「トップNソー
階乗を求める - d.y.d.
22:56 10/09/04 階乗を求める 去年聞いた中で、私が一番感動した式の話。 k! = limn→∞ nk / nCk kの階乗は、「nのk乗 ÷ n個のものからk個選ぶ組み合わせの数」という式で n を無限に大きくしていったときの収束先、である。 特に難しい証明が要るとかではなくて、nCk = n(n-1)(n-2)...(n-k+1) / k! であることを使うと、 limn→∞ nk / nCk = limn→∞ nk k! / n(n-1)(n-2)...(n-k+1) で、n が k に比べて十分大きければ n も n-k+1 もほとんど同じ値なので、 分子も分母もだいたい n を k 個かけているわけでして、 その部分が相殺して、k! が残るという寸法。 （厳密な表現ではないので、気になる人は厳密に証明してください。） 実装 と、この式自体はそんなに不思議ではないのです
【レポート】GNU grepが高速な理由 | エンタープライズ | マイコミジャーナル
FreeBSD - The Power To Serve why GNU grep is fast (なぜGNU grepは高速なのか)といったタイトルの興味深いメールがFreeBSD開発者メーリングリストに投函された。メールを出したのはGNU grepのオリジナル開発者であるMike Haertel氏。Mike Haertel氏はFreeBSDユーザでもあり、FreeBSD開発者メーリングリストで興味深いやりとりがあったため、このメールを流したとしている。Mike Haertel氏の紹介する内容はgrep(1)の実装のみならず、高速な文字列処理を実現するひとつの方法として参考になる。紹介されているGNU grep高速さの秘訣は次のとおり。 GNU grepは入力バイトのすべてをチェックするようなことは避けている。 GNU grepはバイトごとに適用する操作を極力最小限に減らしている。 G
本当に1.5倍のほうがメモリ効率がよいのか - inamori’s diary
C++のstd::vectorにpush_backしていくと、ある領域を確保して、それを超えそうになったらまたある程度ゆとりのある領域を確保するという機構になっています。 ２倍だけじゃない - d.y.d. にまとめてありますが、std::vectorや類似するコンテナは2倍ずつ領域を大きくしていくのかと思いきや、1.5倍というのも多いんですね。実際にVC10 beta2で動かしてみると、 #include <iostream> #include <vector> int main() { std::vector<int> v; for(int i = 0; i < 100; i++) { const std::vector<int>::size_type old_cap = v.capacity(); v.push_back(i); const std::vector<int>::siz
続:Haskellのfibが遅い件 - 西尾泰和のはてなダイアリー
とても勉強になる流れなのでとりあえずざっくりとまとめる Haskellの「fib = 1:1:zipWith (+) fib (tail fib)」はとても遅い Haskellの有名なfibの定義は素朴なループでの定義に比べて格段に遅く、O(n^2.6)くらいの実行時間がかかり、N = 100000でPythonにすら負ける Togetter - 「Haskellの「fib = 1:1:zipWith (+) fib (tail fib)」はとても遅い件」 Integerの足し算のコストとかも絡んでくるのでややこしいという話など fib = 1 : 1 : zipWith (+) fib (tail fib) が遅いかどうかは、使い方に依存する - www.kotha.netの裏 fibを先頭から順に使って行った場合(例:sum (take 300000 fib))の方が、fib !! 3
d.y.d. 2倍だけじゃない
10:01 10/07/20 それでも２倍だ 先日のvectorの伸長度合いの記事に関して 本当に1.5倍のほうがメモリ効率がよいのか という反応をいただきました。とても興味深い。みんな読みましょう。 自分の理解メモ： 「再利用ができるから嬉しい」等の議論をするなら、 今までに確保したメモリ (1 + r^1 + ... + r^k) のうち、 有効に使えてるメモリ r^{k-1} (バッファ拡大直後) や r^k (次のバッファ拡大直前) の割合で評価してみようじゃないかという。 まず簡単のために再利用をしない場合を考えると、この割合はそれぞれ (r-1)/r^2、 (r-1)/r になります（途中計算略）。 この利用率が最悪になる瞬間 (r-1)/r^2 を最善にしよう、 という一つの指標で考えてみると、式を微分なりなんなりしてみると r = 2 で最大(25%)となることがわかります
A Turing Machine - Overview
A Turing machine is a math concept that show that a few simple rules can be used to solve any computable computation. It is the basis for all of today's computers. My goal in building this project was to create a machine that embodied the classic look and feel of the machine presented in Alan Turings 1937 paper on computable numbers. More information can be found at: http://aturingmachine.com
steps to phantasien t(2006-10-31) To BLOB or Not To BLOB
なんとなく Jim Gray のページ を見ていたら, "To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem?" という記事があった. データベース業界には "ちまいデータは BLOB に入れろ, でかいデータはファイルに置け" という口伝があるらしい. (業界ビトでない私はしらなかった...) でも "でかい" って具体的にどのくらいなんだろう. 実験/ベンチマークをして BLOB とファイルシステムを比較, 疑問に答えましたよというのがこの記事. このごろはビデオや写真をウェブに置くのもふつうになりつつある. そういうメディアなデータを保存する世相を知っておくのはいいかもしれない. 読んでみた. この実験では BLOB の実装に MS SQLServer, ファイルシステムに NTFS を
最強最速アルゴリズマー養成講座：アルゴリズマーの登竜門、「動的計画法・メモ化再帰」はこんなに簡単だった (1/5) - ITmedia エンタープライズ
動的計画法とメモ化再帰 今回は、非常によく用いられるアルゴリズムである、「動的計画法」「メモ化再帰」について説明します。この2つはセットで覚えて、両方使えるようにしておくと便利です。 なお、メモ化再帰に関しては、第5・6回の連載の知識を踏まえた上で読んでいただけると、理解が深まります。まだお読みになっていない方は、この機会にぜひご覧ください。 中学受験などを経験された方であれば、こういった問題を一度は解いたことがあるのではないでしょうか。小学校の知識までで解こうとすれば、少し時間は掛かるかもしれませんが、それでもこれが解けないという方は少ないだろうと思います。 この問題をプログラムで解こうとすると、さまざまな解法が存在します。解き方によって計算時間や有効範囲が大きく変化しますので、それぞれのパターンについて考えます。 以下の説明では、縦h、横wとして表記し、プログラムの実行時間に関しては、
「ガベージコレクションのアルゴリズムと実装」という本を書きました。
gcbook, gcai, GCGCLoverのみなさん、お待たせしました。「ガベージコレクションのアルゴリズムと実装」の情報公開です。 書名：ガベージコレクションのアルゴリズムと実装 著者：中村 成洋／相川 光 監修：竹内 郁雄 ページ数：472ページ 本体価格：3,200円 発売開始日：2010年3月17日（水） ※地域・書店によって遅れることがあります ISBN：978-4-7980-2562-9 C3055 読み所 本書は次の2つのテーマを扱います。 1.GCのアルゴリズム（アルゴリズム編） 2.GCの実装（実装編） アルゴリズム編では、これまでに考案されてきた数多くのGCアルゴリズムの中 から、重要なものを厳選して紹介します。伝統的かつ基本的なものから、やや 高度なアルゴリズムを選定しています。GC独特の考え方や各アルゴリズムの特 性などを理解していただくのがアルゴリズム編の最大
Communications of ACM - steps to phantasien(2010-01-04)
年始は食べものの調達が億劫で, 大鍋にカレーを作り三日三晩食べ続けた. 量が多過ぎたので最後の夜は友人 M に助けを求めた. 鍋を空にすべくたらふく食べたあと土産にもらったチャイをすすりふと見ると, やはり腹ごなしに本棚を物色していた M が CACM の山に目をとめていた. CACM: Communications of ACM は, 米国のコンピュータ学会(ACM)が発行する月刊の会誌. 昔々はこれに論文を載せるのが計算機科学者のステータスだった, らしい. たとえば "Goto statement considered harmful" に 続く一連の論争は CACM の投稿欄で行なわれた. ダイクストラがジャンプ放送局に出てくる雑誌を想像してほしい. もうちょっとマシな例だと Quicksort なんかも CACM が初出のよう. 最近は分野の細分化が進み, CACM で最先端の研
SACHICA(類似文字列列挙アルゴリズム) - Yasuo Tabeiの日記
SACHICA(類似文字列列挙アルゴリズム)のC++による実装を公開しました。 http://sites.google.com/site/yasuotabei/sachica sachicaは、同じ長さの文字列集合を入力として、ハミング距離がある閾値以下のすべてのペアーを超高速に出力します。 アルゴリズムは、マルチソーティングという手法に基づきます。 詳しくは、ハミング距離がd以内で長さがmの文字列集合があったとします。初めに、各文字列をk (> d)の部分文字列のブロックに分割します。 今、ハミング距離がd以内の文字列のペアーを求めたいので、もし、ハミング距離がd以内の文字列のペアーが存在すれば、鳩の巣原理により、それらにはk - d個の完全一致するブロックが存在します。この原理に基づき、sachicaはcombination(k, k-d)のすべての組み合わせのブロックをラディックスソ
第7回 性能改善の鍵、インデックスの特性を知る～B-treeとハッシュ （1）B-tree | gihyo.jp
SQLアタマアカデミー 第7回性能改善の鍵、インデックスの特性を知る～B-treeとハッシュ （1）B-tree はじめに データベースを扱う仕事をしていると、パフォーマンスの問題に悩まされることは日常茶飯事です。とくに最近は、データベースに格納されるデータ量が飛躍的に増え、サーバのCPUやメモリといったハード面の増強だけでは追いつかないことも多くあります。 そのようなケースに対応するため、DBMSは性能改善のための手段を多く用意しています。その中で最もコストパフォーマンスの良い方法が、インデックス（索引）です。アプリケーションにもハード構成にも影響を与えずに実行でき、うまくいかなければすぐに削除できるという手軽さが大きな魅力で、効果はしばしば絶大です。 インデックスにはいろいろな種類があり、またDBMSによってもサポートする種類に差がありますが、本稿では最も重要な2つを取り上げます。それ
Diff algorithm - 枕を欹てて聴く
id:smoking186 さんの指摘を受け, First Authorの名前などを付加しました. どうもです. 記事内のcodeは最適化などを施しておらず, 冗長に, 定義どおりに書いています. ifがまとめられたりとかしますが, そのあたりはご容赦を... Rubyでlevenshtein距離を見て以来, 個人的にdiffブームが来ていた. 計算量O(ND) / O(NP)のalgorithmなどがあるのは知っていたが, 論文(英語)および, 解説のみ, またはソースコードのみなど分かれているものが多く, algorithmに疎い自分には理解するのに大変時間がかかってしまった. しかしやっとわかったので, 解説+JS実装してみる. 解説とソースコードがセットだと, 多少はわかりやすくなるかと... 自分は正直これくらい細かく言われないとすぐにはわかんない人なので(the O(ND)だけ
中央値の物理的な説明 - Radium Software
statpics - A Pearl: a Balanced Median Necklace 数学の概念を説明するのに，物理的な「たとえ」を使うことが，たまにあると思う。 例えば平均値の概念は，上の図の (a) のように「物理的なバランスが取れる点」として説明することができる。数直線を棒とし，値の点に等しい質量の重りを付けたときに，バランスを取ることのできる支点の位置が，平均値を表しているわけだ。 それでは中央値（メディアン）はどのように説明することができるだろう。平均値が「棒のバランス」だったのに対して，中央値は「滑車のバランス」で説明することができる。上の図の (b) のようにループ状の紐に重りを付けて，滑車にぶら下げたときに，最も下に位置する点が中央値となる。 この「滑車のバランス」は，左右の紐に同じ数の重りがあることによって得られる。どちらか片方からひとつの重りを選んで，それを極端
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://kikairoya.hatenablog.com/entry/20100718/1279465696
コードを愛でる - コードを愛でる