■次世代PowerPCを語るす vol.5

このエントリーをはてなブックマークに追加
274MACオタ>268 さん
>>268
1999年にわ既にPOWER=PowerPCすから、(スーパー)ハイエンドでわ既に
提示されていたと考えるべきす。
275名称未設定:02/10/26 01:22 ID:0SL7U+Tt


MACオタは、さらに論点を混乱させることで、己の愚かさを隠蔽できると考えているようです。

276MACオタ>269 さん:02/10/26 01:25 ID:fcc7CISj
>>269
命令ウィンドウを増やし、パイプラインを一新することを「刷新」と呼ばないなら
単に名前が"G4"のままであることに目を眩ませられているんだと思うす。
  -----------------------------
  Motola/Appleと共同作業をしているのか?
  -----------------------------
POWER4->PPC970を見れば判るように、IBM独自のアーキテクチャであろうと
同じ命令セットである限りPowerPC全体の革新にわ寄与するす。そういう視点
に欠けていることが問題すけど。。。
277名称未設定:02/10/26 01:26 ID:k+d/qdLI
>>235
TLP=Hyper-Threadingと勘違いしていないか?
TLPが有用だから、Power4はCMPなのだろ。
278名称未設定:02/10/26 01:27 ID:VfglA7x1


MACオタは、自らの視点の欠如に気がつくこともなく、他人の視点の欠如を指摘しようとしましたが、愚かな戯言に終わりそうです。

