Intelの次世代CPUについて語ろう 25

>>936
デコードやエフェクトをGPUに任せることはあってもGPUエンコは未来の話だ

Conroe糞過ぎてバロスｗｗｗ

>>939
と言うことは、
935のアドバイスはGPU(VPU)がデコードやエフェクト処理するから、
その分快適になるということなのかな？

エフェクトはあんまり使用しないけど、ハイビジョン映像だとデコードだけでも
CPUにかなり負担がかかるということなのかな？

使い勝手は知らないが、ATIのAvivoがGPUでエンコードを高速化してたが。

ビデオカードの動画再生支援機能が無いと、ハイビジョンどころか通常の動画再生もままならない。

>>942
ATIのアレはX1000シリーズ搭載マシンでしか使えないようにしてあるけど
今は単に手抜きCPUエンコで爆速に見せかけてるだけじゃなかったっけ？
スレ違いになりつつあるが。

ついでに乗って
MPEG -> Windows Media Videoの変換で
約30分のソースを変換するのにかかる時間は

Turion64 MT-34(1.8GHz L2 1M) + Radeon X1300LE
で16分

Athlon64 X2 4400+ (2.2GHz L2 1Mx2) + Radeon X1600XT x2(この場合の効果は不明）
で2分

catalyst 6.8での結果。
参考までに・・・

CPUとVGA両方変えたデータ出されてもなんの参考にもならん

Turion64 MT-34(1.8GHz L2 1M) + Radeon X1300LE
は10分だな、16分はmp3再生しながらの結果。

仮にCPUだけで変換しているのなら
Turion MT-34とAthlon X2 4400+の違いを加味しても
約5倍もの差は出ないと思いますが。

X1600とX1300のpixel shader数は12と4で約3倍の差
GPUでも何らかの処理が行われていると読み取れるのでは？

　　 ＿＿＿__
　　|　　|　コ |
　　|　　|. .ン.|
　　|　　|. 炉 |
　　|　　|.(笑)|
　|￣|￣￣||ii~ |
　|　 |　凸（￣）凸
　　　　　　　,,, ,,,
（´・ω・）つ┃┃~~~
ｶﾜｲｿｽ

>>946
HDDのオーバーヘッドとか？
怪しいからビデオカード変えてみてよ。

エンコードを手抜きする（処理を端折る）だけでそれだけ高速化するなら、
それはそれで結構なソフトウェア技術な気がする。

>>950
だが画質はかなり悪いぞ。
iPodやPSPに放り込んで見たら消す、ぐらいしか使えん気が。

>>950よ、950の言う通りだぞ

>>948
すんません。
お互い入れ替えてみましたが、時間かわらず・・・
パフォーマンス差はやはりCPUの違いによるものっぽいです。
もっと言えばネットワークカードの性能もあるかも。

ただ、GPUが全く使われていないのか？って事はよく判らない・・・
なぜなら、Brookで書かれた姫野ベンチの結果が
X1600,X1300で、ほぼ同じで約30000MFLOPS
（厳密にはGeForce6100に挿し奴のほうが
CrossFire Xpress 3200に指した奴より若干速い。）

即ちBrookで書かれたプログラムはR5x0,RV5xx世代でいう
1スレッド分（pixel shader 4本）しか使われていないという考察になる。
（だれか、X1900で試してみてほしい・・・）

でも、AVIVOの変換はCPUだけかな・・・

>>953
GeForce6100の内蔵グラフィックで試してみたら？

>>953
すまん、今ではATI以外では使うのは面倒みたいだ。

ttp://www.katch.ne.jp/~kakonacl/douga/avivo/avivo.html

> GPUに対応しているのはRADEON X1000シリーズだが、GeForce 6000シリーズでも
> GPUには依存せずにCPUのみでも動作するし、しかも驚異的に早い速度でエンコード
> するとのことだ。

> 2006年04月12日にATI Avivo Video Converter v6.4となって、ATI Catalyst(x32)ドライバに
> 追加インストールして利用する仕様になったので、RADEON X1000シリーズ専用版となってしま
> った。

> しかし、ATI DirectShow関連のフィルターは以下の如くインストールされるので、GraphEditを用
> いて利用することが可能だ

　　 ＿＿＿__
　　|　　|　コ |
　　|　　|. .ン.|
　　|　　|. 炉 |
　　|　　|.(笑)|
　|￣|￣￣||ii~ |
　|　 |　凸（￣）凸
　　　　　　　,,, ,,,
（´・ω・）つ┃┃~~~
ｶﾜｲｿｽ

AVIVO使ってみた
何気にこれ、AviSynth使えるんだな・・・

Celeron 2 Duo

今回のたるたるはまともな記事だにゃん

でも、大原氏の雑記での全方位ベンチマークについての追加コメントは読んでないようだな
読んでたら、今回のネタは書けないはず

ttp://www.yusuke-ohara.com/weblog2/archive/2006/09/post_46.html#more
>という訳で、本エントリの結論として「おっしゃる通り、原因は確定できません」ということで、お返事に代えさせていただきます。

大原がバカなところはここ
> K7/K8はIPC=6を狙えるアーキテクチャっつーことになっちまいます。
> K7/K8は一応デコード段がx86命令換算で３命令/Cycleのデコード性能なので、
> 普通に考えるとこんな形でμOpが投入される可能性は低いのですが、
> 今スケジューラに３つのLoad命令がデータ待ちしていて、そこに後から３つのALU命令(例えばNOP)がデコーダからやってきて、
> これが一斉に実行ユニットに投入されるとピーク時にはIPC=6という事になります。

3つのLoad命令がデータ待ち？
これK7/K8の欠陥部分だろう？
同時に3つのLoad命令が実行されるとでも思っているのか？、キャッシュが泣いてるぞ。
バカ正直な回路ではなく、いい加減な回路でムダで洗練されていないスケジューラと評価すべき箇所だよ。

リタイヤメントが3命令/clkだから瞬間最大なんて全然意味ない罠。
もし6μOPs分実行できてもリタイヤ待ちでストールするだけ。
整数とFP/SIMDパイプが分かれてる分潜在的には高い並列実行性能は得られるのだから
せっかく32byte/clkのフェッチ帯域にするなら、そのへんは改良の余地はあるのだけど。

デュアルコアItanium2をハイエンドからエントリーまで投入
日本HP、デュアルコアItanium2搭載サーバー新製品7機種を発表
http://biz.ascii24.com/biz/news/article/2006/09/07/664395-000.html

FB-DIMMのほうがより高い耐障害性を付加できるんだけどね
発熱がもたらす不安要素の方が大きいという判断だろうか

> 同時に3つのLoad命令が実行されるとでも思っているのか？、キャッシュが
> 泣いてるぞ。

キャッシュの効かないHPC系のアプリとかなら、まあ、ありうるでしょ。
アプリに依存した話。

Athlon 64はL/Sユニットが２つ(Load/Store両方向×１、Load片方向×1）しかない
同時に3命令はどう考えても無理だよ。

海洋研究開発機構が国内最大級のItanium 2システムを稼働
http://www.itmedia.co.jp/enterprise/articles/0609/05/news023.html

Itaniumイイヨイイヨー（・∀・）

確かにDirect PathとVecter Pathの2系統は強化して欲しいな

>>966
AMDのは欺しなんだよ、実行ユニットがあるように見せ掛けた欺しなw
ちらっと見るとLoadが同時に3つ行えるように見えるし、それでないとおかしい回路構成になってるが、
ダンゴが言ってるように真の実行ユニットは3つ存在しない。
つまりスケジューラがヘボくていい加減な訳で、同時に実行不可能なのに同時に3命令とも実行パイプラインへ投入してしまう。
これストールの原因だし・・・

┌──────┬───┬──────────────┬──────────────┬──────────────┐
│　　　　　　　　 .│ Clock │　　　　　　 機能限定版　　　　　　 .│　　　　　　 シングルコア　　　　　　│　疑似マルチコア(ニコイチコア)　 │
├──────┼───┼──────────────┼──────────────┼──────────────┤
│Pen4　 (90nm)│↑up　 │　　　　　　　　　 −　　　　　　　　　 │1コア Northwood (512KB)　　　　 .│　　　　　　　　　 −　　　　　　　　　 │
├──────┼───┼──────────────┼──────────────┼──────────────┤
│Pen4/D(90nm)│↑up　.│1コア Prescott-V　　　　　　　　　 .│1コア Prescott (1MB)　　　　　　　.│2コア Smithfield (2MB)　　　　　　 │
│　　　　　　　　 .│　　　　 │　　　　　　　　　　　　　　　　　　　　.│　　　　Prescott 2M (2MB)　　　　 │　　　　　　　　　　　　　　　　　　　　 │
├──────┼───┼──────────────┼──────────────┼──────────────┤
│Pen4/D(65nm)│　 −　.│1コア Cedar Mill-V　　　　　　　　　│1コア Ceder Mill (2MB)　　　　　　 │2コア Presler (4MB)　　　　　　　　 │
└──────┴───┴──────────────┴──────────────┴──────────────┘

┌──────┬───┬──────────────┬──────────────┬──────────────┐
│　　　　　　　　 .│ Clock │　　　　　　 機能限定版　　　　　　 .│　　　　　 真のマルチコア　　　　　 │　疑似マルチコア(ニコイチコア)　 │
├──────┼───┼──────────────┼──────────────┼──────────────┤
│core　 .(65nm)│　 −　 │1コア Solo Yonah-SC (1MB)　　　.│2コア Duo Yonah-DC (2MB)　　　 │　　　　　　　　　 −　　　　　　　　　 │
├──────┼───┼──────────────┼──────────────┼──────────────┤
│core 2 (65nm)│↓down│1コア Stealey (512KB)　　　　　　 .│2コア Duo Conroe (2MB、4MB)　 │4コア Quad Kentsfield (4MB)　　　│
│　　　　　　　　 .│　　　　 │1コア Millville (1MB FSB1066)　　 │2コア Duo Merom (4MB)　　　　　 │　　　　　　　　　　　　　　　　　　　　 │
│　　　　　　　　 .│　　　　 │2コア Allendale (2MB FSB800)　　│　　　　　　　　　　　　　　　　　　　　.│　　　　　　　　　　　　　　　　　　　　 │
├──────┼───┼──────────────┼──────────────┼──────────────┤
│core 2 (45nm)│↑up　 │1コア Perryville (2MB)　　　　　　　│2コア Duo Ridgefield (6MB)　　　　.│　　　　　　　　　　　　　　　　　　　　 │
│　　　　　　　　 .│　　　　 │2コア Wolfdale (3MB)　　　　　　　 │2コア Duo Wolffield (3MB)　　　　　│　　　　　　　　　　　　　　　　　　　　.│
│　　　　　　　　 .│　　　　 │　　　　　　　　　　　　　　　　　　　　.│2コア Duo Penryn (3MB、6MB)　 .│　　　　　　　　　　　　　　　　　　　　 │
├──────┼───┼──────────────┼──────────────┼──────────────┤

│core 3 (45nm)│↓down│2コア Silverthorme (4MB、8MB)　│4コア Quad Nehalem　　　　　　　　│8コア Oct Yorkfield (12MB)　　　　│
│　　　　　　　　 .│　　　　 │　　　　　　　　　　　　　　　　　　　　.│4コア Quad Bloomfield (6MB)　　 .│　　　　　　　　　　　　　　　　　　　　 │
│　　　　　　　　 .│　　　　 │　　　　　　　　　　　　　　　　　　　　.│4コア Quad Gilo　　　　　　　　　　 .│　　　　　　　　　　　　　　　　　　　　 │
├──────┼───┼──────────────┼──────────────┼──────────────┤
│core 3 (32nm)│↑up　 │　　　　　　　　　 ？　　　　　　　　　 .│4コア Quad Nehalem-C　　　　　　│8コア Oct 　　　　　　　　　　　　　　│
├──────┼───┼──────────────┼──────────────┼──────────────┤
│core 4 (32nm)│↓down│　　　　　　　　　 ？　　　　　　　　　 │8コア Oct Gesher　　　　　　　　　 .│16コア １６　　　　　　　　　　　　　　│
├──────┼───┼──────────────┼──────────────┼──────────────┤
│core 4 (22nm)│↑up　 │　　　　　　　　　 ？　　　　　　　　　 .│8コア Oct　　　　　　　　　　　　　　 │16コア １６　　　　　　　　　　　　　　│
├──────┼───┼──────────────┼──────────────┼──────────────┤
│core 5 (22nm)│↓down│　　　　　　　　　 ？　　　　　　　　　 │16コア １６　　　　　　　　　　　　　　│32コア ３２　　　　　　　　　　　　　　│
├──────┼───┼──────────────┼──────────────┼──────────────┤
│core 5 (16nm)│↑up　 │　　　　　　　　　 ？　　　　　　　　　 .│16コア １６　　　　　　　　　　　　　　│32コア ３２　　　　　　　　　　　　　　│
├──────┼───┼──────────────┼──────────────┼──────────────┤

Intel's Core 2 Quadro Kentsfield: Four Cores on a Rampage
ttp://www.tomshardware.com/2006/09/10/four_cores_on_the_rampage/

もうクロックを上げないのですか？
早く3.8Ghzの壁を破って欲しいのだが。

そこでPentium終了記念のPentium4 4GHz Premium Edtionの登場ですよ！

PenM〜Core派だがシダミルはちょっと確保しておきたい気分

早くCore 2最適化してよ
これ見てたら先走りが
ttp://jp.xlsoft.com/documents/intel/compiler/Intel_Compiler_v91_performance_indicators.PUBLIC.6-06.pdf

/QxTでSSE4使えるじゃん

あのさぁ、Intelに関する質問スレってないの？
いきなりだけど…

>>980
【ﾏﾀｰﾘ】Intel雑談スレ1coreめ【待ち】
http://pc7.2ch.net/test/read.cgi/jisaku/1143695185/

>>978
Itaniumの向上率がすごすぎて思わず笑った。

gccがはき出すItaniumバイナリは出来がよくないとは聞いてたけど。

>>981
さんくす！

>>982
実際カーネルサービスががんがん動くサーバではLinux + Itaniumは論外だよ
今更こんな話が出るぐらいだもんWindowsのほうが何ぼかマシなんじゃないか
普通はHP-UX選ぶだろうけどね
http://www.hpcwire.com/hpc/836590.html

いや、普通 Woodcrest か、さもなきゃ Opteron。

価格性能比で Itanium より圧倒的に優れてるし、
gcc でもそこそこ性能が出るから Linux でも大丈夫。
もちろん icc の方が性能が出るが、NetBurst や Itanium の場合ほどの差はない。

i

ItaniumサーバーならHP-UX(Windows?)
XeonかOpteron使え
この二つには日本海溝より深い隔たりがあると思うｗ

i