2012年11月16日

マルチスレッドの効果

2007/05/09(Wed) 14:13

マルチスレッドの効果があるのはどんな場合だろう?CPUがひとつであれば並行でタスクを実行しても結果としてかかる時間は同じ。むしろ、タスク間の切り替えが発生して悪化するかもしれない。私がスレッドの必要を感じたのは、ハードコピープログラムを作った時だ。キャプチャしたファイルを1枚ずつファイルにして保存していると、0.1秒間隔、つまり10fpsが限界だった。それもそのアプリのみを稼動させている場合で。他のアプリも使っているような場合は5fpsが限度で、現在デフォルトはそれになっている。5fps,10fpsは、動画としてはかなりの低フレームレートだ。標準的な動画は28とか29とかだったと思う。ただし、キャプチャ対象自体がすでに低レートのストリーム動画だったので、それほど深刻な問題にはならなかった。
今思ったのだが、これはマルチスレッド化ではなく、バッファつきにするべきことに思えた。1枚キャプチャするたびに書き込むのではなく、何枚かまとめて・・・いや、結局1枚ずつのファイルになるのだから最終的には1枚ずつのディスクアクセスが発生する、やっぱりファイル出力は別スレッドにすべきだろう・・・バッファつきの書き込みというのは、大きなファイルの書き込みをまとめる時に使うのであって、複数のファイルを書き込むにはやはり最低1ファイル1回の書き込みが必要だよな・・・?

2007/05/09(Wed) 14:14
おそらく一番いいのは、細切れファイルをたくさん作るのではなく、まとめてひとつのファイルにする事だ。すでに存在するファイルを固めるプログラムは作ってあるから、そのロジックを使ってキャプチャ時に固めてしまえばいい。やってみよう。

普通はAVIファイルにするんだろうが、VFWの使い方がよくわからなかったのと、AVIはサイズがでかいのとで、独自フォーマットにした。1コマはJPGファイルで、その大きさを各フレーム前に記録するのである。motion jpegという規格があり、おそらく基本原理は同じだと思うが、厳密なフォーマットはおそらく違うだろう。しかし、ロジックとしては非常に簡単である。motion jpegはQuicktimeが使っているフォーマットらしい。だがMotionJPEGをAVIに分類しているところもたくさんある。

しかし私が苦労したのは、JPGは一枚ずつファイルサイズが異なるということだ。AVIなら同じなので、ただつなげていって、ヘッダに一こまのサイズを記録しておけばよい。最初はなんらかの区切り符号を挟もうかと思ったのだが、動画中に絶対出現しない値というのがあるのだろうか、おそらくないだろうと考えて、1コマずつのサイズをはさむことにした。再生するときはそのサイズを読み、サイズ分のデータを読んで、1コマと判断するのである。


posted by delsoli at 18:11| delphi | 更新情報をチェックする

型なしファイルへの出力

2005年某月某日
以下は、型なしファイルへの出力例である。

procedure TForm1.Button2Click(Sender: TObject);
var
FS:TFileStream;
s,k:string;
i:integer;
begin
FS := TFileStream.Create('test5.txt',fmCreate or fmShareDenyWrite);
s:='nanasi';
k:='gonbe';
i:=65536;
try
try
FS.Write(s[1],Length(s));
FS.Write(i,sizeof(i));
FS.Write(k[1],Length(k));
except
exit;
end;
finally
FS.Free;
end;
end;


今まではblockwriteを使っていたのだが、こっちのほうがスマートだ。
2005だとblockwriteは安全でないという警告にもなる。こちらは多分出ないと思う。

ファイルへの出力方法がやっとわかった。注意は、テキストの場合と、バイナリデータの場合で異なる事である。integerとか、bmpとかは、そのものを、サイズ指定して書けばよいが、Stringの場合は変数名に[1]をつけ、サイズではなくlength(s)と指定する。[0]じゃないのかと思うがそれは参照できない、というエラーになる。[1]をつけないと、4バイトの数値になる。たぶんアドレスなのだろう。
posted by delsoli at 18:08| delphi | 更新情報をチェックする

ソフトウェア開発がスケジュールどおりに行かない理由

2007/04/04(Wed) 14:10

それは人間の利己心とソフトウェアの本質による。生産性は書いたプログラムの量とかかった時間で計られるのだが、遅れようがバグを満載しようが、作者には何のお咎めもない。しかられたり出世が遅れたりするかもしれないが、連日徹夜してまで防ぐようなことではない。プログラムというのは結局は書いた人にしかわからないものだ。みんなで書けばみんなが理解できるが時間がかかる。天才プログラマであればほっておいてもいいものができる。むしろ彼らにはレビューや進捗管理は仕事の妨げにしかならない。今から述べる事は恐ろしい事実で多くの人は目を背けたくなるだろうが、避けがたい事実である。プログラマは、スケジュールを故意に遅らせているのである。

なぜか?残業したほうが給料が増えるからだ。すわってコーヒーを飲みながらキーボードをたたいていれば、金がもらえるのだ。こんな楽しいことはない。楽しい時間は少しでも長くしたい、だから長引かせる。
しかも長引くと、仕事が遅れると残業代やら深夜残業代などのおいしいオマケがついてくる。これで定時にスケジュールどおりに仕事を終えようと考えるのはよっぽどの人格者かアホだ。

実際、私が開発業務をしていたときは全員がこう考えていた。給与明細を見て残業が何時間だったかと比べあうのである。多分、今もそうだろう。残業やスケジュールの遅れが会社にとって不利益になるかどうかなど、誰一人考えない。考えるのは管理者だが、それだってそれが仕事だから考えているにすぎない。そもそも、企業が利益をあげるという行為は、利己的な行為なのである。そこを皆忘れている。

これはソフトウェア開発だけに当てはまる事ではないが、ほかの仕事は仕事の成果が外から見えるので、こんなインチキが許されないだけだ。先ほどのべたように、プログラムは書いた人にしかわからない、
アウトプットだけしか人は見ない、見たくない・・・。ここにプログラマやSEのインチキがまかり通る理由がある。ではこれを防ぐにはどうしたらよいか。一番いいのは、プログラムなんか作らない事だ。パッケージソフトを買う事。それも、ベストセラーになっているくらい、広く長く流通しているもの。そして、アップデートされ続けられるもの。まあそれは無理だろうが、なんでもかんでもCで書こうとしないことだ。

もうひとつは、労働基準法を改正して、残業代が割り増しになるのをやめる。休日出勤も。完全なる成果主義にする。・・・不可能。こういうことを考えて、私は開発の仕事をやめた、というか、開発の仕事をしなくていい理由をこういうことにしたてた。そして、働く事自体を、否定した。
posted by delsoli at 18:07| プロジェクト管理 | 更新情報をチェックする
×

この広告は180日以上新しい記事の投稿がないブログに表示されております。