TPAIPAI
2002-08-22 13:34:42 ( ID:bgyrsrjiyb2 )
[ 削除 / 引用して返信 ]
現在、P4 1.6GHz PC2100 512MB ですが、
1.メモリーを1GBにする。
2.メモリーをPC2700にする。
それぞれ、効果はどのくらいあるのでしょうか?
メインの使用目的は1時間〜2時間のDVをMPEG2/DIVXへの変換です。
Rolly-A
2002-08-22 15:55:32 ( ID:bu95gh50a5a )
[ 削除 / 引用して返信 ]
どのくらいの効果とは一概に言えませんが、、、メモリサイズについては、通常512MBあれば実際のエンコードでメモリを食いつぶしているということはあまりないということから、効果がないと思います。
私の経験では、Windows2000で256→512はスワップ軽減で効果がありましたけど、512→768は効果がありませんでした。
メモリーをPC2700にするのはCPU―メモリ間のボトルネックが緩和するので、、こちらのほうはいくらか効果がありそうです。
らむじぃ
2002-08-22 16:30:31 ( ID:bzmgtdidzx. )
[ 削除 / 引用して返信 ]
>どのくらいの効果とは一概に言えませんが、、、メモリサイズについては、通常512MBあれば実際のエンコードでメモリを食いつぶしているということはあまりないということから、効果がないと思います。
>私の経験では、Windows2000で256→512はスワップ軽減で効果がありましたけど、512→768は効果がありませんでした。
>
第一の壁が、swap に追い出されない程度のメモリ量です。
第二の壁は、ソースがすべてキャッシュに乗っかる量です。
特に、2path encode 等を行うと、効果の程がわかります。
440GX の世代の頃、友人宅でメモリを2G程積んだマシンで
エンコードして試したことがあります。
>メモリーをPC2700にするのはCPU―メモリ間のボトルネックが緩和するので、、こちらのほうはいくらか効果がありそうです。
ところが、それ以上にDisk IOにボトルネックが有るので、
メモリの帯域比に比べてそれほど向上しません。
#0じゃぁないんですけど、微々たる物です。
fay
2002-08-22 16:50:47 ( ID:k07nygitk0f )
[ 削除 / 引用して返信 ]
簡単に言うと、どちらを行ってもほとんど速度には影響はないでしょう。理由としては
上でRolly-Aさんやらむじぃさんが書いているとおりですが、DVの1時間のソース(約
13G)をメモリ上に載せるのはほぼ不可能ですからメモリを増やしての速度アップは期待
出来ないでしょう。
メモリをPC2700にしたほうが効果がある確率が高いとは言えますが、単純にPC2100のも
のをPC2700のものに載せ替えただけでは意味がないというのは分かっていますよね?
チップセットなどの対応が必要です。また目に見える効果があるという保証もできない
です。
メモリを買う程度の資金で効果がある速度アップとしては、CPUを2G以上に載せ替える
ことくらいでしょうか? メモリ代金+P4-1.6Gの売却金でP4-2AGが何とか買えないで
しょうかね?
tpaipai
2002-08-22 20:32:20 ( ID:z59cx52ngvl )
[ 削除 / 引用して返信 ]
皆さんありがとうございます。
そうですか・・・やっぱりCPUですよね。
でも、効果を体感するには最低でも1.5倍はあげないとなあ・・・2.4Gzかぁ。高いなぁ
3Gz位に上がれば半分で終わるんだけど。
らむじぃ
2002-08-23 01:19:55 ( ID:sdjkupbxvlr )
[ 削除 / 引用して返信 ]
>皆さんありがとうございます。
>
>そうですか・・・やっぱりCPUですよね。
という話でもなくて、トータルバランスなんですな。
一番ボトルネックになっているのはどこかを探して潰していくのです。
>でも、効果を体感するには最低でも1.5倍はあげないとなあ・・・2.4Gzかぁ。高いなぁ
>
>3Gz位に上がれば半分で終わるんだけど。
私は身の回りに…AthlonXP 10G(ぐらい性能持ったのIA32CPUを)下さいと絶叫してます。
# 作業してる時間が…ない…
あとaviに限ります(mpeg1or2でも出来ますけど、精度にあまり期待しない方がいいです)が、豪華マシンを買う金でそこそこマシンを複数台準備し、
それぞれで細切れにエンコードした物をaviutilで再圧縮無し結合すれば
いいかもしれません。
# いや、手間は増えるんですけどね
いしかわ
2002-08-23 09:21:20 ( ID:9fprs1e3ji. )
[ 削除 / 引用して返信 ]
> でも、効果を体感するには最低でも1.5倍はあげないとなあ・・・2.4Gzかぁ。高いなぁ
つい最近までは滅茶苦茶高かったP4 2.53MHzですが、今
とんでもないことになっているようです。(^-^;;
http://www.watch.impress.co.jp/akiba/hotline/20020824/etc_p4pricedown.html
FSB 533MHzのマザーが必要ですが、やっと買ってもいいかな?って値段になりましたね。
#でも、昨日夜9時までやってる某秋葉原大手に行ったけど6万円オーバーのままでした。(^^;
有志
2002-08-23 12:48:59 ( ID:0opu7aqbcro )
[ 削除 / 引用して返信 ]
AVWATCHに次のような記事がありました。
http://www.watch.impress.co.jp/av/docs/20020306/zooma50.htm
>現状のTMPGEnc2.5xシリーズのエンジン部分は、基本設計が3年前である。
>当時のマシン事情から、メモリを節約するような設計となっており、
>そのためエンコード速度が上がらないという事情もあるようだ。
>次のバージョン3ではUIだけでなく、メモリが豊富な環境を視野に入れて、
>エンジン部分を新たに書き直しているという。
この記事によるとバージョン3からはメモリ容量の増設による
スピードアップが期待ができるのではないでしょうか?
あとこれは、個人的なことなのですがやはり
Windowsでロードバランス型のPCクラスタを構築することが
もっと身近になれば、そしてTMPGEncもクラスターに対応すれば
ハードウェア並かクラスターの規模次第では
それ以上のスピードが出るのではないのでしょうか?
もちろんクラスター構築にはとてもコストがかかりますけど...
らむじぃ
2002-08-23 20:22:29 ( ID:bzmgtdidzx. )
[ 削除 / 引用して返信 ]
> あとこれは、個人的なことなのですがやはり
>Windowsでロードバランス型のPCクラスタを構築することが
>もっと身近になれば、そしてTMPGEncもクラスターに対応すれば
>ハードウェア並かクラスターの規模次第では
>それ以上のスピードが出るのではないのでしょうか?
>もちろんクラスター構築にはとてもコストがかかりますけど...
ロードバランス型のクラスタを組んだとしても、TMPGEncでは意味はありません。
ロードバランスはwwwサーバのようなサービスを行う時に意味を持ちます。
一つのデカイCPUができあがるというわけでもないですし、
SMPの様に扱えるわけでもないです(^^;;)
また、Mpegの様なCPU演算を負荷分散するには100Mbpsでは圧倒的に足りません(^^;;)
# GbEでもだめかも?
kanazy
2002-08-24 00:48:37 ( ID:1ota71mrrrc )
[ 削除 / 引用して返信 ]
100baseでも1000BASEでも、Ethernetの規格上LAN経由ではエンコード速度
が出ないのではないかと思います。
そう考えてる理由として大まかには以下の理由です。
1 パケットの処理量(つまりデータの転送量)に比例してCPU負荷が増える。
2 100Mbpsや1Gbpsというのは、連続して大量のパケットを転送した場合の速度であると いうこと。
1についてはEthernetはデータ転送をCPUで処理してるため、転送量が増えるとその分
CPUに負荷がかかります。これに似た例としては昔のIDEのデータ転送モードのPIO方式があります。あれは規格上の速度に対して実際にはCPUの処理能力が低いと性能が出ないという物でした。Ethernetもそれと似た傾向を示します。
実際、最近の例としてはADSL回線やB・フレッツにPCを直結した場合のスループットがPCの性能にも左右されるという話を聞いた覚えのある人も居ると思います。
さらにエンコード処理をしているPCでは余分な処理(パケットの処理)が増えることになります。
(最近のUltraATA形式のIDE接続のHDDはSCSIと同じようにDMAチャンネル経由のアクセスをしているので 基本的にはCPUの処理速度には依存しません)
2については、LAN経由だと相手と通信のためにセッションを確立し、それからデータ転送を行うことになります。つまり送信処理の初期は速度が遅いというわけです。
さらにデータを要求してからデータが転送されてくるまでの遅延時間がありますが、これがローカルのHDDに比べて非常に時間がかかります。
またエンコードをする際のデータの読み込み方にも寄りますが
エンコードする際に必要な部分だけを読みに行く場合(大概はこの形態だと思います)、少ないデータしか一度には読み込まない事になります。それから相手先のPCがデータを読み込み、データを転送することになります。
そのためローカルのHDD(たとえ5400RPMで2世代、3世代前の物でも)へのアクセスに比べて非常に時間当たりの転送量が少なくなります。
(ていうかその世代でも100Mbps超えていたような気がするw)
結論としては、余分なオーバーヘッド(CPU負荷や遅延による待ち時間)が大きくなり速度が出ない、つまりエンコードをしているPCの性能を100%エンコードに使えていないという結論になります。
まあ、他にも高負荷時のPCでのパケットのやり取りには、速度が遅くなる理由がありますが、細かすぎる点なので割愛させていただきます(汗
#LANの接続がミリネット接続だ〜とか1000BASE-SXいうなら話は別ですけどね
#でも1は回避できても2は回避できないでしょうね。それに金のかけるところ間違って
#る気がw
xxx
2002-08-24 03:51:45 ( ID:varimftn/9f )
[ 削除 / 引用して返信 ]
TCPはプロトコルスタックのオーバーヘッドが大きいんで、UDPで作った方がいいね
タスクやスレッド構造をうまく作れば、データ読み込みのオーバーヘッドは隠れそうな
気もするけどね。
yyy
2002-08-26 00:32:32 ( ID:iz2w6hvgwog )
[ 削除 / 引用して返信 ]
UDPは損失があり、非同期のため、連続データを処理させる必要のある、エンコード
等には不適格だと思いますが。
フラグメントや、エラー訂正処理をきっちりしないと、画質が落ちるのは分かるとしても
CPUに別の負荷がさらに掛かってしまいます。
プロトコルスタックオーバーヘッドよりも、CPU負荷オーバーヘッドの方がでかくなります。
それに画質が悪くなるときたら踏んだり蹴ったりです。
|