日々の破片
| 著作一覧 |
2007-03-09
_ W51SAの写真
液晶だとちょっと暗めな感じに見えるけど（表示設定の問題かも）、実際の写真は落ち着いた色味でそんなに悪くないかな？
昨日のDeveloper's Loungeでの梅村さんのプレゼンの様子をW51SAで撮った写真。プロジェクタを使っていることからわかるように薄暗い室内で、かつ逆光だったわけだけど、想像（W51SAの液晶で見えている状態）以上にきれいに撮れている。実際より明るめに撮れている。
晴天下の屋外写真（車までの距離は10数mというところだと思う）。これも、こんなものかな、という感じだけど最初の写真とは逆に実際よりは暗め（落ち着いた感じとも言う）な絵だと思う。
#考えたら、比較して云々できるほど、他のカメラを知らないのでした。でも以前使ってたW21SAより密な感じがして、確実に向上しているという印象は受けます。
#と思ったら、ちょっと違うな。コンピュータをデュアルディスプレイで利用しているんだけど、片方はDELLのデフォルト（Windows最適化）、片方はEIZOをMac用（赤みが強い）に設定していて、DELLのほうで見た印象が上に書いたもの。EIZOで見た印象は、W51SAの液晶で見たのに近くて暗め（したの写真の車の白はきれいだ）。
_ W51SAを使った印象
数字の1〜3が押しにくい（上のモジュールとの間隔が狭いからだ）。慣れが必要かも。同様に、OKボタンがちょっと押しにくく、わりと↓を間違って押しやすい（これは以前の携帯より下が短いので持つ手の位置が合ってないからだと思う）。クリアはむしろ押しやすい。
EdyのチャージはFeliCaロックの解除方法を瞬間的に忘れてえらく手間取った。使うときは、あらかじめロックを解除していたのだが、メニューからの選択時、わりとあせってしまって、OKではなく下カーソルを押してしまいEdyではなくQuikPayアプリを誤起動させたりしてえらくめんどうなことになったり。最初からアプリケーションを起動しておいてからレジに並ぶべきなのかも（というか、いかにも不慣れな状態だということだな）。
#充電用コネクタがW21SAと異なるのだが（薄くなった）、うれしくないね。会社用に余分に買ったやつは完全にゴミになってしまったわけだし。
_ キャッシュが無かった時代
そのころはこんなのが速かった。
struct S {
unsigned char data[64];
};
...
void copy_S(S *d, S *s)
{
register long* dd = (long*)d;
register long* ss = (long*)s;
int i;
for (i = 0; i < 16; i++) *dd++ = *s++;
}
でも、ある頃から、for (i = 0; i < 64; i++) d->data[i] = s->data[i]; のほうが速くなった(というか、どうでも良くなった)。今でもそうかな？
ジェズイットを見習え |
写真、ありがとうございます〜。<br>W31SAに比べても発色が良くなった感じですね。他のサイトで見た写真では接写能力も落ちてないし、カメラに関しては不安要素がなくなったかも。<br>＃でも金がない……。
速さなら<br>//---<br>d->data[0] = s->data[0];<br>d->data[1] = s->data[1];<br>…<br>d->data[63] = s->data[63];<br>//---<br>の方が速いと思います。<br><br>組み込み系なら「#pragma align 〜」とか無いか調べて石によっては(long long*)でコピーしてます。<br>画像系では更に D$ を操作してからやってるんでしょうけど。
そう言えばLSI-Cが、add alをがんがん並べたコードを吐くというような話を聞いた覚えがあったけど、さすがに64個も並べると1回のキャッシュラインのフィルじゃ入らないわけで、かえって遅いとかないのかな？<br>long long*まで行くと一気に8バイト転送なので確かに速そうですねぇ。（D$ってなんだかわからないので後で調べる予定）
add alじゃないや。レジスタのインクリメンタル命令（ニーモニク忘れた）
今のCPUだと、インライン展開するとコードサイズが増えるためにキャッシュの無駄使いが増えて、かえって遅くなることが多いようです。
すみません。D$はデータキャッシュです。<br>組み込み系RISCチップのマニュアルでは D$=Data Cache, I$=Instruction Cacheとなっているのをよく拝見するので真似てみました。「D$をクリアして」と記せば連想してもらえたかもしれませんね。<br><br>転送量によりますが今回記したケースならメモリーの alignmentを 8の倍数に設定して(long long*)の転送にします。<br>サイズの大きい転送の場合キャッシュ(命令＆データ)をクリアしてから転送処理に移ってました。<br>その方がキャッシュラインの整合性などを石が都合良く調整してくれますから。<br><br>ループは展開した方が速くなると思うんですが…最新の石は触ってませんがその辺に製品として出ている石であればLoop UnRolling(LUR) は高速化手法としてマニュアルに載ってます。64バイトとサイズが判っていて速度を要求するなら迷わず展開します。
なるほどぉ>D$<br>そういう書き方するんですね。<br>展開したほうが速いというのはわかるんですが、全部ひっくるめてI$（と早速真似したり）に1回で入ってしまう分だけずらしながらフィルしてくより速いんじゃないか？ と思ったということです。もっとも上の例だとlong long*で転送すればたかだか8行（8opと書くのかな？ ちょっと単位がわからなくなっちゃったけど）なのでループするより速そうな気もしますがどのへんが分水嶺なんでしょうね。<br>#ループだと1ループあたりに必ず加算、比較、分岐が入るのがオーバーヘッドだというのはわかるんだけど、加算、比較は上限が即値であればレジスタだけで終わるから2次キャッシュからI$へ転送するオーバーヘッドがある回数まで行けば上回るんじゃないかな。