mp3 encorder ベンチマークデータの解析

TOPページに戻る　←ついでだから、他も見ていってね

更新メモ


　先日リンクをたどっていると、MrLayer-3さんの、-== MP3 TIDALWAVE UpGrade ==-というホームページを発見した。ここでは非常に面白い試みとして、おなじwaveデータを用いて様々なCPU,OS、エンコーダーでその速度を計測しデータを持ち寄り、そのデータを公開するということが行われていた。　これは面白い！　私もさっそくエントリーさせていただきました。

　さて、このまま眺めているだけではちとつまらない。先日HD-BENCHではそこそこ、良い値なのになぜ以外とＫ６が遅く感じる疑問もあったので、このベンチマーク結果の集大成を、大ざっぱに解析してみた。

　なお、下記のデータは８／２５時点での公開データをもとに解析しており、ソフトのバージョンやＯＳのバージョンなど細かいところは一部ゴッタ煮状態でデータ処理しているので多少いいかげんなところもあるがご容赦願いたい。

　まず、速度であるが、公開されているのは 約 58secのデータの圧縮時間（おそらくポップス系かな？中身聴いてなかったりして）である。どちらかというと、高速なほど大きな数値の方がイメージしやすいと思われるので、その指標として
Encord Speed ＝（エンコードされるデータの時間）　／　（エンコードにかかった時間）
を採用する。すなわち、１秒で何秒分のデータをエンコードできるかを示す数値となり、単位系としては無名数となる。
 

ＣＰＵ種によるエンコード速度の違い

　まずは最初に最もポピュラーそうなOSとエンコーダーでCPU別にエンコード速度を調べてみる。次のグラフはF-IIS　CODECによる速度であり、動作クロックはもちろん、実動作クロックを示している。Slot1系のCPUとこのエンコーダの組み合わせでは、およそ400MHzで速度１となる。つまり５分の曲を５分でエンコードできる計算だ。グラフ中の傾きは原点を通る直線で強引に一次回帰したもので、その傾きは単位周波数(1MHz)あたりの速度に相当する。なお、このグラフではWindows系(95,98,NT)をいっしょくたにしてしまっている(^^;)がこれについては後述する。Celelonはキャッシュが無い分やや遅めなのか？　これがキャッシュの効果なのかは、キャッシュ有りのCPUでON/OFFでデータを取ればわかるかな。

一応、念のため P-IIの場合、OS別に見てみると、それほど優位な差は無いようである。ほとんどが、浮動小数点の演算で占められるエンコード作業では、昨今の高速化されたチップセットや、HDDの転送速度、画面描画などのファクターはあまり関係ないのかもしれない。


 

次に Socket7系のCPUを見てみる。K6、K6-2はほとんど同じで、P54Cよりわずかに速い程度。それに対してP55Cは12%も高速である。同じクロックなら浮動小数点はINTEL系が速いという噂は、この条件では本当のようだ。ちなみに、やはり6x86系はかなり遅めである。

　以上の結果は、ネットワークにアクセスしているみんなが持ち寄ったデータで構成されており、ディスクや画面描画の速度、RAM容量、チップセットなど様々なはずであるが、ほぼCPUクロックとエンコード速度は比例関係にある。mp3のエンコードに関しては（といっても、ここまでの結果は、F-IIs codecとWindows系OSに限定されているが)、ベース１００MHzなどの効果などそれほど大きくないようだ。
 

ＨＤＢＥＮＣＨの結果との比較

　ここで、他のベンチマークテストの浮動小数点の演算速度結果と比較してみる。次の図は、HDBENCH ver2.610 に附属している CPU の測定結果をグラフ化したものである。

HDBENCHではクロックに対し、ほぼリニアに浮動小数点の演算速度の点数は増加している。しかし、ＣＰＵ間の差は、F-IISエンコーダーのそれとは大きく異なっている。 そこで、これらの３つのグラフの図中の傾きを表にまとめてみた。比較しやすいように、Classic Pentiumの速度が１となるようにnormalizeした値も記す。
 
  CPU係数   HDBENCH
  [/MHz] [/P54C]   [/MHz] [/P54C]
P2 0.00271 1.950   64.166 1.038
Celelon 0.00236 1.698   55.986 0.905
P6 0.00252 1.813   55.986 0.905
P54C 0.00139 1   61.844 1
P55C 0.00163 1.173   61.755 0.999
K6 0.00141 1.014   77.429 1.252
K6-2 0.00145 1.043      
6x86 0.00122 0.878   95.833 1.550
C6       49.844 0.806
　この結果から、HDBenchで見ると、intel 系はクロックが同じならほぼ同じ値なのに、エンコード時間はP-IIはP54Cに比べて２倍近く速い。また、HDBENCHではK6の方がP55Cより25%も高速と判断されるが、エンコード処理に関しては逆に15%も遅いということになる。

　以上は実際の計測から求められた係数なので、実験式として  Windows系のOSでは
エンコード時間[sec]　＝　データの時間[sec] × ＣＰＵクロック[MHz] × ＣＰＵ係数[/MHz] × エンコーダー係数
という式が成立する。ここでエンコーダー係数はF-IIs CODECの場合１である。よってこの式からエンコード時間を概算できるので、これより速い結果が出れば、あなたはうっしっしであるし、遅ければどこか設定が悪いところがないか見直した方が良いかもしれない。