279MACオタ>272 さん:02/10/26 01:33 ID:fcc7CISj
>>272
IOPへのデコードわ、POWER4で完全に対称なIU, LSU, FPU等が2つづつあることと
関係が深いものと考えられるす。例えば"lmw}という命令を複数のロード命令に分解
したり、"lwzu"という命令をロードと加算に分解することで、全体的な命令の並列度
を上がることが考えられるす。
しかし、これわ対応する演算リソースが余っているという条件で成り立つ話で、決して
一般的に有効な話でわ無い筈す。
280MACドザ ◆I/6l6yJHSI :02/10/26 01:35 ID:J4/Ovpyb
さすがはMACオタ、振り上げた拳は何がなんでも下ろしません。(笑
281MACオタ>277 さん:02/10/26 01:36 ID:fcc7CISj
>>277
その通りす。ただし後藤氏の記事わPPC970わシングルスレッド
で済んでいるのに、過度にTLPを強調しているす。
282名称未設定:02/10/26 01:38 ID:k+d/qdLI
後藤氏の記事がすべて正しくて、バイアスがないといっている
わけではない。仕事の比重からすれば、x86プロセッサのほうが
詳しくて当然だろう。だが、特に対象をマックヲタク(!MACオタ)に
しているわけでもない記事として、問題があると論う程のことも
ないと思うのだが。
283MACオタ>282 さん:02/10/26 01:50 ID:fcc7CISj
>>282
細かい点わ、ともかくとして>>270に書いた話わ基本的な問題だと思うす。
284名称未設定:02/10/26 01:51 ID:k+d/qdLI
>>265
変に行間読まなければ、一般人は>>220のような解釈をしないと思う。
285名称未設定:02/10/26 02:15 ID:k+d/qdLI
>>283

ttp://www.zdnet.co.jp/enterprise/0210/22/op02.html
みたいな冷静すぎる意見に較べると、後藤氏はPowerPCアーキテクチャに
好意と期待を持っていると思うけどな。でもなければ、わざわざ2日続けた
記事を書きはしないだろう。
286名称未設定:02/10/26 02:37 ID:/aCK5PQw
>>227
Altivecのライセンスのソースはあった。製造契約のソースもあった。
だが、現状では納入のソースがないため、
「納入した」という部分については灰色と言わざるを得ないが…まあいい。

オタに1つ聞きたいのだが、>>223の数値を出すためには、
当然のことながら6.4GB/sを生かせるメモリ環境が必要になる。
問題は、これをどうやって確保するか。
PC3200-2ch、DDRU400-2ch、QBM800などが想定できるが、
いずれも2003年までに実現するためには、問題を抱えていると思うんだが。
漏れの見解はここに。
http://pc.2ch.net/test/read.cgi/mac/1035289350/155-156n
287名称未設定:02/10/26 02:55 ID:++78KOOG
>>Macオタ
前スレで「AltiVecのライセンス取得は任天堂GameCube用CPUの研究用」という
自ら「信頼性のある」ソースとして自信満々に出したものの情報を、
「1年ではCPUなんか設計できるわれないす。妄想す。」とはき捨てた挙句、
「それじゃあ、11月にライセンスもらって3ヶ月でIBMはG4を出荷できるのかよ?」
という発言にだんまりこいてる理由は?
288MACオタ>285 さん:02/10/26 10:12 ID:fcc7CISj
>>285
興味わあるけど、下調べが追いつかなかった。。。ということだと思うす。
289MACオタ>286 さん:02/10/26 10:14 ID:fcc7CISj
>>286
RDRAMも含めて、複数の可能性がある訳すから問題無いと思うす。
チップセットの開発スケジュールから考えて、既に決定済みでとっくに
設計自体も終わっていると思うすけど。。。
290MACオタ>287 さん:02/10/26 10:15 ID:fcc7CISj
>>287
そのすぐ後ろに書いてあるようにTony SmithわWebで情報を集めているだけ
のヒトでG5の腐れルーマーにもひっかかったような人物すから、「見解」の部分
わ怪しいモノす(笑)
291名称未設定:02/10/26 10:18 ID:rUOc508q
>>290
突っ込んで欲しい・・・?
その人MACオタそのものじゃん・・・(w
292名称未設定:02/10/26 11:33 ID:3NZ1NCkt
●Motorola社が一時公開していたプレゼンテーション資料にPowerPC 7457
の記載があった事に関連し、現在出荷されているPower Mac G4 (Mirrored
Drive Doors)/1.25GHzのPowerPC 7455は、他の1GHz、867MHzと比較
し、ダイサイズが小さくなりIDが異なっていることから、先行出荷された
PowerPC 7457/1.25GHzプロセッサーである可能性があるようです。

MACオタは前スレで否定してたけど、これについてどう思う?
293名称未設定:02/10/26 11:36 ID:3NZ1NCkt
4 名前:名称未設定 メール: 投稿日:02/10/14 12:18 ID:KkYseNd6
ところでMirroredDoor1.25Dualに0.13μ版G4が乗ったってホント?

6 名前:MACオタ>4 さん メール: 投稿日:02/10/14 12:52 ID:Cop5M7s/
>>4
ダイサイズを見る限り180nmプロセスのまます。Motorolaのセレクタガイド
にもXC7455わHiP6と記されているす。
http://e-www.motorola.com/brdata/PDFDB/docs/SG1007.pdf

13 名前:名称未設定 メール:sage 投稿日:02/10/14 13:29 ID:KkYseNd6
>>6
あーそうなんか。
山本氏のBBSでそんな書き込みがあったから、どうなんかなぁと思って。
さんくす。

#ところで、その見た限りっていうダイサイズはMACオタも実物を見たってこと?
#いや、上記のBBSにはダイサイズの縮小が確認できたって書いてあったからさ。

15 名前:MACオタ>13 さん メール: 投稿日:02/10/14 13:35 ID:Cop5M7s/
>>13
写真が公開されているすよ。ダイサイズわパッケージとの比率から判るす。
http://www.macbidouille.com/niouzcontenu.php?date=2002-09-26
294名称未設定:02/10/26 11:36 ID:/aCK5PQw
>>289
>RDRAMも含めて、複数の可能性がある
とはいえ、最近のアポーの傾向からみて、
RIMMのようなJEDEC規格に沿わないメモリを採用する可能性は低い。
むしろ「枯れた」技術を採用していく傾向が強いと思われ。
また、RIMMはメモリ自体のレイテンシーや、発熱が大きいという問題もある。
もし6.4GB/sをRIMMで達成するとしたら、PC800-4chになるわけだが、
これも問題点を含んでいる。

1.
RIMMはコストパフォーマンスが悪く、結果として極めて高価な製品となる。
Macの問題点の1つ「コストパフォーマンスの悪さ」は解決されない。
2.
また、RIMMは発熱が大きく、結果として冷却による騒音が問題になる。
最近の流れ「静音化」に逆行している。
また、アポーは主要な用途の1つに音楽制作を想定しているが、
そんなうるさいマシンは実用という面で問題が残る。
(歌録りに雑音が入ってしまうため)
3.
前述のメモリレイテンシーの問題。
i850E(PC1066-32×2)に比べて、iE7205(PC2100×2)の方が性能がいいらしい。
これは、iE7205のチップセットの設計が新しいこともあるだろうが、
RIMMのレイテンシーも影響していると思えるのだが。
295名称未設定:02/10/26 11:39 ID:3NZ1NCkt
ただ、MPC7457ならL2キャッシュ量で区別つくとも思うんだが、
お宝は、そこらには言及してないんだよね.......
296MACオタ>297 さん:02/10/26 12:10 ID:fcc7CISj
>>295
腐れルーマーらしい記事すね。本当ならその違うとかいうIDが出て
くる筈す。ダイ上のマーキングでマスクのリビジョンわ判るし、PVRの
ことならチップのバージョンが判るす。

ただ、最後期の7400の様にHiP7の7455が出てくる可能性わあるす。
297MACオタ>294 さん:02/10/26 12:12 ID:fcc7CISj
>>294
つい先ごろコストの高いPC2700を採用した実績もあるすから、汎用メモリなら
何を使っても不思議でわないす。
298y4d:02/10/26 12:16 ID:3lUKYe6w
>>297
コストと性能のバランスをみればRIMMよりええやろが!
と、強気な事をいってごめんなさい。
299名称未設定:02/10/26 12:16 ID:3NZ1NCkt
>>296
俺も現段階で7457が載ってるってのは懐疑的だけど。
ただ、293にあるように「ダイサイズの縮小もない」って言ってたけど、
それに関しては、MACオタも言を翻してると考えてもいいのかな?
300MACオタ>299 さん:02/10/26 12:18 ID:fcc7CISj
>>299
それわ自分でMacBidouilleの写真から計算してみれば良いかと思うす。
301名称未設定:02/10/26 12:22 ID:3NZ1NCkt
>>300
.............負けず嫌い。
302MACオタ@補足:02/10/26 12:26 ID:fcc7CISj
867〜1.25GHzまでいろいろオーバークロックしているヒトもダイサイズについて
わ何も語っていないす。
http://arstechnica.infopop.net/OpenTopic/page?q=Y&a=tpc&s=50009562&f=8300945231&m=9940912435&p=1

別に日和ってる訳じゃなくて、ダイサイズが小さいという話の信憑性わ
非常に低いすよ。確定情報があるなら、ぜひ教えて欲しいす。
303MACドザ ◆I/6l6yJHSI :02/10/26 13:02 ID:J4/Ovpyb
>>210
>64bit PPCわモード切り替え無しでユーザーモードの32bit PPCコードを動かすことが
>できるす。

に対する突っ込み(コピペ)>>233-234

>>270
> ・元からPowerPC命令セットの基本わ64bitで、サブセットである32bit
>  命令わ基本的に実行可能であることを知らない

あれ?表現が変わってるよオタたん。(笑

http://www.watch.impress.co.jp/pc/docs/2002/1022/kaigai01.htm
>PowerPCはもともとのアーキテクチャが64bitも想定した上で作られ、64bit版のPowerPC 620も
>作られたことは作られた。しかし、このCPUは登場が遅すぎ、また、オリジナルのアーキテクチャ
>では64bitモードと32bitモードを切り替えない限り、既存の32bitコードを走らせることはできなかった。

結局、オタたんの言うことはこの部分の反復に過ぎず、なんら反論になっていないわけだが。(笑

>>270
> ・PowerPCを命令セットでわなく、ハードウェア的なアーキテクチャと捉えている
>  ため、「いままでのPowerPC」などという存在しない概念を比較の対象としている
天上天下唯我独尊決め込むのも構わないと思うけど、自分の狭い視野を絶対的な価値観として
押しつけるような言動は如何なものかと思うすよ。(笑
304名称未設定:02/10/26 13:04 ID:/aCK5PQw
>>297
コストの問題もあるが、むしろPC2700が採用されたのは、
JEDECの規格が固まってからしばらくたってからではなかったか?
現時点ではRIMMはともかく、PC3200とQBMはJEDECの規格が固まってないし、
DDRUに関してもまだJEDECでは規格策定中の段階。
DDRU採用となれば、PPC970搭載機は2004年登場となるし、
これはマーケティング的に不利にならないか?
305MACオタ>304 さん:02/10/26 14:09 ID:fcc7CISj
>>304
もしかして6.4GB/s丁度の数字からずれるとなにか不都合があると
考えているすか?
970バスわ、パケット化された32bit幅のバスすからいわゆるFSBと
メモリバスの非同期に関する不具合わ無いす。むしろ、ぴったり6.4
GB/sにしても良いことも無いすよ。
メモリ側の技術わ、その時実現可能な適当に高速なものを使うと
いう以上のものでわ無い筈す。
306MACオタ>303 さん:02/10/26 14:18 ID:fcc7CISj
>>303
もともとどころかPPC970もモードを切り替えないとダメす。もっとも
それが関係あるのわOSだけで、スーパーバイザモードに関係ない
コードわ、32bitモードに切り替えずに64bitモードのままでも走るす。

この区別が記事の中でついていないのも問題す。
307名称未設定:02/10/26 14:19 ID:G73lR8l9
>>970バスわ、パケット化された32bit幅のバスすから
これってTSP/IPの超高速なイメージでしょうかね?
ちょっとくらいパケットロスがあってもそのスレッドだけ待たせて他の処理はすすむみたいな?
マルチCPUシステムに有利なのでしょうかね。4CPUとかも簡単にできるのか。
RAMってレイドできないのかな?
308名称未設定:02/10/26 14:21 ID:4Q1joNRg
>>304
おれもMACオタと同じようなこと感じたよ。
なんでそんなに同期させたがるんだ?
Max6.4GBってだけで、それじゃなきゃ動かないってことじゃないだろう。
そりゃPen4だって、グラナイトベイやi850Eの方が、ESB533の帯域を存分に
使えて(4.2GB)いいだろうさ。
でもRIMMのコストだののかねあいでi845シリーズをだしてきたわけでしょう
(グラナイトベイはまだ製品はでてないが)。
SDRAM用i845はサッパリにしても、DDR使えるチップセットは(だれもが
RIMMよりは劣ることをわかっていながら)数多く採用されているじゃん。

まずはグラナイトベイと同じくPC2100のデュアルチャネル、あるいはちょっと
がんばってPC2700のデュアルチャネルを実現ってとこからスタートするのであれば
十分あり得るのでは?
そのあとDDRllが広まってくればそっちにのりかえてもいいだろうし。
309MACドザ ◆I/6l6yJHSI :02/10/26 14:28 ID:J4/Ovpyb
>>306
論点は「PowerPC 620」すよ。
310MACオタ>309 さん:02/10/26 14:34 ID:fcc7CISj
>>309
PPC64のプロセッサわ620だろうが970だろうが同じす。
アーキテクチャの規定がそうなっているすから。
311名称未設定:02/10/26 14:35 ID:PKBWHqSE
>>308
>まずはグラナイトベイと同じくPC2100のデュアルチャネル、あるいはちょっと
>がんばってPC2700のデュアルチャネルを実現ってとこからスタートするのであれば
>十分あり得るのでは?
>そのあとDDRllが広まってくればそっちにのりかえてもいいだろうし。

はあ?
DDRが2chの規格がDDRllというんですけど?
312MACオタ>308 さん:02/10/26 14:36 ID:fcc7CISj
>>308
付け加えると公称のMaxわ「約」6.4GB/sで、x86の基準で言うピーク帯域わ
7.2GB/sだし。。。
313MACオタ>311 さん:02/10/26 14:38 ID:fcc7CISj
314MACドザ ◆I/6l6yJHSI :02/10/26 14:42 ID:J4/Ovpyb
>>310
オタたんのお題目上はそうなってるかもしれないすけど、
>>233-234のID:CvKFKqpjさんが引っ張ってきた資料ではそうなってないすよ。
315MACオタ>314 さん:02/10/26 14:47 ID:fcc7CISj
>>314
その資料でもそうなってるす。誤解わ単純にPPC970をBook Eと思い込んでいる部分す。
316MACドザ ◆I/6l6yJHSI :02/10/26 14:56 ID:J4/Ovpyb
>>315
>その資料でもそうなってるす。
どの辺に書いてあるすか?

>誤解わ単純にPPC970をBook Eと思い込んでいる部分す。

http://www.watch.impress.co.jp/pc/docs/2002/1022/kaigai01.htm
>PowerPC 970の64bit拡張は、この問題を回避するデザインになっている。これは、
>'99年に発表されたPowerPCの命令セット拡張「Book E」に基づいている。Book Eでは、
>32bitと64bitはモード切り替えを排除し、その代わり、新しい64bit命令が定義されている。
>つまり、新たな64bitのインプリメント方法が定義された。これに準拠すると、
>既存の32bitコードと新しい64bitコードを、モード切り替えなしで走らせることができる。

Book Eに触れた部分はここだけすけど、どこからそんな電波を受信したすか?(笑
317名称未設定:02/10/26 15:07 ID:gTwr68Yq
まずはそのBookEの在り処を示してくれ。
318定例:02/10/26 15:47 ID:hXUteiS7
>>2ゴラァァアァァァァ!!
何が前スレだ! こいつらは相変わらず無視かよ!
↓↓↓
>>36の中身を参照

あと、スレッド復活おめでとう。
319MACオタを2位にしましょう:02/10/26 17:15 ID:ZQe7QUvm
http://www17.big.or.jp/~bbb/p/tvote.cgi?event=netidol&show=10
あと40000票で2位に浮上するす。
みんなの力を貸して欲しいす
320名称未設定:02/10/26 17:56 ID:4Q1joNRg
>>311はどこでそんなことを教えてもらったんだ…
321不定期:02/10/26 17:57 ID:+JwdW58U
こんなのみつけた。
でも、MACオタはきっと自分のスレッドを建てる。
彼は古い人間だから、2ちゃんの現状が変わったのも知らずに、
また重複スレになろうがお構いなしに。。

P4-PCやXeon-PCてPMG4より速いんですか?その6
http://pc.2ch.net/test/read.cgi/mac/1032957357/944
/*名前:名称未設定 メェル:sage 投稿日:02/10/25 11:55 ID:LABe+c7p
で、現在PowerPC-Mac vs x86-Winスレってのはこんだけあるんだが、
.
PowerPC-Mac vs x86-Win関連
http://pc.2ch.net/test/read.cgi/mac/1034604195/l50
http://pc.2ch.net/test/read.cgi/mac/1034138934/l50
http://pc.2ch.net/test/read.cgi/mac/1033489550/l50
http://pc.2ch.net/test/read.cgi/mac/1032957357/l50
http://pc.2ch.net/test/read.cgi/mac/1034858131/l50
http://pc.2ch.net/test/read.cgi/mac/1031990680/l50
http://pc.2ch.net/test/read.cgi/mac/1034856990/l50
http://pc.2ch.net/test/read.cgi/mac/1032312409/l50
http://pc.2ch.net/test/read.cgi/mac/1034583076/l50
http://pc.2ch.net/test/read.cgi/mac/1033903901/l50
http://pc.2ch.net/test/read.cgi/mac/1033200377/l50
http://pc.2ch.net/test/read.cgi/mac/1032349847/l50

「Power-PC vs x86-PC 統一スレ」みたいな感じでまとめてしまうか?
*/
322名称未設定:02/10/26 18:00 ID:/7SomnpS
>>321
ウゼェんだよ、カス。
323名称未設定:02/10/26 18:39 ID:OV5ZtjlK
>>322
オレもそー思う。。
324名称未設定:02/10/26 18:48 ID:LWElBqWb
昨日一日は静かだったのにな(w
325名称未設定:02/10/26 19:13 ID:/aCK5PQw
>>305>>308>>312
>もしかして6.4GB/s丁度の数字からずれるとなにか不都合があると
>考えているすか?
別に不都合があるとは考えていない。
ただ、PPC970は(少なくとも当初は)ハイエンドマシンに使うのだから、
メモリバスが足を引っ張る形になるのは勿体無いと考えているだけ。

>そりゃPen4だって、グラナイトベイやi850Eの方が、FSB533の帯域を存分に
>使えて(4.2GB)いいだろうさ。
少なくともPowerMacに採用された場合は、ハイパフォーマンスを要求される分野、
アポーの想定だと動画や音楽になるだろう。
この分野について言えば、P4-3Gでもまだ正直足りないと思う。
(もちろんそんなものはないことは百も承知だが)
P4-5Gクラスにならないと余裕は出ないと思う。
そして同時に、この2つはメモリ帯域の広さがきいてくる分野でもある。

>SDRAM用i845はサッパリにしても、DDR使えるチップセットは(だれもが
>RIMMよりは劣ることをわかっていながら)数多く採用されているじゃん。
あくまでそれはミドルレンジの話であって、
ハイエンドではi850系が現時点では採用されている。
DELLもDimension8200は現時点ではi850Eだ。
iMacならともかく、PowerMacはハイエンドモデルだろ?
6.4GB/sが生かせないのは商品としてどうか、と思っているだけだ。
P4を例に出せば、最初に出たのは3.2GB/sが生かせるi850だったし。
326名称未設定:02/10/26 19:25 ID:Y+Ec4CrV
>>321
不定期はまだアク禁になってねーのかよ。
327名称未設定:02/10/26 19:43 ID:gTwr68Yq
おぉ〜、書き込みできてる。復活おめ〜。
328MACオタ>325 さん:02/10/26 19:49 ID:fcc7CISj
>>325
とりあえず「メモリ技術だけが制限要因になる」というレベルに
なったことを喜べば良いんじゃないすか?余った帯域わインラ
インキャッシュの復活という形でつかうかもしれないす。。。
329名称未設定:02/10/26 19:50 ID:gTwr68Yq
>>321 vsスレは荒れやすいので、vsスレと、専門スレを分離希望。
330名称未設定:02/10/26 19:53 ID:4L3qMmPh
MACドザは自分のスレへカエレ!
331名称未設定:02/10/26 20:05 ID:/aCK5PQw
>>328
実はそうでもない。>>223の数値はAMDのHammerに負けている。
そしてメモリ帯域が足りないとなれば、当然>>223の数値は出ない。
そしてHammerのFSBは266MHz(333MHzかも?)

音楽制作の場合、PC内部で完結させる方向に流れつつあるし、
(それはLogicのAU、CubaseのVSTなどが傍証)
実用上では体感できないスペックの差がソフトシンセの発音数などに現れるだけに、
そういう制限要因が気になってくるのだが。
332MACオタ>331 さん:02/10/26 20:11 ID:fcc7CISj
>>331
  ------------------
  とりあえず「メモリ技術だけが制限要因になる」というレベル
  ------------------
これ「性能が」じゃなくて「帯域が」なんすけど。。。
333名称未設定:02/10/26 20:14 ID:4Q1joNRg
>>ID:/aCK5PQw
あんた、すぐあれるこのスレの中で数少ないまともな対応だな。
すぐハァ?とかいうやつ多い中で。
ほっとしたよ。
Macドザとかは読み飛ばしてるとはいえ、うっとおしいのは確かなんだよね。
ところでHammerのFSBが266ってAthlon XP2700, 2800より下がるのか?
この二つはFSB333だし。Hammerはようしらんのだが。
334名称未設定:02/10/26 20:24 ID:gTwr68Yq
>>331 IBMがMPFで発表した数字、つまり>>223の数値には環境が示されていない。
従って、メモリ帯域が6.4GB/s以下だとその数字がでないとも言い切れない。

また、AMDがMPFで発表した数字はOpteron/PC2700の数字。
Opteronと言っている段階で、PC2700x2ch(5.4GB/s)と推測できる。

Hammer@2GHzは5.4GB/sでSpecIntが1202とすると、
970がSpecInt937の時のメモリ帯域は
970見積帯域= 5.4GB/s * 937 / 1202 = 4.2 GB/s

以上からIBM発表値はDual PC2100時の性能だと予測できる。
ただし、SpecIntがメモリ帯域ネックだと仮定した場合。
335名称未設定:02/10/26 20:32 ID:gTwr68Yq
>>333 ゾロ目おめ。
HammerはメモリがCPU直結になったため、従来の意味のFSBはない。
外部I/FはメモリがDDR333サポート、InterConnectは1.6GHz(800DDR)
336名称未設定:02/10/26 21:59 ID:JgmCShEW
>>331
アップルにとって基本的にAMDのCPUよりインテルのP4に負けないのであれはマーケット的にOKだと思う。
それにHammerはメモリーコントローラが統合してるが将来的に問題になるかも・・・。
337名称未設定:02/10/26 22:03 ID:/aCK5PQw
>>332
>これ「性能が」じゃなくて「帯域が」なんすけど。。。
PPC970については現物がまだないので何とも言えないが、
少なくともメモリ帯域が性能低下の一因になることは、P4では証明されている。
そして、動画、音楽(いずれもこれはアポーが想定しているユーザーだが)の場合は、
このメモリ帯域がアプリにおいて大きく影響してくる分野だ。
PPC970の性能が高そうなのは判った。だが、PCとしてトータルで考えた場合、
CPUの性能だけが高くても、足腰が弱ければ絵に描いた餅になってしまう。
漏れが懸念しているのはそこ。

>>333
HammerがFSB266立ち上げの可能性が高い、というのは、
ThoroughbredがFSB266より上がらない、とされていた時代の話で、
現実には(一説によるとnVIDIAの要請のためとされているが)、
ThoroughbredとBartonはFSB333となったから、
HammerもFSB333立ち上げになる可能性はある。だから「FSB333かも?」と書いた。

>>334
>メモリ帯域が6.4GB/s以下だとその数字がでないとも言い切れない。
MPFが商品売りこみの場という側面も考えた上で、
プレゼンテーション値としてボトルネックがない状態、
つまりメモリ帯域6.4GB/sの時と解釈したんだが。
まぁ、漏れが間違いという可能性も否定できないし、現物出ないと何とも…。
>Opteronと言っている段階で、PC2700x2ch(5.4GB/s)と推測できる。
HammerのFSBは266or333だから、恐らく1chでは?>PC2700
338名称未設定:02/10/26 22:23 ID:/aCK5PQw
>>336
ことマーケティングという部分で考えれば、Hammer>Prescottとなった場合、
Intelとの比較が意味を持たなくなる可能性も捨てきれない。
また、こういう情報はあるが、
http://www.watch.impress.co.jp/pc/docs/2002/0131/kaigai01.htm
Prescottは32bitでの立ち上げになるだろう(現時点の情報だと
比較広告にしても「なんだ、32bitと比較できる程度の性能差か」と取られる
………というのは考えすぎか?(w
まぁ、漏れは別にAMD信者ではないが、PPC970の不安要因と感じているだけ。
339名称未設定:02/10/26 22:34 ID:LWElBqWb
>>338
たとえ性能がHammerの方が上になったとしても、AMDの方が出荷量が多くなることは
PPC970のライフタイム中はありえないと思われ。
市場で支配的な方が比較対照に選ばれるのは、自然かと。
340MACオタ>337 さん:02/10/26 22:35 ID:fcc7CISj
>>337
帯域勝負のアプリなら、AltiVecが効く側面が多いすからSPECより遥かに
PPC970わ有利になるすけど?
341名称未設定:02/10/26 22:41 ID:gTwr68Yq
>>337 HammerのFSBは定義が難しい。
HammerはDDR333サポートで、
ClawHammerはAthlonDT,DDR333x1chで、
SledgeHammerがOpteron、DDR333x2ch。
すでに公表された情報なので、自分で調べておいてね。
342名称未設定:02/10/26 23:37 ID:/aCK5PQw
>>339
確かに市場での支配力を見れば…納得。
もっとも、そうなればIntelとの比較広告自体をしてこなくなるかも?
「x86最速CPU」との比較ではなくなってしまうのだから。

>>340
論点がズレている。言いたいことは「x86との比較」ではなくて、
PPC970の性能を生かし切れないことが確定的な
(ここではメモリ帯域がボトルネックになること)
商品を出すことがどうか、ということなのだが…。
AltiVecがそういう側面で有利なのは、
音楽アプリが「G4推奨」となっていることから判る。
そうではなくて、現状のハイエンドPCをもってしても
スペック不足な動画や音楽といった分野に重点を置くのなら、
(アポーがFCP出したことや、emagic買収したことからもそれは明らか)
少なくとも最上位マシンにおいては、PPC970の性能を出しきれる
メモリ環境が必要とされるのではないか、ということ。
まぁ、動画はともかく音楽はニッチ市場だから、
(梅田ヨドバシにはPhotoshopはズラリ並んでいたが、
CubaseSXは1つしかなかった)
そんな採算に合わないものに注力するのは無駄という発想もあるが…。

>>341
情報thx&不勉強スマソ
343 :02/10/26 23:39 ID:BZPdv3hO
ところで、PPC970のベースクロックっていくつなの?
344名称未設定:02/10/26 23:45 ID:4Q1joNRg
>>343
どっかで900MHzってでてだけど、6.4GBの帯域ってことは800MHzなんだろうか…
わからんけど。
345名称未設定:02/10/26 23:56 ID:gTwr68Yq
>>343 970busはCPUクロックの1/2。
1.8GHzなら900MHz
1.2GHzなら600MHz
POWER4のBusと同じ造り。
346MACオタ>344 さん:02/10/26 23:56 ID:fcc7CISj
>>344
450MHzのDDRで900MHzす。
6.4GHzわ、パケットロスかエラー訂正を差し引いた実効値す。
347  :02/10/26 23:56 ID:BZPdv3hO
>>344
900mhzですか。
 ちなみにペンティアム4はいくつなんでしょうか?
348MACオタ>347 さん:02/10/26 23:58 ID:fcc7CISj
>>347
現在133MHzのQDRで533MHzす。
349名称未設定:02/10/26 23:58 ID:gTwr68Yq
>>346 DDRというソースは?
POWER4と造りを変えてきたってことかな?
350342:02/10/27 00:04 ID:3fSHlg1w
後、気になったのでもう一度>>297に突っ込んでおくが、
>つい先ごろコストの高いPC2700を採用した実績もあるすから、
SD-RAMやPC2100との比較ならともかく、
PC2700は別に高価でも何でもない。RIMMと比較すればPC3200でもはるかに安い。
http://watch.impress.co.jp/akiba/hotline/20021019/p_mem.html
http://watch.impress.co.jp/akiba/hotline/20021026/p_mem.html
PC3200についてはコストよりも
JEDECの規格が確定していないことの方を問題視しているのだが?
PC2700については、JEDECの規格が確定したことと、
ベースクロックが同じ167MHzで同期がとりやすいことから、
鉄仮面で採用したと思われ。
351342:02/10/27 00:07 ID:3fSHlg1w
>>346
となると、ピーク値で7.2GB/sともとれるから、
PC3200-2chでも間に合わないということ?(汗
352名称未設定:02/10/27 00:10 ID:1Ap5v+mU
6.4GB/sから5.4GB/s(PC2700X2Chだと仮定して)に下がっても実際の処理速度が
極端に低下する事はないと思う。
コスト的に考えても最初のPowerMacG5はPC2700を選択するのでは?

そもそも、SpecIntのベンチマークテストがメモリ帯域の影響をどれくらい受けるかな?
SpecInt事は詳しくは分からないけどベンチマークテストのプログラムなんて
ほとんどキャッシュに収まるサイズだと思うからそんなに影響はないと思うけど・・・。
353342:02/10/27 00:19 ID:3fSHlg1w
>>352
>コスト的に考えても最初のPowerMacG5はPC2700を選択するのでは?
>>350のリンク先見れば判るんだが、
PC3200とPC2700でそこまでコスト的に大きな差はないのでは?
2003-Q3時点でさらに差が縮まってる可能性も否定できんし。
漏れの指摘した問題点を逆に取れば「JEDECの規格がそれまでに確定すれば、
アポーも採用の可能性がある」ということにもなるし。

しかし、PC3500なる代物があるとは。漏れも情報古いな。
こんな可能性は極めて低いが、PC3500-2chとなれば、
帯域7.0GB/s…凄いな。
354名称未設定:02/10/27 00:22 ID:DGI7ut/0
>>352 Specは複数のプログラムの総合評価なので、
一言でいうと誤りがあるが、誤りを覚悟で言うと、
命令はキャッシュに収まるが、データは収まらない。
したがって、一部はメモリ帯域が効く。
355名称未設定:02/10/27 00:34 ID:zDpSIi9H
>>PC3200とPC2700でそこまでコスト的に大きな差はないのでは?
>>353
PC3200はコスト的問題というよりも、信頼性がまだまだ全然低いという点で
問題があるからっしょ。
実際KT400とかだってめっちゃくちゃモジュールだのチップだの選んだ上でなんとか
PC3200が動くかってぐらいだし(じっさいKT400を採用しているマザーのほとんど
がPC2700までの動作保証しかしてない)。扱いとしてはOCモノってことなんで
しょう。
PC3500なんてCorsairのOC品でしょ。OC厨が買うだけで、対応してるママンなんて
ないし。正式な規格となることは考えられないよね。
356MACオタ>349 さん:02/10/27 00:38 ID:g+8zsjmd
>>349
ExtremeTechのこの記事す。
http://www.extremetech.com/print_article/0,3998,a=32445,00.asp
  ---------------------
  The front-side bus electrically runs at 450-MHz, double-clocked to an effective rate of 900-MHz,
  ---------------------
357MACオタ@補足:02/10/27 00:39 ID:g+8zsjmd
実際にわPOWER4のFabricバスもDDRだったんじゃないすかね。
外販するチップじゃ無いすから、電気的な仕様わ明らかにされて
いないすけど。
358名称未設定:02/10/27 00:41 ID:3fSHlg1w
>>355
>PC3200はコスト的問題というよりも、信頼性がまだまだ全然低いという点で
>問題があるからっしょ。
一時のPC2700と同じと考えていいのかな?(w
まぁ、少なくとも現時点では信頼性に問題ありありだなぁ。
ただ、IntelがPC3200に興味を示しているという情報は気になる。
JEDECの規格が固まるのかな?
http://www.watch.impress.co.jp/pc/docs/2002/0913/kaigai01.htm

>PC3500なんてCorsairのOC品でしょ。OC厨が買うだけで、
>対応してるママンなんてないし。
>正式な規格となることは考えられないよね。
情報サンクス。まぁ、漏れも「可能性は極めて低い」と書いたけど(w
359MACオタ>355 さん:02/10/27 00:45 ID:g+8zsjmd
>>355
PCのマザボの品質も一つの要因だと思われるす。
AppleがPC2700でunbufferedのDIMM x 4を保証しているのわ流石す。
360名称未設定:02/10/27 00:48 ID:3fSHlg1w
>>359
逆に質問。
「JEDECの規格が2003-Q3までに確定する」という条件さえ整えば、
PC3200採用の可能性はあるとみるか?
361名称未設定:02/10/27 00:52 ID:DGI7ut/0
>>357 さんくす。
プローブ付けてみないとほんとの所は闇の中だね。

ただ、技術的には単方向なら900MHzぐらいなら問題なく動作可能な点、
紹介記事にはPOWER4は1:2と書いてあって、DDRの所(MemoryController)
は1:n DDRって明記してあったからFabricの方はSDRではないかとね。

ただ、HypterTransportは単方向で800MHz x2(DDR)の1.6GHzだから
450MHz x2(DDR)の900MHzだと、技術的には見劣りする。
362MACオタ>361:02/10/27 01:03 ID:g+8zsjmd
>>361
  ---------------------------
  HypterTransportは単方向で800MHz x2(DDR)の1.6GHz
  ---------------------------
その辺わ、信号レベルに依存すると思われるす。LVDSを採用したRapidIO
だと500MHz DDRから始めるし、速度優先で非標準の信号仕様のHTわ
800MHz DDRす。
汎用のチップ間接続と縁が無い970 busわ、いつでも信号レベルの変更が
可能すから、900MHzが限界というものでもないかと思うす。
363名称未設定:02/10/27 01:15 ID:3fSHlg1w
う〜ん…CPU周辺の話題は「次世代PowerPCを語る」こととは関係なかったかな?
もしそうなら、スレ汚しスマソ。
ただ、PPC970を生かしきった環境には興味あったんだよね…。
364名称未設定:02/10/27 01:24 ID:DGI7ut/0
>>363 俺的には問題ないよ。
PPC970を活かしきった環境は、時の標準を使うことになるだけで、
どの標準が来ても可能だと思う。

PC2700のままなら、PC2700x2ch(5.4GB/s)で十分だし、
PC3200ならPC3200x2chでフルスペック、
DDRII533(PC4200?)が来たら、PC4200x2ch(8.4GB/s)で帯域がちょいあまる。
QBM800が来たら、QBM800x1chでフルスペックになるしね。
365名称未設定:02/10/27 01:28 ID:DGI7ut/0
>>362 『900MHzが限界でないというのは』確かにそうだね。
CPUクロックの1/2がBus速度なので、2,..,3GHzになったら、
Busも1,..,1.5GHzにスケールアップすることになるしね。
366名称未設定:02/10/27 01:33 ID:wSlf6UW7
MACオタと腐れルーマーの違いについて教えてください。
367名称未設定:02/10/27 01:37 ID:DGI7ut/0
>>366 面白すぎて、、、、、、、、、、ゴメン>オタ。
風情と風評。
368名称未設定:02/10/27 01:42 ID:3fSHlg1w
>>364
音楽は数msのズレが致命傷になるからなぁ…。
後、ちょっと処理がモタるとアウトだし。
で、スペックにも注文がきつくなる(w

24bit/96KHzのAIFFを16トラックぐらい同時再生したり、
ギガ単位のサンプルを複数読み込んでも大丈夫な環境が理想なんだが…。
(EXS24でGIGAフォーマットが読めるので、これは非現実的ではないけど)
まぁ…こんなのはもう2-3年たたないと無理かな?(w
369名称未設定:02/10/27 01:43 ID:3fSHlg1w
>24bit/96KHzのAIFFを16トラックぐらい同時再生したり、
スマソ、そのぐらいは何とかなるか(汗
できることならMTRよろしく64パート…無茶言い過ぎや(w
370MACオタ>368:02/10/27 01:47 ID:g+8zsjmd
>>368
それがどういう処理なのかを明示できれば、どこかに問題があるのか
はたまた、最初からハードウェア的に不可能な領域になるのか、という
議論ができるすけど。。。
371名称未設定:02/10/27 01:49 ID:wdyhFtB4
DAW系はFPUが重要みたいな事をどっかで見た気がするけど
なんか関係ある?
372名称未設定:02/10/27 01:56 ID:3fSHlg1w
>>370
詳しくはこのあたりを。
http://www.japan.steinberg.net/
http://www.midia.co.jp/PRODUCTS/emagicsoft/lp5/index.html

簡単に説明すると、
「PCを楽器&MTR代わりに使う」ということ。
EXS24はサンプラー(実際の音を取りこんで演奏するもの)で、
このサンプルが大きいものだと1.5Gとかある。
これを16個ほどすべてメモリ上に展開した上で演奏ができるかどうか。

また、一般的なAIFFは16bit/44.1KHzで、24bit/96KHzとなると、
サイズが単純計算で3倍ほどになる。
こいつを30-40ほど同時再生することができるか。
373不定期:02/10/27 01:58 ID:8jJL2CeB
>>322-323 また不法侵入ドザか!
>>370 また揚げ嵐か!
>>329 >>333の言葉を借りるけど、すぐあれるこのスレの中で数少ないまともな対応だな。
ほっとしたよ。

>>366-367 ワラタ
>>368-369 オイラも知りたい
374MACオタ>372 さん:02/10/27 01:59 ID:g+8zsjmd
>>372
それが単純に楽曲データをサウンドチップに転送するだけなら
単なるBlockCopyの性能だけすけど、そんなものでわ無いすよね?
375名称未設定:02/10/27 02:05 ID:3fSHlg1w
>>374
場合によってはPC内でAIFFを作製しながら、ということになる。
例えばソフトシンセの場合がまさにそれ。
仮にダイレクトモニタしながらリアルタイム入力するとなると、
PC内の演算でAIFF作製&複数のAIFF再生を同時にこなさないといけない。
また、前述のようにそれがサンプラーだとした場合は、
メモリ上にあるサンプルから音階を検出してAIFFを作製しながら、
片方で複数のAIFFを再生。
しかも、そのAIFFはリバーブなどのエフェクトもかけなくてはならない。
これも演算が必要になってくる。
376名称未設定:02/10/27 02:11 ID:3fSHlg1w
377MACドザ ◆I/6l6yJHSI :02/10/27 02:16 ID:eqWJtM69
>>372
全部メモリに展開する必要はないのでは。
サンプルの先頭から適当な量をメモリ上に展開しておいて、
残りはHDDなり何なりからストリーミングすれば十分でしょ。
378MACドザ ◆I/6l6yJHSI :02/10/27 02:16 ID:eqWJtM69
ところでオタたん、>>316は無視かい?
379名称未設定:02/10/27 02:18 ID:3fSHlg1w
>>377
これはHALionの例だが、音飛びの原因になる>HDDストリーミング
リアルタイム演奏を前提とすれば、
メモリ上にすべて展開するのが望ましい…らしい。
380名称未設定:02/10/27 02:22 ID:3fSHlg1w
http://www.japan.steinberg.net/products/halion/index.html
説明不足スマソ。これがHALion。
381名称未設定:02/10/27 02:38 ID:DGI7ut/0
1) 32bit/96KHzの256トラックの再生を考えると、
32bit x 96KHz x 256track ÷ 8bit = 96MB/s <<<< 2.7GB/s
2) Effect: 1track 1stepに100演算(FFTでは10演算程度)をすると仮定すると、
100op x 96KHz x 256track = 2.4Gop/s
3) Altivec 128bit,32bit x 4op/clock, 1.8GHz
4op x 1.8GHz = 7.2Gop/s >>>> 2.4Gop/s

以上から、PPC970では256トラックを演奏するに足る性能がある様に見えます。
ただし、実際の使用上ではVSTの発音数制限等の問題が発生していることを
考えると、純粋CPU性能とは別の問題があることが考えられます。

つまり、本当のボトルネックは別の所にある。
382名称未設定:02/10/27 02:45 ID:DGI7ut/0
>>381で言ってるボトルネックはみなさんご存じと思います。
そうです、帯域保証するためには最高性能や平均性能を論じても
無駄ということです。
『最低保証できる性能』がどれだけかを見極めることが必要になります。
383名称未設定:02/10/27 02:46 ID:3fSHlg1w
>>381
なるほど…。CubaseSXで最高200トラックだから、そっちは問題ないかも?>AIFF再生
VSTiの発音などの演算はどうなんだろ?
例えば(CubaseSXの上限で考えると)VSTiを32個立ち上げて、
すべてリアルタイム演奏となると、どのぐらいの負担になるか興味はあるが。

>つまり、本当のボトルネックは別の所にある。
例えば、HDD転送速度など?
384名称未設定:02/10/27 03:01 ID:DGI7ut/0
最初に結論を書くと、MacもWinもリアルタイムOSではないので、
最低保証性能に関しては、ハード屋の俺には実際の所は分かりません。

今の環境は最高性能を上げれば、最低性能も上がるでしょうという
極めていい加減な論理で動いているとしか思えません。

>>383 HDD転送速度とかも確かに要因の一つです。ただし、MacやPCの場合は
いろんなソフト(OS,Driver,アプリケーション等)が勝手気ままに動いている
ため、1アプリケーションの実行を固定間隔で保証できない所が問題です。

望むべきは、MacOSXにリアルタイム処理の機能を追加されることでしょう。
385MACオタ>382 さん:02/10/27 03:04 ID:g+8zsjmd
>>382
実際のデータの流れわ、読み書き両方が発生するすからその2倍必要
ということすかね。。。
フィルタがFFTだとすれば、100演算どころでわ無いのでわないすか?
386名称未設定:02/10/27 03:12 ID:DGI7ut/0
>>385 1stepの話だから、1つのdt区間の係数求めて終わりだからその程度。
96kHzで10秒だと、96KHz x 10秒 x 10opで9.6Mopが必要になる。(結構重い)
387名称未設定:02/10/27 03:18 ID:7d9RuwsT
sakuragiはバカ。
388名称未設定:02/10/27 13:14 ID:3fSHlg1w
>>384>>386
>ただし、MacやPCの場合はいろんなソフト
>(OS,Driver,アプリケーション等)が勝手気ままに動いているため、
>1アプリケーションの実行を固定間隔で保証できない所が問題です。
なるほど。つまりは音楽用に使う場合はOS自体がボトルネックになっている?
(私は所詮演奏屋が必要上知識を集めただけなので、詳細については怪しい)
音楽用環境を確保するためには、
1.常駐は入れない
2.周辺機器もオーディオカード、VGAなど必要以外つけない
(なぜVGAが必要かと思うかもしれんが、
オンボードだとVRAMをメーンメモリと共有するため音飛びが発生しやすい)
3.購入直後にHDDをフォーマットして、1つのOSのみの環境にしてしまう
(現状だとOS9のみ。来年移行の筐体が現時点で音楽不向きなのはそのため
なんせDAWアプリはClassicでも動かない)
まぁ、これでも完全とは言えないんだけど…。

>望むべきは、MacOSXにリアルタイム処理の機能を追加されることでしょう。
同意です。

最近の流れとしては、実は32bit/192KHzへの移行が始まっていまして、
この場合だと(386さんの計算から推定)
32bit/192KHzの256トラックの再生を考えると、
32bit x 192KHz x 256track ÷ 8bit = 192MB/s
200トラック前後でも、HDDストリーミングが間に合わなくなる?
となると、全部の曲データとサンプルデータをメモリ上に展開しないといけないから、
4GBじゃとても足りない…。