Intel Larrabee 2コア

IntelのLarrabee(ララビー)について語るスレです。

■前スレ
Intel Larrabee 1コア
http://pc11.2ch.net/test/read.cgi/jisaku/1217915128/

■巷で流れている情報
・マルチコアでなくメニーコアと呼びます
・Pentiumベースのx86コアを多数敷詰めたGPU
・GPUとしての出荷予定は2009年後半〜2010年
・DirectX、OpenGLに対応
・将来的にはGPU以外の市場(並列コンピューティング等)も狙ってる

その他、追加項目は >>2-10 で

ここまでテンプレ

乙

たぶんIDFで発表があると思うが
当たってたら褒めてくれ
http://dango.chu.jp/tripper/20090326.html
http://dango.chu.jp/tripper/20090325.html

Intelの単体ゲーミングGPUが2007年夏〜秋頃に登場
http://techreport.com/discussions.x/10549

Intelの単体VGA(Larrabee)は2008年前半に登場し
2008年の単体VGA総出荷量の20〜30%を占める、価格は$300以下
http://www.digitimes.com/mobos/a20070606VL207.html

「2008年にはLarrabeeの動作デモを公開する」
製品の投入時期については「2008年末〜2009年」
http://pc.watch.impress.co.jp/docs/2007/0611/kaigai364.htm

Larrabeeの開発者向けボードは2008年11月に登場する
http://en.hardspell.com/doc/showcont.asp?news_id=3793

Larrabeeプロセッサの第一陣は，2009年終わりから2010年初めにかけて登場
http://itpro.nikkeibp.co.jp/article/NEWS/20080805/312163/

1月に出ると予想されていたシリコンが更に6ヶ月遅延
http://www.realworldtech.com/forums/index.cfm?action=detail&id=96437&threadid=96378&roomid=2

Larrabeeを市場へ投入できるのは早くても2010年後半
http://www.4gamer.net/games/085/G008505/20090217033/

>>5
年単位で遅延しているな。

589 ：,,・´∀｀・,,）っ-○◎● [sage] ：2009/03/15(日) 11:04:00 ID:mvyTBgoL0
>>588
SIMD特化型x86のメニーコア、従来x86コアとSIMD特化型x86コアの混成コアについては
Intelは2005年あたりから言及してるし、研究開発はそれ以前からやってるだろう。
それがGPUの皮をかぶせたものだとはその時点では明かされなかったけどね。

AMDがFusionのことを語ったのはATI統合後じゃね？
Torrenza構想を語り出したのすら2006年の夏頃。
AMDが先ってのはおかしい。

590 ：名無しさん必死だな [sage] ：2009/03/15(日) 13:11:38 ID:05Tc8pI10
まずはテラスケールコンピューティングの時代がもすぐ来ると言って80コアの試作プロセッサを作り、
次はビジュアルコンピューティングが流行るからと言ってララビー計画をブチ上げる。

なんか開発チームが自分達のプロジェクトに継続して予算をつけてもらうために、
上層部を騙くらかして「将来につながるすごいことやってます」な空気を出してるだけな感じ。

これまで莫大な費用を投じているが、純粋なR&Dならともかく、コードネームを発表して
何らかの製品を出すとしてる以上、利益を出すのが使命。当然だけど2009年3月現在利益はゼロ。

延期延期、次の新しいメニーコアプロジェクト発表、延期延期・・・発売→爆熱低性能で大失敗。
201x年には今のItaniumのぶっ叩かれ具合以上の罵倒の対象になってる悪寒。

591 ：,,・´∀｀・,,）っ-○◎● [sage] ：2009/03/15(日) 13:23:34 ID:mvyTBgoL0
ま、製品を出すまでは利益が出る訳じゃないんだからさ。
長期プランを立てられる企業と即利益になるものしか作れない企業と、
そのへんが一流と二流の境目なんじゃね？

Intelはハードを出す前に、マルチコア開発支援ソフトウェアで足回りを固めつつある。
Threading Building BlocksやPallarel Studioがそれだ。

592 ：,,・´∀｀・,,）っ-○◎● [sage] ：2009/03/15(日) 13:33:03 ID:mvyTBgoL0
＞時代がもすぐ来ると言って
それは君の妄想だ。

Intelは君が思ってる以上にソフト重視で、ソフトがついてこなければ意味がないと
CellやGPGPUを避難する立場にある。

開発者不在のメニーコアほど無駄なものは無いからな。
Core i7に3コア止めて1コアのオーバークロックする機能なんて付けてるのは、
ソフト開発者が十分ついてきてない現状を把握してるからこそのもの。

その意味で、出すにしてもタイミングを見計らっていいとこ取りを狙ってくるだろう。

今流行ってるAtomだって、もともとはメニーコアとして設計されてた
コア設計をシングルコアにカットダウンしたもので、
ポシャった開発計画でも技術転用は積極的に行ってるよ。

593 ：名無しさん必死だな [sage] ：2009/03/15(日) 13:36:24 ID:RiYi+c5g0
>>590
Intel幹部もLarrabeeと心中しようと思ってるほどアホじゃない
Sandy以降のメイストリームプロセッサのロードマップ見りゃわかる

Larrabeeはx86でのベクタ拡張とコア数増大の実験装置
将来LNIが生き残れば御の字といったところでしょ

594 ：名無しさん必死だな [sage] ：2009/03/15(日) 15:29:30 ID:q2KEKfTT0
>>593
LNIとは何でしょうか。
質問してすみません。

595 ：名無しさん必死だな [sage] ：2009/03/15(日) 15:34:35 ID:RiYi+c5g0
http://pc.watch.impress.co.jp/docs/2008/1006/kaigai470.htm
http://pc.watch.impress.co.jp/docs/2008/1217/kaigai481.htm

誤答貼んな

Meteor
ttp://software.intel.com/en-us/videos/meteor/

>>4
数学関数ですが、Intelがこう説明しているは読めませんでしたか？
http://software.intel.com/en-us/articles/prototype-primitives-guide/
　　------------------
　　Math utility functions DO NOT CORRESPOND DIRECTRY TO LARRABEE NEW
　　INSTRUCTIONS, but are added for programming support.
　　[強調部はMACオタ付記]
　　------------------
マイクロアーキテクチャ、ISA、PE (programming environments)と抽象度を高めていくのは
正しい方針なのであって、全部ハードウェア実装と考えるのは大間違いかと…

“プロセッサパワーにおなかいっぱい”の声に対する回答はレイトレーシング
http://www.itmedia.co.jp/news/articles/0402/20/news047_2.html

分散処理って、未だにレイトレーシング位しか思い浮かばない　by Intel
http://hiroshicom.blog.so-net.ne.jp/2007-10-23

IntelがNeopticaと言う会社を買収したという話
http://masafumi.cocolog-nifty.com/masafumis_diary/2007/11/post_ebc6.html

NVIDAがmental rayでお馴染みのMental Imagesを買収
http://blog.livedoor.jp/polo702/archives/51212966.html

NVIDIA、レイトレーシング技術開発のRayScaleを買収へ
http://japan.cnet.com/news/biz/story/0,2000056020,20373923,00.htm

Intel，ゲームデベロッパのOffset Softwareを買収
http://www.4gamer.net/games/021/G002195/20080221047/

［GDC 2008］ゲームに使えるリアルタイムレイトレーシング最前線
http://www.4gamer.net/games/047/G004713/20080222012/

高速レイトレーシング技術、Apple Intel NVIDIA ATI Autodesk出身者らが開発
http://blog.goo.ne.jp/cadboy/e/fabef5f77e8cdc68bb297b5fc6bcb9c8

［GDC 2009］OTOY、LightStageを使ってRubyの新作ムービーを制作
http://www.4gamer.net/games/080/G008082/20090327045/

>>11
そう書いてるだろｗｗ

> 性能面でどうこうよりも、アセンブリ言語や組み込み関数レベルで書きやすいことを重視したのかも知れない。

>>13
ISAに入っていないかもしれないと書いてあるわけですから、
　　-----------------
　　アセンブリ言語や
　　-----------------
こっちは違うと思いますよ。

Larrabee: A Many-Core x86 Architecture for Visual Computing
http://download.intel.com/technology/architecture-silicon/Siggraph_Larrabee_paper.pdf
http://www2.computer.org/portal/web/csdl/doi/10.1109/MM.2009.9
http://portal.acm.org/citation.cfm?id=1360612.1360617
Larry Seiler　 Intel Corporation
Doug Carmean　 Intel Corporation
Eric Sprangle　 Intel Corporation
Tom Forsyth　 Intel Corporation
Michael Abrash　 RAD Game Tools
Pradeep Dubey　 Intel Corporation
Stephen Junkins　 Intel Corporation
Adam Lake　 Intel Corporation
Jeremy Sugerman　 Stanford University
Robert Cavin　 Intel Corporation
Roger Espasa　 Intel Corporation
Ed Grochowski　 Intel Corporation
Toni Juan　 Intel Corporation
Pat Hanrahan　 Stanford University

Pixomaticは2005年の終わりにIntelによって買収されました
http://www.radgametools.com/jp/pixomain.htm
http://software.intel.com/en-us/articles/michael-abrash-biography/
>Michael Abrash is a programmer at RAD Game Tools, working with Intel on the Larrabee project. He is co-author of the Pixomatic software renderer. He worked on Quake at id Software and on Windows NT and Xbox at Microsoft.

Tom Forsythのバックグランドはソフトウェアレンダリング、元3Dlabs
http://www.sgi.co.jp/company_info/press_releases/archives/20080820.html
http://s08.idav.ucdavis.edu/forsyth-larrabee-graphics-architecture.pdf
http://software.intel.com/en-us/articles/tom-forsyth-bio/
>he has written animation middleware for RAD Game Tools, game graphics engines for Muckyfoot Productions and Direct3D video card drivers for 3DLabs.

Tera-scale Computing
http://www.intel.com/technology/itj/2007/v11i3/4-environment/11-authors.htm
>Doug Carmean is a Senior Principal Engineer with Intel's Visual Computing Group in Oregon. Doug was one of the key architects responsible for definition of the Intel Pentium 4 processor.
> He has been with Intel for 18 years, working on IA-32 processors from the 80486 to the Intel Pentium 4 processor and beyond.
>Anwar Rohillah is currently working as a VCG architect focusing on performance analysis and simulation. He has also worked on the Intel Pentium 4 processor family developing hardware prefetchers and doing performance analysis.
>Eric Sprangle is a Principal Engineer with Intel's Visual Computing Group in Austin. Eric has been with Intel for eight years, working on the IntelR PentiumR 4 processor family, and he is currently one of the lead architects on the Larrabee project.

http://japan.zdnet.com/news/hardware/story/0,2000056184,20378365,00.htm
>Larry Seiler氏は、先週サンフランシスコで行われたLarrabeeの説明会で、
>「われわれに必要なのは、CPUの完全なプログラム可能性と、グラフィックス
>プロセッサの並列処理などの独自の機能を組み合わせたアーキテクチャだ。
>そして、そのアーキテクチャがLarrabeeだ」と述べた。
http://pc.watch.impress.co.jp/docs/2008/0822/kaigai461.htm
>LarrabeeのグラフィックスサイドのアーキテクトであるLarry Seiler氏は
>元ATI Technologies。また、ビジュアルコンピューティングについての
>「Chalk Talk」には、NVIDIAでシェーディング言語「Cg」を作ったWilliam
>(Bill) R. Mark氏が登場した。Mark氏はNVIDIA後にテキサス大学オース
>ティン校に移ったが、現在はIntelのリサーチセンターに所属しているという。
When Will Ray-Tracing Replace Rasterization?　講師：Larry Seiler（ATI)
http://www.hc.t.u-tokyo.ac.jp/~kaki/SIGGRAPH2002/Panel_RT_vs_RAS.html

Ray Tracing and Gaming - Quake 4: Ray Traced Project
http://www.pcper.com/article.php?aid=334&type=expert&pid=1
http://software.intel.com/en-us/articles/quake-wars-gets-ray-traced/
>Daniel Pohl started researching real-time ray tracing for games in 2004 during his study of computer science at the Erlangen-Nuernberg University in Germany. he joined Intel’s ray-tracing group.

Stephen Junkins
http://mrl.nyu.edu/publications/gdc-tutorial2001/
>He is a senior software architect in the Graphics and 3D Technologies group in the Intel Architecture Labs.

Pradeep Dubey
http://techresearch.intel.com/articles/Top-Links/1603.htm
>He was one of the principal architects of the AltiVec multimedia extension to Power PC architecture.

Adam Lake, Intel Graphics Media Accelerator 900 Series Software Developer's Guide
http://software.intel.com/en-us/articles/intel-graphics-media-accelerator-900-series-software-developers-guide/

Robert Cavin, Computer Architect at Intel Corporation, SANTA CLARA, CA
http://www.linkedin.com/pub/5/649/606

Roger Espasa, Adding a vector unit to a superscalar processor
http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/e/Espasa:Roger.html

Ed Grochowski
http://software.intel.com/en-us/videos/ed-grochowski-bio/
>I joined Intel Corporation in Santa Clara, California in 1986 and have worked there ever since. I was a member of the design teams for four microprocessors, some of which you've probably owned: the 486, Pentium, Pentium II, and Itanium.

Toni Juan, Data caches for superscalar processors
http://citeseer.ist.psu.edu/old/134846.html

Jeremy Sugerman, I'm working on various GPU programming notions including Brook
http://www-graphics.stanford.edu/~yoel/

Pat Hanrahan, Graphics Systems and Architectures.
http://www-graphics.stanford.edu/~hanrahan/

［GDC 2009＃30］ついにソフト開発者向け情報も出てきた「Larrabee」
http://www.4gamer.net/games/049/G004963/20090328006/

これで当分見納めだろうな
性能出るまでの壁が高すぎる。

IDFがまもなく

http://blog.livedoor.jp/amd646464/archives/51333715.html
＞IntelはGDC 2009にてC++ Larrabee prototype libraryの詳細を発表しました
＞これは実際にLarrabeeでコードを走らせるわけではなく、
＞LarrabeeをエミュレートしてシステムのプライマリCPU
＞にてコードをコンパイル・実行するとのことです

ねーねー団子さん団子さん
サンプル＝動作するシリコン見せてちょ


601 ：,,・´∀｀・,,）っ-●◎○ [sage] ：2009/02/06(金) 07:50:39 ID:36Q+eCpY
もうLarrabeeのサンプルはDreamworksで評価されてるようだが

518 ：Socket774 [sage] ：2009/02/08(日) 20:41:32 ID:oV5466gY
えっ、DreamWorksがすでに使用してるって？
＞「Larrabeeは、われわれが達成できる限界を2倍や3倍どころか20倍にも引き上げてくれる」
この評価は紙の上でのシミュレーション
ちなみにスーパーボールのCMはOpteronで作ったものです

519 ：,,・´∀｀・,,）っ-○◎● [sage] ：2009/02/08(日) 20:42:15 ID:bDqzIbh7
妄想乙

＞IntelはGDC 2009にてC++ Larrabee prototype libraryの詳細を発表しました
＞これは実際にLarrabeeでコードを走らせるわけではなく、
＞LarrabeeをエミュレートしてシステムのプライマリCPU
＞にてコードをコンパイル・実行するとのことです

このライブラリ持ってるけどｗ
てか誰でも使えるけどｗ

＞ちなみにスーパーボールのCMはOpteronで作ったものです

今フォローしておくと
Quad Core Opteronに失望してIntel（Xeon）に置き換えられたそうです。

つまりlarrabeeじゃないんだろ

IntelがGDCでLarrabeeの命令セットの概要を公開

http://pc.watch.impress.co.jp/docs/2009/0330/kaigai498.htm

GeForce7で脳みそが止まって、最近のニュースを見てると
何か3社とも無理矢理で滅茶苦茶みたいだな。

来年再来年あたりで滅茶苦茶のままCPUに統合されて、
MMXみたいなCPUの機能の一つとしてそのまま忘れ去られそうだな。

↓以下ララビー牧場禁止。

それはお前が馬鹿なだけだわ

結局クロック2GHｚ近くなるようで電力効率の悪さはどうにもならなそうだな

そもそも、同じ処理を行う場合プログラマブルな回路は固定回路の500〜2000倍の電気を喰う
CPUのコプロとしては良さそうだがGPUとして使うには効率悪そうだ

Atomは2GHzでTDP2.4Wだが

Atomだけ取りだしてどうするアイフル

計画的に利用するのさ

# 何の話だ？

>>24
リングバスよりも”外側”やらコア数n倍版やらの情報はなしか

ttp://game.watch.impress.co.jp/docs/series/3dcg/20090330_80150.html
西川善司の3DゲームファンのためのIntel・Larrabee講座
3Dグラフィックス大革命。Intel・LarrabeeはDirectXとGPUをぶちこわすのか

intel天下取りすぎて分社化

MS天下取りすぎて分社化

Cell2 B.E. + Larrabee

酷い恥晒しを見た。
机上の空論者は黙ってたほうが身のためだぜ。
http://pc12.2ch.net/test/read.cgi/tech/1232817361/


649 名前：MACオタ＞団子 さん[sage] 投稿日：2009/03/30(月) 19:41:31
>>638
　　--------------
　　Cellならそのまま[x, y, z, *]だろう。
　　--------------
また後藤弘茂並みのトンデモ説を(笑)
16-way SIMDをどう埋めるかという問題は10年前にAltivecが通過した道です。
http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=0162468rH3bTdGmKqW5Nf2F9DHMbVXVDcM
当時のキラーアプリがRGBの各要素1-byteの画像処理で、現在のキラーアプリがxyzの
各要素4-byte FPの3D処理だというだけの違いなのでは？

AIMはvector permuteを選び、Intelはより古いscatter/gatherを選んだというのは特許の話は
別にしても興味深い話です。

650 名前：ペニスは帰れ[sage] 投稿日：2009/03/30(月) 19:53:41
また井の中の蛙の残念な子が来たよ。
GeForceのLSUですらscatter/gatherをサポートしてんのに。


651 名前：デフォルトの名無しさん[sage] 投稿日：2009/03/30(月) 20:09:43
SPUの場合、LSUとshuffle、MFCIOが同じOddパイプだから
内積や回転を多用しないならPermuteせずに128ビットアラインされた
3(4)ベクトルとして使った方が速いんだが

601 ：,,・´∀｀・,,）っ-●◎○ [sage] ：2009/02/06(金) 07:50:39 ID:36Q+eCpY
もうLarrabeeのサンプルはDreamworksで評価されてるようだが

TOMSの受け売りだが何か？
http://www.tomshardware.com/news/intel-larrabee-graphics,5847.html

たとえば、SPEの4つのバラバラのアドレスから32ビットデータを拾ってきて
128ビットにパックするのにかかるサイクル数はいくつでしょうか？
脳みそにウンコがつまってる人はscatter/gatherは旧いからって馬鹿にしたいようだが、
残念なことにCellの実効性能は本当に悲惨ですよ。

まあ机上計算してみればわかります。

>>38
早とちり乙

>>38
サンプル＝何らかの現物を 見た・触れた・通電動作させた の類の文言はまったく書かれてないが

SSE5も今年予定（笑）なんだからまあ落ち着けよ

Tom'sと同日の記事
http://news.cnet.com/8301-10784_3-9985989-7.html

ここには"Monsters vs. Aliens"はDreamWorksとIntelの提携の最初の
成果であると書いてあるだけでLarrabeeが使われるとは書いてない。

つまりTom'sの頭の文章は間違い。
でも本文中にLarrabeeは2009年後半リリース予定と書かれてる
んだから、3月公開の映画に使われるモノか？と疑うのが普通。
ところが情弱団子はそれをしない。
他の情報源に当たることもせずに、勝手にサンプル提供なんて
いう妄想を作り出すのが団子脳。

それも噂だろｗｗ

サンプルってのは無論ソフトウェア（シミュレータも含めて）の話でしょう。
そっち方面はIntelは活発だから。
AVXのシミュレータなら去年の段階ですら出てるんだぜ。
（不特定多数に公開されてるSDEのほうはクロックアキュレートではないが）


たとえばだけど、一部で勝手に出回ってるけど「TAT」みたいなツールって
もともとパートナー向けのツールなんだぜ。
俺も含めておまいらが全てを知るはずがないよ

DreamworksのレンダリングクラスタにIntelが技術協力したのは、どっちかというとソフトウェア技術だぜ。
Xeonも入ってるようだが。
まあAMDとの決別に対する報酬みたいなもんだ。

あ〜あ、もったいない

>>45
とりあえず事実を認める気になったのは結構な話です。
この辺の罵詈雑言も謝っておいたほうが良いのでは？
http://pc11.2ch.net/test/read.cgi/jisaku/1231064800/898-903

何度でも言ってやるよ

898 名前：,,・´∀｀・,,）っ-○◎●[sage] 投稿日：2009/02/17(火) 20:26:10 ID:x/bBLQwK
Demerjian（笑）

ずいぶん説得力の有るソースだなｗｗｗ

彼が言うにはPenrynにHyperThreadingが搭載されてるらしいんだぜ。
脳味噌にウンコが詰まってる人は信奉の対象もウンコなんだぜ。

シミュレータをサンプル扱いするなんて前代未聞！
さすが団子さんだぜ


ばーか

ソフトウェアも含めて、開発にかかわるものはサンプルでしょう。
ハードウェアだなんて何時言った？

http://kishinkan.jugem.jp/?day=20081105

「諸悪の根源」らしいですよ


↓ところでこれ誰の言葉だったかな？
> TheINQのCharlie "Groo" DemerjianがLarrabeeのサンプルが今年の秋にも 開発者向けに配布されると伝えているす。 ...

さぁ土下座をするんだ団子

>>48
でもFUDzillaは信じる団子さん(笑)
　　-----------------
　　929 名前：,,・´∀｀・,,）っ-○◎● 投稿日：2009/02/19(木) 00:06:51 ID:yEXM5r22
　　　　intel LarrabeeにはWindows XP用ドライバが用意されない
　　　　http://a96sj096.cocolog-nifty.com/weblog/2008/11/intel-larrabeew.html

　　　　当たり前だけどDirectX9までの描画メソッドには興味がないみたいで。
　　-----------------
翻訳腐れルーマーサイトのソースはこちら。
http://www.fudzilla.com/index.php?option=com_content&task=view&id=10349&Itemid=1

いつも思うんだが、コレってcellの劣化コピーじゃないの？

脳味噌のウンコが詰まった人の情報筋よりはFUDZILLAは信用できるだろ

>>56
中のヒトは元TheINQって知ってましたか
http://www.google.com/search?q=Fuad-Abazovic+site%3Atheinquirer.net　(笑)

fuckin' hate.

サンプル＝シリコンサンプル
を指すのが普通
僕らとは住む世界が違う団子さんにとってはそんなのは通用しないんですね！
さすが団子さん


ばーか

馬鹿だね。
シリコンサンプルなんてハードベンダーに渡すもんでソフト屋に直接提供するもんではない。

ソフト屋さんにはソフトウェアベースのシミュレータで充分サンプルとして実用になるんだが。
Cellのもあったろ。クロックサイクルアキュレートなやつが。

いつDWがハード屋になったんですか？

> TheINQのCharlie "Groo" DemerjianがLarrabeeのサンプルが今年の秋にも
> 開発者向けに配布されると伝えているす

ここでの開発者が【ソフトの】開発者のことを指してることに気づいてほしい。
ハード開発者はIntelだけだ。

そして「サンプル」とは一般開発者向けにはprotorype primitiveのこと。
確かにあれの公開は彼の言ったとおり約半年遅れの今年3月になった。

ハードだと思って一喜一憂してたのはおまいらだけだよ

>>62
"silicon"って書いてあるのですが？
http://www.realworldtech.com/forums/index.cfm?action=detail&id=96437&threadid=96378&roomid=2
　　---------------------
　　the Taiwanese were expecting silicon in January.
　　---------------------
Intelはチップの開発メーカーであって、ビデオカードやマザーボードの開発メーカーは別途いますよ。

また宇宙から電波でも拾ったんでしょ。
なんせ彼のPenrynにはHyperThreadingが実装されてるんだし。

Demakasejanの作り話をさも実話のように語っても拉致があきません

http://www.xbitlabs.com/news/video/display/20080117222433_Intel_Promises_to_Sample_Larrabee_Processors_in_Late_2008.html

> “Larrabee first silicon should be late this year in terms of samples
> and we’ll start playing with it and sampling it to developers and I
> still think we are on track for a product in late ’09, 2010 timeframe,”
> said Paul Otellini, chief executive officer of Intel.

これも宇宙からの電波かもしれんｗ

http://www.theinquirer.net/inquirer/news/419/1030419/penryn-to-have-ht

まあ、嘘も100度言えば本当になる世界の人ですよ。
純朴だね脳味噌にウンコが詰まってる人は。

http://www.intel.com/pressroom/archive/releases/20080804fact.htm

Intelの公式発表はこれ。
09年になるか10年になるか明確な時期を示してないもののシリコンサンプルを08年末に出せるだ？
量産出荷の半年前くらいに出るもんだと思ったが。

結局「開発者向けサンプル」の正体がハードウェアなのかソフトウェアなのかすら
区別が付いてない記者が多いんだろ。
日本にも「80コア」なんて書いちゃう記者がいるくらいだし、ｳﾞｧｶ記者が勘違いするのもある意味当然。

> 量産出荷の半年前くらいに出るもんだと思ったが。
新規アーキテクチャなら量産の一年以上前にファーストシリコンなんてのは当たり前の話だが。

これはもう少し引っ張れそうですね…

>>69
1stシリコンがOEMに出回るとかないだろ・・・

>>71
>>66の引用部の一行目をどうぞ。
"first silicon should be late this year IN TERMS OF SAMPLES" [注: 強調部MACオタ]

1stシリコンがパートナー向けのサンプルとして出回るとか今まであったか？
Paul Otelliniの出自がどこか知らないからはっきりとは言えないが
普通に勘違いだと思うが

>>73
英文から『最初の[エンジニアリングサンプル用]シリコン』と読むべきかと。
　　------------------
　　Paul Otelliniの出自がどこか知らない
　　------------------
団子さん並のヒトがもう一人？

wikipedia見たよ
ttp://en.wikipedia.org/wiki/Paul_Otellini
うん、やっぱり技術畑の人じゃないのね

>>74
その文をESと読むのはちょっとどうなんだろうｗ

>>75
　　------------------
　　その文をESと読むのはちょっとどうなんだろうｗ
　　------------------
http://lise.me.sophia.ac.jp/kktm/Essay/term_in_terms_of.htm
　　===================
　　　”in terms of 〜”は，by 〜, with 〜, by 〜 using 〜, by the use of 〜のように訳して
　　構わない場合が多いです．時には，context「文脈」によって，「〜という点で，〜という点
　　から，〜という観点から」と訳してもよい場合があります．但し，「〜という観点から」を逆
　　に英訳する場合，”from the viewpoint of 〜”とすると，”in terms of 〜”から少し隔たっ
　　てしまいます．
　　===================

仮にES説を採用するとして、今度は2009〜2010年と異様に幅のある表現が謎
通常のIntelのロードマップだと2H09とか1H10とかの表現がせいぜいで
late 08にESが出るて言う(>>66)ならmid 09に量産出荷とか言っていいはずなのに
これが1stシリコンならそれ以降のデバッグ期間は14〜18ヶ月が相場
野心的な設計だと遅延もままあるのでコンサバティブな予測で2009〜2010年の表現で良いと思っていたのだが

>>77
記事の日付を見ると良いかと。

>>78
何が言いたいのかわかりませんー

今沖田産業

> “Larrabee first silicon should be late this year in terms of samples
> and we’ll start playing with it and sampling it to developers and I
> still think we are on track for a product in late ’09, 2010 timeframe,”
> said Paul Otellini, chief executive officer of Intel.

