マルチスレッド対応 lameフロントエンド (もどき)を作って公開したはいいものの、使うメリットなどが分かりずらいとのことだったので、解説を書いてみた。
微妙な部分もあるかもしれないが、そのときは指摘してくれ…(´・ω・`)
・lameとマルチコアCPU

Phenom x4(Quad-Core)を例に挙げてみる。
Phenom x4などのQuad-Core CPUの中には、4つコアがあり、それぞれが独立して処理を行う。
よって、OSはCPUが4つあるのと同じように処理を行う事ができる。

それぞれのコアが独立して処理を行うため、「同時に2つのCPUを使いますよ」という命令をしない限り、1つのコアしか使わないので、CPUには余力があるのに、処理速度が頭打ちになってしまう。
「同時に2つ以上のCPUを使いますよ」という命令(マルチスレッド処理)を使用しているプログラムを作成するのはなかなかめんどいので、「CPUパワーが必要なのに、1つのコアしか使ってくれないプログラム」というのは結構多い。
lameはそんな「CPUパワーを必要とするが、1つのコアしか使ってくれないプログラム」のうちのひとつ。
lameの場合、
「lameバイナリ側でCPUを2つ以上同時に使用するようにしたら、音質が悪くなった」という問題が発生していたため、マルチスレッド化が進まなかった。
そこで私は
「lameひとつで4つ分の仕事をするんじゃなくて、lameを4つ使って、4つ同時に仕事させればいいんじゃね?」と考えた。
メモリの使用量が増えるのは困る?
プロセスがやたら増えるのが嫌?
フロントエンド4つ同時起動したら同じじゃねーかって?
(´・ω・`)知らんがな
…まぁlame自体ほとんどメモリ使用しないし、フロントエンド4つ同時起動すると、ファイルの競合起こしたりする可能性もあるし…(´・ω・`)
・通常のlameの処理の流れ

通常のlameの処理の流れは、上の図の通り。
この方法だと、CPUコアが1つしか有効に活用できず、
エンコード速度が、Pentium4(HT無効)が一番早く、次にCore2Duo、一番遅いのがCore2Quad…なんて事になってしまったりもする。
現状存在するlameフロントエンドでは、知っている限りでは全てこの方法を取っている。
・マルチスレッドに対応させたlameの処理の流れ(音質劣化有り)

マルチスレッド対応のlameバイナリを使用した場合の処理の流れは上の図の通り。
ひとつのファイルを、ひとつのlameプロセスで、4つのコアを使って処理する、ということなので、ひとつのファイルを処理する時間が、1/4で済むことになる。
lameバイナリ側でマルチスレッドに対応しているので、フロントエンドなどには関係なくマルチスレッド処理してくれる。
現在lameを使用しmp3を作成する方法としては一番効率が良いが、先程述べた通り、
「lameバイナリの処理をマルチスレッド化すると出力ファイルの音質が悪くなる」という問題があるため、推奨されていない。
・マルチスレッド対応 lameフロントエンド (もどき)での処理の流れ

私の作成したフロントエンド(もどき)、mtlamefでの処理の流れは上の図の通り。
4つのソースファイルを用意し、lameプロセスを一度に4つ実行、4つのファイルを並列処理している。
ファイルひとつ当たりのエンコードに掛かる時間は、通常のlameと変わらないが、4つのファイルを同時に処理することで、処理にかかる時間を1/4にすることができる。
フロントエンド側からlameプロセスを多重実行しているだけなので、音質などに影響することは無い。
これはSHA-1ハッシュを使用した実験で実証済み。
ファイルがひとつしか無い場合は、通常のlameと同じ時間が掛かってしまうが、気にしない。
…そもそも、このプログラムを作成する上での基本方針は、
・マルチスレッド処理による処理の高速化
・ディレクトリ単位での一括エンコードなので、ファイルが1つだけという状況はまず無いかと…
4つのファイルを同時に出力することになるので、このプログラムでは、
・出力ファイル名の競合問題
・ファイルコピー・リネーム・削除の排他処理
などの問題がやたら発生し、かなり涙目になれた。
…解説としては、大体こんな感じだろうか。
図などがかなり適当だったが…(´д`)
分かりにくいところなどは、順次修正していく予定。
プログラム本体はこちらからダウンロードできる。
※ 09.07.26
Multi thread Media Encoder Frontend(マルチスレッド対応 マルチフロントエンド)をリリース。
マルチスレッド対応 lameフロントエンド (もどき)より、
高性能で安定性も高い…と思う。
GUIも付いたので、マウスだけでも操作できます。
http://mtmef.g.hachune.net/