開発メモ: アグレッシブだけど白トビしない自動画像補正スクリプト
室内や日陰で撮った写真が期待より暗くなってしまうという失敗をバッチ処理で修正する方法について模索する日々だが、かなり実用的な方法が実装できたので紹介してみる。 トーンカーブの手動修正 何も考えずにオートで写真を撮ると、室内や日陰だと以下のような暗い写真ができ上がってくることが多い。サングラス越しに見ているような陰鬱な感じだ。 このような暗い写真は、PhotoshopやGIMPで開いてヒストグラムを確認すると、ハイライト側が完全に開いてしまっていることがわかる。これを修正するには、山の右端が最も明るくなるように、トーンカーブの右肩を天井にくっつけてあげればいい。
開発メモ: ロック自作による高速化
マルチスレッドのロック機構を自作してKyoto Cabinetを高速化したよという話。 背景 以前の記事にも書いたとおり、組み込みのrwlockはmutexに比べても遜色ない速度で動作して素敵なのだが、実はロック処理自体の並列性があんまり高くないんじゃないかなぁと思い始めてきた。というか、pthreadのロック機構は遅い（期待ほど速くない）んじゃないかなぁと感じる今日この頃。 特にspin lock（pthread_spinlock_t）とrwlock（pthread_rwlock_t）が遅い気がしている。プロファイルをとると、Kyoto Cabinetの実行時間の多くをロック回りの処理が占めているので、こいつらを自作のロックに置き換えて軽量化してみよう。pthreadのロックプリミティブはPOSIXの規程に基づいたいろんな機能を備えているが、自分で作れば自分のユースケースに必要な機能だけ
開発メモ: アトミック演算の性能
GCC拡張のロックフリーなアトミック演算機能と、自分でロックしてアトミックに演算するのとではどれくらい違うかを実験してみた。 TCやKCでのユースケース TCやKCのデータベースオブジェクトでは、ファイルサイズやレコード数をメタデータとして保持している。それらの更新（主に加算）をする操作は頻繁に行われるので、なるべく処理効率を上げたい。 いわずもがな、変数の更新を行うという操作をミクロ視点で見ると、既存の値をメモリから読み出して、その値に対して演算を行って、それをメモリに書き戻す、という3ステップからなる。普通に「+=」演算子などを使うとそれら一連の操作群がアトミックに行われる保証はないので、mutexなどを使ったクリティカルセクションで一連の操作群を包むのが一般的である。 しかし、変数の値を加算するという操作ごときにわざわざロックのオーバーヘッドが伴うのは嫌な感じである。ところで、上述の
開発メモ: KVSとシグナル機構でジョブキューを実現する
いわゆるkey-value storeを使っている際に、レコードの挿入もしくは更新を検知して即座に何らかの処理を行いたくなることはないだろうか。俺はあんまりないけど、結構そういう質問が来るので、きっと巷にはそういう要求があるのだろう。Kyoto Cabinetでそれを実現してみた。 ジョブキュー もうちょい具体的な例を挙げると、ジョブキューである。ここで、「foo」という名前のタスクを考えてみる。読み出し側（ワーカ）は、適当な名前をつけた条件変数を常に監視していて、そこにシグナルが飛んできたら即座にレコードを取得して処理を行いたい。しかし、「一定の間隔毎にレコードの検索を繰返して発見したら処理を行う」というポーリングスタイルにはしたくない。操作にどうしてもタイムラグが出るし、ポーリングのための無駄なトラフィックが発生するからだ。 シグナル待機処理と該当レコードの取得処理を行う擬似コードは以
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