sampling "it" to developersが指すものはそもそも、
"Larrabee first silicon"ではなく"Larrabee"なんじゃないのか？

"First silicon of Larrabee 〜"ならまだ解るんだけどな。
やっぱりMacオタは脳味噌にウンコ詰まってるから英語が読めないんだな。

so fool.

＞英文から『最初の[エンジニアリングサンプル用]シリコン』と読むべきかと。

どう解釈すればこんな電波な解釈になるんだｗｗｗ
ウンコ詰まりすぎだぞテメーｗｗｗ
脳全摘出しろｗｗｗ

もしESを指すならこう書くだろうな

Engineering sample of Larrabee, silicon should be late this year in terms of samples
(以下略

そもそも"developer"がハードベンダーだとは思ってないわけだが。
同時期の記事でDemakasejanが"devs"って表現してるけど、devは
主にソフトウェアの開発者(softwawe developer)のことを指す言葉である

※決してdeviceではない

Anton Shilovの記事いろいろ読んでみたけど、
言うこと全て嘘だらけのDemakasejanほどには電波を感じない。

Intelの外に渡せる現物が存在するとは思えんなぁ
ダイ全体の仕様まだ固まってないだろ

GDCのプレゼン資料の一部がIntel公式にあがってるぞ。
どうでもいい記者どもの妄想記事なんかよりよっぽど読む価値あるネタが放出されてるわけだが。

団子さんが引用部の4行目に気付いてしまったようなので、私は面白くありません。
もう少し引っ張れると思ったのに>>73の方が台無しにしてしまったようで…

たとえば去年のジャンプに掲載されたドラクエ９の発売日で盛り上がれるか？
おまいらのやってるのはそれ以下で、「DQ5でエスタークが仲間になる」レベルな。
非公式ネタである以前に裏が取れてない、というより概して捏造。



MACヲタの信奉するデマ男くんは昔からこういう扱いですよ

> 801 ：Socket774[sage]：2008/09/05(金) 04:37:50 ID:Kupns0iS
> デスクトップ用のGPUに関する記事を書いてるCharlie Demerjianて奴は
> 有名な奴だが「友人によると」とか「私の考えでは」ってな妄想記事が多い奴だぞ
> 海外のフォーラムサイトでは相手にされないレベルの奴
　~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


信奉した結果がコノザマだよ
http://www.theinquirer.net/inquirer/news/419/1030419/penryn-to-have-ht
http://www.theinquirer.net/inquirer/news/724/1002724/penryn-does-not-have-ht
By Charlie Demerjian

ばーか
最初から見てるが？ｗ
口頭で喋ったことなら大して当てにならないよ。
聞き間違いは大いにあり得るし

むしろ折角組み込み関数のプロトタイプが公開されてるんだから生産性のあることやったら？

>>88
　　--------------
　　聞き間違いは大いにあり得るし
　　--------------
腐れルーマーを簡単に信じるヒトって素直ですね(笑)
私は疑り深すぎて…
http://www.google.com/search?q=Otellini+Larrabee+first-silicon

Intelは去年の段階では、2010年いっぱいまで45nm製品を引っ張る予定だったろ。


今年に入って、32nmへの移行を早める代わりに、Havendaleはキャンセルという計画になった。
32nmへの急転換の流れでLarrabeeも45nm版そのものがキャンセルされた可能性が高い。
シュリンクを伴う遅延ならまだいいだろ。Itan(ry

Itaniumは予算カットで遅延しまくりだから・・・
Doug Carmeanみたいな大御所が参加しているLarrabeeチームはお金一杯もらってるっしょ。

LarrabeeはNVIDIAのIP無いと作れなくなるらしいな

なんで元Pentium4とか元Itaniumとかの地雷組が混じってんの

西川善司の3DゲームファンのためのIntel・Larrabee講座

http://game.watch.impress.co.jp/docs/series/3dcg/20090330_80150.html

結局3Dゲームのレンダリングはパフォーマンス低くて使えなくて、並列コンピューティングにしか使えないって事だろ
それもプログラムの書き換え必須ってことで←これが無ければマンセーしたいところ

Dx11より後のゲームがレイトレーシング描写になることはnVIDIAが一番最初に予言してるし、それを見越した上でのGPGPUの動きなんだよな
並列コンピューティングでもGPGPUのほうがコスパ上っぽくて
Larrabeeはどうもミドルレンジとかローエンド向けのオンボあたりの認知になりそうだよな

最終的にメニーコアのミニコアとして統合して、GPUとして動かさないときはただのx86コアとして
活用するってつもりなんじゃないの？

使う使わないがコードによって極端に違うFPやらSSEやらを主コアから分離するのが
最終目標なんじゃねーかと思えてきた。

>>96
まじでレイトレーシングが一般のゲームでも使われるようになるんだろうか？
もう消費電力上げずにパフォーマンス上げるの、そろそろ限界なんじゃないの？
製造プロセスも11nmぐらいで止まるって話じゃなかったっけ？

少なくともユーザー側の需要はほとんどないだろう
現時点でもHD機は売れずに任天堂が圧勝してる始末

結局自分とこの半導体を高く売りたいだけだからねえ

そりゃそうだ
一般ユーザにゃ再生支援つきチップセット+Atom or C7で十分

問題はユーザーがそれに気づきつつある事

ぼけっとしてるとスパコン業界がやばくなるんだろIntelは

来年に1Tで300wで登場だっけ？

公式に具体的な数値が出たことは無い
過去のIBMのスライドには90Wで1200Gflopsとあった

メモリの種類やバンド幅もまだ決まってないのか黙っているだけか

>>105
うーん、ちっとは頭使えよ。
単精度FMA×16並列×16コア×2GHｚで1024GFLOPSだぜ。

もし300Wだったとしてみ？
単純に16で割っても1コアあたり16W強だぜ。既にCore 2なみの消費電力なんだが。

実を言うとSIMD演算ユニットそのものはそんなに消費電力は高くない。
たとえば’、Atomの単精度浮動小数演算の最大スループットは
同クロックのCore 2と同等。
Atomが2GHz・16コアで単純計算で512GFLOPSになるが
2.5〜4W、単純に16倍しても40〜64W程度だぜ。

ちなみにAtomは128bit FADD+FMUL or スカラ2並列実行
LarrabeeはFMAに対応した512bit SIMDユニットに加えて非対称のスカラ演算をあわせて
合計2並列で実行できるのみ。

どう見積もっても1コアあたりの消費電力はAtomの倍未満だろう。
32nmプロセスで製造されることを考えるとそれより更に落ちる（＋固定ハード・VRAM）
多く見積もっても16コア1TFLOPSで100W越すかどうかのレベル。

> Atomが2GHz・16コアで単純計算で512GFLOPSになるが

ここは128GFLOPSだった。すまん

あれ又間違えた
(4 FMUL + 4 FADD)×2 ×16 = 256GFLOPS

寝惚けてるなorz

ｻｰｾﾝ実測ktkr
2 FMUL + 4 FADDで192GFLOPSでFA
orz

GDC2009のスライドがあがってる
http://software.intel.com/en-us/articles/intel-at-gdc/

Larrabee単体じゃなくてGDDRやその他の部品込みで、グラボ等の拡張カードの状態でMAX300wってことだろう
X86対応で色々と融通が利いて実行性能もこの数値なら中々優秀じゃないか？

ところで、SIMDユニットが電力効率がよい事は判る
とは言っても、PowerPC G4の設計で、128bitのSIMDの搭載を載せる場合
SIMD付き500MhzとSIMD無し700Mhzが同じ消費電力という結果だった
これから消費電力の比を単純に計算すると
500Mhz（SIMD無）：500Mhz（SIMD有）：700Mhz（SIMD無）：700Mhz（SIMD有）＝1：2：2：4

電力消費分以上にピーク性能は稼げてはいるから電力効率では優秀
とは言っても、それなりには電気喰うね

2行目の『実行性能も』はただの消し忘れ

単体で200Wは超えるだろ
何となくだが

Intelがまともに性能で張り合おうとするのならハイエンドは200W超えてくるだろうね
競合がそれだけ電力消費して高い性能を実現しているのだから

AtiがQ3に40n、NvidiaがQ4に40nなのに
Larrabeeは来年に45nだしな
しかもその時期も怪しいし

コア数やメモリもそうだが、製造プロセスも明らかになっていないのだが。
ま、投入が2010年の後半ならTukwila級のダイサイズでもない限り32nmだろうけどね。

後藤が言うにはXDR2じゃなかったか？
今のところ最大顧客不在のペーパー規格。
もしくはPS4次第か。

PS4が最大の幻企画ジャン

幻連合だな
NVIDIAにプレッシャーをかけ続けるだけでもIntelとしてはメリットはあるのだろうが。
まあ後藤もLarrabeeはCPUにGPU機能を統合する時代への通過点ってことに気づいてるようだが。

今まででさえCore2Quadを5台とか繋げてエンコしてんだぞ？
そんな所でも低辺のターゲットだ
PCI-Eの限界300W？使ってくるに決まってるだろ

マシン1台あたりのエンコ効率を上げるにはどっちかというと演算ユニットよりメモリーが必要。
んで、そのためにはメインメモリを数GBくらい使えるように64ビット化が進まないと駄目だろ。

んで、Vistaで64ビットに移行すると見越して大量生産したのに
おまいらがXP 32ビットに留まってるからDRAMメーカーがピンチなんだが。

だって、要らないんだもん

要らないなら要らないで良いよ。

FixstarsがCellでリアルタイムエンコ実現してたけどあれはGigaAccel 180上でやってる。
ホストOSから独立したメモリ上で64ビットのLinuxが動いてその上でエンコーダが動いてる。
メモリはDDR2デュアルチャネルの4GB程度。
更にPCIeを仮想イーサーネットとして使うことでホストとの高速通信ができる（Linuxの場合）

Larrabeeのカード側にはそんなにメモリは積まないと思うから
どっちかというとホスト側のメモリが必要だな。

ダンゴは製造とかの話はダメみたいだから無理に語らなくて良い

DDJのLRBni解説記事が、各命令をきれいに図示していて分かりやすい感じかと。
http://www.ddj.com/hpc-high-performance-computing/216402188

俺の持ってる資料に載ってるしｗｗｗ

後手後手だな

http://www.rambus.com/jp/products/xdr2/xdr2_vs_gddr5.html
GDDR5は1Gbpsあたり0.5Wも食うね。


http://d.hatena.ne.jp/cjohn/20090301/1235902584
Radeon HD4870はメモリの「転送」だけで最大58Wくらい食うようだ。

ある程度の容量のキャッシュがあれば、タイルレンダリングすることで
消費電力を抑えることが可能じゃないか、と。
タイルの入れ替えの時にしかメモリトラフィックは発生しないからね。

GDCの講演そのもののビデオはこっちからどうぞ
http://software.intel.com/en-us/videos/gdc-session-overview-simd-programming-on-larrabee/

腐れ記者の勘違いに汚染されてない生の情報が視聴できますよ。

http://software.intel.com/en-us/articles/intel-at-gdc/
おっと、こっちの方が良かったかな

INTELがNVに勝訴してLarrabee開発中止に1万ﾍﾟｿ
NVがINTELに勝訴して廃れて行くに2万ﾍﾟｿ

日本のメーカもメニーコアのプロセッサを開発した方がいいんじゃないか

>>130
それ講演のビデオじゃありませんよ(笑)　
http://software.intel.com/en-us/blogs/2009/04/03/videos-posted-from-gdc-more-coming/
　　------------------------
　　(full session video to be posted in one month - stay tuned)
　　------------------------
>>85でintelの資料を紹介したつもりだったようですが、実際にLarrabee関連のプレゼンがアップロード
されたのは>>112の頃でした。
知ったか振りは恥をかくだけかと…

　　　 　 　 　 　　 　　__‐`'´''"'マ　　　　　　　　　　____＼ 　　ー‐┐ 　　 |一
　 　 　 　 　　 　　 　 Z.　　　 __｀ゝ 　　　　　　　 　＼　 　　　　ﾉ´　 　⊂冖
　∧　　　 　 ／|　　　ﾞ仆斗┘リｰト=┬-､_　　　　　　＼ 　　 ー‐┐ 　 ,／
/ 　 ∨＼／ 　 |　　　　｀L,.っ,ﾉ u }ﾉ ﾉ　　 ＼　　　　　　,>　　　ﾉ´　　　＼
　　　　　　　　　|_＿　　　　兀.!_／／ i | 　 　 l、 　 　 く.　　　ー‐┐　ｰ|ｰ
ー‐┐　ｰ|一ヽヽ　/　　u'　＼ヽ‐'´　　!|　 　　 ﾄ､　 　　 ＼ 　　,ﾉ´　 ￣匚ノ
　ﾉ´　 　ﾉ　こ　　/_____, 　}j 　ハ､ 　ヽ ヽ,＿＿_/　　　　／ 　ー‐┐　 ┼‐ヽヽ
ー‐┐　 ニ|ニ. 　 　 ／　___ノ　／＼_,≧/ u 人.　　　／ 　　　 ,ﾉ´　　 ﾉ　こ
　ﾉ´　　 ⊂冖　　　く　　{上rﾝ´　 ,厶..／ ／　ヽヽ 　 ＼　　　　|｜　　ニ|ニ
ー‐┐　　|　　　　 ／　　 ￣ 　 ノ{こ,　／,〃　 　!|　　　 ＼ 　　･・　　 ⊂冖
　ﾉ´　　　l.__ノ　　 ＼　 　　　,.ｲ　!l｀T´ | / 　 　 |:|　 　　　/　　　　　　 |
ー‐┐　ー‐;:‐　　　　＼ 　　// 　 　l　 |　　　 　|_|　　　∠.、　　　　 　 l.__ノ
　ﾉ´　　　（＿,　　 　 ／ 　　ﾋ_ー--､＿|ｰ､____,ノj┘　　　 /　　　 　 　 ┼‐
ー‐┐ 　 ／ 　 　 ／　　　　 ＼￣＼ー`トｰ-＜　　　　／ 　 　 　 　　 ﾉ　こ
　ﾉ´　　　＼ 　 　 ＼　　　　　　＼　 ヽ　 ＼　　ヽ　　　￣￣|
　| |　　　｣z.___　　　　>　　　　　　 ＼. ヽ.　　ヽ 　 ｌ　　　　 　|／l 　 ／|　　∧　 /＼
　･・　　 /|　（_,　　／ 　　 　　　 　　 ）　lヽ　　 ',　 l、　　　　　　|／ 　 |　/ 　 Ｖ
　　 　 　 ┼‐　　　＼　　　　　　 , イ､_,上ﾊ　　 } 　小　　　　　　　　　 |/
　　　　 　ﾉ　こ　　 　 ＼ 　　 　(乙≧='''"´　,∠,__ノ/
　　　 　　┼‐ヽ　　　 ／ 　　　　　　　　　　厶乙iﾌ/
　　　 　　ﾉ ⊂ト　　く 　　 　　　 　　　 　　 ｀¨¨¨´
　 　 　　 　 　 　　 　 ＼

>>133
つ[DAPDNA]

超小規模・低性能のプロセッサエレメントを動的に再構成して回路を構成する。
PEは単体で演算ユニット・メモリ・ネットワーク機能を持つ。
現時点でもっともニューラルネットに近いハードかもしれない。

http://www.ipflex.com/jp/1-products/3_dd2_arch.html

MACヲタは英語が聞き取れなかったかわいそうな子だってことがわかった

512ビットベクトルに対する全てのload/store操作ににnon-temporalを付けることができる。
scatter/gatherやswizzleも含め。

タイルにしたってLarrabee程度のキャッシュじゃSD解像度くらいでしか役にも立たんと
どっかのスレで教えてやったろうが、馬鹿団子。

効率を上げるのはメモリ量じゃなくて転送帯域だぞ。
ネコの額ほどの広さしかないキャッシュなんて一瞬で使い切って、結局転送速度律速になる。
本来ならReadバス2本+Writeバスの3系統ほしいところだ。

だからローテーションするの。
各タイルに対してキャッシュを一定サイクル数割り当てるってことに意味がある。
割り当て続けるわけではないし、ｳﾝサイクル単位でインターリーブするわけでもない
ころころインターリーブする従来GPUとの違い。

資料まともに読んでないだろ。

L2ｷｬｯｼｭはｷｬｯｼｭであってｽｸﾗｯﾁﾊﾟｯﾄﾞﾒﾓﾘではないぞ

まあ、60fpsで画面処理するのに何回タイルを入れ替えればいいか考えてみればいい。
ピクセル単位で読んでは書き戻す既存GPUは無駄なデータフローが多すぎるよ。


今のGPUって、壁にペンキを塗るのに部屋の中心にあるペンキの入ったバケツを
移動せずに、刷毛に少量のペンキを染ませるためにバケツまで何往復もしてるような常態だよ。
塗る面に応じてバケツを移動すればいいというブレイクスルーをやろうとしてるのがIntel。

そして「バケツを持って歩くのは重たい的な」アホな言い掛かりが>>139

しかし日本の諺に餅は餅屋というのがあるわけで

もちろん。世界で過半数のGPUシェアを持っているのはIntelです。

Larrabee餅

ネハレンとララビのキャッシュ構造って似てるよね、なんとなく
ネハレンのSMT数を4スレッド＆LRBni追加して、
ネハレン1コア4GHz＋ララビ15コア2GHz＋4MBL3の論理コア64個のCPUとかできんもんかね

タイルレンダ自体は360のCoD4なんかでもフレームレート稼ぐためにeDRAMを駆使してやってるがな
電力の問題もあるしメインVRAMの帯域を増やすだけの拡張は見直さなきゃならん。

DirectXのレンダリングパイプラインが既存の3D描画に依存しすぎ
バージョンうｐでむしろAPIの自由度をゴソっと「下げないと」いかん時が来てる

>>141
ひどい勘違いがあるようだが、Larrabeeにブレイクスルーなんて無いよ。
既存GPUに比較して目立つ要素はなにもない。>>147の言う自由度はあがるけど。
団子が主張するタイルだのローテーションだのキャッシュだのは既に実現されてる。

ペンキの話題に乗っかってやるなら、500mlのバケツを20個くらい用意して「さぁどんと来い！」と
叫んでるのがLarrabee。バケツにはペンキ以外にニスも入れられるぜ、万能だろ！？って感じ。

バケツにペンキが残っているうちは他の人とバケツを交換しあえるので一見効率がよさそうに
見えるけど、現実を見ると壁は20平米位の広さがあって30色使うことが要求された。
足りない色が出るので中身交換しにヨチヨチ歩きの子供がお使いにでる。
バケツの容量も足りないからやっぱりお使いに何度も走る。

所詮使えるのは犬小屋の屋根を塗る程度でしたってオチ。

3D処理で扱うデータは
　・ジオメトリ（形状)データ。数万単位の頂点、テクスチャ座標、カラー情報など。
　・シェーディング（陰影）データ。ピクセル毎の演算処理。レイトレも同じ。
　・フレームバッファやテクスチャデータ、アルファ値などのイメージデータ。

レイトレでもZ-Bufferでもこれらは変わらず必要なデータだが、これがどれだけの量になるか考えればいい。
既存GPUではこれら処理ごとに（内部的には）個別の足回りを用意している。

NVやATIのストリームプロセッサ部分に置かれるキャッシュはLarrabeeのものと同様に共有される上、
ATIの場合は別のSPアレイとの共有用キャッシュも置かれる。
メモリインターフェイスはピクセルオペレーションでのタイル処理に併せて4ないし8程度分割して置かれ、
もちろんそれぞれにキャッシュがおかれる。

LarrabeeでIntelがさもすごそうに発表している内容は、Intelにとって画期的なだけで
「あって当然」「なにを今更」の内容でしかない。

＞所詮使えるのは犬小屋の屋根を塗る程度でしたってオチ。

SD程度の画質なら最強ってことか

>>150
SD程度の画質なら最速じゃないとしても、
UnifiedShaderなんかに比べて遥かに高い自由度と、x86系プログラマの熟練度っていう強みから
最強にはなれるかも。

消費電力が数W程度に抑えられるなら、
Windows7が動くスマートフォン用プラットホームとしてQualcommのMSM7xxxxを駆逐できるかも？ｗ

で、Larrabeeのメモリ帯域のソースはどこ？

それは詳しい団子が教えてくれんじゃない？

Larrabeeのキャッシュに幻想抱いてる団子に対し、
> Larrabee程度のキャッシュじゃSD解像度くらいでしか役にも立たん
つーのが俺の主張だし。

>>151
何を持ってＳＤと言っているのかわからん。
解像度の話なら、SDで最強なのを６発積めばＨＤまでいけるってことだろ。

>>148-149
タイルレンダは、ZバッファのRWを完全にオンチップキャッシュで行える → 帯域ケチれる
さらに、半透明ポリを除き事前にZバッファ処理してテクセル参照を画面1ピクセルにつき1回に限定 → 帯域ケチれる

これを64*64タイル程度の適切な単位で実現するには、ある程度のオンチップキャッシュの大きさが必要になってくる

>>153
でもIntelは解像度が高くなるほどキャッシュによってメモリへの
アクセスを減らすことが出来ると言っていたはず
キャッシュはヒット率100%じゃないと意味無いのか? ちがくね?

>>154
まずZ-Buffer法の場合。
オブジェクトはあるグループ単位に切り分けることが可能だからこれは順次処理すればよい。
レイトレーシングと比較して大量のオブジェクト数でも少ないキャッシュですませられる。

しかしそのオブジェクトがどのフレーム領域を占めるかは完全にランダムであり、
Z-buffer法の性格上、BGRA情報およびZ-Buffer情報は頻繁に読み込み-比較-書き出しが行われる。

タイル式で処理する場合はこれを分割してキャッシュに保持することになるが、
必要なキャッシュ量がどのくらいになるかは簡単に計算できるでしょ。

> 解像度の話なら、SDで最強なのを６発積めばＨＤまでいけるってことだろ。

まぁ要するにSLIだのCrossFireやれってことだね。


レイトレーシングの場合。
ピクセル毎に注目するためフレーム領域は一部がキャッシュに乗っていればいい。
この点でZ-Buffer方に比べ、高い解像度でも必要なキャッシュ量は小さくてよくなる。

一方で、レイトレーシングの場合光線と交差するオブジェクトを全て検査する必要がある。
オブジェクトの構成要素は最低でも X,Y,Z座標と透過率、反射率、屈折率、そして RGB。
場合によってはテクスチャ座標（U,V)も必要。1トライアングルあたり72〜132バイト。

全てのコアでこのデータは共有可能なためLarrabeeの場合L2にドカンとのせておけばいいけど、
搭載できるデータ量に対しオブジェクト数がどの程度になってしまうかは簡単に想像つくでしょ。
SD解像度なら数千ポリゴンで済ませられるけど、解像度高くなってきたらそれなりに分割しないと
荒さが目立つ。

これらに加えて複数のTextureイメージ抱えてFSAA用の合成を行いつつ、
さらにインストラクション用にキャッシュを裂かないといけない。

＞BGRA情報およびZ-Buffer情報は頻繁に読み込み-比較-書き出しが行われる
これを完全にオンチップキャッシュで処理し、1/60秒に1回だけ最終表示結果をVRAMに書き出すのがタイルレンダ
既存のGPUはキャッシュ持ってるとは言え、1ポリ描画毎にVRAMにフラッシュせにゃいかんようなもん

>>155
> これを64*64タイル程度の適切な単位で実現するには、ある程度のオンチップキャッシュの大きさが必要になってくる

そういうこと。
たとえば24領域つかって 64x64サイズのタイルを表現した場合、
同時に扱えるフレーム領域は512x192程度でしかない。

>>156
> でもIntelは解像度が高くなるほどキャッシュによってメモリへの
> アクセスを減らすことが出来ると言っていたはず

インテルはいつもこういう部分でポカを行う。もしくは分かっていて騙す。
大量のオブジェクトがスカスカの空間中を遠方で蠢いてるだけなら、「平均的に見た場合」正しい。

一方、大量のオブジェクトが万遍無く空間に散らばっていた場合、全ての領域に
アクセスが散発的に発生する。また少ないオブジェクトでも画面いっぱいに
ドアップで表示されるような場合、全ての領域に連続したアクセスが発生する。
これらの場合、キャッシュの入れ替え作業が頻繁に発生しはじめる。

結果どういうことがおきるかというと、ピーク性能は高くてもある条件下で極端に性能が落ちる、
つまりフレームレートがいきなり低下するという状況が発生する。要するに、「もっさり」GPUの誕生。

>>159
いやいや…タイルレンダでは各タイルの処理は「独立」してるんだよ？
処理の終わったタイルは次の処理タイルに入れ替えれば良いだけ、1タイルに1コア割り当てとか笑止

> 既存のGPUはキャッシュ持ってるとは言え、1ポリ描画毎にVRAMにフラッシュせにゃいかんようなもん

これは相当以前のGPUの話であって、現行GPUはオンチップキャッシュに載ればそこで処理される。
もちろんキャッシュに乗り切らない部分はメモリと入れ替えが発生する。
1/60毎で済ませられるかどうかはLarrabeeもNVもATIも変わらん。

>>160
君はもう少し>157を理解したほうがいい ;-)

いや…あの…ドリキャスのメモリ構造って知ってます？ｗ タイルレンダの概念わかります？

>>161
>1/60毎で済ませられるかどうかはLarrabeeもNVもATIも変わらん。
じゃあメモリのバンド幅とキャッシュサイズをあわせて論議しなければならないのでは？

GT200とかレジスタだけで2MB弱あるんじゃなかったっけ
それとは別に用途毎にキャッシュも積んでるよね

>>163
ああ、もしかしてKYROなんかの奴を言ってる？

あれ、単なるZ-Sortの発展です。領域ごとにポリゴンソートして手前だけ描画。
以前団子には説明したけどな。当然だけど、NVでもATIでもいまのUnifiedShaderなら再現可能。

いまそれが使われないのは、
　・交差ポリゴンの処理が複雑になり正しい表示が行えない、
　　もしくはポリゴン分割処理を伴い速度にペナルティが発生する
　・透明処理が行えない、特殊な追加処理が必要となる
という致命的な欠陥があるから。

>>159
>結果どういうことがおきるかというと、ピーク性能は高くてもある条件下で極端に性能が落ちる、
>つまりフレームレートがいきなり低下するという状況が発生する。
これって現行のGPUでも同じことが起きてるよね...

＞キャッシュに乗り切らない部分はメモリと入れ替えが発生する
タイルレンダの場合、キャッシュに乗り切らない（＝量が可変な）主なデータは頂点データとなる
テクセル参照は、64*64タイルなら必ず固定で4096回だけ発生する （半透明除き）

>>164
> じゃあメモリのバンド幅とキャッシュサイズをあわせて論議しなければならないのでは？
そういうことです。

タイルレンダするからキャッシュ溢れおきず最適に描画できるっていうのは幻想ですんで、
結局足回りが重要になってくるんです。と、>139で申しております^^

>>168
その頂点データがレンダリング途中で可変という実に厄介な現象が発生する。
テクセルだけ注目してはいかんというのは>157のレイトレの方で解説した。

>>166
Zソート？ Zバッファを先に全ポリで更新して、1ピクセルと1回のテクセル参照を対応付けてるんだけど

>>169
別に厄介じゃないと思うけど…次に必要なポリの頂点データはわかってるんだから順次プリフェッチするだけ

>>169
タイルレンダならメモリのバンド幅を節約できるってのも幻想なの?

「Zバッファは同じアドレスを頻繁に更新するので全部キャッシュしておきましょう」
「同じフレームバッファ上のピクセルを何度も塗るのは無駄なので、1回だけ必要な色を塗るように工夫しましょう」
それを適切なトランジスタ数で実現するのがタイルレンダってだけの話

まぁ確かに頂点データの参照は冗長になるね、でもピクセル処理の冗長さとどっちが良いかね

>>170
君のいうタイルレンダをきちんと説明してみ？
DreamCastというキーワードが出てきたからKYRO、もっといえばPowerVRのことだと思うんだけど ;-)
ごめんねPowerVRなら元中の人なんです。

> 別に厄介じゃないと思うけど…次に必要なポリの頂点データはわかってるんだから順次プリフェッチするだけ
交差するポリゴンの前後関係がでたらめになってもよければね。
正しい表示を行う場合、交差部分でポリゴンを分割していく処理を行うため、
ポリゴンスキャンを最初に行う時点で新しいポリゴンが発生し、頂点データが新しくなります。

>>172
> タイルレンダならメモリのバンド幅を節約できるってのも幻想なの?
フレームバッファだけみたら節約になりますけど、3D処理ってそれだけじゃないですからねぇ…。

たとえばHD解像度を64x64で分割した際、1万トライアングルをなめるのにかかるトラフィックって
どのくらいになると思います？　510パスになるわけですけど。

？？？Zバッファなのになんで交差するポリゴンの前後関係なんて話が出てくるん？
分割レンダ＆Deferred Renderingの省メモリ版ってだけの話なのに

事実なんですね

ttp://www.z-z-z.jp/BLOG/log/eid264.html
>Larabeeは、第一世代のものは、ATIやNVIDIAのハイエンドGPUには全く及ばないパフォーマンスといわれている。
>テクスチャユニットに負荷がかかるとリングバスがパンクして思ったほどパフォーマンスがでないらしい。

ところでRadeonHD 4800シリーズってSIMDコアごとにL1キャッシュが16KBしかないんですがｗｗｗ
200SPで16KBですよ。ﾊﾟﾈｪ。
L2のほうは非公開だが、3800のときはテクスチャキャッシュがダイ全体で256KBで
そんなにダイサイズも大きくなってないことから想像に難くない。

GeForceのほうは、1SMあたり64KBのコンスタントメモリ（命令バッファを兼ねる）に16KB
これでメモリ帯域のセーブとか、しょっぱすぎんだろ。
一つのコアでL1 32KB＋32KBとL2 256KB×コア数ってだいぶ帯域セーブできるぜ。


痛い彼はタイルのサイズは256KBだと思い込んでるようだけど、
Larrabeeのキャッシュは分散型ではあるけど共有キャッシュです。
あとは、わかりますね？


あと、命令のサイズの件だけどさ
リニアにアドレッシング出来るレジスタファイルの規模って
命令長にも直結するだろ？ｗ

んで、今のGeForceってレジスタって何本だったっけ？
32ビットレジスタが8192本あるいは16384本だっけ？
さて、1命令の長さは何バイトになるでしょうか？ｗ

Radeonのほうはネイティブ命令セット公開されてるけど、絶句モンですぜ
こんなんでよくGeneral Purposeとか言えたモンです。

補足すると、あくまでたかだかキャッシュラインの1エントリ32バイト程度の
「キャッシュ」
なんだから、上書きしないピクセルまでキャッシュに取り込む必要はないんですよ。
矩形内のピクセル数分だけキャッシュを食うって認識は誤り。
こんだけでだいぶメモリトラフィック減らせますよ。
http://software.intel.com/file/15542

＞テクスチャユニットに負荷がかかるとリングバスがパンク
もしテクスチャユニットの処理で詰まってるだけってなら、
コア空けてテクスチャユニットをエミュレートしてやりゃ良いよね
ほんとにリングバスがパンクってんならどうしよもないけどさ

しかし半透明とAAをどうすんのかって課題はどうしても残るんだよなー
4xSSAAとかなら、全描画を(0,0)・(0,0.5)・(0.5,0)・(0.5,0.5)ずらして4回描いて平均取るとかでいけんもんかね

ソースはFUDzilllaか頭の弱いデマカセジャン先生だろ
毎日がエイプリルフール

Wii 5,000万台とDS 1億台は任天堂にとって何を意味するのか
ttp://pc.watch.impress.co.jp/docs/2009/0408/kaigai499.htm

団子はIntel大好きだからな、盲目的に信用して他が見えてないなｗ
>>178のPDF、40ページくらいから読めば、ポリゴンサイズによっていとも簡単に破綻することが分かるのに。

タイルレンダリングによって稼げるのは少数の小サイズポリゴンが存在しているときだけで、
その前提が崩れるとまともに機能しない現実から目をそむけ続けてる。

ついでに書いてもいないことが見えちゃう妄想癖のおまけつきｗ

>>178の資料からIntelの言うタイルレンダリングが何かが覗えるわけだけど、
結局のところドリキャスはまったく関係なく、>>157前半で説明されたZ-Bufferの発展に過ぎない。

全てのタイルを持つわけではなく、注目する部分のみキャッシュしていくという違いはあるものの、
これはあくまでLarrabeeのキャッシュ構造にあわせメモリのパディングをあわせるだけの効果しかなくって、
ラスタオペレーションでパディングを外れたメモリ領域にアクセスして無駄なトラフィックを発生させるよりは
キャッシュライン毎に分割してトラフィックを発生させたほうがマシ、って考え方。

当然異なるポリゴンを処理する際には別のメモリ領域にアクセスする必要があるし、
ポリゴンサイズが大きくなればその分アクセスするメモリ領域が大きくなるため、
キャッシュ内に収まるなんていうのは完璧な嘘だし、メモリトラフィックが減るっていうのも嘘。
単に「無駄なトラフィックが減らせる」だけ。

で、LBRniではその領域を判別するための稜線計算と認識が効率的に実装できるっていうだけ。

今のGeforceにはそれだけ無駄なトラフィックが多いということですね。わかります。

その分足回りを太くしているね。G80なら 64bit x 6並列。NV770なら 32bit x 8並列。
Larrabeeもメモコン4つくらい積んで Unganged Modeでアクセスしたら、少しはまともになるかもねｗ

9ページ(>>178)の図が実際の製品のダイアグラムだと思っているイタイ子ですか？
あれは模式図だからわかりやすくするためにああ書いてあるのであって、メモコンが幾つになるかは未だ不明なのだが。

で、実現なるのか？
ソースはいまいちだし、コケそーな気がしてきたが

メモコンがいくつになったとしてもリングバスに繋がるんだったら
リングバスが首根っこになるんじゃないの？

>>178
リングバスじゃなくなったらS3のChrome400だなこれ

団子息の根止められたな

>>184,186
ただ帯域を増やすってのは、根本的に電力効率を無視した設計だな。

ちなみにPCゲームはローエンドPCでも動くのを前提に作るから
ハイエンドにあわせてポリゴンは増やせない。
テクスチャの品位やシェーダで差別化する。

解像度が増えるほど有利になるってのは、要するにタイルあたりのポリゴン数は減るってこと。

解像度ごとに別々のポリゴンモデルを用意する？
どこの開発者がそんな無駄金かけるの？
CRISISですらたかだか200万ポリ程度ですよ。

解像度ごとではないにしろLODやDX11からのテッセレータが使われりゃ
爆発的に頂点は増えるよ

あと、解像度が増えりゃ当然処理するタイルが増えるわけだから
結局有利にはならんだろ

あれは主に輪郭部分を滑らかにするのが目的であって描画しないピクセル領域までキャッシュにのせなくていいのは変わらない

>>187
あなたも書いてもいない事が見えちゃう痛い子ですか？
見えない敵と戦ってるひとが多いなぁｗ

足回りがどうなるか不明だからメモコン4つくらい積んだらまともになるかもね、って言ってるだけですよ。
64bit幅のバス一本だけなら、まぁローエンド向け確定でしょうけど。

>>189
リングパケットが一つしか回らないとかなり厳しいですが、コアと同数かせめて 1/2個回ると
それなりにスループットは確保できます。

さて実装はどうなるでしょう？

>>192
> 解像度が増えるほど有利になるってのは、要するにタイルあたりのポリゴン数は減るってこと。

ダウト。
全体のタイル数が増える（たとえば20->192)と分母が大きくなって
平均のタイルあたりポリゴン数が減るという数字を使った誤魔化し。

解像度の高低に関わらず処理しなければならないポリゴンの数は変わらず、
かつ、解像度が増えるほど1つのポリゴンが占めるタイル数が増えるため、
メモリトラフィックはそのまま増加します。

ポリゴンがシーンに1つしかなければ、処理の終わったタイルは用済みでしょうが
実際はポリゴンは大量に存在するため処理の終わったタイルは一概に用済みとは言えません。
特にタイル処理の場合、同一タイル内にポリゴンが複数入り込む可能性が高くなります。

> CRISISですらたかだか200万ポリ程度ですよ。

あんた200万ポリゴンもあったら相当ですって。
RADEON9000、GeForce3程度じゃ 60FPSで処理できませんな。

テクセル処理も60億テクセル/sec位はほしいので、GeForce9600GTでやっとってところですか。

Larrabeeだとジオメトリデータだけでキャッシュあふれてしまいますから、
やっぱりメモリバスは強力なものがほしいですねｗ

妄想悪いけどゲームの性能向上にビジネス的活路はない
エンスーゲーマーなんて絶対数は少ない。
今後はGPGPUがメインアプリになる。というかNはそうしたい。

モニタの解像度が上がっていくのにポリゴン数が増えないんじゃ、ポリゴンが複数タイルにまたがる割合は逆に増えちゃうだろ

>>196
あらあら、自分でCRISISと出しておいてゲーム性能関係ないとか言い出しちゃったよ、この子

>>197
視野角あきらめてるTN以外はドットピッチ頭打ちですがw
倉作った会社がPCゲームはもう儲からないって言ったんですよ

どうでもいいがCrysisだと思う

ゲームの性能底上げのためにも非ゲームが必要ということだよ
少なくともNのGPGPUはそういう位置付け

まあ確かに、このごろは開発費が高騰しすぎて100万本売っても赤字になるケースも出てきたな

つまりまぁ結局のところ>>151ってことじゃないですか？

チップセットの支援なしでOSからアプリ、音声・ビデオ・簡単な3D描画処理まで出来れば
Intelとしてはサードパーティ排除もできてうれしいよね。

そのくらいならメモリ帯域大して食わないからオンキャッシュじゃなくても処理できるしｗ

Larrabeeのメモリバス幅が極端に狭い
前提で語るID:L7T7q90vはなんなの
Intelの中の人だって性能評価ぐらいやってるだろ

キャッシュがあるからメモリ帯域は節約できるという主張に対するツッコミなのでは？

> Larrabeeのメモリバス幅が極端に狭い
> 前提で語るID:L7T7q90vはなんなの

どこでそんな発言したのかｋｗｓｋ

>>205
でも彼は>>186でGPUに非効率的な面があって
それをLarrabeeが解消していること
を認めているんだよね

>>206
>>203

>>207
Larrabeeのアプリケーションとして有効な方向性を示しただけであって、
実装が示されていない現状、足回りを疎かにしちゃいかんよねって話をしているだけですが？

Cache万能論を展開するほうがよっぽど可笑しい。

結局のところ

今わかっているのは
LarrabeeはメインメモリとのByte/Flopsがある程度までは
低いことを許容できるハードウェアアーキテクチャ
ということであって

これは既存の製品との比較では
コスト的電力効率的なアドバンテージであると思われるが
ディスクリートグラフィックスとして実際に市場で成功するかは
シェーダの実装やらメモリバス幅やら競合する製品の出来やら
他にも支配的な要因があってさっぱりわからないわけ


>>208
>そのくらいならメモリ帯域大して食わないからオンキャッシュじゃなくても処理できるしｗ

>>209
> つまりまぁ結局のところ>>151ってことじゃないですか？

> 消費電力が数W程度に抑えられるなら、
> Windows7が動くスマートフォン用プラットホームとしてQualcommのMSM7xxxxを駆逐できるかも？ｗ

よほど悔しくて話が見えてないのかもしれないけどｗ

　Qualcomm MSM7xxx対抗としてのLarabeeを考えた場合メモリ帯域はそれほど必要ない

という話をしてるわけで、因果関係が全く逆。

>>ID:g7ggsR1Y = ID:L7T7q90v
じゃあこっち

>>148
>見えるけど、現実を見ると壁は20平米位の広さがあって30色使うことが要求された。
>足りない色が出るので中身交換しにヨチヨチ歩きの子供がお使いにでる。
>バケツの容量も足りないからやっぱりお使いに何度も走る。
>
>所詮使えるのは犬小屋の屋根を塗る程度でしたってオチ。


#もちろん「俺は昨日のpID:g7ggsR1Yじゃない」
#と主張してくれてもかまわない

なんでこんな日本語の解説しなきゃいかんのだろ。相当頭悪いよな。

>>212
>>140-141の「キャッシュがあればバケツまで何往復もしないでいい」という話に対して
そんな実装じゃ「所詮使えるのは犬小屋の屋根を塗る程度でしたってオチ」だっていう話だろが。

どのポリゴンがどのタイルに属してるか事前に全部ソートしときゃええ話ちゃいますの
1個1個ポリゴンが来たら逐次タイルとコアの割り当て変更するの？無駄すぎる

これって結局VGAとしてPCIEに刺して使うんだろ
よほど限定された用途かソフトが対応するようにプログラムを書き換えないと意味内規がする
でないと結局深夜アニメのエンコあたりにしか使われなさそう
専用ソフトが付属してな

Gpuとして高性能じゃないと普及はしないだろ。
他の用途はあくまでオマケ機能でしかないし。

来年出たとして、1〜2万円でHD4770やHD5850あたりと互角以上の性能がでるのか？

>>216
んな安い訳ないだろｗ
最初のLarrabeeはソフト開発者向けの開発キットのようなもので、恐らく高い。

仮に2010年に出たとして、その時点でグラフィックボードとしてだけ使いたいなら、
nVidiaやAMDのハイエンドのを買うほうが、同じ値段で高パフォーマンスなのが
手に入る。Larrabeeの柔軟性を生かす市販のソフトなんて当面皆無だろうし、
自分でコード書かない人以外には高いだけで宝の持ち腐れ。

ビデオエンコードをやりたい人は、そろそろ聞こえてくるだろうSandy Bridgeのほうが
合理的な選択肢になるはず。従来のエンコードソフトの一部にAVXを使ったものが、
Larrabee向けのものより早く、種類も出てくる。

並列計算そのものや、グラフィックか、物理シミュレーションや、バイオインフォなどの
研究をやってる人以外が相手にするようなものじゃない。
本当にPS4に採用されるなら（ないと思うけど）、ゲーム開発者も使うことになるだろうけど。

ま、ゲームがハイエンドVGAを牽引することはないし
どの会社も一致した見解だと思うんだが。
ゲーム向けディスクリートGPUなんて衰退市場だし。

俺は何度も言ってる希ガスるんだが、Intelがその「ニッチ市場」に参入する意味は
GPGPU殺しと同時にHPC向けのアクセラレータ。あとCPU＋GPU統合時代に向けての実験。
IntelはNVIDIAやATIのハイエンドにゲーム向けVGAとして勝ちに行く気など更々無い。
ミッドレンジクラス程度の性能が出ればゲームにも十分使えるし
そこで初めてGPGPUよりマシなアクセラレータとして評価を得ることができる。

ハイエンド路線の会社は次々縮小あるいは経営破綻。
FF11やリネージュみたいなノートで十分なネトゲはまだまだ盛況。
この状況でどこのソフト会社が、補助電源必須の爆熱グラボ要求するゲーム出そうと思うんだ。
コンシューマ機のお下がり移植が関の山だろ。

キャッシュの活用によって得られる電力効率を破綻させてまで既存GPUの
延長のスペック要求に合わせる必要はないわな

もっとも「本来の目的」であるストリームプロセッサとして困らない程度には
高帯域のインターコネクトバスは備えてくるだろうけど、HPCもラニングコストは
消費電力に比例するからね。

つまり、失敗する

高電力効率かつx86ベースの演算アクセラレータはHPC市場がもっとも望んでるものだよ
導入コストよりラニングコストのほうがかかるからね。
経費削減が叫ばれる今だからこそ電力効率が求められる。


まあ何年か先にはCeleronのCPUコアの隣に載っかってるだろうよ

PCIe x16の帯域を十分活用できるアプリケーションはゲームじゃなかったってことさ

Pixomatic 4（仮）をやりたかったRAD房の夢と
ATIやNVを抹殺したいIntelの野心が組み合わさった結果が
ハイパーファンタジーペーパープロセッサ ララベー

ここ最近の団子のハードル下げがひどいwｗ

最初から言ってると思うが。
意外にも電力効率にフォーカスしたアーキテクチャということが明らかになったので
GPUとしても十分いけると思うぜ。

ミッドレンジGPU並みの性能をミッドレンジGPU並みの消費電力で実現できるなら悪くないだろ。

ちなみにビットインターリーブ命令あるけど、何に使うか解りますか？
わかんねーだろうな。

ヒント：ロード・ストア命令

ららびんびんがでた頃はミドルレンジクラスのGPUの性能は言わずもがな〜
NVとAMDはソフト開発を頑張ればいいし〜

Pentium 4そっくりだね。
TDP限界が見えてしまった＆リーク電流でシュリンクしても消費電力下がらない

1KW補助電源でも用意しないと今までのペースで進化できなくね？ｗｗｗ

40nm世代ではGTX260クラスがミッドレンジの消費電力帯（補助電源要・不要の境界あたり）
に降りてくるという認識でいたけど、それも叶わないようで

というか、今ミドルの主力製品のGTS250ですら、高負荷だと、三年前の
8800GTX相手にせいぜい一長一短なわけで・・・。なんか今年いっぱいは
ロードマップが空欄っぽいし。

とするとビッグチップなNVIDIA製ははやくも脱落か

Intelは製造キャパの限りビッグチップ路線だと思うけど
クロックゲーティング・パワーゲーティングに割いて
実効消費電力を落とすだろうし

というか、ゲームデベロッパーが脱落してないか？
コンシューマに逃げたり、会社そのものがなくなったり
ここまでやるゲーム無くなるとは思わなかった。

日本にはまだエロゲがあるジャマイカ

JKはみんな携帯で100円、200円単位のゲームをやってるよ^^

GDCでは説明なかったようだけど、ビットインターリーブはヒルベルト曲線用だそうだな。
「ハッカーのたのしみ」にも載ってる

ちなみにpunpcklbw＋pmovmskbとかで生成する厨テクとかもあるけど

大半のユーザーはPS2クラスのゲームで満足してる

そーいえばコンピュータ将棋最強のBonanzaってヒルベルト曲線使ってるよね。
LarrabeeがAIに使えるって、そういう意味なんだ
と思いました。

Intelプロセッサが羽生に勝てる時代が来るならそれはそれで面白いじゃないか

物理エンジンで美少女キャラのおっぱいがリアルに揺れるんなら買ってやってもいいぞ

物理エンジンより作家が演出した方がよい
http://www.teck.co.jp/gj/products/himebo/anime/anime.html

日本のエロ絵師は神。

ある性能を出す場合
ワットパフォーマンスを追及→クロックは下げ、その分チップサイズを大きくして補完
コストパフォーマンスを追求→チップサイズを小さくし、その代わりにクロックを上げてカバー

省電力化の方策が同じならね。

たとえばAtom Z550は2GHz動作でTDP2.5Wだけど、回路をシンプルにするのと同時に、
演算クラスタ毎にクロックゲーティング・パワーゲーティングの回路を追加し、
綿密な電力管理をすることで実現している。

GPUはそういう電力の最適化とはほど遠いところにある。
っていうか、まともにやってないと思う。



たとえばだけど、Larrabeeのマスク演算の本質はなんだと思う？
マルチプレクサを使って演算結果をデスティネーションフィールドにブレンディング？否。
エレメント毎にコントロールフロー・データフローを遮断して
「演算そのもの」をマスクすることができるんだ。

あと、スカラを上手く使うことでデータフローの削減もやってるんだ。
同じベクトル内のロード・ストアアドレスの算出なんてスカラレジスタでやればいいじゃん。
ところがベクトル型のプロセッサってのは、ベクトルの全要素で同じ演算やりやがるんだよね。
ﾊﾞｶｼﾞｬﾈｰﾉ?

Atomにパワーゲーティング・・・だと・・・？

ん？Power Gatingはまだだったかな？


http://www.anandtech.com/showdoc.aspx?i=3230&p=4

Clock gating (sending the clock signal through a logic gate that can disable it on the fly,
thus shutting off whatever the clock connects to) is an obvious aspect of Silverthorne's design.
All Intel processors use clock gating; Silverthorne simply uses it more aggressively
- the clock going to every "power zone" is gated, something that isn't the case in
mobile Core 2. Each logic cluster (205 total) in Silverthorne is referred to as a Functional
Unit Block (FUB) and the entire chip uses what Intel calls a sea of FUB design.
Each FUB is clock gated and can be disabled independently to optimize for
power consumption.
The cache in Silverthorne is in its own FUB, which apparently isn't the case in mobile Core 2.

GPU屋からはこういう電力制御のノウハウの話を聞いたことがないな。

今時のGPUならクロックゲーティングは普通でしょ

クロック単位じゃなくてmsec単位だけどな。

GPUの自称クロックゲーティングが効くまでのタイムラグと
AtomのC1,C2が効くまでの時間ってどっちが短いんだろうな
MONITOR/MWAIT命令ってクロック単位で制御できるぞ。

ハードウェア制御とソフトウェア制御を混同してないか？
クロックゲーティングとC1/C2ステートは同レベルの話じゃないでしょ。

Larrabeeって結局MSにもソニーにも見限られたらしい。

>>246
msec単位じゃソフト制御より効きが悪いぜ

どうやって時間測ったんだろう
CPUで言うEISTやC'n'Qみたいなのと勘違いしてないか？
あれは遷移時間体感できるからmsecと言うのも分かるが

http://benchmarkreviews.com/index.php?option=com_content&task=view&id=179&Itemid=72&limit=1&limitstart=13

> The GPU also has clock-gating circuitry, which effectively "shuts down" blocks of the
> GPU which are not being used at a particular time (where time is measured in milliseconds),
> further reducing power during periods of non-peak GPU utilization.

案外、ソフト制御じゃねーの？ｗ

Intel の Pat Gelsinger 氏、IDF で Larrabee や Nehalem EX など説明
http://japan.internet.com/webtech/20090408/4.html

今のIntelオンボもタイルレンダリング

タイルレンダのときってタイルごとにVS全部計算しなおすの？
Xbox360だと分割数が最大4つなので最初のパスでタグをつけるらしいけど、
Larrabeeとかじゃそういうのは現実的じゃないよな。
かといってメモリに書き出すのもないと思うし。

なんのための共有キャッシュだよ

その中間バッファどっから調達すんだよ？

テクスチャデータが通過する度にCPU向けのデータもザックリクリアされる共有キャッシュ素晴らしス

全てのロード・ストア命令にノンテンポラル（キャッシュを汚さない）指示を付加できるんだけどね。
1回しか使わないデータはみんなノンテンポラルでロードすることになるよ。

転載しておくか
> Intel Gets Ready to Push Ct Out of the Lab
> ttp://www.hpcwire.com/features/Intel-Gets-Ready-to-Push-Ct-Out-of-the-Lab-42634332.html
> Ctはベータ版が年末に出る。最初の製品版は2010年末に出る。
> Ctを使う最大の利点は、Ctの高度な抽象化によってマッピングが透過的に行われるために、
> プログラマーがベクタユニットやプロセッサコアを操作したりデータ構造をマップする必要がないと言うことだ。
> また、この技術は決定論に基づいているので競合やデッドロックの問題を避けることが出来る。
> 並列計算には「正当性の確保」と「スケーラビリティ」という二つの困難がありCtはそれらを解消することを目標にしている。
> CtはC++のSTLの利便性を踏襲する形での拡張によって実装されており、
> Ctの提供するデータタイプとオペレータを用いて既存のコード書き換えることで、
> コードのデータレベルの並列性を引き出すことが出来る。
> Ctの長期的な目論見はデベロッパにメニーコアへソフトウェアをシームレスに移植させることである。
> 従って、今日、SSE4によってデータ並列計算を行うNehalemをターゲットに作られたアプリケーションは、
> Larrabee(LRBni)やSandyBridge(AVX)対応のアプリケーションになるだろう。

C++を便利にしたような言語でSSE・マルチコアを用いたアプリをさくさく開発できて、
気がついたらAVXにもLarrabeeにも対応してた、ってのを目指してるのだろうね

OpenCLは終わりっぽいね

という夢をみた。

だってOpenCL（笑）って実質GPGPU専用言語じゃん。
もちろんCPU向けの開発にも「使える」のは知ってるが、この場合は"able"であって"useful"ではない
N88BASICでAjaxできますって言われてもメリットが思い浮かばないのと同じ。
MSに支持されてない時点でWindowsでの標準化は無理だし

逆にIntelの提供する拡張はivec/fvec/dvecみたいな微妙なSIMDクラスライブラリまで
VC++標準で取り込んだのがMS。
（あまりに微妙すぎてSSE3以降の関数はラップされてないが）

知識が偏ってんな。とても重い実数計算の需要に対応してきた世界では
Windowsがマイナーだったし、その影響がそんなに即座に消えるわけがない

団子とかただのCPUオペコードヲタじゃん

Larrabeeは単に普及度だけで言えば、IntelはCPUと混載するって言ってるんだから間違いなく普及はする
でも単体の拡張カードとして売れるかどうかはキラーアプリしだいだろうな

今のところLarrabeeが使えそうなのはHPCを除けばゲーム・エンコ・画像系のビジネス用途
ビジネス用途はパイが少ないし、エンコに至っては海外ではそもそもTVを録画する文化自体が無い

結局Intelがやるのはゲームメーカーに実弾投入してLarrabee最適化ゲームを出させる事だな
ぶっちゃけXboxに採用させることに成功すればチェックメイトだが・・・
まあMSは戦略上それはしないだろうな

Larrabee自体はどうあれ、LNIは新しいスタンダードになるって事ですね。

NVと実弾競争になればゲーム屋に美味しい展開。
しかし実弾の効果を出すには、ハイエンドチップからローエンドまでラインナップが必要では？
ミドルレンジ級チップしか無いのに最適化してしまうとユーザーが困る。

ならない

ララビもいつの間にか16コアになってて
ずいぶんしょぼくなったな

16コアは最小構成でそ。補助電源無しで動くかどうかのラインの。
ハイエンドはこれだろ→http://pc11.2ch.net/test/read.cgi/jisaku/1235460118/758


下馬評通り2GHzなら16コアで理論ピーク1TFLOPSで、GPGPUとしてはGTX280を超えるね。
（GPUと比較して）大容量のキャッシュを積んでる分汎用性は圧倒的に上だろうし

まあ、ただしゲーム用GPUとしての性能に疑問符がつくってのは確かに同意せざるを得ない。

本来ならTesla（あるいはFireStream）と比べるべき代物だろう
TeslaやらからはGPUとしての固定回路や出力系統は排除されててLarrabeeは持ってるが
それは立場の違いだと思うのです。

Larrabeeは「GPU機能を兼任するCPUコア」として、どこがネックになるのか、
市場を使って調査をする必要があるからな。
Celeronとの混載はその次の段階。

逆にTeslaはGPU機能を持つ製品が既にあるので、兼ねる必要がない。
必要ならQuadroを買ってくれと。

Intel Larrabee 2009年後半または2010年前半に登場が濃厚？

http://happinesslife120.blog31.fc2.com/blog-entry-1744.html

出る出る詐欺にならないことを祈れ

何はなくともCtのデキ次第なのだろうなあこれ
1つのプログラムをダイナミックリコンパイルによってどこまでマルチコアスケーラビリティが出せるのか

Itaniumも第1段のチップは超ショボかったよね
デベロッパーにサンプルとして配ったプロトタイプの余りを市場に出した感じだった

Larrabeeは45nm-8コアで300�o2、16コアで600�o2クラスか

32nm-16コアだと300�o2、22nm-16コアだと140�o2で収まる
最終形は22nm-48コアらしいから、430�o2で処理能力3〜4Tってところか

Larrabeeは600mm2と書いてるフランスのサイトだと、45nmだと48コア、
32nmだと64コアかって推測してるけど。
Intelが去年140mm2のMeromくらいでLarrabeeだと10コアくらいと計算してたから、
45nmの300mm2で8コアってのはいくらなんでも、コア数少なすぎると思うが。

論文読んでないのか
10コア+4MBのL2キャッシュで140mm^2だよ
PenrynのL2キャッシュは6.0mm^2/MBなので
16コア+4MBのL2キャッシュだと185.6mm^2位になる計算

>Larrabeeは45nm-8コアで300�o2、16コアで600�o2クラスか
何このPenryn級のリッチコアｗ

10年前は命令レベルの並列性を追求しし
今はデータレベルの並列性を追求するとな

魔法のコンパイラさん（とその他中間レイヤーさん）がんがって！

〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
従来のスーパー・スケーラRISCでは，並列処理可能かどうかはプロセッサ内で判断されていた。
そのためプロセッサ内部で命令内容を解析する必要があり，これがプロセッサを高性能化する
上での大きな壁になっていた。また，並列処理可能か否かはコードの配列にも依存する。
そのためプログラムによっては並列処理の効果を最大限に発揮できないという問題も抱えていた。

これに対してEPICではプログラムをコンパイラが分析し，並列処理を最も効率的に行えるコードを生成する。
このためプロセッサは並列処理可能か否かを解析する必要がなく，コンパイラが作成した並列処理可能
なコードを実行するだけでいい。つまりハードウエア（プロセッサ）に完全に依存するのではなく，
ハードウエアとソフトウエア（コンパイラ）が役割を分担するのである。並列処理の方法をどうするかは，
ソフトウエアに任せた方が実行時の効率が高く，より高度な手法も導入しやすい。ハードウエアは
よりシンプルな構成によって，与えられた命令を高速に処理することに専念できるのだ。

このようなアプローチによって，インテル Itanium 2 プロセッサはスーパー・スケーラRISCをはるかに
凌駕する並列処理能力を実現した。主要なRISCプロセッサでは，1サイクルで同時実行できる命令数
は最大でも4命令。これに対してインテル Itanium 2 プロセッサは，現時点で最大6命令を実行できる。

コンパイラ屋だけでやれると勘違いしてできたのがEPIC
Ctではマもそこそこ頑張るんだよ
CELLやCUDAの様な非人道的な要求はしないというだけで

>>270
どんなコア数、キャッシュサイズ、メモリバンド幅、ベクタ長でも
スケーラビリティを引き出せるDaynamically reoptimaizeに期待しましょう＾＾
http://pc.watch.impress.co.jp/docs/2008/0822/kaigai_10.jpg
超インテリジェンスな抽象化機構が見事に最適化してくれます＾＾
http://pc.watch.impress.co.jp/docs/2008/0822/kaigai_11.jpg

さあお前ら、nVIDIA様がとっととVIAを食って超すごいCPUを出してくれることを祈る作業に戻るんだ

nvは潰れるだけだろ

IONプラットフォームが解禁になった以上必要ないだろ。
x86市場はintel以外は儲からない仕組みになってるからな。

CUDAはね、
SIMDの各エレメントをThreadという概念に抽象化するのはいいのだが
switch文とか途中returnとかやったらクソ遅くて
結局元のハードウェアがSIMDでってないということを意識しないといけない
意識して書かないとCPUの半分の性能もままならない代物

ということ。
Intelはベクトルという概念を隠しもしない。
STLで行列演算とかやったことある人なら直感的に使うことができるだろう

言語仕様としてはCtのほうが無理なく抽象化してる。

>>273
＞140mm2のMeromくらいでLarrabeeだと10コアくらい
それはI/Oや内部バス、GPUとしての後処理ユニットの部分を除いた
純粋な演算ユニット部分だけでの話でしょ

汎用性を付与するために多量のトランジスタを使ったX86対応回路、面積効率の悪いMIMD、リングバス（しかも16コア以上では2階層）を
使って尚600mm2で48コア突っ込めるとなると、単純計算でトランジスタあたりの効率は既存GPUの数倍になる

これじゃピーク性能は低いが汎用性に優れた・・・などと言う話は吹き飛ぶよ

＞GPUとしての後処理ユニット
こんなもんあるの？ テクスチャこねこねユニットだけじゃね固定なの

>テクスチャこねこねユニットだけじゃね固定なの
その通り。

>>282
あのさー、ゲームがやりたいならゲーム用GPU買えばいいジャン。
僕らそういうの求めてないんだからさ。

48コア＠3TFLOPS版があるってこと自体が、電力効率の高さの証明になってるんだが。
暗黙に300W上限の縛りがあるからね。
GTX295なんて1.5TFLOPS程度だろ。

了解！
普通にRVxxxやGTxxx買います

GPUは単純にシェーダーだけにトランジスタ全部割けるってわけにいかんからねー
ROP数やメモリ量・バンド幅なんかをバランス良くリッチにせにゃいかん

対GPGPU用途で圧勝するってのは大前提でゲームは二の次でしょう
時代がソフトレンダになるのを待つみたいな。
ゲームなんかのためにGPUの水準に成り下がる気はないでしょう。明らかに。

逆にさ、GT300とか必要なゲームとかって出るの？
マップやオブジェクトのデータ読み出しがネックだから、ストレージに金かけたほうがマシになりそうだけど。

Memory I/Fがそんなにトランジスタ喰うかよ

GPUのトランジスタ消費は素人には分りづらいな。→GT200でSPあたりの
レジスタ数4倍になってどれくらいトランジスタ増えるのかとかよくわからん

メモリI/Fはトランジスタは食「え」ないが正解じゃないかな。
熱密度が大きくなるから

R600のリングバスは２億超えでした

>>291
　　----------------
　　熱密度が大きくなるから
　　----------------
どこでそんなトンデモ説を覚えてきたやら…
http://ascii24.com/news/i/tech/article/2005/02/10/imageview/images765504.jpg.html

LarrabeeのリングはCellのEIBと同程度だろうけどね帯域的には

R600がリングなのは熱の分散の為もあるのよ

Cell（笑）（笑）（笑）（笑）（笑）（笑）



ちなみにGPUのメモリ帯域依存度はCPUやCellと比べものにならないよ

トランジスタ数じゃなくてコストだろう。
キャッシュは熱密度が低いし、Pentium Mではそれ自体を
ヒートスプレッダとしての副作用を期待してL2を大きくしたふしがある。

>>296
　　-------------
　　ちなみにGPUのメモリ帯域依存度はCPUやCellと比べものにならないよ
　　-------------
確かにGPUの温度/熱分布のデータを見たことはないですね。
そのうち見つかったら紹介しましょう。

RAMBUSが言うにはメモリ転送帯域当たり消費電力はGbitあたり0.5W

GDDR5のね

>>297
　　--------------
　　キャッシュは熱密度が低いし、
　　--------------
熱密度が低いのは、アクセス頻度が小さい"L2"以降のキャッシュ限定の話です。
L1キャッシュの消費電力は非常に大きいのですよ。
古典的な参考文献ですが、Table 1とかをどうぞ。
ftp://ftp.cs.utexas.edu/pub/techreports/tr03-20.pdf

常識。なにを得意げに。
直接アドレッシングできる点でIntelアーキのL1はGPUのレジスタファイルと似たようなモンだし。

>>285
Larrabeeの性能が劣るなんて話はしてないぞ
45nm世代の600mm2のチップに48コア詰め込めるとすると処理能力は3T前後
これは性能があまりにも“高すぎる”って言ってるんだよ

GT200を45nmにシュリンクして600mm2まで拡張しても2T前後にしかならない
なのにピーク性能より汎用性に重点を置いたLarrabeeが3T？

ようするに>>273の『45nm-600mm2のチップに48コア載ってるかも〜♪』
って予測は期待しすぎじゃないか？ってこと

別にLarrabeeをけなしてる訳じゃ無い

>>303
>>274の意味がわからないなら素直にそう言えよｗ

>>302
　　----------------
　　直接アドレッシングできる点で
　　----------------
ちょっと妄想入っているような…
メモリアドレスを引数に取れることをもってL1を「直接アドレシングできる」とは言わないのでは？

http://www.overclockers.com.ua/news/hardware/2009-04-10/103617/
> Во-вторых, стало известно об увеличении
> возможного количества ядер топового графического
> чипа Intel Larrabee с 40-48 до 64 штук.

>>306
AtomにすらL1 Read専用のステージがあるのも知らないのか
ああそうか知らないのか

それと、レジスタ的に使えるってのはIntelの中の人自身の言葉だぞ

あとLarrabeeの場合キャッシュラインのサイズとベクタ長が32バイトで一致してる

>>306
それソースは>>273の方が引用しているフランスのサイトですよ。
　　-----------------
　　Источник:
　　HardWare France
　　-----------------
読めないのなら海外サイトを引用すると恥を書きますが。

> 「LarrabeeではL1キャッシュをレジスタの延長と考えることができる」とIntelのTom Forsyth氏は説明する。

http://pc.watch.impress.co.jp/docs/2009/0330/kaigai498.htm

>>309
「直接アドレシングできる」というのとは意味合いが違うような…
CELLにおいて128個のレジスタはL0-cacheであるというのと同じように、使い方の話題ですよ。

何度でも言ってやるがL1リードはパイプラインに組み込まれてるんだよ。

addps v1, v2, [mem]は1クロックサイクルのスループットでこなせる

SPUのshufbでルックアップ可能なテーブルは2本のレジスタに収まる32byteだけだが、
Larrabeeの場合は32KBのL1キャッシュ全体だ
もちろん複数サイクルかかっていいなら、L1に収まる必要もないがね



>>307は64バイトの間違いね

>>311-312
せめて意味を理解して書いていると思いたいのですが…

きっとload命令と加算命令に分解されて処理されると思い込んでいるんだな（笑）

GT200のレジスタファイルのレイテンシは64KBあったりするけどその分レイテンシは大きいんだよ
レジスタだからキャッシュより速いなんて固定観念は捨てて下さいｗ

×GT200のレジスタファイルのレイテンシは64KBあったりするけど
○GT200のレジスタファイルは64KBあったりするけど

GeForceの悲惨なレジスタリードレイテンシの話題
http://forums.nvidia.com/index.php?showtopic=66238

>>317
　　-------------------
　　GeForceの悲惨なレジスタリードレイテンシの話題
　　-------------------
意味が分かっていますか？帯域幅の問題のようです。
　　===================
　　- operand gather:
　　Input operands from registers are read sequentially from the same bank(s) of the register file.
　　Takes from 2 cycles (1 32-bit input operand) to 12 cycles (3 64-bit input operands).
　　(actually 1 to 6 cycles as the RF clock is half the shader clock)
　　===================
読んだ通り、最小単位のデータではレジスタの動作クロック(シェーダーユニットの半分)換算で
シングルサイクルとのこと。

二人が何を話してるのかさっぱり分からんけどさ
（どっちが正しいのかもわからん）
ハッキリ言って迷惑です。
特に団子はこのスレに限らないけどいつも連投しまくるし
冷静さを欠いてすぐに感情的になるし正直見苦しいんだよね


とにかく両者自重してください

ホモジニアスの多数コアプロセッサって、歩留まり良さそうだよね
17コア焼いといてゴミついた1個オフすりゃおｋって確率が高くなる

>>319
今更何言っても無駄。大人しくあぼんしとけ

>>318
わかったろ？
だから、一般的なCPUのレジスタと同じ尺度でレジスタだからCPUのキャッシュより速い
なんて思い込むのは無意味だと。


ちなみにLarrabeeは各コアあたり本物のSIMDレジスタからのレジスタリード帯域は192B/clkで、
L1からでも64B/clkは最低限な
去年8月時点でそう書いてるし。

>>319
　　----------------
　　二人が何を話してるのかさっぱり分からんけどさ
　　（どっちが正しいのかもわからん）
　　----------------
ここは日本語圏の人達に解放された、公開の掲示板です。興味の範囲が微妙に異なる人が
いることは当然なんですよ。
もし判らないことがあれば、尋ねていただければ回答が帰ってくる場でもあります。
ちょっとしたチャチャ入れは別にして、私が投稿する内容は理解できるようになって損は無いかと。

>>322
　　---------------
　　わかったろ？
　　---------------
全然。
GPUのようなメニイコアシステムで、バス幅(=配線)をケチって構造をシンプルにすることは
単なる設計上のトレードオフです。レイテンシ的にバス幅分のデータをシングルサイクルで
読み書きすることは、アドレス変換を必要とするL1キャッシュには無理です。

ちょうどデバイスドライバ経由でのアクセスが必要なHDD上の仮想メモリを「物理メモリと同じ」
と強弁するのと同じことだと思いませんか？

GeForceの実効性能の低さは誤答すら指摘してるよ
http://pc.watch.impress.co.jp/docs/2008/0707/kaigai452.htm

GPU特有のトレードオフ（笑）を抱えたまま汎用プロセッシングがどうとか
嘲笑の対象にしかなりませんぜ。


> レイテンシ的にバス幅分のデータをシングルサイクルで
> 読み書きすることは、アドレス変換を必要とするL1キャッシュには無理です。

1サイクルは流石に出来るとは思わないが、GPUのレジスタファイルみたいな程度の
水準で良いなら十分可能だと言ってるわけだが。

それはそうと、いつぞのTera×3では、LarrabeeのL1のレイテンシは１じゃなかったかな？
勿論信じてはいない。

http://microboy.seesaa.net/article/70255114.html

>>325
　　-----------------
　　GeForceの実効性能の低さは誤答すら指摘してるよ
　　-----------------
>>302から読み直して欲しいのですが、誰もGPUのレイテンシを問題しているのではなく、
「直接アドレシングできるか」を問うているのですが？

俺は帯域とレイテンシしか問題にしてないよ
TLBを参照してキャッシュのタグを・・・云々は実用的なクロックで出来るのなら何の問題もない

殆どの命令の一つのレジスタオペランドをModRM + SIB + DISP + imm8によるメモリ参照に
置き換えることが出来る点で使い勝手の面では全然問題にならないわけだし
（むしろメモリからのロード時にNumeric Convert出来る点で容量効率的に巨大レジスタファイルより優位性がある）

Tera Tera Teraのコア数やメモリの量から察するに
当時のLarrabeeは2008年の半ばから2009年の頭には出す計画だったんじゃねえかな
まー今だから言えることだが

テープアウトはまだかね？

>>330
>>267

>>328
　　-----------------
　　（むしろメモリからのロード時にNumeric Convert出来る点で容量効率的に巨大レジスタ
　　ファイルより優位性がある）
　　-----------------
ロード時のscatter/gatherやconversionが有効なのは否定しませんが、DDJ記事
(http://www.ddj.com/architect/216402188)において、"currently a two(multi)-instruction
sequence. "という文言が散見されることから見ても、最初のLarrabeeの実装においてその機能が
単なるロード・ストアと同じレイテンシで動作するとは思わないほうが良いかと。

当たり前
逆に、Numeric Convertをしない時までするのと同じレイテンシになられては困るし
過剰なオペレーション密度の追求は熱密度を高め、結果的に性能向上の足枷に
なりかねない

>>333
返事が返ってくる度に、本当に意味を理解してもらえているのか不安になるのですが…
　　--------------
　　過剰なオペレーション密度の追求は熱密度を高め、結果的に性能向上の足枷に
　　なりかねない
　　--------------
その思い込みと逆に、Intelの方は『将来は単一命令にしたい』と述べているのですけれど、
判っていますか？例えば、
http://www.ddj.com/architect/216402188?pgno=4
　　===============
　　Figure 12: vgatherd v1 {k1}, [rbx + v2*4]. This is a simplified representation of what is
　　currently a hardware-assisted multi-instruction sequence, but will become a single
　　instruction in the future.
　　===============

Larrabeeキャッシュでかすぎワロタ
>>139はどうした?死んだのか?

vgatherdがマイクロコード実装ってのは　【俺が8月に予見したとおり】　だろｗ
演算ユニット側で分解するとか言ってた馬鹿がいるが。

最大16回のマスクつきvloadd に展開されるんだろう
どこでって、とりあえずはデコーダじゃね？
もちろんその際にマスクレジスタはソフトからは見えないシャドウレジスタあたりを使うことになるだろう

できれば今のCore MAのように除算器側で独自にループをまわして処理したいんじゃない？
俺は将来の実装ってのがCore MAに統合した場合の実装に思えて仕方が無いが
インオーダ型プロセッサには単一μOP化する段階ではない。

>>335
ワーストケースいろいろ考えてみたけど、最大サイズなら1080pくらいなんとかなりそうだよな
たぶん4kが無理だとかイチャモンつけるんで無い？ｗ

○　できれば今のCore MAの除算器のようにALU側で独自にループをまわして処理したいんじゃない？

>>336
　　----------------
　　vgatherdがマイクロコード実装ってのは　【俺が8月に予見したとおり】　だろｗ
　　----------------
ちょっと当時の議論を読んでみましたが、それあなたと議論していたヒト達の共通認識だった
ようですが？
http://pc11.2ch.net/test/read.cgi/jisaku/1214999146/388
http://pc11.2ch.net/test/read.cgi/jisaku/1214999146/400
http://pc11.2ch.net/test/read.cgi/jisaku/1214999146/402
多分、最後のヒトを叩きたかったんだと思いますが、『複数命令に分割されるのは、キャッシュラインを
またぐ場合』という認識は間違っていないようです。

複数の内部命令に分解されるならデコーダで分解ってのが正解。

ワーストケースで16サイクルってのは逆にいうとPermute/Numeric Converおよびマスクは
ゼロコスト（レイテンシはともかくスループット的には）ってことな。

>>339-340
細かいことですが、
　　--------------
　　複数の内部命令に分解されるなら
　　--------------
今のところLRBniの命令は『内部命令』では無く、『(複数の)他の命令』に分解されるだけです。
新しいISAですから、現段階では命令とハードウェアの対応関係が保たれているのも当然かと。
　　---------------
　　ワーストケースで16サイクル
　　---------------
intelは『16回のキャッシュアクセスが必要になる』と述べているだけで、サイクル数は言及して
いなかったのでは？
http://software.intel.com/en-us/articles/game-physics-performance-on-larrabee/
　　================
　　The speedup of gather/scatter is limited by the cache, which can usually access
　　one cache line per cycle, which may result in 16 accesses to the cache in the worst case.
　　================

やっぱり鶏みたいな頭なんだな。いつの話だと思ってるんだ。

http://software.intel.com/file/2093

The VPU instruction set also includes gather and scatter support,
that is, loads and stores from non-contiguous addresses. Instead of
loading a 16-wide vector from a single address, 16 elements are
loaded from or stored to up to 16 different addresses that are
specified in another vector register. This allows 16 shader
instances to be run in parallel, each of which appears to run
serially, even when performing array accesses with computed
indices. The speed of gather/scatter is limited by the cache, which
typically only accesses one cache line per cycle. However, many
workloads have highly coherent access patterns, and therefore
take much less than 16 cycles to execute.
　　　　　　　~~~~~~~~~~~~~~~~~~~~~

＞今のところLRBniの命令は『内部命令』では無く、『(複数の)他の命令』に分解されるだけです。

命令セットとして公開されてない裏のマスクレジスタを使う命令だぞ
内部命令でなくてなんだよ

馬鹿だろ

そもそも何のための「デコード」だよ

新規の命令だろうがプリフィックスのエンコーディングが変わっただけでx86そのものだ。

POWER脳は去れ

P5まではx86の符号化された命令を"Instructions"と言うのに対し
内部命令を単に"Operations" (OPs)と呼んでた。

P6ではそれを更に分解するから"Micro-Operations"（μOPs）なわけで

>>342
それはキャッシュからの転送に必要なサイクル数のことで、命令のスループット／レイテンシを
示す数字じゃ無いことは読めば判るかと。

>>343
それはロード／ストアキューの『内容』であって、裏レジスタとは呼ばないと思いますよ。

いいや、命令セットとしてk0〜k7とは別のマスクレジスタが必要だ。
ロードした値をどうやって合成するんだ？

途中で割り込みが入ったらどうやって状態を待避するんだ？

そもそも別の命令に置き換わるってdemerjianばりの妄想のソースはどこですか？

デコーダを通る以上シンプル命令だろうが内部命令だよ。
x86そのままのエンコード形態のままデコーダを通過する命令など、ない。
旧いP54Cのマニュアルを見てもそんな記述は見られない

>>347
　　--------------
　　デコーダを通る以上シンプル命令だろうが内部命令だよ。
　　--------------
団子さんの認識ではRISCにはデコーダが無いことになっているのですか？

可変長命令ほどに複雑なロジックは必要ない、の一言だな。

表から見える命令ではない
実際表から見える命令では足りないことがわかる。


haddpsはPentium 4の内部RISCではシャッフル×2と加算の3命令だがx86からでは
いわゆる裏レジスタを使う手段がない

>>349
　　---------------
　　可変長命令ほどに複雑なロジックは必要ない[が、やはり内部命令であることに変わり無い]
　　---------------
ということでしたら、単なる表現の違いなので噛み付かれる筋合いは無いですね。
　　---------------
　　haddps
　　---------------
LRBniにその命令は見当たりません。>>341で取り扱っている話題はLRBniと実装の関係です。

複合命令の中間値のストアだけに使われるいわゆる裏レジスタなら8086の時代から知られてた。

ちなみにSSE3のHADDPSの例なんて不可視のテンポラリレジスタを用いる複合命令をSIMDに応用した典型で
それを関係ない話だと思いこんじゃうあたり勉強不足だな

っていうか、デコードされた命令が「内部命令」じゃなければなんなの？ｗｗｗｗｗ

>>353
　　------------------
　　っていうか、デコードされた命令が「内部命令」じゃなければなんなの
　　------------------
『命令』が演算を行うのでは無く、『論理回路』が演算を行うのです。

ALUは加算・減算・ビット論理演算を全部一つでやるのです。
動作を定義してやるのはやはり内部命令ですよ。
それとも、命令毎に別々の回路を通してるとでも思ってるのか？ｗ

>>355
　　--------------
　　命令毎に別々の回路を通してるとでも思ってるのか？
　　--------------
その通りですよ。
加算回路とか乗算回路とか聞いたことはありませんか？
http://journal.mycom.co.jp/column/architecture/070/index.html
http://journal.mycom.co.jp/column/architecture/078/index.html

馬鹿すぎｗｗｗｗいっぺん氏んで見る？ｗｗｗｗ
意味を理解しろよ


「ALU」は算術演算も論理演算も面倒見ますよってユニットだ
お前の論調だと減算や論理和・論理積など各オペレーションごとにユニットが必要になるだろｗ
常識で考えろ

http://www.is.titech.ac.jp/~ohshima/TA/architecture/ohshima/7/node9.html

なんでこうも計算機科学の基礎も理解してない人間が現れるんかな

それとも、今日も【MACのきげんがわるい】のか？
きめぇｗｗｗ

↓恥ずかしい発言だな
http://pc11.2ch.net/test/read.cgi/jisaku/1238152183/356

>>358
その"ALU"の中には、>>357で安藤氏が解説しているような回路が入っているのですよ。

ちなみに乗算器のページの方を見れば、乗算器には加算器とシフタが含まれていることから
も判るように、完全に独立しているという訳でもなく、入力ポートを切り替えて汎用性を持たせる
ことも可能です。

いずれにせよ、パイプライン上のどこかの段階で『命令』は制御信号に変換されることになります。

命令デコーダがやるのはOpcodeとOperandの正規化であって内部命令は文字通りの命令だ

MACヲタの拙い妄想に反して、Intelは演算ユニットに対し
一種のダイナミックコンフィギュレーションを用いることで
命令毎に専用回路を用意する必要がないようにしてるわけだが

たとえばSSEのPSADBWはSIMD乗算の最終段を使い回してると言っている

>>361
　　-----------------
　　内部命令は文字通りの命令だ
　　-----------------
それで>>348で『RISCは？』と問うたのですが？
まぁ水掛け論に陥るのも馬鹿らしいので、シンプルなRISCの一例としてAVR32のマニュアルより。
http://www.atmel.com/dyn/resources/prod_documents/doc32001.pdf (p.22)
　　---------------------
　　3.3 Decode unit
　　The decode unit generates the necessary signals in order for the instruction to execute
　　correctly. The ID stage accepts one instruction each clock cycle from the prefetch unit.
　　This instruction is then decoded, and control signals and register file addresses are generated.
　　---------------------
>>360の最後の行に書いた通りの内容です。

P54CはRISCではない。
だからPOWER脳は去れ

団子は否定のための否定をしてる感じだな
頭固すぎでしょ

加算回路と減算回路はマルチプレクサによって回路を使いまわしつつ切り替えることで実現できるね
http://www.ie.u-ryukyu.ac.jp/~wada/digcir05/alu.html

ここでは触れてないが、更に加算器のCarry in/outを捨てれば論理積(AND)、
carry outを伝播させずに出力に使えばXORになる。
ついでに、SIMD加減算の本質って何かわかる？
桁上げの伝播を途中で断ち切ってるだけだよ。

特に、乗算器みたいな規模の大きな回路を備えるようなCPUなら、なんとかして
回路を複数命令に使いまわせるようにしようと考えるわけで。
CPUによって加算ユニット・乗算ユニットがあるってのは確かにそうだが
決してそれぞれ加算命令専用回路と乗算命令専用回路ではない。
命令ごとに別々の演算回路を用意する、すなわち加算専用回路と減算専用回路が
並立なんて効率の悪いことはいまどき、いや、最初から、してないってことだよ。



ハッキリしたことがある。奴は大学すら出てないね。
ぶっちゃけALUの実装の知識は落第レベル。

内部命令のOpcodeはマルチプレクサの制御用入力ビットの集合である。
ま、馬鹿はしななきゃ直らないだろうな

45nmで600〜700mm2とかいってるけど本気でどこに売る気なんだ
てかこれじゃただのベクタプロセッサじゃね

>>368
ベクタマシンの心臓部としては中途半端だわ。Xeon疎結合のマシンが
威力を発揮するような計算をしている人には重宝されるかもしれんが、
メモリバンド幅もノード間結合ももっと太くなきゃ話にならんという
計算をやりたい研究者もたくさんいるわけで

大規模計算機より疎結合のクラスタが重宝されるこの時代にいまだにそんな研究者いるの？
それただ単に問題の分割ができてないだけなんじゃないの？

>>366-367
　　----------------
　　マルチプレクサによって回路を使いまわしつつ
　　----------------
なんだかスゴいところに噛み付かれて、驚いています。
マルチプレクサって『切替』を行う演算器です。電子回路として何を切り替えているんだと
思いますか？

　　----------------
　　内部命令のOpcodeはマルチプレクサの制御用入力ビットの集合である。
　　----------------
その認識だと、行先の演算器が全く異なる整数演算と浮動小数点演算とかのコードが
重なってしまいますよ(笑)

それからこれ、
　　----------------
　　内部命令のOpcodeはマルチプレクサの制御用入力ビットの集合である。
　　----------------
>>361で団子さんが主張している
　　================
　　命令デコーダがやるのはOpcodeとOperandの正規化であって内部命令は文字通りの命令だ
　　================
と矛盾しませんか。

団子に便乗するようだが
ペニスはx86が元々マイクロコードベースのCISCだってことを知らないのか、知っててなお
内部命令の概念が解らない真性の馬鹿のか、どっちだね？

それでなくとも2Way以上のスーパースカラにおいてデコード後の命令をキューイングしたり
スケジューラで演算ユニット振り分けるのに内部命令表現が必要なことくらい、わかるだろうに。

内部命令(マイクロコード)がALUの選択及びALUのコンフィギュレーションのためのビット集合をコード体系化したものってのは正解

というか、ディジタル回路1年生の奴でも判る
そんな当たり前のレベルの議論せんでも…

NVIDIAのChief ScientistがLarrabeeを批判
http://www.xbitlabs.com/news/video/display/20090413143345_Intel_Larrabee_s_x86_Compatibility_Is_Drawback__Chief_Scientist_of_Nvidia.html

nVidiaを批判したいくらい

nVidiaが酷評する ＝　とても良い物

x86のGPU統合化の流れが気に入らないだけだろ

AMDも同じ考えだよ

45nmプロセスが立ち上がったの2007年
IntelにとってはLarrabeeの量産を開始する今年後半?には
45nmプロセスはもう既に先端プロセスじゃないんだよな

http://blog.livedoor.jp/amd646464/archives/51339541.html#comments
17億って・・

＞もし4GHzのGDDR5を搭載すればメモリ帯域は256GB/sとなりかなり広いですが、
＞512bitとなると基板が複雑となるためよりコストがかかります

あのダイのでかさからメモリバス512bitだろ

ごめん20億らしいや

Tukwila並のトランジスタ数！？

>>376
賞賛するわけないだろ。そんなことしたらお終いだろ。

来年の登場であることを考えると少ないくらいだな
やっぱ旧世代プロセスの穴埋めに使う路線だと期待できない。
IntelCPUもプロセス先行が強さの理由の大半な訳だし旧世代じゃ話にならん。

プロセスで先行しているからあのダイサイズで45nmなのだが。
6月テープアウトと言われるGT300のダイサイズがLarrabee並なら55nmだろう。

？

Graphic Processable General Purpose Unit

同一設計のプロセッサなら消費電力はクロックの３乗に比例するという法則を逆手にとって
クロックを7割に抑えてコア数を3倍にすれば消費電力据え置きでスループットは約2倍

理屈はそうだけどな。

1.7GHz〜2.5GHzってずいぶん幅が有るなと思ったんだよね
んで、16コアの2.5GHzと48コアの1.7GHzが大体同じくらいの消費電力ってことになるのかな？
と思ったり。

あと、コア数が増えると1コアあたりのタイルのスワップの頻度も減るから
高解像度での電力効率は更に上昇する・・・かもしれない。

Tera*3は2006年だから45nmプロセスでも正確な予測は難しかったのだろう。
そもそもTera*3でのコア数は16〜24だしそこまでの含意はないと思われ。

汎用回路の電力効率は専用回路の1/500〜1/2000にしかならんよ

専用回路を使わず汎用回路で代替すれば、その分汎用ユニットを多く積めるから技術演算では良いね
GPUのような決まった過程の多いもので使うには電力効率が落ちるけどね

>>395
受け売りわろすｗ

受け売りつーか、どっか別なスレでこの文見た覚えがあるんだが｡

いまどきのGPUに専用回路なんて半分もない。中途半端に汎用なプログラマブルシェーダが大部分を占める。

とりあえず消費電力がクロックの三乗に比例するなんてのは
単純化しすぎた例だからそれで実物を想定するのはやめれ

　　|　｡ 　 ｡
　　|ノ＿ノ　　　
　　|ﾟ Дﾟ)　＜　400
　　|　 /　　　　
　　| /

多倍長整数扱う命令とかすげー豪華だな。

ソフトウェアで柔軟にレンダできるんなら、「A-Buffer」採用できないのかな
タイルレンダとも相性が良いと思うのだけど

ヒント 256KBのL2

>>403
？ VRAMに外出しすりゃ良いじゃん、VRAM足りなくなったらメインメモリに出せば良い
それに可変長だけど、処理順序工夫すれば1タイル分の半透明ピクセルバッファでいけると思うし

それでも、必要なピクセルを含むキャッシュライン分だけフェッチすればいいんで
メモリ帯域あたりの性能ではかなり優位だと思われ

初代は実装するメモリ帯域よりリングバスの方でネックになるのでそれすら微妙。

ソースは善司の妄想ブログ

定量的議論の出来ない奴の意見は
文学部の学生が書く科学評論のようなもの。

Chromeが優れた電力効率を実現してる理由を説明するだけで
ｾﾞﾝｼﾞｰの妄想は否定できる

高性能を目指せば電力効率が落ちるのは仕方ない

ララビは誰でもブラッシュアップされた2世代目からが本番と思ってるだろ
本腰いれてじっくりやればいい
放っておいてもディスクリートのGPUは滅ぶんだし

それ、単にダイを大きく出来ないだけじゃないのか？
キャッシュを抱えずにメモリコントローラにガンガン負荷かける設計にしておけば、電力効率は悪くなるが
SRAMにトランジスタ食われずに済むからな。
面積あたりの性能か、電力効率かのトレードオフなんだろ。

逆に言うと、600mm²を超える巨大ダイを低コストで作れるIntelからすれば電力効率に振ることが出来る。
各コア256KBのL2キャッシュが割り当てられてるLarrabeeには、メモコンにガンガン負荷かける必要がないわけだ。

Chromeって、S3のChrome？
まさか、団子氏から好評価の言葉が出るとは思わなかった。

実際、メディアが突っ込んだアーキテクチャについて取材した記事もないし
S3自体も詳しい資料を出していないんで、構造についてはまったくの謎。
中国語サイトに乗った、このブロック図で色々妄想するしかないんだけど

ttp://img144.imageshack.us/img144/3791/0005929201aeb476buz6.jpg

DXSDKのサンプルとか試してみたやつだと、GSが絡んだやつとか
GPUで繰り返し演算するようなやつは、何か得意みたい。

ttp://www.youtube.com/watch?v=pGnrBu3N2QE

他のスレに張ったGPUBenchの結果はバグっぽい気が大いにするが
仮に信じてみるとATI,nVIDIAとは違うな、という気はするね。

Cache Hit Fetch Cost
540GTX
ttp://xs538.xs.to/xs538/09165/fetchcost_single743.png
8800
ttp://graphics.stanford.edu/projects/gpubench/results/8800GTX-0003/fetchcost_single.png

Streaming Access Fetch Cost
540GTX
ttp://xs138.xs.to/xs138/09165/fetchcost_seq387.png
8800
ttp://graphics.stanford.edu/projects/gpubench/results/8800GTX-0003/fetchcost_seq.png
はじめの0-30 instあたりの傾向が違う
ただ、readback,downloadは激おそ（CPUがnanoだから？）

intel,ATI,nVIDIAに注目が集まる中、誰からも注目されないところで
なんかゴニョゴニョやってるS3
不気味なダークホース・・

「LarrabeeはChromeに似てる」という意見はリアルでもよく聞いた。

っていうか、GDDR5の4GHzとか消費電力がﾊﾟﾈｪ
馬力は有るに越したことはないけど、キャッシュに収まるような演算に対してまで
負荷かける設計にするべきじゃないね。

双方、CPU屋さんがついてるんで
なにかしら似た思想があるのかもしれませんね。

Intelでも600mm²のダイは低コストじゃ作れんだろ
HKMGはAMDのCPUのSOIよりはコストパフォーマンスが良いが、かといってGPUのバルクよりは高い

ただし、巨大チップでも大量のコアで構成される形なら、何個か死んだ物でも製品として使えるから
まったく使い物にならないチップは少なくなるから、コストパフォーマンスは上げられる

要するに“Intelなら”じゃなくて“Larrabeeなら”、比較的低コストで作れる可能性がある

nvidiaもgt200でレジスタ増やしたってことだったが
実はS3もChrome400/500ではレジスタ増やしてるらしい

たぶん世界で一番的確に400/500について把握してるサイト
ttp://translate.google.co.jp/translate?u=http://it-daily.ru/AlgoNetGetNews.action.php%3FID%3D9645&hl=ja&ie=UTF-8&sl=ru&tl=en

>Growth in productivity, however, say in the S3, is achieved mainly by a quantitative increase in the registers.
（あとexcalibur E1が128bit,E2が256bitとかの情報が・・）
で、その効果
ttp://www.youtube.com/watch?v=b32iKtPF15Q
まぁ、クロックもあがってるんだけど、spで1100MHzから1025MHzで75MHzほど
花火はCPUがあれなんで、あれだけど・・

下手に演算ユニット増やすより、レジスタやキャッシュ増やした方が効果的なのかもね。

>実はS3もChrome400/500ではレジスタ増やしてるらしい

書き方がなんか違うな
400から500ではレジスタが増量されてるってことね

GPUはx86みたいに互換性に縛られていないから
記憶領域の階層化を比較的自由にデザインできるしな

階層化　→　階層構造

>>419
x86が互換性に縛られて記憶領域を自由にできなかった例ってあったか？
Pentium 4では8本の論理レジスタを仮想化し、128本からなるレジスタファイルを動的に割り当てていたが。

Larrabeeが出た後も、そういった「ハード屋のエゴ」で
ハードウェアの仕様を隠し続けるなら
いい加減見捨てられるシナリオもあり得ると思う

NVIDIAのことですね。わかります。

600mm²って言っても2世代微細化すれば150mm²だからな。
順調に行けば、2011年末に出せる。
PS4には十分間に合うっしょ。

Intelってそんなに辛抱強かったっけ?

IntelとしてはPS4に使ってもらいたくないでしょ。
また、悪いイメージがつきかねないから。

G80だとSP毎8KB(32/8*2048)でGT200で倍増して16KBか？

今のところLarrabeeは高性能路線の家庭用ゲームのGPUとしては期待薄。

やっぱり少々GPUパフォーマンス無くてもいいチップセット内臓orCPU内臓で普及させて
コード蓄積してHPC狙うというのがメインシナリオだと思う。

ゲームで高性能路線そのものが期待薄なんですけどね。
携帯電話やDSばっかし儲かってるやないですか。

それはそうなんだけどPS系ってウリがハイスペ路線だから曲げられないだろうなとw

そこは高速エンコでハイスペアピールとか？
画質を落とさず1枚のBDにxx時間も録画できる！みたいな

PCゲームって凄い勢いで縮小してるって話じゃん。
ソフトも今や家庭用ゲーム機とのマルチ前提での開発でしょ。
DX11が登場してもほとんど採用するゲームが無いなんて事もありえるしね。
いっそXBOX720とかが出るぐらまで先延ばしにした方が無難じゃね？

PCゲーム自体はまだまだパイは大きい。
FF11がいまだに人気なのはブロントさんのおかげなのは確定的に明らか。

っていうか、ハイエンド路線のデベロッパーが軒並み脱落してる。
ポストCrysis級のゲームが未だに出てない。

っていうかさ、高画質厨って声は大きい割に金は落とさないんだよね。
「あれ？携帯ゲームで十分儲かるなら据え置き・PCゲーいらなくね？」←今ここ

Intelとしてはディスクリート【Game Processing Unit】の市場は深入りする気はないってのが本音だと思うよ
ほっといても壊滅する市場だし。
だからこそNVIDIAやATIよりも汎用プロセッサよりに振ってる。

MMORPGがくそ重たくなっていけばok
AIONとかTERAとか

初代doomの頃から米国陸軍と2人3脚で進化してきたFPS
どこへ向かうかは米軍のサジ加減次第

>>433
FF�]�Tは超負け組MMOゲーだぞ？

はいはい韓流ネトゲ最強韓流ネトゲ最強

そもそもネトゲやってる奴自体

>>437
Acitivision Blizzardの起源は韓国！

こうですか、わかりません><；

ごめん、リネやROマンセーな人かと思った

FF11の功罪って国産MMOとして一番成功したゲームであると同時に
後発のゲームの市場まで食ってしまったことにあると思ってるが。

つーか、基本無料（アイテム課金）って苦肉の策だと思うけどな。
FF11の後釜の確立はスクエニ自身が失敗してる

インテルは今までゲーム機市場に食い込んでなかったから、
利益がほとんど出なくても、使って欲しいはず。
ライバル（IBM、AMD、nVIDIA）を苦しめられるだけでもメリットがある。

なにその荒らし屋

>>441
一応、議論には正しい事実認識が必要ですので…
　　---------------
　　インテルは今までゲーム機市場に食い込んでなかったから、
　　---------------
http://jibun.atmarkit.co.jp/ljibun01/rensai/gyoukai/015/01.html
　　===============
　　Xboxはペンティアム III 733MHzに加えて、マイクロソフトとNVIDIAの両社が共同設計した
　　カスタムチップを搭載している。
　　===============

そういえばXboxはCeleronだったね。

ハイグラ需要なくなるとしたら、
高性能プロセッサ需要も激減しね？
アキバとか半壊しそう

ハイグラゲームってモノがどのくらい人抱えてるかしらないけど、
それ諦めるとデザイナー、エンジニア、総リストラ時代迎える。

ハイグラの「傾向」が変わる、という事ではないかね
勿論そっちに需要があれば、だがIntelだし主導してんの

PCだってWindows7失敗確実だろうし、
もうサイズも何もかも縮小していくのかねえ？

XPの右上にアナログって表示すればいいのか

サポート打ち切りでかけるプレッシャーが
テロップでかけるプレッシャーみたいなものだろう

3Dゲームなんてみんなほとんどやってなかったでしょ。
それでもなんでハイエンドのビデオカードが売れてたかって言うと
3DMARKというキラーアプリがあったからさ。

3DMarkがキラーアプリとかｗ

…結構正しいかも

最適化したはずのvantageがああいう残念なものに終わったんで
nvidiaはグダグダなんですね
わかります

PCゲームが縮小してるのは日本固有の話だな

据置き型ゲーム機の市場も国内は縮小している。

>>454
海の向こうではリアルで大手デベロッパーが統廃合の嵐ですが
ライトなオンゲが流行ってるのって日本だけの話じゃありませんぜ

PCゲームは海賊版のせいで需要が売上に反映されにくい

DOOM以降ちょっと極端なくらいFPSに特化しすぎてしまったからだろうな。
そら飽きられるは。

日本のマスコミは屋内系趣味全般に対してマイナスイメージばっかり流す

マイナスイメージも含めて宣伝になってるという罠。
2chのネオ麦と同様にね



ところで俺のID微妙にIntel入ってね？

優男が大剣振り回して自分の存在に悩みながら世界を救うゲームが売れるのが日本のコアゲーム市場ｗ
ムサいマッチョのオッサンは好まれない

海外PCゲーは、MMOなら1000万オーバーのWoWの一人勝ち(他にも100万人規模のやつがいくつか出てきてるけど)
ゲーム配信プラットフォームなら、Steamが2000万オーバーで、
Counter-Strike各種の合計のピーク人数は20万程度いるし、他のマルチプレイゲーも数万規模。自社販売ツールがあるはずの
EAですら参入。他にも、Facebookでのゲーム配信や、無数のカジュアルゲー配信、販売サイトなんかがあるから、実は競争が激しく、
家ゲーと全く違う方向に行ってるのがよくわかる。

Crysisみたいな技術博覧会的ソフトは、もうお呼びじゃないのかね？
あそこPC向けだけは、もう作らないとか言ってなかったっけ？

Crysisは幾らtexture貼り付けられるかって・・

日本がPC-88時代に経験したことがAT互換機にも起きてるだけ。
まあベンチマークソフトがある限りビデオカードは売れるでしょ。

>>462
その半分以上が業者と架空アカウントだろ

WoWは2000万超えてる
ROあたりでも800万
ちなみに欧米のMMOは月額課金が中心で基本料無料アイテム課金は少ない
業者や架空アカウントはアジアが中心だろ

でもって、これらのMMO系は確かに負荷は軽いが
だからといってこれらのプレイヤーがオンボや安い単体カードで済ませる訳じゃない
世界でも、MMOの運営に性能不足に起因する問い合わせが来るのは日本のみ
海外ではPCの準備から含めて楽しむもの

あと、あっちのPCゲームのベースはテーブルトークだから、
テーブルトーク世代のおじいちゃんおばあちゃんゲーマーも普通に居るｗ

ツッコミ入れたいけどLarrabeeのスレだから入れない

話題をLarrabeeに戻すとしたら
Larrabeeのヒットに結びつくようなPCゲームは出そう　とかか？

OFFSETエンジン？だったかの開発会社買収してなかったっけ？
そこが技術デモもかねたゲーム出すんじゃない？

個人的には映画トイ・ストーリーがそのままのクオリティで動きます。
くらいのインパクトが欲しいね。

クオリティー面で、同じ時期に出るGPUに明確なアドバンテージを持てる程の演算能力の差は無いでしょ
それよりもPhysXのような追加効果や、大量の群集を個別に動かすような処理の要るゲームが合うんじゃないか

その方向なら最悪、GPUとしては売れなくても、CPUに代わってゲームにリッチな効果を付与する為のカードとして売れるかも
PhysXと違ってCPUのコプロとして動かせるなら対応ゲームも増えそうだし

>>471
物理演算専用カードとか売れるわけないから。

GPUとして成功するかは、AMDとNVIDIAがLarrabee対抗としてどんな製品を出すかによるね。
もし同じような製品しか出してこなかったら、製造プロセスが進んでる分、インテルが有利だと思うけど。
でも最終的にはヘトロジニアスCPUに統合されるから、競合製品がどうとか関係なくなると思うよ。

NVIDIAとATIが40nmを出した後に
45nmで出してくるIntelが有利とな？？

誰も45nmのLarrabeeのこととは言っていない。
600mm2のチップじゃどうしようもないだろう。

>>472
専用カードにする必要はない
GPUとして買われ、そして時間が経って第一線を退いた後でも、ゲームの物理演算やエンコ、あるいはCPUの
アクセラレーターとして使えるなら、捨てられずに、新しく乗せられるGPUの下のスロットで第二の人生を送れる

搭載率さえ上がれば物理演算のオプションを乗せるゲームも増えるし、
また物理演算のオプションを乗せたゲームが増えれば、一枚でGPUと物理演算をこなるLarrabeeも売れるようになる

PhysXと似たような物だが、あちらよりは汎用性が高いだろうからやり易くは有るだろう

いよいよ来週登場だぞ！価格は$99！！
http://northwood.blog60.fc2.com/blog-entry-2777.html
http://northwood.blog60.fc2.com/blog-entry-2783.html

Larrabeeがとうとう出たのかと思ったじゃないかw

>>476
とうとう99ドルで1TFLOPSもの演算力があるチップが手に入るようになったか
感慨深い

>>475
＞GPUとして買われ、そして時間が経って第一線を退いた後でも
その頃にはもっと電力パフォーマンスのいい製品が出ててさっさと引退だろ

とりあえず物が出て、リングバスがどれくらいボトルネックになるのか知りたいな。

とてもじゃないがランダムアクセスに耐えられない

ただ、噂されてるGT300はなにやら新アーキのようだ
nVidia's GT300 specifications revealed - it's a cGPU!
ttp://www.brightsideofnews.com/news/2009/4/22/nvidias-gt300-specifications-revealed---its-a-cgpu!.aspx

これに対しATIはどうすんのかね

ATIはGPGPUじゃなくてAMDとしてSocketF用にHT3.0で繋いだStreamProcessor出してほしいなぁ。
LarrabeeもGPUとしてじゃなくてQPIでつないでLGA1366に載せちまえばいいのに。

ソケットに差すとメモリ帯域が半分以下になるから、性能下がっちゃうんじゃないの？
SocketG34だと4chだから256bitで同じになるけど、クロックはGDDR系と比べるとずっと低いし。

ATIは外部SSEユニットになるんじゃないか
例の統合CPUはPCI-eも含むらしいし

SocketFでもLGA1366でも、ローカルに自前のメモリが繋がるし
QPI/HT経由で別プロセッサのメモリが別帯域でアクセスできるから帯域が狭いという程じゃないよね。

DDR3-1600つかったPC3-12800なら帯域は12.8GB/s、LGA1366ならそれが3本で38.4GB/sec.
QPI一本で25.6GB/sec.で2本をプロセッサ間接続に使えば 51.2GB/sec.合計89.6GB/sec.のメモリ帯域がある。
4プロセッサ構成で3本使ったら 76.8GB/sec. + 38.4GB/sec.で 115.2GB/sec.。

対して2GHzのデータレートを持つGDDR3を256bitで接続したHD4850のメモリ帯域は64GB/sec、
データレート3.6GHzのGDDR5を繋ぐHD4870でようやく115.2GB/sec.、
2.2GHzのGDDR3を512bitで繋ぐ GTX280が140GB/sec.。

でも演算ソースと結果はメインメモリからやり取りしなくてはいけなくて、
そこはPCI-Express2.0 16レーンで 16GB/sec.。

メモリ帯域が致命的になるほど大規模な演算になればなるほどソケットタイプのほうが有利じゃね？

>483-484
メモリチップも載せたユニットをソケットに。
しかしこれだと容量が足りないだろうな。

>>486
それはソケット1のみがメモリアクセスの必要な処理を行い
ソケット2〜3はメモリアクセスの必要な処理を行っていない場合にのみ出る数値だろ

現実にはローカルに繋がるメモリですら、他のCPUからの呼び出し要求が割り込んで
帯域が削られるな

4ソケットとか、そこまでコストかけて115.2GB/secとか微妙な帯域出してもしょうがないでしょ。
普通に256bitでGDDR5繋げれば、同じ帯域が得られるのに・・・。

>>473
TSMCの40nm（リーク電流だだ漏れ）とIntelの45nm(HKMG)じゃ電力効率では後者有利だろｊｋ

あとは、ダイサイズあたりの単価くらい？
Intelにとっては減価償却の終わったプロセスであるというコスト面での優位性がある。

トランジスタ単体の性能、ましてや改善されたかもしれない噂を元に、
製品の電力効率を語っても無意味だろｊｋ

しかも噂の出所は団子の大好きなDemakasejanなんだしｗ
http://www.theinquirer.net/inquirer/news/878/1050878/tsmc-40nm-revealed

バルクでHKMGを導入しないでリーク電流を抑える魔法があるの？

魔法なんて必要ない
全てはバランスの取り方で決まる

しょせん480gflopsや312flopsを謳おうと、35.2gflopsに劣る場面が多々あるA社n社には期待できない

HKMG導入は32nmからだし、材料も変えてないのに改善されるわけがないです。
いや、TSMCの40nmが主張する優位性はあくまで同社の55nm、45nmに対するもの
ってことを考えないといけません

http://pc.watch.impress.co.jp/docs/2007/1212/iedm03.htm
> High-k/Metal gateで製造した45nmトランジスタのゲートリークは、65nm世代に
> 比べると劇的に低下した。nチャンネルFETのゲートリークは25分の1以下に、
> pチャンネルFETのゲートリークは1,000分の1以下になった。トランジスタの
> 駆動電流はnチャンネルFETが65nm世代に比べて12%向上し、pチャンネルFETでは
> 65nm世代に比べて51%も向上した。

トランジスタレベルでの電力効率に関してはバルク・非HKMGに対してかなり貯金がある状態なのでは？


2GHzで動くインオーダのx86コアの消費電力がどんなもんなのかってのは、Atomという先例がありますですね。
あと、キャッシュを活用したほうがVRAMのメモリ帯域（消費電力）をセーブできるのかなと。

>>492
絶縁膜厚くすればいいだろ
性能出ないけど

>>495
HKMGはゲートリークは抑えられても、90nmで大いに問題になった
サブスレッショルドリークは抑えられない
それとそこで出ている駆動電流の向上は歪Siによる成果であって、
HKMGの導入ではゲート容量が増えて性能にはマイナス
さらにチップの性能にはRC遅延なんかも関係してくる

プロセスを評価する場合は全体を見ないと


>>496
まあその通りだね
だからこそ性能を向上させるために各種テクニックが必要になってくるわけで
そうすると今度はコストの問題が出てくるから悩ましいな

Intelの90nmプロセスで問題になったのはゲートリークだったと思うが・・・
既にIntelは量産プロセスに適用可能なトライゲートトランジスタの開発を完了しているが
それを45nmプロセスでも32nmプロセスでも採用しなかったことから
(Intelにとっては)それほどクリティカルな問題じゃなかった ということだと判断している

>>オフリーク

>>485
本気で言ってる？

現状、RadeonではネイティブVLIWの動的コンパイルだけでもCPUでソフトウェア処理してるんだけど
現行のSSEにはVLIWのコンパイルより長い時間かかるような命令なんてまずない
一番時間のかかる除算ですら数十サイクル
命令レベルで投げようとしてるのなら本末転倒


もしハッタリではなく実用になるレベルで演算を分担やるとすれば命令(SSE)単位じゃなくて
プロシージャ・スレッド単位で丸投げするモデルだな。

すなわちマのスキルや労力はCell(笑)と同じかそれより更に上が要求される


その意味でCPUとの命令セットの違いを意識しなくて良いLarrabeeが一番マシな選択になる

AMDはUMCの40nmを使っていけばいいよ

だからGPUにCPUと同じSSE5を載せるんじゃないのか

SSE5はそういうものじゃないって

　# この話題何回目だ?

どういうもの？

AMDは将来世代のCPUでアクセラレーターを搭載するとしている

これで最初に思いつくのは・・・
今のCPUはスカラユニット＋ベクタユニットの1対で構成される汎用コアを複数搭載しているわけだが
これを複数の汎用コア＋独立したベクタユニット群に整理し直すん感じかな
例えば、汎用コア×4＋ベクタユニット群×1とかって構成になるんじゃないか？

AMDのロードマップに、SMTやコア内のSIMDユニットの拡張の予定が無いのはそういう事かも

なんか2,3年前の話題を繰り返してるような…


>>498
サブスレッショルドリークで合ってる

トライゲートトランジスタを使わないのはコストとリスクが大きいからでしょ
既存の技術の改良で済むならそれが一番

サブスレッショルドリークはシミュレーションとかが比較的早期に確立してたからな〜事前予測30%のリーク電流が60%まで増えたことの説明としては説得力が足りない気がする

>>501
おいおい
SSE5で提供される命令は、FP積和で1命令あたり最大8オペレーション
GPUは数百オペレーション単位での並列実行しかできないので、全然別物

CPUとGPUのベクトル演算単位のギャップを埋めるには
CPU側には512ビットとかそれ以上のベクトル長の新たなSIMD命令が必要だし
GPU側もVLIWを辞めて命令あたりの並列度を下げないといけない。

必然的に行き着くのはLarrabeeという解だ。
君が思ってる意味でCPUの肩代わりができるGPUはLarrabeeが唯一だ。

つか、SSE5をGPUうんぬん言ってた本人はAMDから追放されて、Fusionの構想自体、大きく後退してますし。

GPUとして考えるからおかしい
CPUのSSE5ユニットがGPUにのると考える

GT200とかってD3Dを動かしているだけだと全然使われない
回路が結構有るんじゃないの？

逆にGPUのVLIWをSSE5に合わせて128bitにあわせたら、GPUとしての性能下がらない？
少なくとも、今のRadeonとはかなり違う構成に変更する必要があると思うけど…。
SSE5のユニットをGPUに単に増設するだけなら、CPUのSSEユニットを強化すればいいだけだし。

VLIWから離れてみようか
ちなみに現在でもshader 1個に発行されるのは最大32bit 5要素+分岐分

>>509
使われない回路はないけど、稼働率の低い回路はあると思う。
というか、D3Dとして使うと、シェーダーユニットの稼働率は半分以下だよ。
ここでもメモリ帯域がネックになってる。

というか、メモリ帯域が伸び悩んでるから、汎用処理に舵を切ってる。

ラデはシェーダコア1基に対しデコーダフロントエンド1基ならともかく、
数十基のシェーダに1基のデコーダで同じ命令をブロードキャストする
超並列SIMD構造だから厄介なんだよ。

当のAMDはNVIDIAのようなビッグチップ路線は終わりだとすら言ってる。

FusionのSSE5はどっちかというとDX11の論理パイプラインの前半部分でCPUをGPUの補助的に使うための技術じゃないかね。

余剰CPUコアをシェーダライクに活用するための。

>>513
NVIDIAのビッグチップ路線も限界だけど。
（どちらのとは言わないが）マルチチップ路線もあまりうまくいかなかったよ。

GPUの処理は超並列処理だけど、出力先のフレームバッファは1つしかないのが問題。
最近のCF･SLIはフレーム単位で並列処理をしてるけど、
今度はフレーム単位で遅延が発生するから、ゲーム用途にはデメリットが大きい。

マルチチップといっても今のは
メモリの共有も無い、単にCF,SLIだし

>>515
GPUのメモリ帯域でメモリ共有は無理なのでは。
というかそんなことしたらマルチチップにする意味がなくなってしまう。

でもその準備はRV770で行われてるよ

関係ないど、今思うとlarrabeeっぽいなこれ
ttp://www.yusuke-ohara.com/weblog2/archive/2008/01/r700.html

CellがまだGPUの補助ではあるが、ぼちぼち結果だしてるけど、
このままランダムアクセスを垂れ流さないコア向けの手法が確立されていくと
余分な回路が乗ってて積めるコアも一回り少なくなってしまって、
しかもクロックも伸びないとなるとLarrabee出る幕なくなるよ。
Intelはハードにこれ以上投資するんじゃなくて、全部ソフトにまわすべきだと思う。
こっちの方が底抜けに大変でしょう。MSに頭下げて莫大な金払うくらいでないと。
一番いいのはMSにLarrabeeを丸ごと売り払ってしまうこと。
規模的に開発できそうなのはMSくらいしかない。

どこを縦読み？

Larrabeeのコアでかいよ？
x86コアだからなんとかなるとか夢見すぎ。

でかくてもいい、逞しく育ってほしい

＞CellがまだGPUの補助ではあるが、ぼちぼち結果だしてるけど、

プレ捨て３ローカルの話なんてどうでもいいです。ビジネスになってないんだから。

＞このままランダムアクセスを垂れ流さないコア向けの手法が確立されていくと

DirectX 11(SM5.0)世代ではランダムアクセス機能は仕様です。残念でしたね。
見た目が騙せるとかのレベルじゃないんです。
それともWiiと同じ枯れた技術路線の話ですか？それこそ任天堂に勝てっこないじゃん。
どのみちVAIOにすら使ってもらえないCellに使い道はないでしょ。
128ビットSIMD専用なんて、来たる2010年代には既に化石ですよ。

＞MSに頭下げて莫大な金払うくらいでないと。

利益にならないことをやる必要がどこにあるんでしょうか？
莫大な赤字出してまでゲーム事業続けてるソニーはぶっちゃけ異常だし、
それと同じ感覚でものを語られても困りますぜ。Intelは無駄金払うのは嫌いな会社ですよ。
Itaniumはかろうじて黒字出せてるからやってるけど、年々厳しくなってるから
開発予算はどんどん削られてるようだしね。



さんざんがいしゅつだけど、Intelはゲーマーのためにプロセッサ作ってるんじゃないんですよ。
自動車メーカーがF1のために自動車作ってるんじゃないのと同じこと。
Larrabeeはx86の命令セットベースの科学技術計算用アクセラレータで、なおかつそれ自体が
汎用メニーコアプロセッサとしても使えるものですぜ。WebサーバやRDBを動かしたりもできる。

更にCPUとLarrrabee（に限らずメニーコアCPU）とを橋渡しするフレームワークとしてTBBやCtを用意してる。
Intelはハードを売るためのソフトの開発には莫大な時間・費用をかけている。
あくまでCPUの延長線上にLarrabeeがある。
GPU機能なんてSIMD特化するついでに付けたようなもんだし、素性が汎用プロセッサだから
DirectXやOpenGLを経由せずに柔軟にミドルウェアを起こすことができる。

GPUの「汎用」がグラフィック用途のついでに過ぎないのとまったく逆の立場だな。
GPU市場において、Larrabeeが汎用的過ぎて、グラフィックに特化されたGPUとは戦えないっていうのなら
汎用とグラフィック専用は相容れないものってことになるわけで、まったく同じ理由でGPGPUは
真の意味で汎用化できない。

GeforceはSP数がRadeonより少ないからうんぬんかんぬん
って言ってた人を思い出したｗ

Atom程度の性能のx86が16コアあって更にSIMDを強化したら何が出来るか
考えられる人には最高のデバイスになりそうだけどね

※Atom程度、って言ってもCell（笑）なんかのスカラ演算性能はそのレベルにすら達してない

コアが増えるほどプログラミングが難しくなるって言うけど、
コアが１００万個くらいあったら逆に簡単になりそうな気がしないでもない。

AMDの6コアCPUの写真が出たけど、配線が占める面積がかなりあるね

>>525
ちょっと条件が足りないんじゃないか。結ぶ太さが大幅に違えば
同じ100万個でも全然話が違ってくるのでは

>>522
ゲーム機の話はともかく
＞科学技術計算用アクセラレータ
こっちで倍精度版のCellを無視するのはどうして？ビジネスになってるよ

ろーどらんなー（笑）

>>522
> ＞このままランダムアクセスを垂れ流さないコア向けの手法が確立されていくと
>
> DirectX 11(SM5.0)世代ではランダムアクセス機能は仕様です。残念でしたね。
> 見た目が騙せるとかのレベルじゃないんです。

DX11のランダムアクセス機能が仕様ってw
二重に勘違いしてるぞ。
それはおいておいてタイルレンダリングを採用したLRBがまさに
「ランダムアクセスを垂れ流さないコア向けの手法」じゃん。

> 128ビットSIMD専用なんて、来たる2010年代には既に化石ですよ。

化石とかじゃなくてさ。
DLPに振るかTLPに振るかってことじゃん。
おれには512bitSIMDはコア数を上げられないLRBの苦肉の策にしかみえないな。

糞遅い共有メモリ
非公開のアセンブリ言語
全く足りないキャッシュ
でも何でもいいからとにかく沢山スレッド走らせたいんですね。わかります。

いや、DX11世代からはランダムアクセスが欲しくなるのよ

ttp://game.watch.impress.co.jp/docs/series/3dcg/20090325_79920.html
ttp://game.watch.impress.co.jp/img/gmw/docs/079/920/3dd1110.jpg

>DirectX 11は、後述するDirectX演算シェーダーへの対応にシンクロする形で、GPGPU的なポテンシャルがピクセルシェーダーにも与えられる。
>これがDirectX 11のピクセルシェーダーに新機能として与えられる「Unordered Access View」（UAV）という新概念だ。
>
>Unordered Accessとは、つまりはランダムアクセスのこと。
>
>なんと、ピクセルシェーダーからビデオメモリへのランダムアクセスが可能となるのだ。
>これまでピクセルシェーダーは、あらかじめそのピクセル座標に対応して
>ビデオメモリに書き込み（出力）しかできなかったが、この制約が取り払われるのだ。

>ピクセルシェーダーとDirectX演算シェーダーで、ランダムメモリアクセスができるようになってしまった関係で
>面倒になるのが、複数スレッドからの同一メモリアドレスアクセスの管理だ。
>実行タイミングによってメモリの内容が変わってきてしまう可能性もでてくるわけで、
>これはマルチスレッドプログラムで起こりうるデバック困難な現象を生みかねない。
>そこでDirectX 11におけるピクセルシェーダーとDirectX演算シェーダーでは
>Atomic Operation（不可分操作）に対応した命令がサポートされている。

nvidia,s3,intelはしっかりやってきそうだが
atiはどうかな・・

DX11はAMDべったりじゃなかった？

基本的にDXの規格はMSとGPU各社の協議で決まるはず
ATIべったりと思われている一因は、テッセレータの仕様がXBOX360のものに近いこと
それと、fetch4が標準サポートになったことぐらいで
そのほかに関しては、どこよりという判断はできない

昔の記事を物色していたら気になるものが

ttp://game.watch.impress.co.jp/docs/20060514/ageia.htm
>また、浮動小数点演算性能は58GFLOPSだそうで、また命令実行レートは毎秒220億個の実行が可能と言うことになっている。

ttp://pc.watch.impress.co.jp/docs/2006/0412/kaigai260.htm

>「我々のプロセッサは(GPUのような)ストリーミングプロセッサではない。
>フィジックスではストリーミング型のデータ構造ではないからだ。
>例えば、オンチップのメモリ帯域が重要となる。
>
>演算で使うデータはオンチップに載せる(ことで高速化を図っている)からで、
>PPUでは2Tbit/secの内部メモリ帯域を持つ」
>
>とAGEIAのManju Hegde氏(Co-Founder, Chairman and CEO)は語る。

>GPUのProgrammable Shaderの演算コア自体の物理的な実装も、
>現状ではフィジックスシミュレーションのようなGPGPUに向いていないとHegde氏は指摘する。
>「GPUでは(Programmable Shaderの)汎用レジスタの数が極めて少ない。
>これは、フィジックスのように、複雑なデータ構造に対して、異なる複数のアルゴリズムで処理を行なう場合には、特に問題となる。
>PPUでは、そのために多く(のレジスタ)を備えている」とHegde氏は指摘する。

案外540GTXのこの値は単にスカウターの故障（ベンチのエラー）とは言えないのかもしれないね・・
いや、知らんけど

Stanford GPUBench
Streaming: Basic Throughput
8800
ttp://graphics.stanford.edu/projects/gpubench/results/8800GTX-0003/streamthroughput.png
ttp://graphics.stanford.edu/projects/gpubench/results/8800GTX-0003/streamthroughputbytes.png
4870
ttp://xs138.xs.to/xs138/09161/streamthroughput332.png
ttp://xs138.xs.to/xs138/09161/streamthroughputbytes603.png
540GTX
ttp://xs538.xs.to/xs538/09161/streamthroughput357.png
ttp://xs138.xs.to/xs138/09161/streamthroughputbytes432.png

>>530
は？苦肉か？
GeForceは32並列のSIMD（自称SIMT）、RadeonはRV700系は5(+1)並列のVLIWの更に40並列のSIMDだけど？
Cellは命令間のレイテンシが大きすぎて、命令レベル並列化ができない処理をやらせるとクロック相応の仕事すらできないし
それとは別の理由で分岐が大の苦手（笑）

なんなら、Atom 1.6GHz＞＞Cell SPE 3.2GHzという悲惨なベンチ結果いくつか出そうか？ｗ

Cellのパフォーマンスは128ビットSIMDの3.2GHzではなく、1024ビットSIMDの400MHz程度だと思ってください。
DMAが1024ビット単位でないと効率的にできないのと、Intelプロセッサと比べても
各命令間のレイテンシが異常に大きいこと、これに尽きますな。

未だにCellCell言う人が後を絶たないな
あんな失敗作と比べられてintelも悲しいだろう

>>528
ちなみにそっち方面はIBM自身が見捨てると見てる

特化型じゃないIntelプロセッサでもAVXの採用で浮動小数演算のスループットが更に倍になるので
生半可なアクセラレータでは太刀打ちできなくなる。

そもそもトップ500に入るスパコンにIntelプロセッサが大量にされてること自体、浮動小数演算のスループットだけが
求められてるわけじゃないことの証左ですしおすし

あれ、デジャブ

>>539
x86プロセッサがtop500で高シェアな理由は単純に
倍精度基準の$/LinpackFlopsが安いから、で説明できてしまう

もちろんLINPACKだけで計れない性能があるのは確かだよ
浮動小数以外の性能だとますますx86の性能が圧倒してしまうってのが正直なところなんだが。

http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=2615776


つか、コストって一番重要だろ
スパコンの場合は、導入コストよりも消費電力も含めたラニングコストが重視されるわけだが。

あと、プログラム組みにくくて性能が出せない状態ってのも稼働時のコストパフォーマンスを
悪くする要因になるから、使えるソフト資産があるってのも大事なんだぜ。

Linpack以外≠浮動小数点以外

現在のtop500でW/flopsが少ない上位はx86系ではなくPower系

単に”資産”と言ったら未来のものは含まない。
スパコンの利用は30年以上
　top500の半数以上がNプロセッサ以下
　93　98　003　2008　年
　08　64　256　4096　N
x86も疎結合マシンもスパコンユーザーにとっては新参
どうみても現段階のスパコン向け資産で疎結合x86に明確な優位はない。

PowerPC系のことはPower系とは言わないかな

そのNが急速に伸びてるのが象徴的だね。
2008年にはIntelだけで75％、AMDも含めれば実に90％近くでx86が採用されてる。

結局のところ「スパコンならではの資産」など大したウェイトは占めてなくて
コンパイラやライブラリ次第ってことだ。

＞現在のtop500でW/flopsが少ない上位はx86系ではなくPower系

ま、整数性能やアウトオブオーダなんてW/flopsに寄与しないからな。

「単精度なら勝つる！」って息を荒げる人もいるだろうけど、
x86の強みはむしろ整数演算性能にある。
>>542で例示した遺伝子解析問題なんかが好例。
ソースコード見れば解るけど実はSIMD整数演算主体。

トップ500のなかでPower/Cellアーキテクチャを納入してる業者ってIBMくらいだし
IBMがガチで"Goodbye PA"すればなけなしのシェアも事実上消滅する。

＞コンパイラやライブラリ次第ってことだ。

自動、半手動ベクトル化よりもMPP並列の方が難しい。後者の方が歴史が浅い。
これもまた現段階でx86疎結合に明確な優位はない。
科学技術計算分野でバイナリ互換に何の優位もない事は言うまでもない。

単精度ならといってるのはGPU大量導入してる人

遺伝子データベースだけ？
その遺伝子データも蛋白構造がわからなきゃ利用に結びつかない。
データベースへの需要に比例して構造のための実数演算需要も生じる

>>545
　　-----------------
　　>>542で例示した遺伝子解析問題なんかが好例。
　　-----------------
それって文字通り汎用SIMD ISAの先駆だったAltivecの得意分野だった訳ですが、
団子さんが主張する程、世間に大きなインパクトを与えたかどうかは…？
http://eshop.macsales.com/images/Items/PowerMacG5_Perf_WP_071503.pdf (p.13-14)

AltiVecなんて全然得意でもなんでもないよ

>>546
＞これもまた現段階でx86疎結合に明確な優位はない。
＞科学技術計算分野でバイナリ互換に何の優位もない事は言うまでもない。

優位がないのに9割近いシェアを得てるんだよね

やっぱり性能じゃないの（笑）

米国の公共事業だからIBMに金が流れやすい？


200 ：名刺は切らしておりまして [] ：2009/03/11(水) 12:54:24 ID:TQXBEJ9B
>>196
＞素朴な疑問なのだが、なぜLINPACKが、HPCの性能を測る標準的なベンチマークになってしまったんだろう。
純粋に政治的な問題です。
LINPACKベンチマーク原理主義とTOP500原理主義はアメリカの国策なわけです。

>>198
＞自分達の都合＞＞＞＞世界の都合
アメリカの国益＞どうでもよい＞世界の太平

208 ：名刺は切らしておりまして [sage] ：2009/03/16(月) 00:21:21 ID:oORgBQwI
>>154
アメリカはITバブル崩壊後の2000年以降バイオテクノロジーに舵をとった
遺伝子や新薬で特許取りまくり他国を出し抜く戦略
そして分子計算はスカラ機にマッチした（加えて核分裂シミュにもマッチ）
当時ダメだと言われ始めたLINPACKベンチマークが生き残ったのは米国の意向だったわけ

そんなわけで米国の団体・機関が主体となって行っている
タンパク質解析プロジェクトの類に自分の計算機資源を使わせるようなことは避けている

219 ：名刺は切らしておりまして [] ：2009/03/22(日) 17:41:51 ID:tnJqbrXC
>>217
アメリカはそれをわかっていて詐欺のLINPACKベンチマーク絨毯爆撃を続けている。

222 ：名刺は切らしておりまして [sage] ：2009/03/22(日) 20:25:12 ID:4urJOpxf
>>48
そういうことは米政府とIBMに言ってやれ。
ロードランナーだっけ。核分裂のシミュレーションとか。
まるっきり全部公金だろ。

http://blog.goo.ne.jp/topography/e/32b297c79eb33bd1d8338e5f9fc0929e

のこの一番下のSmith-Waterman検索結果の根拠とするアプリケーションってさ
誰かさんの大好きなIBMのレポートですよｗ

んでもって比較に使ったアプリケーションはQ6600にPS3が惨敗してるやつ>>542と同一っぽいね。
進化の止まったAltiVecなんて今のx86に及ぶはずもなく
無残にも返り討ちにされてしまいましたね。

>>551
　　----------------
　　進化の止まったAltiVecなんて今のx86に及ぶはずもなく
　　----------------
意図的に誤魔化しているのかどうかは判りませんが、二つ誤解がありますね。
　1. SPE ISAとAltivecは別物
　2. 2000年代前半に最強の遺伝子探索のプラットフォームであったPowerMacがTop500で
　　メジャーになることが無かったのに、何故にx86がTop500で大きなシェアを占める理由が
　　遺伝子探索アプリの性能なのか？

1．SPEのSIMDユニットおよびそのための命令セットがAltiVec（VMX）を元にしているのは明らかでは？
　もちろんswps3はCellのPPEも使ってますぜ

２．IBMがCellの優位性の1例として示したアプリケーションでx86に惨敗してるという事実が重要です
　PPE1機のAltiVecだけでx86-SSE2に勝てると鼻息を荒くしてたのに、どんなザマですか

>>542の報告書ですが、本当に読んでいればCELL/B.E.の性能上の問題として指摘されている点は
『Altivecとの違い』に起因することが判る筈です。この結果をもってAltivecを叩いちゃうのって(笑)
　　------------------
　　On the other hand, the performances of the Cell/BE are limited by its sparse vector
　　instruction set. For instance, the lack of support for 8-bit integer vectors restrains
　　performance on short, unrelated sequences with low scores, which constitute the largest
　　portion of the benchmark dataset.
　　------------------

そもそもCellの性能面の優位性なんてPS3が発売された2006年末時点で既に無かった。

>>553
1.の弁明は恥の上塗りだったようですね。せめて引用対象は中身を読んでからやりましょう(笑)

じゃあswps3をPOWERでビルドして動かしてごらんよｗｗｗ
PPC/AltiVec用で動かすこと出来るだろ。


ま、そもそもPOWER（笑）なんて低性能はお呼びじゃない。
Celeronデュアルコアと争ってなさいってことで。

まとまった暇が有ったら手元のマシンでこのベンチとってみたいんだけど
PPE 3.2GHzとの比較にはAtom 1.6GHzがお似合いかな？

POWER(笑)の相手なんてCore MAには役不足でしょう

>>557
　　----------------
　　じゃあswps3をPOWERでビルドして動かしてごらんよｗｗｗ
　　PPC/AltiVec用で動かすこと出来るだろ。
　　----------------
本当に>>542を読みましたか？プラットフォームごとの最適化について述べられていて、
「ビルドして動かしてごらんよｗｗｗ 」という話では無いのですが？？

http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=2615776
いいから動かせよペニス君


何度も言うけどAltiVecに対するSPEの弱点云々以前の差です
6+1コア駆使して4コアに大差付けられてるんだし
http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=2615776&rendertype=figure&id=F1

おいペニスくん
まさかビルド方法がわからないとか言うなよ？


http://www.inf.ethz.ch/personal/sadam/swps3/
からソースコード落としてきて

make -f Makefile.altivec

だけだぞ？
PPC-Altivec専用でビルドするのにCell全く関係ないぞ。

連投見苦しい

Atom VS Cellとか色々
http://dango.chu.jp/tripper/20090414.html

なんかネタ提供してよ

体験主義の団子さんは、また怒り狂うかもしれませんが…

ハイエンドプロセッサにおける遺伝子探索コードの性能比較ははSPECint2006にHMMerが
含まれていますので、同種のコードの性能評価には使えます。
http://www.spec.org/cpu2006/Docs/456.hmmer.html
　　-----------------
　　Benchmark Description
　　　Profile Hidden Markov Models (profile HMMs) are statistical models of multiple sequence
　　alignments, which are used in computational biology to search for patterns in DNA sequences.
　　　The technique is used to do sensitive database searching, using statistical descriptions
　　of a sequence family's consensus. It is used for protein sequence analysis.
　　-----------------

> Project Leader - Kaivalya M. Dixit (IBM)
> - Alan MacKay (IBM)
（笑）

おもっきしPOWER(笑)の出る幕無いな。

Cellは言わずもがな

http://spec.org/cpu2006/results/res2008q4/

どこにPOWER（笑）なんて登録されてるのよｗｗｗｗ

あったあった

>542
Q6600にPS3より結果の良いベンチが一つあっただけでなぜそんなに喜べるのか？
PS3
　2006Nov システムで　\50k-\6xk
　2007Dec　システムで　\40k-\55k
Q6600
　2007Jan　CPU単体で　\110k
　2007Jul　CPU単体で　\37k

>549
>541

団子さんが自分の世界に入って勝利宣言を始めたようですね(笑)

実際にベンチマーク結果を8コアで比較すると下記の通り。
新しいものほど順調に良くなるという話で、何倍も違うというネタにはならないかと。
■456.hmmerの比較(8-core)
　・Shanghai/2.9GHz: 258(peak)/160(base) [2009Q2, cpu2006-20090330-06865.html]
　・Nehalem/3.2GHz: 245(peak)/191(base) [2009Q2, cpu2006-20090216-06529.html]
　・Core2/3.33GHz: 225(peak)/176(base) [2008Q4, cpu2006-20080915-05367.html]
　・POWER6/4.7GHz: 204(peak)/167(base) [2007Q2, cpu2006-20070518-01103.html]

性能を高クロック＋SMTに振るか、コア数に振るかは方針の違いってことで、
同じ16ソケット同士の比較で文句ないよな？ｗ

http://spec.org/cpu2006/results/res2008q4/cpu2006-20081003-05500.html
IBM Corporation IBM Power 570 ( 4.2 GHz, 32 core, RedHat)
456.hmmer 883/667

http://spec.org/cpu2006/results/res2008q4/cpu2006-20081208-06233.html
Unisys Corporation Unisys ES7000 Model 7600R, Intel Xeon X7460, 2.66GHz
456.hmmer 1800/1440



それとも8ソケット48コアのほうが良かったか？
http://spec.org/cpu2006/results/res2008q4/cpu2006-20081208-06231.html
456.hmmer 900/720

>>570
英語が読めないんですから、無理しちゃダメかと。
それ32コアと96コアの比較ですよ(笑)
http://spec.org/cpu2006/results/res2008q4/cpu2006-20081003-05500.html
　　------------------
　　32 cores, 16 chips, 2 cores/chip, 2 threads/core
　　------------------
http://spec.org/cpu2006/results/res2008q4/cpu2006-20081208-06233.html
　　------------------
　　96 cores, 16 chips, 6 cores/chip
　　------------------

>>568
一つや二つじゃないけどな。っていうよりスレッド化されてるアプリすらAtomと良い勝負なんだけどどうなの？>>563

ちなみにD945GCLF2 実売8000円（Atom 330搭載）

>>571
なんでソケット単位の比較しちゃいけないのｗｗｗ

1ソケット当たりの消費電力はPOWER6のほうが食ってるんだから
2コアでもXeonMP 6コア分の性能があってしかりだろ？ｗ

システム全体でのトータル性能や電力効率を加味して決まるのであって
コアあたりで決めるお前ローカルのルールは世界のどこに行っても通用しないよ、ペニス君。

コードを最適化しない人間に全く非はなく全部設計が悪いせい＞Cell
システムの設計思想に非はなく疎結合に最適化しない人間が悪い＞疎結合MPP

この辺りのダブスタ、だんご氏は論理ではなく信仰に随っていて
ただ知識で身を鎧っているだけにしかみえないな

逆にさ、密結合のベストソリューションって何よ？ｗ

どのへんで疎と密を分けてるのか理解できないんだが。
Cell自体粗結合型マルチコアだろ

＞コードを最適化しない人間に全く非はなく全部設計が悪いせい

馬鹿だな。大規模システムにおける「最適化」ってのは、根本的に向いてないプロセッサを除外することになるんだよ。
電力の無駄だからな

クラスタのメリットは、ノード単位での入れ替えができること。

>>573
　　---------------
　　なんでソケット単位の比較しちゃいけないのｗｗｗ
　　---------------
簡単にまとめると下記のようになります。
　1. アーキテクチャよりプロセス世代の影響を大きく受ける
　2. HMMerの特性として、メモリフットプリントが小さくL2までのキャッシュのヒット率が高い
　　ベンチマークのため、アンコアの影響が小さい
　3. 上記によりアンコア部にトランジスタを費やしているプロセッサは不利になる。
　4. 一方で、アンコア部にトランジスタを費やしているプロセッサはより大規模なSMP構成が
　　可能になるため、最大規模での絶対性能は高くなる。
　　これはこれで、ひとつの「性能上の優位」。
　　(例: SPARC64 VII/2.52GHz: 2530(peak)/2530(base) [2008Q3, cpu2006-20080711-04737.html])
　　　　　
最初の話くらいは常識かと期待したのですが？

SPEC2006におけるメモリ所要量に関する資料です。
http://www.spec.org/cpu2006/publications/SIGARCH-2007-03/05_cpu2006_wss.pdf

＞　1. アーキテクチャよりプロセス世代の影響を大きく受ける
プロセス世代の遅れそのものがアーキテクチャの魅力を低減させる要因です

あとは指摘している消費電力効率から目を背けた詭弁なので、読む気がしない。
XeonMPは事実として最大96コアのスケーラビリティが得られてるわけで
それは他のベンチマーク項目からも明らかだな。

Top500では7割以上のシェアを取っていながら電力効率ではほとんど上位に入っていない。
プロセス世代ではIntelが一番進んでいるにもかかわらず。
将来Larrabeeが入ってくるとこれがどう変化するか面白そう。
http://www.green500.org/lists/listdisplay.php?month=11&year=2008&list=green500_200811.csv&start=1&line=50

ちなみにうに死すのXeonMPシステムの消費電力は1セル（4ソケット）あたり1.5KWなんで
UnisysのMPサーバは16ソケットの96コアで合計6KW程度かな
http://www.unisys.co.jp/news/NR_080916_es7000_1.pdf

ソースは敢えて示さないけど、POWER6の16ソケットがどんだけ大食らいか知ってたら
1コア同士で比較すべきなんて口が裂けても言えないね。
実際の消費電力を目の当たりにしたら、俺が16ソケット同士の比較が妥当だと言った意味が嫌でも理解出来るよ。
それでなくとも【64スレッド】でしかも4GHzを超える高クロックな時点で、ハンデを与えろと言える立場ではない。
10進演算だけは無敵なんだからそっち方面だけに注力してればよろしい


>>581
あくまでLINPACK基準の電力効率だからそのへんは懐疑的だ。
実際の利用シーンを反映してないし。

SPEC値だとPenrynからNehalemに置き換えることで、HT対応などにより同クロックでも
実効性能は1.5〜2倍程度になるが、LINPACK基準では1割もあまり伸びなかったりするし。

ま、CellやBlueGeneみたいな目的特化型が一概に悪いとは言わんが
多彩なプログラマビリティが必要な用途にはCore MAに勝るソリューションはないだろう。

>576　だとしたら
Scienceが抱えている課題の種類別比率に対して疎結合MPPの設置割合が
明らかに多すぎる現状は、是正、調整しなければいけないな。

×向いてないプロセッサ
○向いてないシステム

>>582
　　----------------
　　ソースは敢えて示さないけど、POWER6の16ソケットがどんだけ大食らいか知ってたら
　　----------------
サーバーの消費電力が問題になっている昨今。ソースなんていくらでも(笑)
http://www.green500.org/lists/listdisplay.php?month=11&year=2008&list=green500_200811.csv&start=101&line=201
166-168位あたり。
下には下が沢山いる順位かと。

Green500はシステム構成が判りずらいので、Top500の登録消費電力データより。
http://www.top500.org/list/2008/11/100
　38位 POWER6/4.7GHz x 4896-core: 782.48 [kW]
　83位 Xeon 54xx/3.0GHz x 4584-core: 510.61 [kW]

スパコンで多彩なプログラマビリティは普通は必要ないよな

>>586
高いお金を出して建設したスーパーコンピュータは様々な用途に使うことを前提にしますので、
そういう訳にはいきません。
特にクラスタは、適当に切り分けて小規模なジョブを流すことも多いのでPCワークステーションと
同レベルのプログラマビリティは必要になります。

どういった使い方を想定して仕様を決めているかは、この資料とか。
http://accc.riken.jp/HPC/Symposium/2008/kurokawa.pdf

それDPだろ。
Xeon MPはDPよりもノードあたりの性能は高く、コアあたりの電力効率は更に上を行っている。
単純にクロックを抑えてコアを増やしてる分良くなって当たり前なのだが
俺がUnisysの16ソケット96コアと比較したPOWER 570 4.2GHzの16ソケットは

> IBM Power 570の結果は、16チップ、32コア、およびコア当たり2スレッドのシステムによるもので、
> Result（Peak）は832でした。サイト・プランニングに推奨される最大電力使用量は、5600ワットです。
http://www-06.ibm.com/systems/jp/power/benchmark/570/

とまあ、同じ16ソケットでの消費電力がほぼ同じに収まってるわけだが。
Unisysの1.5KVA/cellってのもどうも電源の定格消費電力な気がしたので、
実際の消費電力を反映した正確な数値が欲しいところだが。

しかしTop500でXeon MPがあまり使われないのは、DPより新規製品が出るのが遅いからかね。

>>588
　　--------------
　　それDPだろ。
　　--------------
Xeon 54xxってデュアルコア製品があると思うのなら調べてみてはいかがですか(笑)
http://processorfinder.intel.com/List.aspx?ParentRadio=All&ProcFam=528&SearchKey=

システム全体の消費電力の話題ですが、プロセッサの割合はそれほど大きなものではありません。
しかも年々、その割合は低下しつつあります。下記の資料のp4-5をどうぞ。
http://www.ecmwf.int/newsevents/meetings/workshops/2008/ModellingSummit/presentations/Winchell.pdf

ついでにGreen500の消費電力値ですが、団子さんの大好きな実測値ですよ。
http://www.green500.org/faq.php
　　----------------
　　At publication time, will you be specific as to which form of power was used?

　　Yes. We will use "measured power" if a formal submission is made here and if the
　　number makes sense relative to the peak power rating. Furthermore, the list will
　　indeed explicitly show whether measured or peak power was used. (Since "measured
　　power" will be less than "peak power", it is advantageous to make a formal Green500
　　submission.)
　　----------------

「Xeon DP」の意味がわからなかったのかペニス脳は。5000番台って言わないと理解できないかな？
具体的に言えばPenryn世代でいえばHarpertownのことだ。
4コア×2ソケットで1ノード8コア。それをクラスタ化するにはInfinibandで相互接続するだろ？
どんだけ消費電力食う？
つまりそういうことだ。恥ずかしい奴だ。



Xeon MPはDunningtonのほうだ。7000番台な
Xeon DPのFSBは1066/1333/1600MHz、しかしDunnington のFSBは1066MHz
性能低っ！って思った奴は素人。X7460でも130WのTDPに収まるのだ。ただし2.66GHz。
メモリー帯域は大容量L3キャッシュでセーブするので大きな問題は生じない
しかしながら外部アクセラレータをフル活用するのにはあまり向かないな。

Dunningtonはネイティブで96コアいけるが
逆にそのせいでMSが困ったことになった。

2008無印までのWindowsは64論理プロセッサまでしか使えなかったからな

なんでLarrabeeのスレでXeon談義になってんの？

スレッドの並列度としてはLarrabeeはXeonMP級なんだよな。
容量は少ないが

>>588
>Xeon MPがあまり使われないのは

MP版が高すぎるからだよ。一般人が単体で買えるような
所にXeonは2ソケット版しか流通してないが、Opteronの2xxxと8xxxの
価格差とあんまり変わらんはずだから価格比較サイトで見てみるよろし

あー間違えたな　別に一般人でも買える所でも扱ってる

http://www.osp.ru/news/articles/2009/17/7476720/

今更Polarisのダイフォトは食傷気味

話の腰を揉んですまんが、Larrabeeのopcodeって公開されてる？

解ったところで何もできんよ。
ああ、何も出来ないのさ。

　　　　　 .,,-‐''"~~￣ﾞﾞ'''ｰ､,
　　　 .,／'　 ザルカウィ　 ヽ　http://aliennationreport.com/SHOSEIKODA.wmv
　　 ,,i´　　　　　　　　　　　　ヽ
　　 |　＿,,,;---‐‐‐---､,____　 |　　　　　香田くん ＝ NVIDIA
　　|‐''／　　　　　　　　　＼ﾞ''ｰ|
　　|　|　　　　　　　　　　　　|　 |　　　　ザルカウィ ＝ INTEL
　 （ ./　,;;iiilllllllliii;;,,;;iiillllllllii;;,, |　 ）
　　.| | 　≪・≫/| | ≪・≫　.|　/
　　 | |＼　 ~~//　 |　~~~ ／| /
　 　 | |　|　./ .L;....;J ヽ　|　//　　陸自撤退の要求を日本が断ったから
　　　.| ヽ､,,;;iiill|||||||||lllii;;, ／.|
　　　 ヽ 　 |'"~ｰ--‐~ﾞﾞ'''|　/　　　　香田証生は、んっごうの刑！
　　　　　|　 ﾞ'''ｰ----‐''"　|
　 _＿_／＼　　　　　 r'"￣`⌒'"⌒`⌒⌒'ー､_ 　
／　　|　　　＼＿＿.r'　　　　　 香田 　　　　　ヽ
　　　　　　　　　　（　　　　　　　　　　　　　　　　｀ゝ
　　　　　　　　　 （;;;;;;;;;;;;;;;;;人＿（＼!（(^i_/ヽ､::*::: }
　　　　　　　　　　| 　　　/*-''￣　:;;￣''-　　 i　　ﾘ
　　　　　　　　　　| 　　ソｒ《;,･;》､i 　 r《;,･;》､ |　.　|
　　　　　　　　　 　ﾘ　 i ;;;;;; 　　 |　　　::::　　 | 　　|
　　　　　　　　 　　}　　<ﾍ　:;;;;; ﾉ　:::　　　/;; >　　i
　 　　　　ｺﾞﾘｯ　　 |　　|:::l:;;;;;;;*`;;ー;;`ヽ:　l::::|　　 |
⌒⌒ヽ　　 　 　彡｀';:;　ヽ:::;;; l l=＝=ｭヽ　::/　 ﾘﾉ
　､　　）￣}￣￣￣￣￣ヾ　;; |､'^Y^',,|:::／|　/　　　　　んっごう！！
､_人_,ﾉ⌒)}─┐ 　 　.,,;:':;}#;＼∬;;;-'／ 　| （
　　＿,,ノ´　　└───;ｲ;ﾟ;'∬:∬　　　　 j,/
r‐'´ ﾌﾞﾁｯ…ﾌﾞﾁﾌﾞﾁ…','/；;∬∬∬　　 　　＼

TSMC confirms 40-nm yield issues, gives predictions
ttp://www.eetimes.com/news/semi/rss/showArticle.jhtml?articleID=217201043&cid=RSSfeed_eetimes_semiRSS


TSMC's 40nm problem revealed
ttp://www.theinquirer.net/inquirer/news/878/1050878/tsmc-40nm-revealed
http://pc11.2ch.net/test/read.cgi/jisaku/1217915128/635

DDJ記事、第2弾。"Rasterization on Larrabee"
http://www.ddj.com/hpc-high-performance-computing/217200602

SCEAのパートナー企業インソムニアックゲームズがLarrabeeについて調査中
ソースは俺

だから違うと思います

誤爆

Cell死亡か

>>603
団子さんのことですから、腐れルーマーに引っかかっている可能性も否定できませんが、
LarrabeeはIntel版CELL/B.E.ですから、何の不思議も無い…という程度の信憑性はあるで
しょうか？

＞Intel版CELL/B.E.
ふふ、未だに言ってるのか馬鹿め


まずCellはGPUではない。

>>603
ソースの"俺"は誰だ？

発信源はあくまでdango.chu.jpだよ

16コア程度だと、ピクセル処理において、ラスタライズ法でもレイトレーシング法でも微妙じゃないか

おそらく45nmで600mm^2を超えるダイサイズなのに、16コアなわけがないだろう

firewall.insomniacgames.com / Squid [10.0.1.9]

ま、なんでも良いけどな俺は。
ただIntelがゲーム業界に売るなら負け癖がついたプレステじゃなくてXboxシリーズの後継機だろう。

NVIDIA以外のOpenGL実装って微妙すぎるし。

>>613
それはいくらなんでも自意識過剰というヤツでは？

内容も吟味せずにそんなことが言えるのかね

まあ、楽しみにしておくと良いよ

512bitだと、32bit16wayだから
GPU換算Larrabee1コア16spって事になるのかな？

推測
600mm^2　Atom換算24コア
24コア*16sp=384sp（2Ghz）

トライアングルセットアップで躓いてたけど性能でそう？
というか性能でてるの？

>>613 >>615
まあネタとしては面白い

>>615
　　----------------
　　内容も吟味せずにそんなことが言えるのかね
　　----------------
そんなこと言われても、ページ閲覧履歴から内容を吟味できるのは団子さんだけな訳で(笑)

>>616
> 600mm^2　Atom換算24コア

同じことを書こうとしたがまあいいや。
ただその計算には重大な誤りがある。

Atomのダイの40％近くがFSBインターフェイスに食われ、あとは電力制御用のブロックとかが食ってる。
L2は512KBと、Larrabeeの256KB/coreよりも多い。

AtomはP6とP5の中間的なパイプライン構成だが
LarrabeeはP5ベースでパイプラインはAtomよりシンプルなものだ。
512ビット×2のリングバスもCellのEIBを見る限り大したダイサイズは食わないと思われる



ということで48コア程度なら積めるのでは？

>>619
倍ですか

ところで、GPU換算で出したLarrabeeにおけるsp数って合ってる？
でグラフィック用として性能でそうなの？

Larrabee:A Many-Core x86 Architecture for Visual Computingから600sqmmなら40コアだと予想している
48コアなら650sqmmを超えると思う
ただ例のウェハの写真からダイサイズを正確に測るのは難しそうだから48コアでも全然おかしくはない

そっち方面は微塵も重要だとは思っていない。あくまでx86ベースのアクセラレータだから。

餅は餅屋というではないか。
ディスクリート版を出す本質はあくまでGPGPUに対する予防線だ。


まあゲームコンソールに載るとしてに2011年以降の話になるだろうから
ゲーム機の採用を足がかりに普及させるというカードはどのみち使えない。

Larrabeeの登場でGPGPUはどうなっちゃうの^p^

メモリ帯域ネックで演算ユニットを持て余す状態で、汎用コンピューティングで活路を見出そうとしてる
現状をみると、GPUに特化したハードってのは逆に無駄が多いし、各コア毎に高速アクセスできる
ローカルキャッシュを備えるのはパフォーマンス設計上逆に有効かもしれないね。

>>620
前述した論文によると
1GHzの10コアで1600*1200 AAx4のHalf Life 2 ep.2がFPS60切らずに動くみたいだが
それってどうなのよ？と逆質問
ゲームしないからさっぱりわからんのだが

LarrabeeがIntel版Cellなんて頭の悪いこと未だに言ってる奴がいるが
CellはSCE版Niagaraだろ（笑）

と、そこでNiagaraとの違いを指摘してもいい。
それがそのまんまLarrabeeとCellの決定的な違いになる。



>>625
http://pc11.2ch.net/test/read.cgi/mac/1214461149/166-167

現実には2年で3倍なんてペースで伸びてないし、8800GTXが2年近くもトップに君臨してたそんな閉塞感漂う
GPUの現状。

キラータイトルが未だにCrysisだし。

キラータイトル「ベヨネッタ」になると信じてる

TheINQの連中なら、俺が「インソムニアックゲームズの奴がLarrabeeについて調べてた」って情報を流せば
素敵に脚色してデマ記事作ってくれるんだろうか？

Demakasejan先生の創作に期待下さい。

個人的にグラフィックス面でも期待してるんだが
そんなに厳しいのかな

ttp://game.watch.impress.co.jp/img/gmw/docs/080/150/html/lrb08.jpg.html
texture unit以外にも固定機能ユニットがあるようだが
どの程度の機能をつんでるのかな

過去のIntel GPU関連のソフトに関わった人間が絡んでたらこける
Intel謹製コンパイラやらMKLやらのエース級が担当すればいける かも

この団子の浮かれっぷりは恥ずかしい。

別に。

それより任意のキーワードで24時間以内にページランクでトップにする方法思いついた。

>>630
GDC2009のMichael Abrashのプレゼン資料のp.11で次のように書かれています。
http://software.intel.com/file/15542
　　--------------------
　　- Fixed-function texture sampler units
　　- Also a per-core cache-management unit
　　- No other fixed-function units
　　--------------------

ペニスくんに同じく
テクスチャユニット以外とSIMDが強いx86コア以外の機能は特に載ってないと見ている。
メモリ帯域ネック（それを解消しようとすると消費電力・熱密度がネックになる）の打開策は
キャッシュの搭載および大容量化くらいしかない。
その意味での優位性はあると思うよ。

DX11で標準仕様に盛り込まれるテッセレータをソフト実装してどんな性能が出るのかは計りかねるが。

調べてたってインターネット検索でしょｗｗ？
組織ナンバー3の団子さんならご存知だと思うんだけど
こういう場合はNDA結んで情報を開示を受けるんだよ。
で性能が洗いざらい記述されたドキュメントを受け取る。
で、調査段階では複数のベンダーに対して同じことやって
どれがいいかを見定めるんだ。

俺は組織のNo.3なんて言ったことはないな。
別のところでは組織トップだし。

団子さんは組織の四天王の一人ですよ

>>636
ちなみにプロトタイプライブラリについての情報だよ。
NDAもなにも登録もなしに誰でも使える。

>>638
もちろんトップはアガサ博士な

>>638
団子3兄弟

> で性能が洗いざらい記述されたドキュメントを受け取る。
> で、調査段階では複数のベンダーに対して同じことやって
> どれがいいかを見定めるんだ。

どれもSCEの下請けが独断でできることではないな。

細かいことはどうでも良いがこれっていつ出るん？
赤い彗星の逆襲みたいにみんな驚く性能あるんか？

もちろんクローズドなLarrabee SDKが存在することは知ってるよ。
去年あたりから一部企業向けに情報は出てる。

インソムニアックは独立系なんだから、やろうと思えば単独でNDA結べるでしょ。
例えばLarrabeeに最適化したゲームをローンチ時に発売するなどで。
団子だって組織のトップならIntelとNDA結んで情報ゲットできるんじゃないｗ
誰よりも早くLarrabeeの仕様を知ってソフト書きはじめられるなんて本望じゃないの。
最速のトリップ検索を作りますっ！て

そんなので釣れるのはNotarinVIDIAくらいだ。

一応↑と話があったときの名義は俺が事業主扱いでした。

>NotarinVIDIA
糞ﾜﾗﾀｗｗｗ

>>644
　　--------------
　　クローズドなLarrabee SDKが存在することは知ってるよ。
　　--------------
腐れルーマーサイトを読むことは『知っている』とは言わないかと(笑)

>>648
ルーマーじゃねーし。お前ルーマー大好きだな
ちなみにintel.com配下のドメインですよ

>>642
WWSの内情について知らないのがはっきりした。良かった。

>>650
んー？
SCEのソフト開発パートナー企業の離反が続いてること自体は誰でも知ってるだろ。
PS3が始まったときからじゃないか。

そうだね。GDC来ればよかったのにね。

GDCでのプレゼン資料ならWebに出てるだろ
インソムニアックがPS3をなんとかマシに使おうと努力してるのだけは知ってるが
それ以上は興味ないよ。

いまのハイエンド指向のデベロッパーは、いくら画面綺麗にしても任天堂に勝てないのに
ずいぶん無駄な努力してるなという印象しかない。
PS1が何故勝てたのかそれすら忘れてる感じ。

あ、パラッパの松浦さんの新作は楽しみにしてるよ。

>>653
参加しないと雰囲気は判らないし、質疑応答は発表プレゼンに含まれていないかと…
学会とか参加したことは無いのですか？

悪いがIEEEとACMくらいしか読む気はないな。
一応職場経由で開発者カンファレンス行くことはあってもゲーム関連とは全く関係ないし。

>>656
　　----------------
　　悪いがIEEEとACMくらいしか読む気はないな。
　　----------------
どちらも学会の名前で、論文誌の名前じゃ無いのですが(笑)
そもそもIEEEがどれほどの数の雑誌を発行しているｌことか…

学会誌だけは会社で取ってるが、学会そのものの参加はご無沙汰だな。
そもそも学会なんて発表するネタも書いてきてない人間が参加するモンじゃないよ。

まして学会誌を読んで内容を理解出来ない人間が参加して理解出来るイベントでもない。


開発者カンファレンスそのものは雇い主の会社としてMS主催のイベントにたまに声がかかるくらい。
会社の営業トップの人がMSKKの樋口さんと並んでる写真みせてくれたよ。
その程度の付き合い。
俺個人でやってる方は某Nが最初で最後だよ。何で声がかかったのかいまだにわからん。

しかし内心ステータスっぽくて嬉しい団子であった

ちなみに>>645的な需要で行くと
俺個人のソフトならLarrabee C++ Intrinsicsへの移植ならとっくに終わってるし、
ネイティブアセンブリコードすらNASMの構文で書き終えてるからな。
4スレッドもあるのに1スレッド当たり汎用レジスタ16本＋SIMDレジスタ32本は十分すぎる
レジスタ余りすぎて逆に何に使おうか迷う状態。

でもまあ、現在ペーパープロセッサも同然のLarrabeeに構う必要ないでしょ。
手元にちょっとばかし面白いデバイスが手元にあるのでそっちに没頭中ですよ。
いつでるか解らないアーキを待つよりも今使えるもので技術の蓄積する方が有意義だ。

ま、それでもCell（笑）は全く役に立たないがな。




それはそれとして、LarrabeeがPS4に採用ってのは団子やさん的にもあまり歓迎できないな
くされはCellと心中してくだしあ＞＜
というか、Intelの経営陣はWiiをかなり意識してるようで、Larrabeeも体感指向のゲーム機に採用させたいといってた。
勝ち馬に乗りたいと思うのはIntelとて同じだ。

http://www.inside-games.jp/news/332/33233.html
この辺の据え置きゲーム機2位争い（笑）の応酬見ててもわかるでしょ
この期に及んで任天堂ハードとは別次元だと言い張るソニーと、暗にWiiの成功を褒め
性能だけでは無くコンテンツ力が重要であることを語るMS。

SCEはトップがこれだから、今のPS陣営の人は、映像表現さえ上がれば関心を集められると
盲目的に信じてる感じがする。てか、そういう人しか残ってない気がする。
（ま、バランスを重視した360の方が結果的に高い映像表現が出せてるのが皮肉なもんだが）
世のJKを見てごらん。ゲームなんて携帯の画面程度でも要求にマッチすれば没頭できるんです。

SCEのお人は先が見えてないのはもちろん、それ人間としてどうなのよな発言が多いのがな
発言見る度にあの会社の製品は避けようと思わせる力がある

でもWiiの売り上げ急激に落ちちゃったよね
スクエニ×松浦の新作なんて600本しか売れなかったしどうするんだろ

本体の方は飽和状態だけどソフトの売り上げが悲惨なのが多いね。
メジャマジ・マーチなんか600本しか売れてなくて
その内半分が読者プレゼントみたいだし。

ま、ポリカーボネイトの円盤が売れようがハードウェア屋のビジネスにはならないのよ。
任天堂は弱者救済の便利な会社ではないということだ。
Intel的にWiiの方向性で関心があるのはリモコンとか、あのPS3（笑）以上に売れてる白い
「板です」とか、つまりハードウェアだよ。

あのへんの延長に物理演算の需要を喚起できないかと期待しているわけだ。
Intelはモーションに関しては、Wiiリモコンみたいなデバイスを使わずEyeToyみたいなカメラと
ソフト演算でモーションを検出しようとしている。
リアルタイム画像解析だな。
わざわざ物理エンジン屋のHavok買った意味もそこにある。


というか、それとは別にオムロンなんかと共同でWiiFitのPC版そのものな健康器具の規格を作ろうとしてるが。

まあヤクザだな。
でもIntelだけは違うと思ってたんだがなあ。
Corei7コケた位で洗礼受けるもんかね。
あLarrabeeのせいか。

ま
で
C
あ

おまいら

家に閉じこもってないで
れじゃーに池よ

レジャーってのは余暇って意味だ
余暇に行く、って何だそれ

こいのぼりだよ

好きなベンダがある…というのは向学心につながりますから悪いことじゃ無いと思いますが、
気に入らないベンダを叩きたいという欲求は、先を見る上で目を曇らせることにしかならない
と思いますが…さて。

>>658
　　------------------
　　学会なんて発表するネタも書いてきてない人間が参加するモンじゃないよ。
　　------------------
学生時代に参加したヒトが多い筈なので学会を例に挙げましたが、海外では講演に質疑応答が
付随するのは当たり前で、面白い情報もそこから仕入れられることが多いです。
私がしばしば拾ってくる会計報告関連のtranscriptでも、Q&Aの部分に面白い情報があるでしょう？

＞気に入らないベンダを叩きたいという欲求は、先を見る上で目を曇らせることにしかならない

その一例がペニス先生ですね。わかります。

＞私がしばしば拾ってくる会計報告関連のtranscriptでも、Q&Aの部分に面白い情報があるでしょう？

他人の質問の返答を拾ってきて楽しむだけの下らない人間にはなりたくないものだな。
まあ俺もSONY四半期決算のシャーペンカチカチは面白すぎて毎回笑わせてもらってるが

全力で訂正する。ボールペンであると。

インテルもララビみたいな電力食いの馬鹿でかいチップつくって大丈夫？
Appleが開発してる独自プロセッサがiPhoneやiPodファミリーに軒並み載せられたら大変なことになるぞ。

ターゲットが全然違うのにアホでしょうか？

appleがcpu設計とか意味わかんないんだけど
金をどぶに捨てるようなもんだろ

もとATIの人がAppleに移って作るのはiphoneようのメディアプロセッサ

P.A.semiだろ。
PPC970と命令セット互換の省電力プロセッサPA6Tを作った技術力は本物だよ。
オリジナルのPPC970がどうしようもなかっただけに。

IntelはLarrabee以外にもMID用の独自GPUを開発してるが。

>>677
実証主義を標榜する割に、
　　----------------
　　省電力プロセッサPA6Tを作った技術力は本物だよ。
　　----------------
見たこと無い代物に、こういうこと書いちゃうのが判らないんですよ(笑)

＞見たこと無い代物に、

お前が見たことがないんですね。わかります。
NECのストレージアレイにも採用されてるよ。

かわいそうに。

>>679
(笑)
http://pc11.2ch.net/test/read.cgi/jisaku/1186887760/797
　　----------------------
　　797 名前：MACオタ 投稿日：2008/01/16(水) 01:53:52 ID:1O/FEDl+
　　　　久しぶりにPowerPCの話題を書くような気がするすけど、NECがストレージシステムのコントローラ
　　　　として、P.A. SemiのPWRficientチップを採用するとのことす。
　　　　http://www.pasemi.com/news/pr_2008_01_10.html
　　----------------------
http://pc11.2ch.net/test/read.cgi/jisaku/1172923824/711
　　======================
　　711 名前：・∀・）っ-○◎● 投稿日：2007/04/28(土) 03:36:20 ID://+RcVJg
　　　　きっとあれだ。未だにPPCを捨てきれないマカーだ。

　　　　PWRficientは確かにかなり惹かれるものがあるが
　　　　ESが700ドル、評価キットが8500ドルもするような代物だぜ
　　　　出荷時期には安くなるのか？
　　======================

くだらない足の引っ張り合いはともかく、ぴーえーせみの連中がARM互換を作っているのは報道であったような気が。
ARMを作らされていると聞いてがっかりした記憶がある。

いっそiphoneをPowerにしてくれればよかったのに。

知るも知らないも何もPA6Tで動くコード書いたことがあるし（笑）

もっとも本番以外はx86ホストでクロスコンパイルやってたけどな
PA6Tは良くも悪くもレイテンシ・スループットの特性は7450の64ビット版的な性能だ。

>>681
ARMも創生期からAppleの血が入ったアーキテクチャですから、悲観する必要は無いと思いますよ。
http://www.ot1.com/arm/armchap1.html
　　----------------
　　A new company was set up with Apple, Acorn and VLSI Technology as founding partners.
　　The Acorn RISC Machine became the Advanced RISC Machine and Advanced RISC Machines
　　Ltd was born. Many of the original designers moved from Acorn to join the new company,
　　with others working in an advisory role. Additional expertise was provided by Apple and
　　new blood was recruited from around the world.
　　----------------

気が入ったとかキモイキモイ
創価学会員の同族意識そっくり

×気が
○血が

そういやインソムニアックって
スパイロ・ザ・ドラゴンシリーズやラチェット・アンド・クランクシリーズ
の会社だっけ？

Dobb'sのサイトの解説がそのまんまIntel公式資料として採用されたらしい
http://isdlibrary.intel-dispatch.com/isd/2494/drdobbs_042909_final.pdf

>>688
Abrash氏はIntel社員なので、順番が逆かと。
http://software.intel.com/en-us/articles/michael-abrash-biography/

drdobbs_042909_final.pdf
~~~~~~~~


もう疲れる。
よく絡んでこられるモノだ。恥の概念がないの？

>>690
タイトルの下に著者名が書いてありますよ(笑)

だからなんだ？


サイトの内容丸写しだといってるのだ？

くだらねーな学会員は

まあ今日やった己の恥ずかしい発言から目を反らさず、しっかり反省してくれ

167 名前：MACオタ＞団子 さん[sage] 投稿日：2009/05/05(火) 19:21:28 ID:q7/3GqkF
>>166
　　------------------
　　低減してマルチスレッド化ってなんだボケ
　　------------------
インオーダーですので、6サイクルで実行可能な処理が3サイクルになれば、
2スレッド分行ってもOK。

ほんと超一級の揚げ足取りだな

ゲーム屋風情が偉そうに

ゲーム屋風情のアクセスログに一喜一憂してる人もいるらしいね

gatekeeper1.scei.jpのログ送りつけてみようかなと思うんだ

この前時間指定でアクセスしてたのおれだよ。
指定どおりじゃなくて30分遅れたりとかだったけどなw
何か迷惑かけた？

ゲハにカキコするスクリプト仕込んじゃった

ああ、ちなみに嘘だ。
リピーターの来訪回数でいえば*ntel.comのほうが多いくらいだし
（RSSリーダーに登録されてるから更新する度に巡回してくる）

団子さんはム板以外にもいたんスね・・・

scatter-prefetchはすげーな。最大16個のキャッシュラインをバックグラウンドでキャッシュ上に集めることができる。

んで、おまいら「それくらいCellのMFC DMAでも出来る」って言うだろ？
わかってねぇ。何もわかってねぇ。

団子さん、アセンブリを極めたいんですが、いい書籍ないですか？
金は惜しみません

金を惜しまないのなら本棚の端から端まで買えばいいんじゃね

>>704
惜しまないが、本だけ買えばいいってもんじやありゃしんす

つ　4004

各CPUベンダが出してるマニュアル以上のものはない。

>>707
あざっす、
団子さん、流石ですね、私尊敬してます

ちなみにネギ振りシミュレーションでニコニコ技術部デビュー考えてたり

団子さんはスキルは尊敬できるんだけど人格に難ありだと思う。

>>710
ネットとリアルは違うと思います

道を究めるのに粘着質であることは大前提でしょ。

>>712
その通り
歴史を造った偉人にも人格に難有りの粘着質が多い
馬鹿と天才紙一重なのだ
中途半端はいかん
奇人変人を極めるといい

そそ。ついでに、大抵の名無しは何でも新しいものは全部否定するのが当然と思ってるが、
それじゃぁ先駆者にはなれん。

新しいものが成功するより失敗する確率のほうが高いから、外野で眺めているだけなら
とりあえず全部否定してるほうが気分は満たされることが多いが、それだけだ。

× 全部否定
○ ほとんど否定

一般人と偉人の間で性格に難のある割合に差はあるのか？

一緒に仕事するなら奇人でも有能ならなんとかするがプライベートは遠慮する。
仕事で2ch見に来てるわけではないから性格破綻コテはNG登録

というかLarrabeeって奇人変人に我慢しなきゃならないほど革新的か?
またx86かよとしか思わんのだが…

P54CにワイドSIMDつけただけだからコア単位で見れば何の先進性もないな。
分散共有キャッシュも一種のNUMAみたいなもんだし

まあ、汎用コンピューティング用途など微塵も意識して作られてないピクセルシェーディングに
特化したハードで、根本的に向いてない問題を数の暴力に任せて解くよりは、
技術の蓄積のあるx86のほうがマシとはいえるレベルではある。

Larrabeeそのものが、汎用CPUとしては新興のGPGPUに対するアンチテーゼだろ。
x86でもストリーム・SIMD特化すればここまでできる的な。
CPUから見れば遙かに多くのスレッドが同時に動くメニーコアで先進的かもしれないが
GPGPU側から見れば、リスクを避けて堅実なソリューションを用意してきた感じだな。

莫大な金投じた割に、
＞技術の蓄積のあるx86のほうがマシとはいえるレベルではある。
この程度しかアドバンテージがないんだよな。
しかもその数の暴力すら満足に使えないリッチコア仕様な上に、
その他大勢のプログラマが頭使わずに使えるようになる環境の構築に、
これから更にどれだけ金吸い込むか未知数という。
少なくともこんな物の擁護に徹夜なんぞしたくないぜ

>＞技術の蓄積のあるx86のほうがマシとはいえるレベルではある。
>この程度しかアドバンテージがないんだよな。

"技術の蓄積のあるx86のほうがマシ"というのは一種のレトリックだろう
そのまま受け取って"この程度しかアドバンテージがない"と言うのは少し頭が悪い
Itaniumの失敗やARMネットブックが一向に流行らない事を見ればx86の支配力がわかる

Tim Sweeny氏は大絶賛しております

DX11世代のGPUがどうなるのかみてみないと、なんともいえない

nvidiaはまた大幅に改編するみたいだし
ATIのR800世代は既存路線ぽいが、なんとなくその次あたりでlarrabee互換に走りそう
S3は読めないな・・chrome400/500のshaderは優秀なんだが、いかんせんローエンドだし
マルチGPUとかにすれば上も出すかも試練が
ただ、GPGPUにかんしては一応のメジャー規格DXCS,OpenCLが出来たので
最初からゲーム市場狙ってないS3は、あるいは他よりもこちらに偏向した小規模GPUとするかも

>仕事で2ch見に来てるわけではないから性格破綻コテはNG登録
最近この手の書き込み流行ってるな。

実質、団子がスレ主みたいなこのスレでわざわざ
｢ボクちゃんNG登録しちゃうもんね〜｣
報告しなきゃいけないほど、団子に人生振り回されているのか?
NG登録は黙ってするものだ。名無しがNG登録なんて
コテにしてみりゃどうでもいいということすらどうでもいいくらいの
どうでもいい話なんだぜ。

>>724
そしてNG登録に過剰反応するのも流行ってる、とｗ

せっかくだから説明してやってるんだが。

匿名掲示板で自分にとっての興味のない話題を
自然とスルーできないやつはそもそも匿名掲示板に向いてない。
個人的には専用ブラウザのNG登録機能なんて精神的に不器用なお子様が使う機能だと思っている。
ましてや興味がない、気に触る情報をフィルタするための機能であるNG登録を行ったという
報告をわざわざ書き込みして知らせるなんてみてて恥ずかしいからやめてくれっての。
そういう書き込みが一番無駄だ。本人の能力の低さも容易に想像できる。
以上、読者の意見です。

>>726
テラブーメランｗ

誰も言わないことを特別に説明してやっているのだ。
低能くん達はありがたく思いなさい。
匿名掲示板は個人のものじゃないだろ。フィルタを報告なんて
自分は馬鹿です、と報告書き込みしているのとほぼ同義です。

匿名掲示板で自分にとっての興味のない話題を
自然とスルーできないやつはそもそも匿名掲示板に向いてない。

匿名掲示板で自分にとっての興味のない話題を
自然とスルーできないやつはそもそも匿名掲示板に向いてない。

匿名掲示板で自分にとっての興味のない話題を
自然とスルーできないやつはそもそも匿名掲示板に向いてない。

匿名掲示板で自分にとっての興味のない話題を
自然とスルーできないやつはそもそも匿名掲示板に向いてない。

ｗｗｗｗｗｗｗ

久しぶりに見事なブーメランを見たな

>>720
＞どれだけ金吸い込むか

一種の公共事業的な性格のものだと思ったらどうだろうか。
世界3大バカと言われるエジプトのピラミッドも、実は農閑期にその他大勢に
仕事を与えて食わせるための公共事業だったという説があるくらいだし

熱いスレだな

>>731
そんなことしなくてもデスマはごろごろ転がってるよ!

>>720
> しかもその数の暴力すら満足に使えないリッチコア仕様な上に

「P54Cベース」ごときがリッチコアって言えちゃう君に乾杯。
外部バスコントローラ込みでこんな数字だよ。
まあL2キャッシュがオフダイの時代なんであまり参考にならないかも知れないが

Pentium (P54C) : 330万
Pentium MMX (P55C) : 450万


どういうコアの数え方をしているかは知らないが、SIMDの1エレメントを1SPとするGeForce方式の数え方だと
1コアで16SP、48コアなら768SP相当だね。

数の暴力とはまさにATI
ttp://www.youtube.com/watch?v=pmBd9HQgTCQ

320SPが32SPに負けるっていうと誰も信じないけど
実際負けるんだよな・・

DX11世代でちょっとは改善してほしい

>>735
いや、それ暴力になってないからｗ

Larrabeeはいくら？

>まあ、汎用コンピューティング用途など微塵も意識して作られてないピクセルシェーディングに
>特化したハードで、根本的に向いてない問題を数の暴力に任せて解くよりは、

効率の悪い物を、数を増やして誤魔化してるわけだから

まぁnvidiaの9600GT(312gflops)あたりでも
PPU(58gflops)と同等だからなぁphysxは

既出かな
ttp://isdlibrary.intel-dispatch.com/vc/2527/GamePhysicsOnLarrabee_paper.pdf
Game Physics
Performance on the
Larrabee Architecture

最終ページにスケーラビリティーについて書かれてるけど
(1GHzで0〜64core)シミュレーション？

さて、何コアだろう

ttp://www.pcgameshardware.com/aid,683947/Detailed-Larrabee-Die-shot-shown-by-Intel/News/
ttp://www.pcgameshardware.com/?menu=browser&article_id=683947&image_id=1127811
Detailed Larrabee Die shot shown by Intel

48コアっぽい

次世代CPUのスレに数えたのが有るけど32コアだね
演算ユニット以外の部分が殆ど無いってのが不思議な感じがするね

ATIはリングバスやめたら面積節約できたって言ってなかったっけ

コアのレイアウトがAtomに似ているな

どうみてもコアが大量に載ったCPUです。本当にありがとうございました。

beyond3dじゃ緑はtextureだろうけど、青はなんじゃらほいって
ttp://i41.tinypic.com/2hcdzja.png

xringインターフェイスかな？

電源管理ユニットかも

夢があるね

ダイサイズどれくらいだこれ？

すごく・・・大きいです

団子のだんごの色ってなんでころころ変わるんだ

たまにかびるとか？ｗ

ttp://www.hardware-infos.com/news.php?news=2944&sprache=1
GT300は一応40nmで490mm2以下との噂なんで
larrabeeは45nmで幾らなのかねぇbeyond3dや900mm2?とか噂してるが

45nmで900mm2だとしたら、当初20万〜30万円コース、32nm時代でも10万超えるとか
高くなりそうな気が直感的にするけど、どうだろう。

IDFで出たLarrabeeのウエハが、今回の32？コアのやつのウエハなら、
600〜700平方mmくらいになるんじゃないかな。

なんかItanium思い出すな…

900mm2とかワンショットで露光出来んのか？
上下のメモリパッド？が何bit分あるのかな

なんでそんなにダイがでかいんや
効率悪そうだねぇ

1TFLOPSを超えるのに必死なんでしょ

1tflopsといってもATIのRV770のような物じゃ役に立たんし

16コア2GHzで1TFlopsだから、32コア2GHzで2TFlopsの可能性もあるんじゃないかな。

本日のだんごのLarrabeeネタ
ttp://dango.chu.jp/tripper/20090513.html

900なら48コアで性能ダントツだな

>>758
ステッパの最大が21*21mmくらいだった気がするから無理じゃね？

900�o2で48コアじゃ16コアでも300�o2超えちゃうじゃん
これだとGPUとしての性能は惨いことになるが・・・

せっかくのララビで１６コアじゃつまらんな。
アイナたんだって論理８コアなんだし、絶対４８コアはほしい。

というか900�o2とかって聞いた後だと、>>740の写真でコアごとにある黒っぽい部分がいかにもL2っぽく見えてきたんだが・・・
この部分が256KBのキャッシュだとすると、比率的にコア1個ごとのサイズでかくね？

80486ベースにしろとあれほど言ったのにもう

900はガセだからｗ
実際は600だ

600も単なる噂に過ぎんよ

>>771
げるたんが抱えてるシリコンウェハ
縦横の大体のサイズはわかるだろあとはわかるな？

2.5cm四方前後だったそうだ。

larrabeeも物理処理に向かなそうだな
atiのが依存関係の問題でshaderがほとんど死んだのと同じで

larrabeeもsoaだと無駄が多いだろうし
aosでも1/4は死ぬ

何をおっしゃいますやら。
1命令でAoS・SoAを動的再構成するGather命令を備えてますが。
ギャザーアドレスをバックグラウンドでプリフェッチする命令も備える。
このあたりはTom Forsythの講演資料にも載ってたろ。読んでないのか？

むしろRadeonの弱点は1命令デコーダに対して演算ユニットが何十個も繋がってる特殊性にある。
オンコアのワークメモリが少ないのも欠点。

larrabeeのパイプラインって何段？

Intelはレジスタ番号みたいな「処理ロジックに（将来的に）影響がでそうなもの」を、
OPの後ろのほうに置くのは極端に嫌がるんじゃないのかな。もちろん妄想だけど。

物理は512MIMDらしい、GT300か

京速のベクトルプロセッサが白紙化したことで各陣営チャンスが巡ってくるな

古い情報しか見つからなかったがLarrabeeのパイプラインの段数はPentiumと同LVって事だが・・・
6段〜8段じゃクロックは1Ghz＋αまでしか上がらないんじゃないか？

Atomより短くはなるとは言ってたが8段ごときで済むわけがないだろ。
LarrabeeはP5みたいに大まかに言ってSIMD命令とスカラ命令を交互に並べないとスピードが出ない。
パイプラインの非対称性がP5のU/Vパイプラインライクなだけ。
P5のパイプライン構成そのものなわけがない。

Atomは2つのシンプルデコーダは対称で、デコードした命令をいったん一つのキューに溜めて
また更に演算ユニットを振り分ける。
なにより4WayのFGMTなんでパイプラインを長くすることでのペナルティがあまり無い。

すまん後半が意味不明だったかな？
Atomより短くなる必然性と、10段を超えることでの性能への影響な。

Atomは18段とCore MAより多い。

いやいや段数が多いんなら良いんだけどね

http://plusd.itmedia.co.jp/pcuser/articles/0808/05/news072.html
＞パイプラインの段数についても、Pentiumと同様のショートパイプラインだとインテルは説明している。

他のとこでも大体似たようなことが書かれてるから不思議に思ってんだよ
もしかすると、一番処理時間の長そうなSIMDエンジンを1クロック動作させるのに必要な時間を基準に行程を分割すると
他の部分は7段とかでも良いということに事なのか・・・とも思ってね

ショートってのは誇大表現だ。10段は余裕で超えるのは確定的に明らか。

P54Cってさ、命令のプリフィクス・エスケープバイトが1バイト増えると1クロックストールしてたんだぜ。
1バイトOpcodeの命令しか2並列実行できない。
P55Cで2バイトOpcode（0F xx /r）とかをストールなしで実行できるようになったが、段数は1段増えた。


んで、ただでさえ64ビットとか対応するだろ？REX解析しなきゃならない。
更に、Larrabeeの性能の肝となるSIMD命令はそれより更に長い命令ばっかだ。
それらをパイプラインハザードなしに解析しなきゃいけないんだぜ。
P54Cのパイプラインそのまんま使えるわけねーじゃん。

4Wayマルチスレッディングだからハザードパスが相対的に小さく見えるって意味だとしたら
20段くらいあるかもな

行程がPentiumより多いのは分かるんよ

でもパイプライン各段の所要時間は違うでしょ
長い段は分割してしまえば1段あたりの所要時間は減るからクロックを上げられる
でも分割できない段もあるから、最終的にはそこがネックになるよね

例えばA-B-C-Dの行程4段それぞれの所要時間が1-2-8-4だとする
この場合Cがボトルネックになるから、CをC1＝5、C2＝3の2段に分け
A-B-C1-C2-Dの5段にすれば、各段の所要時間は1-2-5-3-4となって、ボトルネックの所要時間は5になる
これならクロックは8/5＝1.6倍に上げられる

でも、Cが分割できない行程だったら・・・
逆にAとBはまとめてしまって、AB-C-Dの3段にして、各段の所要時間は3-8-4とできる
これだとクロックは上がらないが、出てくるまでに必要なクロック数が1減るし、何かあるときのペナルティーも減る

Larrabeeでも、SIMDの部分の所要時間が特大なら、他の行程を整理して段数を減らせるんじゃない？

レイテンシを減らす発想が無い気がする。
「4Wayのマルチスレッディングならレイテンシ8の命令が2に見える」とか
ForsythがGDCで言ってるわけなんだが
逆に言うと、そういう命令があるってことなわけだな。

レイテンシが8とか言ってる時点でExecute部分だけでそれ相応の段数はあることになる。

Intelの場合、パイプライン段数のことを言うときは基本的にハザードパスなんで
浮動小数などの演算工程が多い命令は段数に入れてないことが多いのだが。

Cell ラスタライズ
http://journal.mycom.co.jp/articles/2006/09/14/cedec3/images/cedec_raster.wmv
Cell レイトレーシング
http://journal.mycom.co.jp/articles/2006/09/14/cedec3/images/cedec_raytrace.wmv

ららべーはこれより綺麗な映像作れるんですよね？
ちょー期待してます

Larrabeeは2010年前半登場
http://www.tgdaily.com/html_tmp/content-view-42452-135.html

ラインナップについて明かされてはいませんが、ローエンドで少なくとも8コア、
ハイエンドで少なくとも32コアとなるだろうとのことです
動作クロック2GHzの32コアでパフォーマンスは2TFlopsとなるとのこと

32nmへはいつ移行するのかね

移行したとして、いきなりこんなでかい物を作るかね

Larrabee
http://i40.tinypic.com/20iv3oj.png
黒い部分がL2-256kBだと思うが、キャッシュとその他の部分の比率は1：10程度

Phenom�U
http://pc.watch.impress.co.jp/img/pcw/docs/167/815/kaigai_6.jpg
L2-256kBが2ブロックで512KB
よって1ブロックで計算すると、L2-256kBとその他の部分の比率はやはり1：10程度

スカラ部分はPentium級で小さい筈だから、512bitSIMD関連の部分が特大なのか

>>791
32nmプロセスはかなり前倒しされているから製造面では余裕っぽいが
デザインにどのくらいの時間がかかるのかとか
何時開発始めるのかわからないからねー

>>792
ベクターユニットはプロセッサコアの1/3程度らしい
黒い部分はL1キャッシュでは？

>>793
黒い部分が何かの確証があるわけではないのですまないけど・・・

黒い部分はL1なら32KBと言う事になる
その他にL2が512KB乗っているが、L1：L2＝32KB：512KB＝1：16
つまり、黒い部分がL1ならその他の部分全てがL2でもまだ収まらないよ

>>794
ごめん写真ちゃんと見ないでレスしてた
L2っぽいね

>>793
1コアにL2は512KBじゃなくて、256KBだけど。
あと、L1とL2では容量あたりつかっている面積が違うから、単純に比率で計算しても意味がない。
Nehalemのダイ写真でも見てみればいいよ。L2はL1と比べて容量ほど面積食ってないのわかるから。

レス間違えた。
>>794ね。

>>769-767
256KBですね。間違いました
まあ細かい部分はともかくとして、結果は同じかな

>>796
　　---------------
　　L1とL2では容量あたりつかっている面積が違う
　　---------------
読者のための参考として。
http://journal.mycom.co.jp/column/architecture/125/index.html
　　===============
　　奇妙に思われるかも知れないが、トランジスタより配線の方が面積を食い、一般に記憶セルの
　　サイズはトランジスタの数ではなく、水平と垂直の配線の本数でサイズが決まる。つまり、図3.6
　　の記憶セルではワード線が1本、ビット線が2本で面積は2単位であるが、図3.8のセルではワード
　　線が2本、ビット線が4 本で、面積は8単位に増加してしまう。
　　===============
記憶セルに同時読み書きが行えるようになっている(マルチポート構成)L1は配線のせいで
面積を喰うってことで。

TechReportの予想によるLarrabeeとGPUの性能比較。
http://www.techreport.com/discussions.x/16920
信頼度は参考程度ではありますが…

計算上のピーク性能なんだから（計算ミスぐらいは有るかも知れないが）信頼出来るんじゃない？
と言うか、比較対象のGT285とRD4890は65nm世代（55nm）で、Larrabeeは45（32?）nm世代な事を考えると
これでも少ない気がする

あと、Larrabeeは固定回路が少なくて、GPUよりも多くの行程を汎用回路で処理しなきゃいけなかったような・・・
この分も余計に処理能力を喰われそうだが、それでも性能出るのかな

汎用部分と固定部分のデータ交換のオーバーヘッドもあるから
かならずしもソフト処理が不利とは言えない

Lucilleの開発者（あくまでオフラインGIレンダラ）の受け売りだが。

http://software.intel.com/en-us/articles/intel-software-network-at-siggraph-2009/

とりあえずTwitterに追加したぞ、と

>>792
何かこう、対称だったりしないのな
1リング16コアとかあったけど、これをどう分けたら16個一組になるんだ？

8coreで1ブロックじゃないかね

クロック数による差別化はしにくいから有効コア数をかえてくると思うんだが

32,24,16,8

>>801
そんなことより、600mm2くらいのダイサイズなのに
メモリが256bitってのはどう考えればいいんだ

リングバスが飽和しちゃうんじゃね

ただメモリ帯域増やせばいいなんて馬鹿のすること

メモリ帯域いらんって言う割には多い印象が。

64bitで我慢しろ

GT300は512bitで256GB/sec確保するらしいね
ララビーダブルスコアで完敗ｗｗ

カタログスペックはお腹いっぱいです

CellのLSよろしく、各ｺｱ付属のL2内でｺｱ毎処理を完結させれば帯域消費は抑えられるって事なのかな

>>810-814
>>139-

GDDR5で512bitだとそれだけで100W食うのだが。

ねーよ

>>815
ぶっちゃけNotarinVIDIAのGPUのSRAMは、CUDAで割り当てられる最大数の16Warp程度まわせば
1ワープ当たり1〜2KB per Warp程度しかない。
ひたすらメモリ帯域増やさないと性能が出ない。
もう氏ねとしかいいようがない。

一度に捌くワークセットが少ない分、L2と言わずL1だけでも遙かにセーブできる

non-temporalってメンドくさいよね？

別に

そういうのってプログラマが意識するもんじゃなくね？

CtとかOpenCLからは意識する必要ないだろ

GT300（笑）は単純にSP数倍増だから帯域も倍にしないといけないだけ。
まあ実質GTX295がシングルダイになって毛が生えたようなもんだな
エレガントでもなんでもない。

まじで？
まぁ話半分できいとくわ

RV770のL2キャッシュ4MBみたいに、大量のメモリ積むんじゃね？

Larrabeeだって既存のGPUと比較してマシってだけでメモリの壁は厚いと思うけどねえ
TSVがあれば問題解決なんだろうか

汎用プログラム動かすのに1〜2KBとか致命的すぎるだろ
どこのセガサターンだよ

団子びびってるねｗ
GT300がLarrabeeをふるぼっこにする姿が目に浮かぶｗ

スタック再帰もできないクソプロセッサいらないです。

深さが有限でいいなら手動でスタック確保してwhileで再帰もどきはできるよ。CPUのコードもインライン展開とかの最適化始めるとそういう最適化も始めることになる。

ゲームで早ければどっちでもいいよ

OCamlを使えるようにしろ。話はそれからだ。
Larrabeeはコードが最初から揃ってる状態ってのは強みだな

リングバスとキャッシュという複雑な要因があるから、
実際にソフトを動かすまでは性能は分からないと思うな。
まあ、シェーダー世代のGPUとして見るなら、性能＝メモリ帯域と言ってもいいだろうけど。

言いたいことがよくわからんのだが、スタックのメモリをnewで取るってことならむしろ遅くなるだろ？

物理演算世代でしょ。
なんのためのPhysXやHavokだよ

あとあれ。オープンソースの物理エンジンがあったらいい。GNU主導で。

>>835
CUDAにヒープもスタックもないよ。決め打ちで配列を取る。再帰がそれより深くなったらプロセスが落ちてくれればいいな、みたいな。最悪ハングしてリブート。CRTが燃えたりしないから立派なもの。

NVは段々ビジネスパイプラインが狭まって逝くのぉ
チップセットも両プラットホームから洋ナシ宣告

IONがあるジャマイカ

あれこそPineview登場で年内に終わるでしょ。945GCを捌けたら用済みでは？
32nmに至っては単体版の予定すらなさそうだし

イオン推進エンジン作れ

>>837
組み込み屋さんはそういう感覚なのか…

アプリ屋こそ触るようなモンじゃないけどな

最終的に実用的なアプリで使われなきゃ意味無いだろ？
まあ、上手いことライブラリから使えるようにしてくれや。

抽象化なんて所詮誤魔化しだからな。
ハードの特性通りにしか動かない。

画像処理とかの技術が確立してる分野なら抽象化も上手くいくだろうけどね。

Larrabeeがx86の皮を被せてるのは色んな意味で潰しだな
移植できないアプリが事実上ない。

移植の問題もいい加減どうにかならんのかね？
やっぱりVMなんぞを使うのは団子的には我慢できないの？

嫌いではないが
それで性能出ないなら世話無いわ

CUDAはハードが透けて見えるのがいいところだろ。
Cの思想を受け継いでいる。

嫌な制限ばかりが透けて見えるがな。
肝心のネイティブ命令レベルのスループットなどの詳細情報は公開されず

いやな制限を綺麗に回避して、爆発的な性能が出たときの高揚感は異常。
CUDAプログラミングをパズルとして考えれば、ある程度制限あったほうがおもしろい。
パズルであることを受け入れたなら、CUDAに生産性を求めるのは筋違いであることがわかるだろう。

どっちの制限も、どっちのパズルも、どっちの生産性も似たり寄ったりだと思うけど、
パズルを解いて楽しもうという人の数がlarrabee>>cudaであることがx86の*唯一*の利点だと思うな。

パズルに普遍性があればやる気もでるが
流行歌のような寿命で役に立たなくなるかもしれず

解いて遊ぶのが目的のパズルとは違うから
難易度は低い方が良いに決まっている

パズル要素ならCellのほうがよっぽどやりがいあると思うけどね。
命令の仕様が全部見えてて、並べたとおりに動くんだぜ。

CUDA（笑）ってただのブラックボックスじゃん。
なにより、正確な資料出す気が無いのが気に入らん

>>856
RPGでいったら、３Dダンジョンを自動マッピングしてくれるか方眼紙で手動マッピングしなきゃいけないかの差って所かな？
たしかに方眼紙でマップ作る気力はもうないな。

おっと世界樹の迷宮の悪口はそこま（ｒｙ

たしかにあれ怠いわ。

GT300はなんだかとても威勢がいいうわさがとんでいるな。2.4TFLOPSとか。
さらに、Nvidiaがもし来年Q1の28nmプロセスへ速めに移っていけるなら、GT300 X2とかでも、
巨大チップで45nmのLarrabeeと同等の消費電力ぐらいになるんじゃないか。
そうしたら、ピーク性能は倍以上の差。
でも、Intelの32nmも順調だから、移行すればすぐ追いつける。

余談だが、PS3はピーク性能はxbox360の倍ある状態で世に出たが、実際に使われ始めると、xbox360の
方が使いやすくて、結果、実行性能はxbox360の方が上なんて状況が多々あった。

LarrabeeとGT300のピーク性能が、たとえ倍違っても、Larrabeeの方が性能でやすいとか、使いやすいなんてなれば、
ピーク性能なんかあんまり関係なくなることもあるかもね。まあ、逆に使いにくいとか性能でなくて、目も当てられない
なんてこともあるかもしれないけど。

ピーク性能：　
Larrabee < Nvidia GPU

コストパフォーマンス：　プロセスルールと歩留まり、これまでのディスクリートGPU市場での競争経験を考えると
Larrabee < Nvidia GPU ???

ゲームの実行性能：固定部分の割合、メモリバンド幅、ゲームごとのキャッシュ効率の違いがあることを考えると
Larrabee < Nvidia GPU ????

科学技術計算の実行性能：ローカルメモリの量、メモリバンド幅、開発環境を考えると
Larrabee > Nvidia GPU ?

HPC用に開発環境をどれだけ用意するのか、力を入れているのかがLarrabeeは未知だ。
Nvidiaは、いっても、株主からクレームが来るくらい、そっちへの投資はしている。
Larrbeeも、Ct用意したり、研究所つくったり、かなりやっているみたいではある。

ピーク性能：　
Larrabee < Nvidia GPU

コストパフォーマンス：　プロセスルールと歩留まり、これまでのディスクリートGPU市場での競争経験を考えると
Larrabee < Nvidia GPU ???

ゲームの実行性能：固定部分の割合、メモリバンド幅、ゲームごとのキャッシュ効率の違いがあることを考えると
Larrabee < Nvidia GPU ????

科学技術計算の実行性能：ローカルメモリの量、メモリバンド幅、開発環境を考えると
Larrabee > Nvidia GPU ?

HPC用に開発環境をどれだけ用意するのか、力を入れているのかがLarrabeeは未知だ。
Nvidiaは、いっても、株主からクレームが来るくらい、そっちへの投資はしている。
Larrbeeも、Ct用意したり、研究所つくったり、かなりやっているみたいではある。

いやLarrabeeはソフト屋にlibrary作ってもらうためのいわば公式ES品だから
性能はでないし、一般市場ではあまり売れないよ。