　この結果を見ると、NIFの回覧で試用させていただいた、K6-2 300MHzが、HDBENCHで計測するとそれほど遅くないのに、mp3のencordになると、P6-200（PC-9821Ra20）よりかなり遅かったという体験とぴったり一致する。なぜかSocket8のOverDriveにかなり期待してしまう今日この頃である。PC9821に付くのかいな(^^;)

　さて今回はこのくらいにして、次回はこれらの結果をふまえてエンコードエンジン別にデータをみていきたいと思うけど．．．時間と暇と、ちょっとまだデータ数が少ないかもね。
 

 エンコーダーの速度比較

つい先日ちょっとまだデータ数が少ないかもねと書いたくせに、やっぱり比べてみたくなるのが人情とゆうもの。しかし、上記のF-IIsように、データを処理するほどは、データがない（8MHzエンコーダーは比較的多いようだが）ので、エンコーダーが変わってもＣＰＵ係数（F-IIs codec)は変わらないという無茶な仮定を設定し、強引に速度比較をすることにした。すなわち、先に求めた CPU係数を用いてすべての結果を強引にP54C でエンコードした結果として処理するということになる。
よって次に示すグラフで上にドットが来る方がより高速ということになる。また直線から点が上下に大きくずれている場合は
CPU係数がこのエンコーダーにはあてはまらない　-> 特定のCPUやOSなどに最適化されている可能性
エンコード時のオプションや環境などによりかなり速度が異なる ->データを解析するときあまり細かいことは見てない（私の手抜き）
などなど様々な要因が考えられるが、とりあえず比較するくらいはできるかな(^^;)

これは、F-IIs CODECと8Hzの結果である。F-IIsは比較的直線によく乗っている。これはこのエンコーダーの結果から係数を求めたので当然といえば当然かもしれない。これを見る限り8Hzはやや高速なようだ。

Producer Proがこの中では最も高速なようで、mpeg Encが最も遅い。 SCMPXは大きくばらついているのは、環境のせいか、エンコードオプションのためかは検討していない。ほんとはどの辺なんでしょうね？

というわけで、以上の図中の傾きを一応表にまとめてみると次のようになる
 
Encorder係数
  [/MHz･P54C]  
mpegEnc 0.00023 0.165
LeEnc272 0.00056 0.403
UNREAL 0.00073 0.525
Blade 0.00085 0.612
SCMPX 0.00086 0.619
Producer2 0.00131 0.942
F-Iis 0.00139 1.000
8Hz 0.00160 1.151
Xing 0.00905 6.511
一応参考までに Xing の結果も掲載しておくことにするが、mp3 encorder impressionでも書いたように、16kHzから上の音は処理しないという反則技を使っているので当然かも。しかし速いですね。
 

 ３８６ＳＸ１６ＭＨｚによるベンチマークエントリー経過

　現在、ＰＣ９８０１ＵＳ　３８６ＳＸ　１６ＭＨｚというマシンで上記のベンチマークにエントリー中です。

ＣＰＵ：上記の通り、３８６ＳＸ１６ＭＨｚ　当然コプロは無しです
メモリー：６４０＋専用内蔵が２Ｍ＋メモリーカードスロット（Ｃバス相当）８Ｍです。
ＨＤＤ：外付けＳＣＳＩ２
ＯＳ：Windows95 A　（９８も動かせますけど面倒なのでやめました。ＮＴ３．５というのも動かしたことあるけど(^^;)）
エンコーダー：Ｂｌａｄｅ Enc 0.6 です。今から考えたら 8Hz にすれば良かったですね。半分くらいの時間ですんだはずなのに。
 
No
Date
h:m:s
sec
残り
合計
割合
終了予定日
start
1998/8/27 21:30
0:00:00
0
660:00:00
660:00:00
0
1998/9/24 9:30
1
1998/8/30 15:32
66:02:00
237720
610:23:49
676:25:49
9.7
1998/9/25 1:55
2
1998/8/31 14:45
89:15:00
321300
588:09:52
677:24:52
13.1
1998/9/25 2:54
3
1998/9/2 18:18
140:48:00
506880
534:22:21
675:10:21
20.8
1998/9/25 0:40
4
1998/9/3 19:18
165:48:00
596880
508:25:39
674:13:39
24.6
1998/9/24 23:43
5
1998/9/5 16:12
210:42:00
758520
461:52:53
672:34:53
31.3
1998/9/24 22:04
6
 1998/9/11 15:58
354:28:00
1276080
290:26:02
644:54:02
56.6
1998/9/23 18:24
7
1998/9/21 16:26
594:56:00
2141760
51:19:01
646:15:01
92.3
1998/9/23 19:45
8
1998/9/24 13:52
664:22:00
2391720
5:47:23
670:09:23
99.1
1998/9/24 19:39
 9 1998/9/24 19:38 670:08:00 2412480 0:00:00 670:08:00 100  

　やっと終わりました。実に１ヶ月弱かかったことになりました。40208minという結果はどんなもんかな。さっそくメール送らなきゃね。
　最初に試したときの４００ｈくらいだったのは、おそらくプロセスが専用２Ｍのメモリーに載ったんでしょうねぇ。キャッシュもないのでメモリーの速度差がもろに出てるのでしょうか(^^;)