ユメのチカラ: メモリアクセスは遅い
多くのプログラマにとってメモリアクセスの速度を気しなければならない状況というのはめったに無いが、OS、ライブラリ、コンパイラ、RDBMSなどの実装をする時には意識をしなければならない場合がある。 IA-32 Intel Architecture Optimization Reference Manual (order number 248966) をひもとくと6章にOptimizing Cache Usageというのがある。 マイクロベンマークの定番 lmbench http://www.bitmover.com/lmbench/ では、一次キャッシュ(L1)や二次キャッシュ(L2)を測定してくれる。例えば、わたしが利用しているノートだと、L1が1.776nsでL2が5.3490ns、メインメモリアクセスが139.4nsである。 Memory latencies in nanosecond
ユーザーに尋ねても必ずしも正しい答えは返ってこない
今日はたまたま「ユーザーからのフィードバックを集めることの難しさ」が話題になったので、それに関連するエントリー。 もの作りにおいて、「ユーザーが何を必要としているか」を知ることは大切だが、だからと言ってユーザーに尋ねれば正しい答えが返ってくる訳ではないところが難しいところ。具体的な例としては、こんなものがある。 1. サイレント・マジョリティの声は聞こえてこない これはMicrosoftで実際にあったことだが、Outlookのチームではユーザーから寄せられる機能追加のリクエストに従って色々な機能を足していた時期があったが、その結果不必要な機能ばかり増えて、単純な作業が逆にやりにくくなってしまった（たとえばカスタム・フォームが良い例）。このケースでは、ごく一部のヘビー・ユーザーばかりが声がでかく、「今の機能で十分、これ以上複雑にしないで欲しい」というユーザーは何も言ってこない（こういう人たち
livedoor Readerパーフェクトガイド - livedoor ディレクター Blog
※この記事は、2013年3月14日にアップデートしました。 こんにちは、「livedoor Reader」などのディレクターを担当している佐々木です。 「世界の技術者、刺激したい」―ライブドアRSSリーダー英語版公開 「RSSリーダーにも2対8の法則がある」と池邊CTOは言う。2割のヘビーユーザーが、8割のフィードを読んでいるというのだ。「livedoor Readerは、2割の人に最適化している」 これは弊社スタッフの偽らざる本音なのですが、そうは言っても、より多くの人に使っていただけるよう、livedoor Readerのサイト上では初心者向けの説明を中心に掲載しています。 しかしそれによって、2割のヘビーユーザーに対して満足な説明ができていなかったのではないか、ということを心配してきました。 そこで今回は、Webディレクター向け（つまり、2割に相当するヘビーユーザーであるべき職種の人
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HOBO NIKKAN ITOI SHINBUN - 1101.com - 任天堂の岩田社長が遊びに来たので、みんなでご飯を食べながら話を聞いたのだ。
