08/10/06 02:16:32 Gjt1lbWv
まあ、使ってないレジスタは退避しないという方針に基づいても、
汎用レジスタ16本とSIMDレジスタ16本、マスクレジスタ、EFLAGSにMXCSRなど
諸々は基本的に退避しないといけないな。
FP/MMレジスタの退避はまあ使わないなら必要なさそうだな、
関数コールとは違ってABIを規定できない筈だし（するのか？）
211:,,・´∀｀・,,）っ-○◎●
08/10/06 02:21:10 Gjt1lbWv
>>209
だから言ったとおりじゃん。
Larrabeeのコアはヘテロジニアスマルチコアにおける「IA++」と同じものだって。
ちなみにゲルたんがいってることは4年前に後藤自身が解説したこととなんら変わってない。
SSEと共存できないだとか、いや、共存できるだとか、後藤が一人で混乱してただけで
Intelは一貫してたわけだ。
212:MACオタ＞団子 さん
08/10/06 02:23:54 pdu9F3SC
>>210
なんとなく見積もりが違う気がするすけど。。。
-----------------
関数コールとは違ってABIを規定できない筈だし（するのか？）
-----------------
Larrabeeわ目的が異なるスレッド(orタスク)が併走する設計になっていないす。
(例えば4つのSMTわMMUを共有するため、スレッド間のメモリ空間の独立性の自由度わ低い)
演算リソースわユーザーコードで占有され、タスクのスケジューリングも自前で行うすから、
ABIも必須でないす。こういう点でもCELL SPEと各コアの使い方わ近いかと思われるす。
213:MACオタ＞団子 さん
08/10/06 02:26:36 pdu9F3SC
>>211
記事でわAVXが妙に無視され気味な訳すけど、その辺気にならないすか？
スケジュール通りなら、2010より数年間AVXとLNIが並立するというISAの分離が発生するすけど。。。
214:MACオタ＠訂正
08/10/06 02:28:47 pdu9F3SC
>>212で少し記述間違えたす。
誤: 4つのSMTわMMUを共有するため
正: 4つのSMTわTLBを共有するため
215:,,・´∀｀・,,）っ-○◎●
08/10/06 02:37:37 Gjt1lbWv
> つまり、256-bitと512-bitのずれは、時間軸上のずれに過ぎず、
> PC&サーバー向けCPUもいつかは追いつくことになる。
さて、問題あるかね？
LarrabeeでSSE/AVXをサポートしないとも言ってない。
特にAVXについては、LNIでVEXエンコーディングを用いる以上
デコードできてしかるべきだし、やれるんじゃないの？
まあ「絶対サポートする」と強弁する気はないが。
後藤はLNIがVEXエンコーディングって事実はまだ把握してないようだが
なんとなくは気づいてるような。「命令は固定長にするのが望ましい」とかな。
216:MACオタ＞団子 さん
08/10/06 02:49:18 pdu9F3SC
>>215
----------------
256-bitと512-bitのずれは、時間軸上のずれに過ぎず、
----------------
マーケティングトークわ別にして、Intelわ論文で「512-wideはグラフィック市場のための選択」と
公言しているす。
(Siggraph Larrabee論文より)
--------------------------
We chose a 16-wide VPU as a tradeoff between increased computational density and the
difficulty of obtaining high utilization for wider VPUs. Early analysis suggested 88%
utilization for typical pixel shader workloads if 16 lanes process 16 separate pixels one
component at a time, that is, with separate instructions to process red, green, etc., for 16
pixels at a time, instead of processing multiple color channels at once.
--------------------------
217:,,・´∀｀・,,）っ-○◎●
08/10/06 03:10:51 Gjt1lbWv
3byte版のVEXのm-mmmmフィールドは5ビット（32種類）あって
SSE*の再定義とAVXの新命令のために3つ（0F, 0F38, 0F3Aのエイリアス）
使ってるが、あと29個も残っている。
こいつとVEX.Lフィールドとの組み合わせで、いくらでも命令を定義できる。
将来的にISAの均質化を目標としているのならAVXまでのSIMD命令も
Larrabee（IA++）側でサポートしないといけない。
もちろん、統合までにやる話であって、最初の世代ではすべてやる必要も無いんだが
じゃあ、最初の実装のLarrabeeで128bit/256bitのSIMDをサポートしないとして
その理由は何よ？
積和算にしろシャッフルにしろ、全部Larrabeeにインプリメントされた機能で実装できそうだ。
専用ハードがないならないでマイクロコード実装でもいいんだけどな。
SSEが64bit SIMD
Sandy Bridgeでも256bit AVXは内部的に128bit命令を2個実行するだけの実装にとどまってる。
まあ、あれはAVXを実装したCPUですら無条件でサポートされるものではないことは
マニュアルにて示唆されてるが。
SSE4.1を無効にしたWolfdaleコアがあるように、マーケティング上の理由で
ローエンドCPUでは無効にするとかそういう類のものになりそうだが
218:,,・´∀｀・,,）っ-○◎●
08/10/06 03:13:22 Gjt1lbWv
後半書き直し
最初のPentium IIIからPentium 4においてSSEが64bit SIMD×2で実装されてたように
Sandy Bridgeでも256bit AVXは内部的に128bit命令を2個実行するだけの実装にとどまってる。
LNIでもAESくらいならサポートしない理由はある。テーブルが複雑だし。
まあ、あれはAVXを実装したCPUですら無条件でサポートされるものではないことは
マニュアルにて示唆されてるが。
汎用CPUではSSE4.1を無効にしたWolfdaleコアがあるように、マーケティング上の理由で
ローエンドCPUでは無効にするとかそういう類のものになりそうだが
219:MACオタ＞団子 さん
08/10/06 03:53:53 pdu9F3SC
>>218
-------------------
Sandy Bridgeでも256bit AVXは内部的に128bit命令を2個実行するだけの実装にとどまってる。
-------------------
また根拠の無い話を(笑)
反証にわソースがあって、"Terra Terra Terra"プレゼンでわ、Gesher (Sandy Bridge)のコアあたり
のDP Flops/cycle/core=7とあるす。8の誤植かどうかわ別にして、「サイクルあたり4-wide x 2 (積和)」
じゃないと到達できない数字す。
220:,,・´∀｀・,,）っ-○◎●
08/10/06 03:58:29 Gjt1lbWv
古い記事見たら、LarrabeeにVEX使うことは後藤は既に気づいてた。
URLﾘﾝｸ(pc.watch.impress.co.jp)
> また、512bitsや1,024bitsといったベクタ長の拡張も容易になる。
> Intelが、2008年末から2009年にかけて投入する予定のメニイコアCPU「Larrabee(ララビー)」は、
> AVXの命令フォーマット拡張の上に乗っている可能性が高い。
> AVXには、今後、毎世代命令セットを大きく拡張して行く、Intelの戦略が根幹を伺うことができる。
あと、ここ注目。
> 「5バイトバージョンの2つ目のペイロードはフルではない。将来の拡張のために3ビットが残されている。
> 3bitsあれば、1,000以上の新命令を加えることができる。新しいフィーチャ、新しいレジスタ、
> 新しいベクタ長。ほとんどなんでも加えることができる」(Valentine氏)。
m-mmmmフィールドは5ビットあるのに「3ビット」とはなんぞや？
これが間違いではないとすれば、5ビット32通りの中に0F, 0F38, 0F3Aフィールドがあるのではなく、
3ビット＋2ビット（Reserved, 0F, 0F38, 0F3A）と考えてることになる。
それならそれで1000命令以上といったのはおかしいわけだが。
ちなみに後藤はここでも暗にVEX方式であるべきだと説いているようだ。
URLﾘﾝｸ(pc.watch.impress.co.jp)
> Intelは、Larrabee拡張命令のフォーマットの詳細については明らかにしてない。
> しかし、想定できる点がいくつかある。まず、命令フォーマットはデコードしやすいものでなければ
> ならない。x86命令のデコード時の複雑さの多くは、x86命令が可変長であることに起因している。
> この問題を軽減するためには、Larrabee拡張命令を、固定長にすることが望ましいと推定される。
この記事で
> MMX Pentium以降のMMX/SSE系の拡張命令は、サポートしないと推測される。
なんてトンデモなことを言った理由は、むしろVEXプリフィクスの合理性を主張したいからな気がした。
実際には、MMX/SSEが使ってきた2byte Opcode空間はMMX以前から使われてきたしLCP＋2byte Opcodeなんてのはザラ。
SSEの命令フォーマットがデコードできない理由にはならない。「遅い」ならまだわかる。
221:MACオタ
08/10/06 04:09:18 pdu9F3SC
余談すけど、今回の後藤記事の内容のヒドさに、私わ落胆したす。
かつて後藤氏わ、素朴な質問をぶつけて相手に詳しく語らせることで、自身の素養の無さにも
かかわらず良いインタビューをモノにしていたす。（ちなみに、逆のスタイルが本田雅一氏で、
話を聞くより自分の意見を売り込もうとしてるんじゃ無いかと思われるようなやり方す。)
ところが今回の記事、まるで自分の憶測の裏付けを必死でGelsinger氏に求めているとしか
思えないような代物す。これでわ記事自体、都合のいい言葉だけを引用しているような
バイアスがかかっている疑念すら出てくるす。
222:,,・´∀｀・,,）っ-○◎●
08/10/06 04:10:35 Gjt1lbWv
>>219
また妄想を
128ビットである理由は俺のサイトにも書いている通り
256bitに作用するシフト命令が無い時点でネイティブ256ビットはありえないんだよ。
7が誤植で実は8でしたという思い込みはできても
実は4でしたというほうへの思い込みはできないのはおめでたいとしか。
GesherはSandy Bridgeを特定して指すという前提がそもそもおかしい。
AVXをサポートするgmmintrin.hには、FMAのIntrinsicsも含まれている。
元のGesher New Instrunctions（GNI）はFMAまでのサポートを含んでいたことがわかっている
FMAをサポートする次の世代も含めてGesherだ
そして、7DPという数字については、128bit FMA＋ 128bit Dot-Productで7でも計算が合う。
ばかだなぁFUCKヲタは。
223:MACオタ＞団子 さん
08/10/06 04:16:33 pdu9F3SC
>>222
何度か書いているすけど、
-------------------
俺のサイトにも書いている通り
-------------------
議論の相手や聴衆が、自分と同じ情報を持っているという思い込みわ、勘弁して欲しいす。
それわそれとして、
-------------------
128bit FMA＋ 128bit Dot-Productで7でも計算が合う。
-------------------
内積のような高級命令ってシングルサイクル・スループットなんすか？
224:,,・´∀｀・,,）っ-○◎●
08/10/06 04:37:03 Gjt1lbWv
IntelコンパイラのSSE組み込み関数のヘッダファイルはCPUの開発コード名を冠してる
SSE3 pmmintrin.h (Prescott)
SSSE3 tmmintrin.h (Tejas)
SSE4.1 smmintrin.h (Swing)
SSE4.2 nmmintrin.h (Nehalem)
AES/CLMUL wmmintrin.h (Westmere)
AVX/FMA gmmintrin.h (Gesher)
Tejas/SwingはNetBurstがロードマップに存在した時代の死んだコードネームです。
Gesherも死んでSandy Bridge/IvyBridgeは後釜なんじゃないの？
Intelが開発コードを変えるのは気分じゃなくて何かしらアーキテクチャ定義に
変更があったからではないかな？
事実、GesherではFMAまでをサポートする予定でgmmintrin.hが定義されたのに
Sandy Bridge・Ivy Bridgeあるいはその次の世代という段階的なサポートになってしまってる。
> 内積のような高級命令ってシングルサイクル・スループットなんすか？
おまえはドリームキャストを馬鹿にしたな
もとい、水平加算を伴う命令は将来シングルサイクルスループットでできるようにすることは
開発者向けには前々から公約にしてたよ。
「Gesher」というコードネームが消えた今となっては真相は誰も知らないわな。
つーか、あの資料の該当ページを抹消したのにも何かしらロードマップ上の理由があったと思ってるが。
225:MACオタ＞団子 さん
08/10/06 04:53:48 pdu9F3SC
>>224
-----------------
Gesherも死んでSandy Bridge/IvyBridgeは後釜なんじゃないの？
-----------------
思い込みに合わせて現実を改変するのも勘弁して欲しいす。一応風数ソースで。
URLﾘﾝｸ(pc.watch.impress.co.jp)
=================
Sandy Bridgeは、もともとはヘブライ語のコードネーム「Gesher(ゲッシャ)」で呼ばれていた。
GesherからSandy Bridgeへと変わったのは、技術的な内容の変化があったからではなく、
名称だけだという。
=================
URLﾘﾝｸ(www.atmarkit.co.jp)
=================
32nmプロセスの2世代目（新しいマイクロアーキテクチャを採用）の開発コード名が従来の
Gesher（ゲッシャー）からSandy Bridge（サンディ・ブリッジ）に変更されたが、こうしたコード名の
変更は「靴下を替えるように、頻繁にあること」だという。
=================
もう少し詳しい理由わ、こちら。
URLﾘﾝｸ(www.theregister.co.uk)
=================
Gesher - 'bridge' in Hebrew - is also the name of an Israeli political party.
We wondered how long Intel would stick near the semi-charged name and have now learned
the answer -- about seven months.
=================
226:,,・´∀｀・,,）っ-○◎●
08/10/06 05:03:54 Gjt1lbWv
で、7は誤植で8だという根拠は？
7は誤植だという一方で8が真実だというのはずいぶん都合がいい考え方だなぁ
4GHzで28GFLOPSとも書いてあったぞ。
227:,,・´∀｀・,,）っ-○◎●
08/10/06 05:05:55 Gjt1lbWv
URLﾘﾝｸ(xtreview.com) /images/davis.pdf
これだろ？
先に出るLarrabeeのベクトル長が8か16かも曖昧な資料が根拠になにを妄想してるのかなFUCKくんは
228:,,・´∀｀・,,）っ-○◎●
08/10/06 05:09:15 Gjt1lbWv
FMAがSandy Bridgeで実装されないことそのものがロードマップの修正だと思わんかね？
Intelの*mmintrin.hでサポートされる組み込み関数の使える命令がCPU世代をまたがったことは一度も無い。
229:,,・´∀｀・,,）っ-○◎●
08/10/06 05:30:14 Gjt1lbWv
Sandy Bridge世代ではいまだに内部128bitである根拠
◎AVXではメモリアドレッシングで指定されたソースに対しミスアラインロードを許容するが、
SIMDユニットがネイティブで256ビットをサポートするとすれば、アラインメント補正処理を
ユーザーに開放したvpalignrの256bit版がないのはおかしい。
シフト・ローテート処理が128ビットのままでは、スループット的にアンバランスが生じる。
◎256bit化の対象となってる浮動小数演算は、SIMD演算ユニットが内部128bitのまま256ビット版を使う
・命令レイテンシ隠蔽のため引き伸ばすだけでも実効性能は伸ばせる。
・SandyBridge世代においてもなお16バイト/clkまでしかないらしい命令フェッチ帯域の節約になる。
まあ俺はどっちでもいいよ。
内部256bitといい続けることで恥をかくのはお前だけだから。
230:MACオタ＞団子 さん
08/10/06 05:49:29 pdu9F3SC
>>229
前者わ興味深い指摘だと思うす。今後わ、最初にこういう論拠を示してから自説を展開するように
お勧めしたいモノす。
後者に関してわ、何度も現実に裏切られているのでわ？
231:MACオタ＠補足
08/10/06 05:55:43 pdu9F3SC
>>227
少しだけ補足す。
-----------------
先に出るLarrabeeのベクトル長が8か16かも曖昧な資料
-----------------
"Terra Terra Terra"のp.16のブロック図に"SIMD-16"とあることから、この時点で16(512-bit)-wideわ
確定していたことが判るす。従ってDP flopsの未確定部分わ、この時点で積和命令を実装するか
否かが確定していなかったことを示すす。
232:,,・´∀｀・,,）っ-○◎●
08/10/06 07:11:08 Gjt1lbWv
じゃあ、palignr の256bit版が存在しないのを「誤植」だとでも思っておきなよ。
VEX.L=1にすると未定義例外が出るってハッキリ書いてあるんだがな。
たとえばAltiVecｔのvpermが先頭64ビットまでしか作用しなかったらきっと
理不尽だと思うだろうけどそれと似たようなもんだよ。
233:,,・´∀｀・,,）っ-○◎●
08/10/06 07:14:21 Gjt1lbWv
全部誤植でAVXのベクタ長は1024ビットかもしれないよ
極論言うとMACヲタの妄想はそういうことだ
234:Socket774
08/10/06 07:21:47 +Gr7A0as
実物が無い以上
全部妄想です
235:Socket774
08/10/06 07:28:18 kNki4HP2
xmmレジスタが登場してから演算器が128ビットになるまでを考えると128*2の可能性は大きいな。
同業者の状況を見るに、急いで新昨日で巻き返さないといけないなんて状態でもないし。
236:Socket774
08/10/06 09:32:50 xPkVE/H5
7DPで28GFLOP資料が間違ってるという一方でそれを根拠に
237:Socket774
08/10/06 09:59:29 xPkVE/H5
7DPで28GFLOPS＠4GHzという資料が数字が間違ってるという一方で
それが根拠にネイティブ256bitだというのは苦しいわな。
256bitでない根拠にならなりうるが。
間違ってると言った数字を根拠にする理屈はありえない。
ちなみに積和＋内積で7DPを満たせるってのはム板でも議論されてた。
64bit SIMDではあるがK7ではE3DNow!によって内積をスループット1クロックで行えていた。
別に困難でもないんじゃないの？パイプライン段数増えていいなら。
238:,,・´∀｀・,,）っ-○◎●
08/10/06 11:07:36 Gjt1lbWv
URLﾘﾝｸ(software.intel.com)
もう既に。中の人に近いところではAVXのパフォーマンスについて議論がなされてるよ。
AVX-256での行列積のスループットはSSE2の1.4～1.6倍程度だそうだ。
ざっと概算しても新命令のvpermil2psの効果分＋3オペランド数増加分程度の
スループット向上しか得られてない。
これは内部128ビットのままである証拠にならないかな？
MACヲタも無根拠な256ビット幻想なんて捨てて
Intel謹製のパイプラインシミュレータでスループットの検証してみれば？
239:,,・´∀｀・,,）っ-○◎●
08/10/06 12:04:19 Gjt1lbWv
むしろSandyBridgeって乗算命令って2ポートで発行できるようになってないか？
FMA＋DotProductで7DPを実現するスタイルだと、乗算だけに限っては既存のCore 2ファミリの
2つの浮動小数ユニットのどちらでも2DP/4SPの乗算が可能になる。
まあ、加減算とは排他になるが。
240:,,・´∀｀・,,）っ-○◎●
08/10/06 12:20:40 Gjt1lbWv
でだ
FMUL/FADDとある２つの演算機の両方に乗算・加減算を実装してどちらでも加算・乗算を発行できる
ような形にすれば、既存のSSEコードでも若干性能向上が期待できる。
それに、新命令のFMAのパフォーマンスという観点でも1つの実行ポートに両方の演算ユニットが
ぶら下がってるほうが性能を出しやすい。
256bitでのパフォーマンスが伸びてないというより、レガシーを含めた128bit SIMDでの
パフォーマンスを若干ながらも伸ばすアプローチを採るのはそれなりに意味はある。
いじょ。
フォローしておくと256bit SIMDでも相当速いよ。シミュレーションの通りなら
今のCore 2と比べてざっと2倍ってのは嘘じゃない。
単に256bitじゃないと恩恵が無い実装にはしなかっただけでしょ。
241:Socket774
08/10/06 21:20:32 ooDOnZoT
とりあえず、この手の話で
団子 >>> MACオタ
なのはよくわかった。
今日の団子はいつもよりかなりまともな理屈をならべているな。
242:Socket774
08/10/06 21:30:52 ooDOnZoT
つーか、団子は正直、拡張命令ネタだけでいい。他はいらん。
243:Socket774
08/10/06 21:56:38 ooDOnZoT
対戦成績表'08
ﾅﾏｴ 10/6
---------------------------------------------------------------------
団子 ○
オタ ●
10/6 AVXの実装など
244:,,・´∀｀・,,）っ-○◎●
08/10/07 01:05:22 Aeh0Wlge
MACヲタとかってさ
まさかとは思うんだけど
AVXの128bit SIMDを使うと、256ビットの上位128bitも毎回ゼロクリアしないといけないから
256ビットでないといけないとか
思ってないよな？
まあ俺も最初はそう思ったよ。
でも、よくよく考えたらさ
むしろ、YMM下位(XMM)のみの演算ではYMM上位が常に0と決まってるからこそ、
上位のゼロクリア処理をサボって256bit未満の幅のSIMDユニットでも効率的に処理できるわけだよね。
fxchやxorゼロクリアでレジスタリネーミングのヒントとして解釈するのと同じで。
AVXのマニュアルには、レガシーSSEを使うと、YMMの上位をゼロクリアせずそのまま残すから偽の依存関係が発生するとある。
逆に言うと、AVX-128を使ってるときはYMM上位の依存関係が常に解消されてるってことなんだよね。
そりゃそうだ、結果が常に0なんだから。
その値をソースにとるAVX-256の命令あるいはレジスタ退避命令に遭遇するまで、実際にゼロクリアをする必要すらない。
で、レガシーSSEをなんでYMMの上位をゼロクリアしない仕様としたのかって、
そりゃおそらく、AVX-256との併用時に依存関係を故意に発生させて、性能出なくするためだよ。たぶん。
まさに飴(AVX)と鞭(SSEと同時利用することに対するペナルティ)。
そうまでしても、プリフィックスが付き捲って複雑怪奇な命令フォーマットとなってしまったSSEを整理したい。
245:Socket774
08/10/07 07:06:44 z3zv0nRE
larrabeeってDX11世代のGPUやOpenCLで使った場合のGPUに対して
余程のパフォーマンス的アドバンテージが無い限り
結局ニッチな仕様のGPUで終わるんじゃないのかい？
246:Socket774
08/10/07 08:10:27 RBYU5KK8
ところがCPUに内蔵されるようになる予定だから話はちょっとこじれる。
247:Socket774
08/10/07 11:59:50 ikSGh2Nd
それはAMDがやろうとしてる事と
何が違うの
248:Socket774
08/10/07 12:07:47 AXOmBY8z
どうせCPUに内蔵されるから、単体カードとしてのLarrabeeはぼろぼろでも、
CPUに内蔵されたら、今と同じでシェアだけは高い可能性があるってことじゃね？
249:Socket774
08/10/07 12:28:34 Jbkrm287
マリオと抱き合わせでクソゲーを買わされたトラウマが…
250:Socket774
08/10/07 12:34:13 z395BKc1
>>247
ポイントは全部x86。
同じ命令セットで汎用スカラ処理が得意な大きなコアとSIMDだけは得意な特化型コアが並立する。
で、ワークロードに応じて最適なコアを選んで実行するようになる。
AMDのやろうとしてることの最終構想はCPUのSSE命令をGPUでやること。
現実にはGPUの大量の演算ユニットだけあってもSSE命令の供給が間に合わなければ意味がない。
CPU内蔵のFPUすら、持て余してる時間が多い。
フロントエンドやスケジューラにどれだけトランジスタつぎ込んでるか考えれば
AMDがやろうとしてることがいかに無謀で馬鹿げてるかは。
251:Socket774
08/10/07 13:05:15 ikSGh2Nd
適切なコアの判断は何処でやるの？
252:Socket774
08/10/07 14:10:41 Qxng3wLy
並列計算プログラミングを勉強している者ですが、質問があります。
Dual CoreとQuad CoreのCPUを用いてバックトラッキングの速度計算をやっているのですが、
実際のマルチコア対応演算プログラム（例えば、将棋や囲碁など）だと、
Dual CoreとQuad CoreはSingle Coreの物と比べてどのような処理をやっているのでしょうか？
253:Socket774
08/10/07 22:47:24 z395BKc1
>>251
OSのカーネルじゃね？
XP/VistaのカーネルはRDPMCでプロファイルとってコンテクストの割り当てを最適化する
機構を既に備えている。
現状、SMTで論理プロセッサが複数あるCPUで、同一物理CPUかを判定したり、
メモリ階層を考慮した最適化くらいはOS側でやってくれる。
IntelとMSは共同でメニーコアの研究やってるからなんらかの解決策は出してくるでしょ
254:Socket774
08/10/07 23:16:45 lzSJaurJ
ララビーのコア1個1個はOSから
それぞれCPUとして認識されるっての？
255:Socket774
08/10/07 23:33:09 z395BKc1
GPUではなくずっと先の話だ。
256:,,・´∀｀・,,）っ-○◎●
08/10/08 01:57:04 0Yot2dF8
>>252
「バックトラッキング」って言葉の意味がわかってるなら話は単純だが
複数のコアあるなら、その分だけスレッド起こして各枝の探索に割り当てていけばよくね？
257:MACオタ
08/10/08 07:46:16 Iaqsra3B
IBMがDunnington対抗でPOWER6搭載サーバーのミドル～ローレンジで搭載コア数を2倍にしたす。
単純にソケット数を2倍にした模様。
URLﾘﾝｸ(www-03.ibm.com)
-------------------
As the world's most popular midrange server, the IBM Power 570, now offers more energy
efficiency and consolidation options with new processor cards that double the number of
cores in the same system footprint.
-------------------
過去の情報でわ
「POWER6+でコア倍増(MCM?)」ｽﾚﾘﾝｸ(jisaku板:850番)
「実わ実装密度倍増？」ｽﾚﾘﾝｸ(jisaku板:45番)
ときて、結局POWER6でソケット数倍増という形で実現しているす。POWER6+って順調に遅延しているか、
Dunnington対抗で、製品投入を急いだという感があるす。
ただし、ミドルレンジのPOWER570にもハイエンドと同じPOWER6/5GHzを投入しているすから、搭載
チップ数倍増と合わせて、POWER6自体の歩留まりわ上がっていそうす。POWER6+登場前の在庫
整理の可能性もあるので、POWER6+がいつ登場する(or しない)かわ、注目す。
258:レトリック君
08/10/11 00:01:35 pJwx8BrO
>>252
枝分岐する探索をthreadに割り当てとかじゃね？
憶測だがｗ
259:レトリック君
08/10/11 00:05:06 ndohKGFa
>>250
> で、ワークロードに応じて最適なコアを選んで実行するようになる。
dynamic loadbalancing?
そんなとろいことやってたらﾒﾆｺｱではscalabilityﾎﾞﾛﾎﾞﾛのキｶﾞｽ
これも憶測だがｗ
ねむー仕事でくたくただの介。モヤ済みﾉｼ
260:MACオタ
08/10/14 04:00:26 OQHMmdpk
>>257の続報すけど、IBMサイトのPower 560 Expressの価格ページで、搭載プロセッサが
"POWER6+"と記されていることが話題になっているす。
URLﾘﾝｸ(www-03.ibm.com)
当初予定されていた45nmプロセス製造のPOWER6+によるコア数倍増のロードマップがズレて、
POWER6のままでのコア数倍増製品の投入至ったという推測を裏付けているかと思われるす。
なお、ITJungleのTimothy Prickett Morgan記者がIBMに問い合わせて、実際にわPOWER6の
ままであることを確認したとのことす。
URLﾘﾝｸ(www.itjungle.com)
--------------------
I checked with my sources at IBM, and the Power 560 is not based on the Power6+, but rather
the existing Power6 chip, which is implemented in 65 nanometer processes.
--------------------
IBMサイトのページわ、今後訂正されるかもしれないすけど、当該記事にわスクリーンショットが
掲載されているす。
261:MACオタ
08/10/14 04:05:30 OQHMmdpk
TechNewsWorldのRoss Mauri (IBM, Power System事業部長)インタビューより、POWER8の仕様
策定が開始されたという話題す。
URLﾘﾝｸ(www.technewsworld.com)
--------------------
"We are working on Power7 and next week I have a meeting to hear about research on
Power8," Mauri said. "We're not slowing down."
--------------------
262:MACオタ
08/10/14 05:23:17 OQHMmdpk
NCSAが建設するPOWER7を採用したスーパーコンピュータ"Blue Waters"の水冷技術に
関する記事す。
URLﾘﾝｸ(www.techworld.jp)
---------------------
NCSAの代理ディレクター、ロブ・ペニントン（Rob Pennington）氏によれば、水冷方式の大きな
アドバンテージは「CPUの高密度実装を可能にすること」であるという。同氏らは、開発中の
コンピュータを設置するために、現在NCSAで稼働しているスーパーコンピュータの2倍分の
施設を確保している。だが、現行コンピュータのコア数が9,600 基であることを考えれば、同
プロジェクトにおいて高密度化がいかに重要な課題であるかがわかる。
「水冷方式だからこそ、CPUコアの高密度実装が可能になった。もし、空冷方式でサーバを
冷却しようとしていたら、フロア内の空気の流れを確保するために、さまざまな制約が課される
ことになっただろう」（Pennington氏）
---------------------
前スレに書いたPOWER7に関する情報も参考に。
ｽﾚﾘﾝｸ(jisaku板:950番)
=====================
開発グループが異なるとわ言え、POWER6で電力効率向上のために一旦あきらめたOoOEを
再投入する 技術的裏付けわ謎す。冷却に関してわ水冷技術で先行しているために問題わ
無さそうす。
=====================
263:Socket774
08/10/16 23:08:49 AOjFjrQU
>>254
それは無いと思われ。
URLﾘﾝｸ(softwarecommunity.intel.com)
論文によればLarrabee上で実行されるプログラムは、
専用コンパイラで生成されなければならないと書かれてるし。
それにシステムコールもLarrabee側では実行されず、
CPU側で動作してるコードに一旦コールバックして実行されるらしい。
(つまり、OSはLarrabee上で動作していない)
既存のアプリを再コンパイルなしで実行出来ないなら別にx86互換でなくてもねぇ。
264:レトリック君
08/10/17 01:49:41 TAQlmPyn
ｺﾝﾊﾟｲﾗが作り(流用し)やすいのは、一つの大きなﾒﾘｯﾄだろ。
すぐできる。が、しかし…
265:,,・´∀｀・,,）っ-○◎●
08/10/17 02:22:31 Q2jCyvxh
nVIDIAが「ハイエンドクアッドコアよりデュアルコアにSLIなGPUのほうがエンコ速いよ」
って挑発してる状態だからね。
あくまで継続的に高付加価値のCPUを売っていきたいIntelには、GPUを牽制するのもやっぱり
x86である必然性が出てくる。
・将来のSIMD拡張LNIの先行実装
・トランジスタあたりのスカラ性能もそれなりには出る
・x86最強ｗｗｗｗｗ
つーか実際問題ハイエンドを欲するのはエンコとかゲームとかなわけで、
大量のSIMD演算をこなせるエンジンが必要になる。
CPU側のサブコアではなく敢えてディスクリートGPUとしてのモデルを採ったのは
いろいろな実験を兼ねてるんだと思われ。
というか、CPU側にはまだ汎用コアを詰め込んだ方が良いと判断したんだろう。
266:Socket774
08/10/17 17:40:12 J9fBLUft
むしろx86スカラコアがおまけで主力はSIMDエンジン
267:Socket774
08/10/17 20:02:23 WL69sFTm
んでそいつらのためのGDDR3
ディスクリートしか道が無い
268:,,・´∀｀・,,）っ
08/10/17 23:29:41 pmXEC0Ia
LeadtekのSpursEngine搭載アクセラレータボードは3万だってな
VGA機能のないSIMDアクセラレータですらこの価格だから
VGA機能を兼ねるLarrabeeでもそれなりの値段はしそうだな。
269:Socket774
08/10/18 00:02:12 98LL/FGc
それはどれだけの普及を見込んでるかによるのでは？
270:,,・´∀｀・,,）っ-○◎●
08/10/18 00:41:06 3i9EJ3i8
SpursEngineはチップの単価が1万円程度だからなぁ。
ハイエンドSIMDアクセラレータになるか、ローエンドGPU扱いされるかは
ソフト次第だと思うよ。
その点においてIntelはしっかりしてると思ってる
少なくともCellみたいに当のSCE自社すらまともなライブラリ作れないような企業より。
271:レトリック君
08/10/18 01:49:03 PCcfdfg/
Larrabee、試しに買って、お家でもﾌﾟﾁHPCしてみるか、どうするか…
Cellだとｱﾌﾟﾘが完成するまで203高地・死体累類状態を数年続けた後、
ｱﾌﾟﾘが完成して日の目を見る前にﾌｪｰﾄﾞｱｳﾄされちまいそうで
迷わずｽﾙｰしたけれども。
272:MACオタ
08/10/18 15:32:06 8sSawSax
S3もGPGPUに参入したす。
URLﾘﾝｸ(www.s3graphics.com)
URLﾘﾝｸ(drivers.s3graphics.com)
273:MACオタ
08/10/18 16:53:08 8sSawSax
IBMの2008Q3会計報告も出ているす。
URLﾘﾝｸ(www-03.ibm.com)
URLﾘﾝｸ(www.itjungle.com)
ハードウェア部門に関してわ、前年同期比10%減の$4.4Bとのことす。
- z (メインフレーム): 台数ベースで+49%の大幅増加。売上ベースでも+25%
- p (Unix/Linux): 売上+7% (Power Systems統合後のi-Seriesも含む)
- i (AS/400): 売上-85%
- Microelectronics (半導体): -27%
POWER6搭載製品わ、まあまあ好調に見えるす。
ゲーム機用プロセッサの受託設計で大儲けして以来、Microelectronicsの売上わ低下する一方す。
そのうち研究施設だけ残して工場わ売り払われるかもしれないすね。。。
274:MACオタ
08/10/18 17:11:38 8sSawSax
TheINQのCharlie "Groo" Demerjianが最近RWT掲示板に出没しているすけど、彼の書き込みから
興味深い話題をいくつか。
「xbox3 Larrabee採用説」
URLﾘﾝｸ(www.realworldtech.com)
-----------------------------
Last up, MS is likely to use the API that keeps Larrabee in a box the most.
-----------------------------
「Nvidia身売り説」
URLﾘﾝｸ(www.realworldtech.com)
-----------------------------
My bet is that they won't be an independent company at this time next year.
-----------------------------
「Nvidia/VIA交渉」
URLﾘﾝｸ(www.realworldtech.com)
-----------------------------
It was tried. If you know anything about Jen-Hsun and Wen-Chi, the two together in the
same room has all the makings for someone getting stabbed in the eye with the spork
that came with lunch.
Needless to say, no deal was done, and comedy did ensue.
-----------------------------
「既にクロスライセンス締結済みの企業(intelとか。。。)わ無い？」
URLﾘﾝｸ(www.realworldtech.com)
-----------------------------
Anyone who would be in line to buy them has likely already cross-licensed everything they
have, so patents would not likely be an issue.
People will be bled off as the writing becomes quite apparent on the wall. Intel is already
picking them pretty clean, so what will be left?
A good analogy is Transmeta. Lots of bright people, lots of interesting tech, no one bought
them. Why? Same real reasons.
-----------------------------
275:Socket774
08/10/18 21:26:40 /HoQ2eKv
>>272
Core2Duo E8400 3.0GHzと430GTでは約2.3倍の差がつきます
もっともCPUはシングルしか使われませんが
ちなみに119枚の2048*1536のjpgを処理した場合
E8400 3.0GHz : 215.744s
同CPU+430GT : 95.398s
------------------------------------
Turion64 1.8GHz : 9.474m(568.44s)
同CPU+440GTX : 179.594s
同様にS3からエンコーダでも提供されれば
VIAプラットフォームにとって強い味方になりそうですね
276:,,・´∀｀・,,）っ
08/10/18 22:37:44 zYJcwEab
>>275
＞ E8400 3.0GHz : 215.744s
＞ 同CPU+430GT : 95.398s
＞ Turion64 1.8GHz : 9.474m(568.44s)＞ 同CPU+440GTX : 179.594s
やっぱ同じGPUでもプラットフォームで差がつくんだな。
GPUでできない仕事をCPUにオフロードしてるから当然といえば当然だが。
ということは、よりCPU側に投げる仕事を減らしたのがGPGPU市場を制しうる。
Larrabeeの勝因はここにあるかもな。
もっとも固定機能部分が遊んでたら意味Nothingだが
277:Socket774
08/10/18 23:15:28 u6Y7ZtAB
> Larrabeeの勝因はここにあるかもな。
もう勝ったことになってるよｗ
278:Socket774
08/10/18 23:21:44 ytSBAqMG
>>264
既存のコンパイラをある程度流用出来るのは分かるけど、
Larrabee側でシステムコール呼んだらCPU側で実行されるってどうやるんだろ?
システムコールの引数がポインタだと、
①Larrabee側のコードもCPU側のコードも同じメモリ空間を共有するか
②システムコールごとに決まったサイズ(たいていは構造体)のデータをコピーするかしないと...
①だと変数にアクセスする度にPCIバス通して通信するわけだし
②だとWin32での実装が大変そうだ。
279:,,・´∀｀・,,）っ-○◎●
08/10/18 23:24:17 3i9EJ3i8
公称1TFLOPSとかあるのに、GPGPUとして使ってみるとCPUの良くて数倍程度の性能しか
出せてないのは、実効性能が低いからでは？
キャッシュが小さかったり、演算の小回りが利かなかったり。
280:,,・´∀｀・,,）っ-○◎●
08/10/18 23:26:28 3i9EJ3i8
>>278
> Larrabee側でシステムコール呼んだらCPU側で実行されるってどうやるんだろ?
っていうかシステムコールをホスト側で処理する必要あるんだっけ？
Larrabee側にもOSを持っててPC上のOSとはメモリ空間は独立なのに
281:Socket774
08/10/19 02:57:01 +w69zuzc
URLﾘﾝｸ(fah-web.stanford.edu)
さて、何倍でしょう。
282:レトリック君
08/10/19 03:05:40 bSIbs2Cr
>>278
やり方は色々考えられるだろうけれども、
実際にIntelがどうするについては参考文献を読んでから書来たいところ。
読んでいる時間あればだけれども…orz。
パット思いつきで書けばthrouputneckが懸念されるのはread/write システムコールだけ。
でもさ、並列化のセオリーで言えばIOって思いっきりcriticalなんだよねｗ
>>279
数コア程度のCPUの性能分析と同列に考えない方が良いよ。
283:,,・´∀｀・,,）っ-○◎●
08/10/19 03:07:58 cnb0JIoy
モデルの大きさが違うんじゃなかったっけ？
キャッシュ（Cellの場合LS)の容量に合わせた小さいモデルを選択してるだけで
それをもって性能比較とするのはどうかなと
だって、PCと同じ大きさのモデルをシミュレーションするのは
性能以前に「無理」なんだろ？
284:Socket774
08/10/19 07:03:49 pCG8Muu0
モデルの大きさはCPU>CELL>GPUということだけど、定量的な情報が無い。
クライアントがバージョンアップするたび扱えるモデルも大きくなっているとも言ってる。
285:Socket774
08/10/19 08:11:33 r0tXXKIM
今のcore2duo2GHzと母板のその他機能がワンチップで省電力になるのはいつごろだい？
286:Socket774
08/10/19 15:28:58 2HT/SDCh
5年後位のCPUのハイエンドって今のよりどれ位性能アップしてるの？
287:Socket774
08/10/19 19:03:02 vfzJSlhJ
>>280
論文の6.1節
"Two current limitations are
that application system call porting is not supported and the
current driver architecture requires application recompilation."
それから
"Additionally, execution of some
C/C++ standard library functions called from Larrabee application
binaries must be shared with the host operating system.
Specifically file I/O functions such as read/write/open/close, etc.,
are proxied from the Larrabee application binary back to a service
that executes such functions remotely on the host OS."
とのことなので気になってます。
>>282
read/writeもそうだし、スレッド間の協調のためのAPIもホスト側で実行するなら...
この論文には詳しい実装手法は載ってませんでした。
他に論文orドキュメント知ってたら教えてくらはい。
288:,,・´∀｀・,,）っ-○◎●
08/10/19 19:05:01 cnb0JIoy
来年のICC11にひょっとしたらLarrabee開発ツールも載っかるかもしれないのでそれまで待ちましょう
289:Socket774
08/10/20 07:24:09 prDv+JC8
>>275に新たにE8400+440GTXを加えて
E8400 3.0GHz : 215.744s
同CPU+430GT : 95.398s
同CPU+440GTX : 88.941s
Load->処理->saveのうちLoad,Saveはどの結果でも同じと仮定し
処理のみの時間を出してみると
x+y=88.941sec
x+1.139y=95.398sec
x+c=215.744sec
x:laod+save時間 y:440gtxの処理時間 z:cpuの処理時間 1.139=1025/900(440SP/430SP)
x=42.488sec
y=46.453sec
z=173.256sec
となり
GPUとCPUでは約3.7倍となる
CPUはシングルスレッドで12gflops、440は65.6gflops
GPUの実行性能としては、マズマズかと
実行中はこんな感じ
URLﾘﾝｸ(www.nicovideo.jp)
290:レトリック君
08/10/20 22:50:05 c6B+e61k
>>287
残念ながら詳しい文献は持っていないよ。関係者のﾌﾞﾛｸﾞ
Intel Graphics Jobs - Graphics - The Computer Science Agora
URLﾘﾝｸ(i2cs.cs.uiuc.edu)
の近くにある8月19日のslide
architecture reading group slides -- 19 aug 2008.key
URLﾘﾝｸ(i2cs.cs.uiuc.edu)
の11枚目辺りを見てもIOに関しては
. GPU variant: stdlib I/O proxied by host processor
としか触れられていない。これは多分PCIExpress add-in card形態のものの場合だと思うけど、
PCIｶｰﾄﾞ内のLarabbeeからNorthやSouthにぶら下がったI/Oを(Host CPUと調停しながら)
アクセスする手段は(第三世代になっても)無い？(←知らぬ)か何かにより、Open MP compilerで
compile&linkしたexecutableのhost CPU用binary側にI/Oを代理実行して賄ってもらうん
じゃないかとそれをproxyと書いているんｼﾞｬﾏｲｶと、コレはﾓﾚの予想だけれどもさ。
ちなみにthread同期に関しては同じく11枚目に
on-chip thread synchronization and communication
と書かれていて、これはLarrabee内のcore間の同期でPCIは経由しないものの筈。
逆にLarrabeeとhost CPU間のPCI経由同期もあるはずで、OpenMP compierは
２種類のbinaryを含むececutable内でこの２階層の同期を取り扱えるような
codeを生成するのではないかと、ｺﾚも予想だけれれどもさｗ
ご苦労さんなこったぜ
291:Socket774
08/10/20 22:53:06 hafoWKI3
とうとうGPUでprintfデバッグができる時代が来るのかw
292:Socket774
08/10/20 23:10:58 prDv+JC8
仮にS3がChrome400にExponentialの技術を使ってるとしたら
10年に及ぶ、随分と長い伏線だな
293:287
08/10/21 00:26:01 mj+qHKTV
>>290
おぉ、サンクスコ。
>PCIｶｰﾄﾞ内のLarabbeeからNorthやSouthにぶら下がったI/Oを(Host CPUと調停しながら) ...
というか、いわゆるカーネルモードのプログラムは全てCPU側で処理するのでは?
つまり、in/out命令のレベルで調停するのではなく、
read()/write()システムコールの処理を一括してホスト側で処理するのではないかと。
(もちろんLarrabeeを動作させるうえで必要な最小限のカーネルというかファームウェアが特権命令をLarrabee上で提供することはあると思うけど)
また、論文のコピペした部分 ”『現在の』ドライバ設計ではアプリケーションの再コンパイルを要する”とあるので
将来的には再コンパイルは不要となるのではないかと漏れは予想してます。
だとすると、やはりLarrabee上で発行されたint命令を
必要に応じてホスト側のint命令として処理するコードがドライバに組み込まれるのではないかと。
>OpenMP compierは ２種類のbinaryを含むececutable内で
>この２階層の同期を取り扱えるような codeを生成する
OpenMPで自動並列化するときにCPUの演算資源とLarrabeeの演算資源を同時に活用できるってこと?
クレイジーだね!
294:MACオタ
08/10/21 05:40:21 CIoXnd95
中文版EngadgetがIDF Taipeiで仕入れたLarrabee情報を掲載しているす。
URLﾘﾝｸ(cn.engadget.com)
・コア数: 最大32
・動作クロック: 最大2GHz
・製造プロセス: 45nm～32nm
・今年11月にプロトタイプ登場？
コア数と動作クロックに関してわ、
コア数と動作クロックより最大ピーク性能わ、
倍精度: 2 [GHz] x 8 [並列] x 2 [積和] x 32 [コア] = 1 [TFlops]
単精度: 2 [GHz] x 16 [並列] x 2 [積和] x 32 [コア] = 2 [TFlops]
基本的な性能上のターゲットわ、"TFlops on Chip"ということの様す。
295:レトリック君
08/10/21 20:47:23 FLpnRXeu
>>293
> >OpenMP compierは ２種類のbinaryを含むececutable内で
> >この２階層の同期を取り扱えるような codeを生成する
> OpenMPで自動並列化するときにCPUの演算資源とLarrabeeの演算資源を同時に活用できるってこと?
> クレイジーだね!
OpenMPは演算性能やlatencyに大きな非対称性のあるthreadが混在すると
基本的にloadをbalanceさせ易くないし、PCI経由の同期はそれなりに遅く密接な
同期の間に挟まない方が性能的に有利なので、並列regionに突入するチームを
host CPUとLarabee内のthreadで混成するところまでは、さすがにやらないのでは
ないかと想像して□。
しかし、特定のH/W threadやcoreを固定的に割り付けるaffinity APIをpthreadに拡張し、
OpenMP APIはその上に乗っかるわけだし、host<->Larrabee間のmessage/data passing
protocolは非同期APIもサポートするからCUDAのようにGPUがご多忙中の裏でhost CPU
も一仕事させられる上で必用な仕組みは備わっている。
それがOpenMPのチームを編成するthreadの割付指定拡張の様な??ものなのか、
あるいはCtのみのサポートなのかは今のところ想像の域を出ない。
Ctは非常にダイナミックなのできっと何か仕掛けてくると思う。LLVMの様な仮想命令と
optimizationまで取り入れられる。○○とは役者が違う、もう参ったよって感じ。
しかし、ﾓﾚは何を2chでﾏｼﾞﾚｽしているのやら…
296:287
08/10/21 22:40:09 mj+qHKTV
>しかし、ﾓﾚは何を2chでﾏｼﾞﾚｽしているのやら…
いやいや勉強になるわ。
>CUDAのようにGPUがご多忙中の裏でhost CPU も一仕事させられる上で必用な仕組みは備わっている。
うーん、これはこれでCELLみたいにスーパーハカー的なプログラミング作法を要求しそうでやだなぁ。
あっても良いけど、いつの間にか○○しながら××することが性能出す上で当然みたいなことにならないといいね。
>Ctは非常にダイナミックなのできっと何か仕掛けてくると思う。
>LLVMの様な仮想命令とoptimizationまで取り入れられる。
Ctでコーディングしたら、コードの自己書き換えを伴った実行時最適化が掛かるってことでおk?
>>294
サンクスコ。
各x86コアが2GHz動作するってことかな?
297:Socket774
08/10/21 22:41:04 n0ZU/45N
>>289
CPU<-->GPU間が遅くて連携は難しいとか言われてたが
Chrome400程度のローエンドでこれほどなら
AMDのFusionとかの構想も結構期待できるのか？
それともChrome400が特殊なのかね？
Exponential？
298:レトリック君
08/10/21 23:55:47 xkV0DQUZ
>>296
> >LLVMの様な仮想命令とoptimizationまで取り入れられる。
> Ctでコーディングしたら、コードの自己書き換えを伴った実行時最適化が掛かるってことでおk?
印刷物は会社に置いてきちまったけれども、それでOKだと思う。
抽象IA命令だったっけな、これをruntimeに最適化しながら
具体的なIA-32、IA-64、Larrabeeなどの最適化Nativeが生成されて行くと
いうような事が確か文献に。
最近ﾓﾚの周りではこういう研究もﾌﾟﾁ流行の気配なんだ。ﾆﾔﾘ
299:,,・´∀｀・,,）っ
08/10/22 01:01:34 yn2f9k6s
自己書き換えっていうか動的生成のほうが正しい
文字通りの自己書き換えは（既存コードシーケンスの上書き）は、
ページ属性操作が煩雑かつトロくさくて最近はあまり流行らない
XDビットの兼ね合いもあるし。
バイトコードを動的に並べてExecutable属性つけてそこに飛ばすほうが速い
300:Socket774
08/10/22 02:52:45 72ds95ht
「粘着力はヤモリの足の10倍」、はんだ代替に使える導電性接着剤を米大学が開発
URLﾘﾝｸ(eetimes.jp)
なかなか興味深いですね。
アーキテクチャ関係ないけど。
301:Socket774
08/10/22 17:13:40 QGUEJiks
【1Peta-FLOPS】GPGPUについて語ろう【実用間近】
ｽﾚﾘﾝｸ(avi板)
302:Socket774
08/10/22 23:54:49 /t9vpjfq
消費電力は電圧の2乗・周波数に比例するって言うけど
性能も周波数に比例するから、アイドル時に電圧下がるなら
速く処理が終わる高クロックのがワットパフォーマンスは良くなんじゃない？
だとしたらPentium4は何が悪かったの？
周波数を上げても消費電力も性能も同じだけ上がるだけだけど
その周波数を上げるのに電圧を上げなくちゃいけなかったってだけ？
303:Socket774
08/10/23 00:21:58 zxkBdXPG
>>302
見通しではリーク電流を順調に減らせるはずだったけどそうはいかなかった。
それでもTDPと共にクロックを上げ続けたおかげで冷却が物理的に間に合わなくなった。
304:Socket774
08/10/23 00:35:49 svKUApOq
>>295
> Ctは非常にダイナミックなのできっと何か仕掛けてくると思う。LLVMの様な仮想命令と
> optimizationまで取り入れられる。○○とは役者が違う、もう参ったよって感じ。
おれの知ってるCtはOpenMPなC++コードを吐くコンパイラだったのだが、
いつのまにそんな高機能になったの？
ソースプリーズ
305:レトリック君
08/10/23 01:16:27 cidyWJKe
>>304
ＧhuloumのTechnology Jurnal 2007やWhitepaper。
forward scalingの章辺り以降VIP、VCGの記述の辺り。
今では英語のwikiからもintelのＣｔのｻｲﾄからﾘﾝｸがたどれる。という以前に、
URLﾘﾝｸ(www.google.co.jp)
など…
306:レトリック君
08/10/23 01:26:41 cidyWJKe
ググるんだったらこっちの方がええんかな…
URLﾘﾝｸ(www.google.co.jp)
すぐに実用的製品に至るかはﾜｶﾗﾝが、appleの件もあるので
307:287
08/10/23 02:27:45 Ig/uBMS+
>>298
>具体的なIA-32、IA-64、Larrabeeなどの最適化Nativeが生成されて行くというような事が確か文献に。
ふむふむ。
インタプリタでは間接分岐を工夫しないと性能に影響が出るって論文で読んだけど、
インオーダーのLarrabeeなら、それほど影響は出ないかもね。
URLﾘﾝｸ(citeseerx.ist.psu.edu)
>最近ﾓﾚの周りではこういう研究もﾌﾟﾁ流行の気配なんだ。ﾆﾔﾘ
kwsk!!
>>299
>自己書き換えっていうか動的生成のほうが正しい
なるほど。
しかし、これだけだとLLVMって言うよりJVMのJITっぽいよね。
308:,,・´∀｀・,,）っ-○◎●
08/10/23 02:50:46 le5WL46E
やることはJVMのJITそのものだよ。
単純な演算の繰り返しなんで、コンパイル時間より実行時間のほうが多いからJITでも十分。
分岐パターンが一意に決まらない複雑な演算もやらされるJavaよりもある意味では有利。
たとえば、このアプローチが有効なのは
URLﾘﾝｸ(homepage1.nifty.com)
にもあるような量子化の定数を実行時に決めるやつ
GPUでやるような並列コンピューティングの場合、条件分岐の評価を最初の1回目だけあとは
同じパターンを延々繰り返しなんてのが多いからこういう最適化はかなり役に立つ。
JavaScriptエンジンも最近の実装ではJITを使った高速なものがある。
YARV(Rubyの別実装)でもXbyakを使ってx86ネイティブコードを動的生成することが試みられている。
309:287
08/10/23 03:38:21 Ig/uBMS+
Xbyak面白れぇ!使ってみよw
>単純な演算の繰り返しなんで、コンパイル時間より実行時間のほうが多いからJITでも十分。
逆に汎用言語の処理系ではLLVMみたく最適化の結果をファイルに書き戻す処理は流行りそうに思うけど。どうかな?
>JavaScriptエンジンも最近の実装ではJITを使った高速なものがある。
ｷﾓ過ぎるな、おいｗ
ブラウザの上でJITとか走った日にゃ、超高速ブラクラとか遭遇しそうでry)
>YARV(Rubyの別実装)でもXbyakを使ってx86ネイティブコードを動的生成することが試みられている。
ほぅ。さすがssdさんはそんなことまでやってたのか。
VM型インタプリタだから中間言語の仮想命令を一つずつネイティブ命令に置き換える実装?
それとも各仮想命令間をまたぐスーパー命令を動的に定義してくれんのかな?
YARVって確かネイティブスレッド対応だし、YARVのソースをLarrabeeコンパイラに掛けたらそのまま並列化出来そうだよね。
310:Socket774
08/10/23 19:18:18 LbWZWVyh
>>302
ロード時の電力が半端じゃないだろ。
少なくとも初期のPentium 4はアイドル時はPenII以降のデスクトップでは最も消費電力が低い部類です。
311:Socket774
08/10/23 19:48:27 wWDSOmen
>>308
> JavaScriptエンジンも最近の実装ではJITを使った高速なものがある。
唐沢俊一のトリビアなみだなwww
Lars Bakで調べると吉
312:Socket774
08/10/23 20:12:48 wWDSOmen
>>308
> やることはJVMのJITそのものだよ。
ちゃんと調べてから書けば、幼稚なことは書かずにすむ
URLﾘﾝｸ(portal.acm.org)
313:,,・´∀｀・,,）っ
08/10/23 20:45:10 5SLKKRne
>>311-312
Googleのv8エンジンも知らないなんて幸せですね
314:,,・´∀｀・,,）っ
08/10/23 20:59:14 5SLKKRne
ヒント
SoftWire
単に自分自身がネイティブコードを生成するかVMがやるかの違いでしかない
BrainFuckのJITのサンプルがあるからちょうどいいだろ
BFソースプログラムからすればXbyakで書かれたサンプルアプリはJIT型のVMとみなせる
315:Socket774
08/10/23 21:06:13 svKUApOq
「JVMの」ってのがバカにされてるところじゃない？
よくわからんけど。
JVMってスタックマシンだよな。
316:Socket774
08/10/23 21:08:39 O1XSmp3q
JIT手を見る。
317:Socket774
08/10/23 21:16:00 wWDSOmen
MACオタですら馬鹿にされたらムキになって調べてくるのに
団子って自分の知識が世界の全てだから、ずいぶん幸せそうだなww
318:Socket774
08/10/23 21:17:37 svKUApOq
あと最適化が手動のJITと同列にするのってどうなの？
319:Socket774
08/10/23 21:29:48 wWDSOmen
Lars Bakという人名すら知らない団子は本当に幸せそうだ
320:Socket774
08/10/23 21:38:53 O1XSmp3q
へえ
URLﾘﾝｸ(d.hatena.ne.jp)
>Self VM から Animorphic VM、Java HotSpot VM、OOVM、そしてこのほどの V8 には、“VM の魔法使い”と呼ばれるラース・バック（Lars Bak）が共通してかかわっているという話のようです。
321:,,・´∀｀・,,）っ
08/10/23 21:46:44 5SLKKRne
また頭のいかれたフェンス君かな？
>>315
見方の違いでしかない。
たとえばWindows上のJVMはjava.exeはバイトコードを読んでx86ネイティブコードシーケンスを動的生成するWin32アプリとも見なせる。
あとは動的生成対象のコードシーケンスが外部ファイルかアプリに組み込まれてるか
あるいは外部ファイルがテキストかたとえばJavaバイトコードか、
の違い。
ちなみに最近はRubyも単体EXE作れるんだな
322:Socket774
08/10/23 21:51:42 wWDSOmen
>>321
> ちなみに最近はRubyも単体EXE作れるんだな
小学生の豆ちしきを披露する前に、ちゃんと調べよう
323:,,・´∀｀・,,）っ
08/10/23 21:55:02 5SLKKRne
JVMやV8のネイティブコード生成ルーチンとSoftWireやXbyakのそれは技術的には同じだよ
324:レトリック君
08/10/23 21:58:46 uLYL10Hy
Perlなども単体.exe作れるが…あれはLLVM等とは別扱いすべきだな。
途中で生成されるＣのソースコードはひたすらVMの機能関数呼び出しの羅列で
Perl本体の.oとリンクするわけだし…
Rubyはｼﾗﾈ
325:Socket774
08/10/23 22:03:59 svKUApOq
もとのCtの話にもどると肝はJITそのものでなくその時点での最適化でしょ？
SoftWireもXbyakもそこは手動なんだから同列に語れないでしょ
むしろJVMのHotSpotなら話は近いと思うけど
326:,,・´∀｀・,,）っ
08/10/23 22:11:26 5SLKKRne
v8のソースちゃんと読んだ？
ぶっちゃけ実行時最適化もVM開発者が労力かぶってるだけの話でしかないんだが。
SoftWireは元々シェーダスクリプトをx86で実行するためのVMの土台のライブラリだから
立場的にはなにも変わらない。
327:Socket774
08/10/23 22:19:49 qrrIV8EU
URLﾘﾝｸ(v8.googlecode.com)
Xbyakのやってることそのものだな
328:Socket774
08/10/23 22:33:24 svKUApOq
JVMのソースなら数年前に読んだよ。
V8は別にあんまり興味ない。
最適化に興味があるのでそのあたりおもしろいところがあれば紹介して欲しい。
329:Socket774
08/10/23 22:44:44 wWDSOmen
>>328
> 最適化に興味があるのでそのあたりおもしろいところがあれば紹介して欲しい。
dynamic optimizationでciteseerを検索する
いろいろ出てくるので興味のあるものをたどってゆく
citeseerに本体がなくても、著者のページにあることがあるので、タイトルでぐぐると吉
330:レトリック君
08/10/23 22:46:45 iaMxptJD
どのﾚﾍﾞﾙでの最適化をご所望かﾜｶﾗﾝけど
最適化関連で多少注目していてｺｺに書いて差し障りのないものとしては
COIN、某大学の広域、LLVMの最適化・生成、あと海外の大学の数件くらいなどしかｼﾗﾝ。
役に立てずｽﾏｿな。Compiler Infrastructureでｸﾞｸﾞｯﾃ見ては？
さて、一杯飲んで寝るとするか…
331:,,・´∀｀・,,）っ
08/10/23 22:55:58 5SLKKRne
COINSのMLは学生時代から登録やってるが、たまに質問が投げられても中身がないな
332:Socket774
08/10/23 22:56:45 wWDSOmen
>>330
svKUApQqが静的最適化に興味があるんだったら、最近の分厚い成書をまず読むべき
Muchnickのがおすすめ
333:レトリック君
08/10/23 22:58:18 9GEasw9b
そんなことﾓﾚに言われてもｼﾗﾝｶﾞﾅｗ
文句ならﾒｰﾙ書いたﾔｼに言えば＞
334:レトリック君
08/10/23 23:00:31 9GEasw9b
>>333は>>331宛ね、念のため。
335:,,・´∀｀・,,）っ
08/10/23 23:03:00 5SLKKRne
おもっきり実装レベルの話をすれば、生成したネイティブコードシーケンスの両端に
RDTSCみたいなクロックカウンタしこんでかかったクロック数を計測するだけだよ
あとは経験則で最適なコードシーケンスを選んでいくだけ。
Larrabeeの場合フィードバック最適化はあまり必要ないんじゃないかと
だってコンパイル時にCPUわかっちゃうだろ？
336:レトリック君
08/10/23 23:05:08 9GEasw9b
>>335
いや、だからさ、単体ﾚﾍﾞﾙでもの考えすぎだって…
くどくく言いたくないけれど
337:,,・´∀｀・,,）っ
08/10/23 23:46:53 5SLKKRne
逆に泥臭いことが嫌いならさ、言ってるじゃん
i社「最適化ノウハウは我々にあるから君らバカ共はCtの取得だけに勤しんでくれ」
いずれにしても肝心なことは教えないから自ら茨の道を歩む人は
計測しつつトライアンドエラーしかない
338:Socket774
08/10/23 23:47:28 svKUApOq
皆様どうもありがとう。
興味あるのはLLVMのようなリンク時、実行時の最適化です。
>>335
プロファイルをフィードバックする最適化はgccでもできるけど
それなりの効果はあるよ。
339:レトリック君
08/10/23 23:55:09 yKlJgebI
if then elseのどっちの説をストレートに通してpipeline stoleを減らすかを
profileベースで決めるだけでもそれなりに効果はああったな。
いや、15年前の技術でｽﾏﾝけれども。ｵｯﾁｬﾝで悪かったな…
340:,,・´∀｀・,,）っ
08/10/24 00:09:23 KkYgEOUG
静的な最適化といえば必須テクはテンプレートメタプログラミングとかの類だな
再帰とかめちゃくちゃ速くなるぜ
あ、実行時にfprintfでCのソースを動的生成してコンパイラを走らすアホなフレームワークとか知ってるが
あれはソース読んで腹筋を激しく鍛える以外の意味は無いと思う
341:レトリック君
08/10/24 00:12:33 gseqQVPN
なんかあほらしくなってきた…
寝よっと
342:Socket774
08/10/24 01:15:56 WGYTUVJN
団子ちゃんの根底にあるものをわかってれば
そんなに疲れないんだけどねー
343:287
08/10/24 01:43:43 OoG1Pbto
....何か荒れてるな。ひょっとしてオレのせい?...orz
COINSのくだりなんか政治的な匂いがするな。
>>340
>実行時にfprintfでCのソースを動的生成してコンパイラを走らすアホなフレームワークとか知ってるが
>あれはソース読んで腹筋を激しく鍛える以外の意味は無いと思う
最適化とは関係ないけど、javassitでアスペクト云々とかの事例もあるし、そこまで悪いとは思わないけどなぁ。
>>339
>if then elseのどっちの説をストレートに通してpipeline stoleを減らすかを
>profileベースで決めるだけでもそれなりに効果はああったな。
間接分岐予測の精度向上って昔からあるんだな。
VLIWが主流になるからこうゆう研究は下火になるって考えられた事は無かったのか?
344:Socket774
08/10/24 04:02:49 TKCXfGgg
>>343
> ....何か荒れてるな。ひょっとしてオレのせい?...orz
> COINSのくだりなんか政治的な匂いがするな。
いつものように、団子が自分の知っている単語(だけ)を振り回す、小学生のようなマネをしているだけです。
> 間接分岐予測の精度向上って昔からあるんだな。
> VLIWが主流になるからこうゆう研究は下火になるって考えられた事は無かったのか?
プロファイリングで分岐の最適化する話は、まさにVLIWと共に進歩したよ。
345:,,・´∀｀・,,）っ-○◎●
08/10/24 04:20:02 JJ0keCsa
だまれフェンス
346:,,・´∀｀・,,）っ-○◎●
08/10/24 04:24:15 JJ0keCsa
今日もJITのコンパイラソースも読めない恥ずかしいフェンス君がいたいね
347:,,・´∀｀・,,）っ-○◎●
08/10/24 04:28:39 JJ0keCsa
>>343
いちいち文字列化してファイルに書き出し、更にそれと1字1字読んで解析することほど
コンピュータにとって無駄な作業はないよ。
実際問題効果は得にくい。
それならまだコンパイラのバックエンド組み込んじゃったほうがエレガント。
GCCなんてオープンソースなんだし。まあGPLだが。
348:,,・´∀｀・,,）っ-○◎●
08/10/24 04:47:31 JJ0keCsa
それとね、インタプリタは字句解析→関数コールの繰り返しだから
たとえばCより速いとかさえ考えなきゃ、単純にマシンネイティブコードの
シーケンスに置き換わるだけでも十分な効果は得られるわけだよ。
普通のプログラム使ってる分には自己書き換えや動的生成といった技術では大した効果は得にくい。
まあ、Perl何かでよく多用する正規表現の評価なんかはどのみち正規表現ライブラリでやることになる。
文字列処理ばかりは、どうしてもそんなに速くならない。
まあ、Nehalemで正規表現の文字クラスを一括判定出来そうな命令も加わってることだし
SIMDに置き換え甲斐はあるんだけどね
あ、知ってると思うけどXbyakの更新ログ見てみな。度々コミットしてる「団子厨」って俺だよ。
宣伝乙だろ？
349:Socket774
08/10/24 05:15:32 OzDh+l4t
熱くなって書く前に、レスをまとめろ。
350:Socket774
08/10/24 05:29:27 RPdK9r5W
焼き団子旨そう。
351:Socket774
08/10/24 10:26:57 VSMFhSl7
XbyakってJITって言ってもJITコンパイラでなくJITアセンブラだよね
興味持つ人は少ないと思われる
352:,,・´∀｀・,,）っ[2代目のたんぺ]
08/10/24 12:17:40 KkYgEOUG
もちろんアセンブラ部分の上の部分さえ作りこめばコンパイラになる。
YARVのサブプロジェクトとして使われてるyajitがXbyakベースのコンパイラ第一号だ
Xbyakの動向はRuby教祖まつもと氏も関心をお持ちのようだよ。
353:Socket774
08/10/24 12:53:08 nPsOzf0O
gccのasm()の方が好みだな。rtl式使えるしcompilerは当然既にあるし
つかスレチ
354:,,・´∀｀・,,）っ
08/10/24 12:55:43 KkYgEOUG
それただのインラインアセンブラ
JITは実行時生成だ
355:Socket774
08/10/24 13:00:44 /SfLy6s3
遊びとしては面白いだろうけど使う気が起きないわ。
356:Socket774
08/10/24 21:53:28 AnZEaAc/
>302
Pen4は内部で早いうちにx86命令をRISC命令に分解して
トレースキャッスに予測がヒットするのを前提として
楽観的に予測実行をせざるを得ないアーキテクチャだと
聞いたことがあります。リプレイシステムなんてのも実装されていました。
もちろんトレースキャシュにヒットする場合は速いのですが、そうも行かない
場合も多く、ヒットしない場合はリプレイシステムで再実行がかかります。
また、RISC命令に早期に分解しているため、実行命令数も増えます。
実行命令数が増えたのと、再実行が多いため、リソースを食いまくり、
限界に達したのかもしれません。
Core2系では、x86命令を早期に分解せず、むしろ合体をして実行命令数を減らします。
最後の最後ではRISC命令に分解するみたいですが。
全部受け売りです。もし間違った理解をしていたらごめんなさい。
357:,,・´∀｀・,,）っ
08/10/24 23:45:47 KkYgEOUG
>>356
うーん
微妙な理解だなぁ
命令長が不規則で複雑怪奇を極めたx86命令の命令の切りだし＆デコードはそれだけでも大がかりな作業なんだよね。
特に3-4命令同時にやろうと思えば。
Core2だって決して万能ではない。
NetBurstにとってはフロントエンドの負荷軽減のための省電力技術としての側面もあった。
Nehalemではものすごく限定的だがμOPsをキャッシュする機構を復活させている。
もちろん、ごく短いループでしか効果はないが。
358:Socket774
08/10/24 23:48:35 0trr2tDp
つーか、それ以前に>>302の認識が間違えているから、
レスつけても仕方がない。
359:Socket774
08/10/25 00:59:14 8sTdYtfU
>>348
すごいな団子さん
尊敬する（嫌味じゃないよ）
360:Socket774
08/10/25 01:35:55 L+S6Bhz8
そのうち程度がばれて
へるみからそっぽ向かれるに10,000ベリカ
361:,,・´∀｀・,,）っ-○◎●
08/10/25 01:40:52 ixbtkhbG
ベリカってどこの単位だよ
とりあえずAVXのYMMレジスタ対応まで好きなように拡張していいって許可ならもらった
362:Socket774
08/10/25 01:41:11 Qy6a875T
トランスメタのコードモーフィングでジャバを半ネイティブ実行する仕組みがあれば、
ネットブック用CPUとして未だ生き残ってたかもなあ。
363:Socket774
08/10/25 01:42:53 L+S6Bhz8
まあ、ネットで目立つ人材を叩いてまわるだけで10年近いのに、
自分では何も発信できないどっかのコテよりは数倍マシですね。
364:,,・´∀｀・,,）っ-○◎●
08/10/25 01:50:52 ixbtkhbG
FUCKヲタの悪口はそこまでだ
365:,,・´∀｀・,,）っ-○◎●
08/10/25 02:01:38 ixbtkhbG
URLﾘﾝｸ(www.epitech.eu)
epitechってどのくらいのレベルの大学なのよ？
これをさらに高速化出来る手法編み出したんだが。
つーか、ソース読んで1時間でわかった。
366:,,・´∀｀・,,）っ-○◎●
08/10/25 02:12:50 ixbtkhbG
正確にはグランゼコールか。フランスの高等教育制度はよくわからん。
367:,,・´∀｀・,,）っ-○◎●
08/10/25 02:16:21 ixbtkhbG
>>362
無理無理、ネイティブ自体が大した効率良くない。
368:Socket774
08/10/25 02:19:23 uOTfz0/u
これってどれ？
369:Socket774
08/10/25 02:43:28 TSYF4R+f
>>363
団子も大嘘ついては訂正しないことではMACオタに引けを取らんけどな
370:Socket774
08/10/25 03:31:32 Qy6a875T
>>367
webページってテンポラリデータでHDDにキャッシュするから、そのキャッシュに
JSをx86ネイティブにコンパイルしたコードもキャッシュする、ってのはどう？
もうやってるかもしれんが。
371:Socket774
08/10/25 03:46:25 wPAPYS2d
こんなのあったけど、ポストカードが貰えるらしい。
URLﾘﾝｸ(zigsow.jp)
372:Socket774
08/10/25 08:13:34 ELNg1SOp
>>370
JavaScriptとJavaの違いを学んだ方がいい 実行の方式が全く違う
Scriptなのでネイティブ変換はできません HTMLの解析結果との連携なんかもあるし
373:レトリック君
08/10/25 10:17:14 nhfwknIq
ｵｰﾄﾏﾄﾝてSIMD処理に適しているのか？
状態の扱いは思いっきり依存ありげでvectorには不向きな気がするが
ﾌﾄ疑問に思っただけだが
374:レトリック君
08/10/25 10:27:55 nhfwknIq
URLﾘﾝｸ(www.google.co.jp)
ﾁﾗ見してみたが、芳しい検索結果はみつかりまへんな…
375:,,・´∀｀・,,）っ-●◎○
08/10/25 11:01:10 ixbtkhbG
>>372
だから、v8はネイティブ変換やってるってば
>>373
普通は適してないよ。
というか馬鹿まじめにオートマトンなんてやってないよ。
正規表現エンジンでよく使われる後方参照なんて、
DFAじゃ実現そのものが不可能だし。（NFAといっても良いかも疑問）
PCREも鬼車はBoyer-Moore法で固定文字列として扱える部分を大雑把に判定することで
高速化してる。これはNFAでやるとものすごく遅いから。
手法にとらわれない本質って大事だよ。
正規表現を使って文字列検索をすることの本質は、ステートマシンを使うという
手段ではなく、あくまで文字列検索という目的。
で、文字列サーチ部分はSSEの支援を受けようと思えばできる。
状態変数そのものも高速化できる。
たとえば、SSE4.2の文字列比較命令を使うと、
XMMレジスタにロードされた最大16個の文字が
[1234567890ABCDEF]のいずれかにマッチするかを
1命令で判定するなんてこともできる
これ、動的生成でこそ効果発揮すると思うけどどうよ？
まあxmmレジスタに読む値は即値化できないがな
376:,,・´∀｀・,,）っ-●◎○
08/10/25 11:04:05 ixbtkhbG
- PCMPESTRI (SSE4.2) Packed Compare Explicit Length Strings, Return Index
- PCMPESTRM (SSE4.2) Packed Compare Explicit Length Strings, Return Mask
- PCMPISTRI (SSE4.2) Packed Compare Implicit Length Strings, Return Index
- PCMPISTRM (SSE4.2) Packed Compare Implicit Length String, Return Mask
力技だが、BM法でやってた文字列サーチを代用することもできるし
文字クラスのマッチングのように使うこともできる。
377:レトリック君
08/10/25 11:17:38 D32E8APC
文字列処理と正規表現をごっちゃにしている
378:,,・´∀｀・,,）っ-●◎○
08/10/25 11:33:41 ixbtkhbG
馬鹿だね。「正規表現」は必ず全部有言オートマトンとして文字列比較しないといけないとでもお思いですか？
C++ TR1にもほぼそのまま採用されたBoost Regexですら固定文字列として扱えるパターンを抽出してｒ
boyer-moore法を使ってる
379:,,・´∀｀・,,）っ-●◎○
08/10/25 11:35:10 ixbtkhbG
しかし、ぶっちゃけ今普及してるPerlコンパチのあれは「正規」でもなんでもないんだがな。
380:,,・´∀｀・,,）っ-●◎○
08/10/25 11:43:05 ixbtkhbG
GNU GREPも複雑な正規表現で無い限りBM法やtrieを使ってる
ソースコードも読まずに古い知識を広げるのはやめていただきたい。
381:,,・´∀｀・,,）っ[がいしゅつ]
08/10/25 11:59:32 o0eDstJh
いい？
abc(def|g[hij]?)*k+
なんてパターンを与えられたら
まず必ず評価する "abc" にマッチする部分をBM法ないしその他の高速な固定文字列検索法で検索し、マッチしたところに対してNFAで評価するのがモダンな実装。
382:レトリック君
08/10/25 12:20:05 l1Ioy72A
文字列処理はどうでもいいの
finite automatonはどうかという書き出しだが
383:レトリック君
08/10/25 12:28:22 l1Ioy72A
おまえさんは文字列処理で扱える範囲の単純なパターンマッチングだけ
考えているんだろうけど、ｵﾚが着目しているのは例えは
URLﾘﾝｸ(search.cpan.org)
なの。
384:,,・´∀｀・,,）っ
08/10/25 13:03:44 o0eDstJh
バカだな
俺はFAそのものを高速化できるなんて一言も言ってないぜ
NFAの最大のネックはバックトラックだし。
FAを使わない方が絶対的に速いんだから、いかに問題を切り出すかが課題。
モダンな正規表現エンジン高速化のテーマなの。
固定文字列なりtrieなりシンプルなパターンに落としこみ、JITで命令を使ったシーケンスに変換すればいい。
あ、おまえはSSE*はSIMDだと認めてないんだったかなｗ
もちろん梟本は持ってるよ俺は
おまいは持ってすらなさそうだが
385:レトリック君
08/10/25 13:11:01 aymmFkOp
>>384
> あ、おまえはSSE*はSIMDだと認めてないんだったかなｗ
誰と勘違いしてんだ
386:レトリック君
08/10/25 13:17:04 aymmFkOp
NFAの話に対し、NFAに頼らずにすむ高速化しやすい問題を扱えばいいと…
387:,,・´∀｀・,,）っ
08/10/25 13:31:59 o0eDstJh
あ、
ベクトル演算＝ベクトルマシン
だったかな
固定文字列部分が4文字以上あるならmpsadbw+pminposuwを使う方法もある。
実際BMより速い。
ていうかレトロ君の脳内の正規表現パーザは後方参照（\1-\9）通りますか？
388:Socket774
08/10/25 13:33:22 Rb6i6i1G
>>362
月アスのインタビュー等でDitzelが「やってる」って答えてたよ
後藤さんの海外ニュースにも掲載されてる
URLﾘﾝｸ(pc.watch.impress.co.jp)
> Crusoeは、命令セットをハードウェアではなくソフトウェアでインプリメントしている。
> (中略) そのため、x86ではなく、異なる命令セットをインプリメントしたCMSを作ることもできる。
> 実際にTransmetaはJavaでそうした実験をやっている。昨年9月にディツェル氏は「CMSにJavaを
> インプリメントして、直接Javaのバイトコードを扱えるようにする実験はやった。Crusoeは、
> 世界最速のJavaプロセッサになりうる。しかし、Javaプロセッサの市場は大きくないので、
> 現在は提供していない」と語っている。
まぁ、「実験してる」発言であってデモしたわけじゃないので、性能は「？」だけど
389:,,・´∀｀・,,）っ
08/10/25 13:33:57 o0eDstJh
いったい誰がNFAを高速化するなんて言ったんだ
思考回路が短絡してるな
390:レトリック君
08/10/25 13:35:56 gt5hlvzQ
文字列処理の話を勝手に始めたのは誰？
391:レトリック君
08/10/25 13:38:18 gt5hlvzQ
>>389
だったら最初から黙っていればいいのに…
392:,,・´∀｀・,,）っ
08/10/25 13:43:54 o0eDstJh
正規表現は必ずFAで処理するものだと思いこんでるのはお前だけだよ
393:レトリック君
08/10/25 13:46:44 gt5hlvzQ
だから高速化しやすいケースの話ではなくFAの話だと
文字列はどうでもいいと。何度も書かせるな。
394:,,・´∀｀・,,）っ
08/10/25 13:47:49 o0eDstJh
>>391
自己分析としてならその発言は正しいな
無知の君は最初からは黙ってれば良かったんだ
395:レトリック君
08/10/25 13:48:54 gt5hlvzQ
だめだコリャ…
396:,,・´∀｀・,,）っ
08/10/25 13:49:34 o0eDstJh
俺はFAの高速化の話題なんて振ってないし
一人相撲はいい加減にしないと
397:レトリック君
08/10/25 13:52:44 gt5hlvzQ
ｵﾚはFAの話しをしてたんだよ。
それを聞きたくもないのに文字列処理の話しに勝手にそらしてﾚｽつけたのはお前だぜ。
訳わかんねぇぞ
398:,,・´∀｀・,,）っ
08/10/25 13:53:25 o0eDstJh
まさかレトロ王国(国民1名)には
正規表現によるマッチングにFAを使わないといけないなんて法律でもあるのか？
399:レトリック君
08/10/25 13:55:45 gt5hlvzQ
じゃFAなしで頑張ればいい。どうぞご自由に。
400:,,・´∀｀・,,）っ
08/10/25 13:57:38 o0eDstJh
FAを処理なんて誰が言い出したんだ？
正規表現による文字列検索にはSSE4が応用できるとは言ったが。
正規表現をまずFAに展開するなんて誰も言ってない。
401:レトリック君
08/10/25 13:58:45 gt5hlvzQ
だからお前に聞いていないと
402:レトリック君
08/10/25 13:59:46 gt5hlvzQ
ｵﾚも言っていないがそれが何か…
403:,,・´∀｀・,,）っ
08/10/25 14:00:02 o0eDstJh
純粋にFAだけで処理する実装の方が珍しい
404:Socket774
08/10/25 14:01:46 ly2TAH+6
団子はなんで誰に対しても攻撃的なんだろうな
405:レトリック君
08/10/25 14:02:06 gt5hlvzQ
それこそ誰が言ったのかと…
まいいや、時間の無駄だった
406:,,・´∀｀・,,）っ
08/10/25 14:05:44 o0eDstJh
>>373のレスは誰に向けてなのかな？
独り言なら失礼した。
LLでよくある正規表現による文字列検索のことは言ってなかったんだな
407:,,・´∀｀・,,）っ
08/10/25 14:08:46 o0eDstJh
>>373と>>374には繋がりは無かった（ということにしたい）んだな
408:レトリック君
08/10/25 14:18:23 iSfdTgiD
あのな、忙しいんでほどほどにしたいんだけれども
正規表現をによるパターンマッチングの内、文字列処理もある。
文字列処理にのみ着目すると色々高速化の方法がある。
方法があるとわかっている問題は解けているも同然だから
研究課題としてどうでもいいの。
状態の更新の様な依存がある問題をどう並列化するかのﾓﾃﾞﾙとして
ややこしいパイプライン化等が有効かとか、まぁ場合によるので一概に言えないが、
SIMDに関しては一括処理する単位が小さいので、
まぁいくらなんでも無理ジャマイカと、休日部屋掃除をしながら
つらつらと考えていた訳よ。
あばよ、勉強にならなかったぜよノシ
409:,,・´∀｀・,,）っ-●◎○
08/10/25 14:24:13 ixbtkhbG
お帰り俺
で、>>374は結局何を検索しようとしてたの？
finite automaton regular expression SIMD
こんなん見つかるわけ無いよ
っていうか
英語表記は Finite Automata だし
~~
日本語だけじゃなくて英語もだめなんだね。
根本的に全てFAに変換する必要自体ない。
後方参照をサポートするとすでにFAとは呼べなくなるし。
410:レトリック君
08/10/25 14:26:25 4A5jsRDR
それ複数形だが…
だからもういいって。
411:Socket774
08/10/25 15:07:38 TSYF4R+f
>>410
団子は抽象的なものの考え方ができないし、
自分の知識にないものは世の中に存在しないのと同じなんだよ
412:,,・´∀｀・,,）っ-●◎○
08/10/25 15:10:24 ixbtkhbG
正規表現＝FAで処理するものだなんて考えてるレトロ君ほど
凝り固まった考え方の人間もいないけどな
413:Socket774
08/10/25 15:24:43 TSYF4R+f
そうそう、団子は論理もおかしいんだった
>>408
リストベクトルを使って幅優先探索することくらいじゃまいか
414:,,・´∀｀・,,）っ-●◎○
08/10/25 15:51:29 ixbtkhbG
リストベクトルって固定観念の象徴たるフェンス君が好きな用語だな
415:,,・´∀｀・,,）っ-●◎○
08/10/25 15:53:44 ixbtkhbG
DFA
JIT
416:,,・´∀｀・,,）っ-●◎○
08/10/25 15:59:59 ixbtkhbG
ちょっと誤爆した
SIMDはともかくとして
DFAをJITでネイティブコード化するのは悪くないアプローチだよ
正規表現エンジンでDFAを使った実装が不人気なのは、後方参照とかのサポートの問題
だけじゃなくて、特にUNICODEだと遷移テーブルが膨大になってかえってキャッシュミスでおそくなる
ケースが多いから。
JITだとテーブルを使わなくていい部分は使わない、使っても小さくてすむ場合は小さくする
っていう最適化ができるからその点の弱点は克服できる。
もちろん後方参照はDFAでは表現不可能なので（というかNFAですらない）
別の方法を考える必要があるけどね
417:Socket774
08/10/25 16:09:56 gzPxDYkX
>>360
団子ちゃんがへるみたんからソッポ向かれるのはいいけど
Xbyakに俺ライセンス的なものを主張しはじめないかとか
すごくしんぱい
今までの言動、行動を見てるとねー
418:,,・´∀｀・,,）っ-●◎○
08/10/25 16:15:01 ixbtkhbG
URLﾘﾝｸ(www.dodgson.org)
ま、この辺でも読んでみてくれ
まあ確かに状態遷移にSIMDは不向きだと思うよ。
ただ、テーブル参照を高速化するアプローチには部分的には使える。
コード読んでもらえばわかるんだが鬼車やPCREの「VM」ってのも所詮はインタプリタなので
ネイティブコード化して高速化する余地はいくらでもある。
で、○成氏はどうもつまらんところで苦戦してたらしーが
NFAすら使わない方法のほうがうまくいったらしい
419:Socket774
08/10/25 16:26:20 TSYF4R+f
> それに加えて，1TBの共有メモリを有する32CPUのスカラSMPのAシステムと，
> 3ノード96CPUのベクトルコンピュータのVシステムが付いています。
稲垣足穂かよw
420:,,・´∀｀・,,）っ-●◎○
08/10/25 16:33:14 ixbtkhbG
>>417
ほんとの所
2.06にコミット依頼したとき部分的に提案突き返されたので
ああ、この人はこういう人なんだなと思いました。
コンパイル時引数チェックが甘いのと32ビットと64ビットをマクロで切り替えてるのが
不満だから、テンプレートベースで基本クラスを再設計してコーディングインターフェイス
互換なやつを作ってるのが本音。
というかSourceForgeに修正BSDライセンスで利用登録しちゃってるわけだが。
コードまだ1行もあげてないけどね。
421:,,・´∀｀・,,）っ-●◎○
08/10/25 16:38:17 ixbtkhbG
>>419
っていうかレトロはエンタープライズ級のハードで解決しようって考え方がジジくさいなぁ
そこまでの問題でもないのに
422:,,・´∀｀・,,）っ-●◎○
08/10/25 17:06:37 ixbtkhbG
ひげぽんスレでもxbyakの話題出てたけどへるみ氏はおもっきし過去の人扱いされてた。
まあ、俺も午後時代で終わった人と思ってるが
423:Socket774
08/10/25 17:44:26 L+S6Bhz8
xbyakつくれてる時点でひげぽんより圧倒的に上だろ。
OSなんて多少の知識があれば体力勝負。
424:Socket774
08/10/25 21:43:58 GxCuJdr8
詳しそうな人が多いのでここで聞いてみる
プロセッサのメモリ関連でCRFって何？
425:レトリック君
08/10/25 21:45:24 xE6DXe+8
>>418
> URLﾘﾝｸ(www.dodgson.org)
このblogはそこそこ面白ぇな、特にgrepが圧倒的に早くて愕然とする下り。
grepが早いのは前から有名で昔から雑誌の雑文やネットに書かれたし、
perlもpythonもreは実行時にcompileしている。
ｵﾚはそのreを高速化するつもりなど毛頭ないし、そんなテーマで飯は食えない。
ましてやエンタープライズ級のハード、って何だかわからんがｗ持ち出す気などさらさら無い。
なんでそう妄想で話をスリップさせて因縁つけてバトルしたがるかね。
状態遷移問題の並列性について考えていた際、
FAに関しては並列化はともかくとして、SIMDは性能向上に貢献ないだろという話だったのにさ。
426:Socket774
08/10/25 22:02:30 uOTfz0/u
>>423
Xbyakの何が凄いんだ？
デザインが簡潔
それだけじゃね？
427:,,・´∀｀・,,）っ-●◎○
08/10/25 22:12:44 ixbtkhbG
>>423
アホの俺にいじれてる時点で技術的にはたいしたもんじゃないよ
まんまSoftWireのパクリだし
ほかにもこんなんがあるよ。こっちはC
URLﾘﾝｸ(luajit.org)
428:,,・´∀｀・,,）っ-●◎○
08/10/25 22:33:39 ixbtkhbG
>>425
ABC(DEF|GHIJ)
こういうパターンならABCDEFとABCGHIまでは同時に探索できるよな？SIMDで。
バックトラック回数の削減にもなるぞ。
状態マシンの概念破壊してるじゃんって言われたらそれまでだけどさ
あー、SSE4.2のマニュアル読んでみるといいよ。
Intelが言うにはアレはXMLパーザを組む為に作ったそうだが
XMLに限らずいろんな字句解析に使えるよ。
429:レトリック君
08/10/25 22:36:49 FO7gKhrT
>>428
parse関連でserialの性能にコマったら4.2はいずれ読んでみるよ。㌧ｸｽｺ
430:Socket774
08/10/26 05:41:04 G2GmaOgr
>>424
commit reconcile & fences
詳しく走らん
読め
URLﾘﾝｸ(csg.csail.mit.edu)
431:Socket774
08/10/29 13:06:52 kNyEllLf
ARM Forum 2008レポート【マイコン編】
16bit/8bitマイコンの置き換えを狙うCortex-M3マイコン
URLﾘﾝｸ(pc.watch.impress.co.jp)
講演では低コスト化の手法を、主に以下の4種類に分類した。
1)半導体の製造コストを下げる(回路面積を小さく抑える)、
2)メモリ・コストを下げる(必要なメモリ容量を少なくする)、
3)電力コストを下げる(消費電力を低く抑える)、
4)開発コストを下げる(安価なツールで短期間にプログラミングできる)、
である。
1)の「半導体の製造コストを下げる(回路面積を小さく抑える)」では、
組み込みマイコンに特化したアーキテクチャ「Cortex-M3」を開発する
とともに、ARMの特徴だった豊富なバンク・レジスタを大幅に削減して
回路面積を縮小した。
2)の「メモリ・コストを下げる(必要なメモリ容量を少なくする)」では、
命令セット・アーキテクチャを16bit/32bit混在の命令セット「Thumb-2」
だけにしてプログラムの容量を抑えるとともに、アンアラインド・データ
・アクセスとビット操作機能を導入してデータを効率的にメモリに収納
できるようにした。
3)の「電力コストを下げる(消費電力を低く抑える)」では、演算効率を
高めて処理に必要なクロック数を少なくするとともに、省電力モードを
設けた。演算効率の向上では、命令バスとデータ・バスを独立に装備
するハーバード・アーキテクチャを採用するとともに、1クロック・サイ
クルの乗算命令を装備し、ベクトル割り込みに対応した。省電力モード
では、スリープ・モードとディープスリープ・モードの2種類のモードを
設けた。
4)の開発コストを下げる(安価なツールで短期間にプログラミングできる)
では、32bitアドレスによる4GBの広大なメモリ空間、命令セットの一本化
によるプログラミングの簡素化、C言語での割り込み記述、デバッグ機能の
拡充などを紹介していた。32bitアドレスとは既存の16bitマイコンによる
アドレス空間の制約を意識したもの。命令セットの一本化とは既存のARM
コア(Thumb命令セットとARM命令セットの両方を装備)との違いを説明した
ものである。
432:Socket774
08/10/29 18:46:13 /D3z94P5
まあソフト次第だが、AMDやnVidiaのGPU用ソフトとの競争は、果たして何処が有利なのやら。
リードテック、東芝「SpursEngine」搭載カードの発売日が決定
URLﾘﾝｸ(pc.watch.impress.co.jp)
433:Socket774
08/10/30 23:48:23 lsPMzbOZ
団子のメッキがボロボロ剥げてるな
434:,,・´∀｀・,,）っ-●◎○
08/10/31 01:24:55 4XY8bTKQ
メッキｗｗｗｗ
NVIDIAの平柳って人知ってる？
先日メールでいろいろ話があってだね。
でね、俺も賺さずいろいろ情報聞いちゃったわけよ。
メディアに未公開の情報も掴んじゃってます。
とりあえずLarrabee出るまではCUDA厨やらせていただこうかなと。
435:,,・´∀｀・,,）っ-●◎○
08/10/31 01:27:08 4XY8bTKQ
俺のあっちのサイトでの活動を評価してくださったのよ。ぶっちゃけ。
おまいらときたら、机上の空論を並べるばかり。
天と地の差とはこのことだよ。
436:,,・´∀｀・,,）っ-●◎○
08/10/31 01:30:48 4XY8bTKQ
GTX2xx無償提供してくれるってさ
437:Socket774
08/10/31 02:59:54 uvaoJ3ur
はいはい、すごいでちゅねー
438:Socket774
08/10/31 07:28:48 evEq7qRq
馬鹿だなぁS3しかないだろGPGPUは
682 ：Socket774 [↓] ：2008/10/31(金) 00:16:25 ID:YC2/oQgy
URLﾘﾝｸ(xs432.xs.to)
例のAMD製Shaderの命令発行数を測るプログラムで
9800GTX+,4870,4670,2600Pro,440GTXを比較
VSで2600が4670を上回るのが面白い
現在のATIのドライバーではVSは1アレイに制限されているので
共に8 shaderとなる2600,4670では似かよった結果になるのだが
クロック差を考慮すると、shaderあたりの命令発行は
2600の方が効率がよいということになるな
9800と440が似た傾向にあるのはshaderが同じくスカラであるためだろう
こうした差をものともせず、例の動画のような
（4670に迫る）shaderパフォーマンスを発揮する440は異常といえるだろう
683 ：Socket774 [↓] ：2008/10/31(金) 00:31:10 ID:pSuOrXQl
>>682
ものすごい低性能ってグラフにしか見えないんだが、俺ってグラフの見方分ってないのかな・・・
684 ：Socket774 [↓] ：2008/10/31(金) 00:37:32 ID:YC2/oQgy
上のはあくまで命令を発行できる数の比較でしかない
実際のshaderを走らせた場合はこのようになる
S3 Chrome 440 GTX VS ATI Radeon HD 4670 Shader Performance
URLﾘﾝｸ(jp.youtube.com)
439:,,・´∀｀・,,）っ-●◎○
08/10/31 07:45:45 4XY8bTKQ
CUDAらねー
440:,,・´∀｀・,,）っ-●◎○
08/10/31 07:53:23 4XY8bTKQ
S3ってチートで一躍有名になったTridentを吸収したメーカーだよね
URLﾘﾝｸ(pc.watch.impress.co.jp)
さぞすばらしいトリックがあるんだろうな
441:Socket774
08/10/31 08:27:23 5OfT4oui
固定機能で手抜きってなんらともかく
shaderでそんな事が出来るのかよ
ドライバーのdownloadサイズ12MBそこそこので
100MB近いnvの方が余程あやしいわい
S3はExponential関連のライセンスもってたなそういや
442:,,・´∀｀・,,）っ-●◎○
08/10/31 08:41:46 4XY8bTKQ
CUDAランタイムとかも入ってるんじゃなかったっけ
443:Socket774
08/10/31 10:16:45 5OfT4oui
CUDAあわせてもそんなに大きくなるかね？
ＡＴＩが全部込みで役40MB程度ですし
444:Socket774
08/10/31 10:32:26 5OfT4oui
中身見たらPhysXで50MB近く使ってるわ
445:Socket774
08/10/31 12:20:56 5OfT4oui
VS2008でCUDAが使えるようになるらしい？
446:,,・´∀｀・,,）
08/10/31 13:20:45 s94Xq44X
それ機密情報なのに何で知ってんだよ
俺はリリース時期まで聞いた
447:Socket774
08/10/31 13:46:20 myJZpXG5
だからあのスレに団子が来たのか･･･。
448:Socket774
08/10/31 13:58:01 s4dWBUTT
2008サポートは2.0Beta出した頃から言ってたじゃん
いつになるかを明言してなかっただけ
449:,,・´∀｀・,,）っ
08/10/31 14:05:11 s94Xq44X
いつになるか聞いちゃいました
俺が持ち上げたしたってことは、まあつまりそういうことなんで
そこは察してね
450:Socket774
08/10/31 15:10:21 5OfT4oui
年末
クリスマスあたりですかね
451:Socket774
08/10/31 15:18:47 LCLCvTNB
フロントエンドにVSが使えてもどうってことないんだが・・
CUDA以外でもそういうのは他にもいろいろあるし
問題はデバッガとプロファイラだな
452:Socket774
08/10/31 15:38:56 wIzZPI7o
なんか団子が暴れてNVIDIAのイメージ悪くなりそうだなｗ
453:,,・´∀｀・,,）っ
08/10/31 15:48:39 s94Xq44X
CUDA2.1知ってるよね？ていうか公開情報だよね。
まぁおもしろい機能いろいろだね。
ま、おまいらが関心があるとしてそのVS2008をサポートするバージョンが
2.1になるか2.0のマイナーアップデートになるかってことだけど
まぁ楽しみにしててくれ。
とりあえず俺的にはOffice2007 Ribbonスタイル（＝Win7標準スタイル）のUIを持つ
CUDAアプリケーションが簡単に作れるのはそれなりに意味はあるかなと思ってるが
454:Socket774
08/10/31 16:53:51 NS7cE79c
ある小学生の身内にゲーム作ってる奴がいるような、そんな錯覚。
455:Socket774
08/10/31 17:01:45 B3wviq+I
商用アプリについてもAMDのGPGPU戦略がわからない。
TMPGEncやアドビには働きかけてるんだろうか。
456:,,・´∀｀・,,）っ
08/10/31 17:06:44 s94Xq44X
うまい喩えだな
ただ別に身内でもないし敢えて言うなら実力でコネを作ったっていうか。
その小学生がたとえばロックマンの新作の敵キャラ募集で当選したと仮定してみなよ
457:Socket774
08/10/31 17:28:48 5OfT4oui
私は素直に期待してるよ
アプリが増えるのはGPGPUの底上げにもなるし
是非にがんばって欲しい
まぁ、無理をしない程度に
458:,,・´∀｀・,,）っ-○◎●
08/10/31 23:25:50 4XY8bTKQ
ブロンズメッキが剥がれた下からは何が見えた？
459:Socket774
08/10/31 23:29:55 R/tjyq+c
nvのグダグダ加減
みたいな？
152 ：Socket774 [↓] ：2008/10/31(金) 22:57:00 ID:QmA5a6BH
また出棺追加？
Nvidia forced to dissable chipset PCI prefetch
URLﾘﾝｸ(www.fudzilla.com)
特許侵害で機能を使えなくしないといけないらしい。＞チップセット
460:,,・´∀｀・,,）っ-○◎●
08/10/31 23:48:22 4XY8bTKQ
ま、俺に絡んじゃったのが最大の死亡フラグだな
CUDAやるのもIntelの中の人に開発ツール提供してもらうための踏み台にはなるかもな。
461:レトリック君
08/11/01 00:36:29 U3KlK9XI
Streaming言語の方言ｗによる囲い込み大作戦でどのﾍﾞﾝﾀﾞｰも必死乙状態だが
無料で使えるくらいにしないと普及しないってば…
特にCt。
いや、GCC4.3,4.4にLarabeeのOpenMP対応 .mdをcontrinしてLinuxや(BSDでも←個人的嗜好)
Larabeeを活用できるようにするくらいの懐の深さがあればもはや最強、
もう君臨状態だろうな…
462:Socket774
08/11/01 06:34:45 6TR6R6aV
URLﾘﾝｸ(www.intel.co.jp)
IntelはCtを普及させる気がないのか・・・
463:Socket774
08/11/01 06:56:42 WnvDrRVI
ないある
larrabeeもDX11まかせ
464:,,・´∀｀・,,）っ-●◎○
08/11/01 08:06:19 sHed6bxe
Native C/C++/Asm任せに決まってるだろ
465:Socket774
08/11/06 18:54:48 Lf5PDE2z
GPUアーキテクチャについて語るスレは無いのか…
466:Socket774
08/11/06 19:23:10 leuTujNQ
厨vsスレがあるだろ
467:MACオタ
08/11/10 23:18:10 tiJfK2Pl
中国のIT誌、www.ciw.com.cnのFrank Soltisインタビューす。
URLﾘﾝｸ(epaper.cio360.net)
興味のあるヒトわ、google translateの中国語->英語変換でもつかえば良いす。
目ぼしい内容わ、次の通り。
- POWER7わ既報通り8-core
- POWER6と比較した場合の動作クロックを尋ねた記者の質問に対して、「コアあたりの性能
は従来以上」と回答している。
468:,,・´∀｀・,,）っ-●◎○
08/11/11 23:47:25 QXpmwhjN
フィックスターズ、「Yellow Dog Linux」の米Terra Softを買収--Cellビジネスの拡大目指す
URLﾘﾝｸ(japan.zdnet.com)
469:Socket774
08/11/14 00:02:12 fmVVAWW5
MIPSマネージメント・セミナー2008レポート
～1GHz超の高速MIPSコアとマルチスレッドのクアッドMIPSコア
URLﾘﾝｸ(pc.watch.impress.co.jp)
470:Socket774
08/11/14 20:59:38 G7FkAxgL
これってnVidiaのCUDAよりも使い易いっぽいかな。
AMD、12月のCatalystで「ATI Stream」を実装
～RadeonでGPUコンピューティングが可能に
URLﾘﾝｸ(pc.watch.impress.co.jp)
471:Socket774
08/11/14 21:36:05 N6R2JAKQ
これってMicrosoftのDirectXよりも使い易いっぽいかなって言いながらPreyを紹介するようなもんだが
472:Socket774
08/11/14 22:30:23 Z7zjfxMQ
普通にCで書いたコードを最適化してくれればそれで良いんだけどな
473:Socket774
08/11/14 23:31:23 CEbeYL1E
>>470
Cyberlinkは今年の夏の終わりくらいに何か出すって言ってたよね
474:,,・´∀｀・,,）っ-●◎○
08/11/15 00:01:17 dkxKaXUE
さて、Larrabee持ち上げるか
俺飽きるの早かったCUDA
475:Socket774
08/11/15 12:47:07 vp9zWwD5
nVidiaの話はどうなったんだよ
476:,,・´∀｀・,,）っ-●◎○
08/11/15 13:21:41 0EXHNI7+
あーだめ
Intelなら各命令のレイテンシ－スループットとか事細かに公開するじゃん。
企業秘密のため答えられませんとかどんだけ。
まあ大体傾向調べて判っちゃったけどね。
Larrabeeのほうがまだ高性能。の可能性高い。
477:MACオタ
08/11/15 14:27:16 5OpFeaxx
今週わSOIプロセスにからむ重要な報道が多かったので、まとめておくす。
まず、IBM一党の45-nm SOIプロセス受注開始の報道。
URLﾘﾝｸ(www.eetimes.com)
---------------------
IBM claims 45-nm SOI can offer up to a 30 percent performance improvement or 40 percent
power reduction, when compared to bulk silicon.
---------------------
バルクとの比較と言っても、Intelの最先端HKMGプロセスと比較している訳じゃ無いというのわ、注意
すべきす。IBMとシンガポールのCharteredで、このサービスを提供するし、AMDの"The Foundary
Company"も、セカンドソースとして加わることになる筈す。
記事の方わ、この発表と合わせてSOIプロセスがニッチに留まっている現状について次のように述べて
いるす。
- コストが相変わらず高い
- SOIに対応したIPライブラリが少なすぎる
- 過去にIBM自体がASIC製品での提供を重視していた
- しかしNvidiaがSOIコンソシアムに加入するなど、性能目当ての顧客の参入も出てきた模様
SOIがニッチに留まっている現状を反映して、SOIウェハの製造企業の経営も苦しくなっているとのことす。
- Ibisわ経営危機で見売り先を探している状態
- Soitecの今年第3四半期の売上わ、前年より28.1%低下。世界経済の下降により今後の見通し
も苦しい。
478:MACオタ＠続き
08/11/15 14:38:56 5OpFeaxx
上の記事でも売上低迷が取り上げられたフランスSoitec社すけど、先日シンガポールの新工場
落成の報道があったす。
URLﾘﾝｸ(www.eetimes.com)
フル稼働で1M wafers/yrの規模とのことす。
SOIプロセスのファンダリ企業としてわ、IBM, Charteredに加えて"The Foundary Company"が加わって
市場が拡がることを当て込んでいると思われるす。
SOI市場拡販のためにわ、盟主IBMも手を売っており、>>477の記事で取り上げられた"IPが無い"という
問題解決のためにARMと話をつけた模様す。
URLﾘﾝｸ(www.arm.com)
URLﾘﾝｸ(techon.nikkeibp.co.jp)
-----------------
英ARM Ltd.は，米IBM Corp.の45nm SOIのシリコン・ファウンドリ・サービス向けに，回路ライブラリ
を提供することになったと発表した
-----------------
479:MACオタ＠続き
08/11/15 14:48:23 5OpFeaxx
AMDの製造子会社"The Foundary Company"の方針わ、先日のAnalyst Meetingでも説明が
行われたすけど、Fab36, Fab38, 新設のFab4xの三工場体制で32-nm SOIプロセスを提供し、
22-nm世代も予定していることを表明したす。
URLﾘﾝｸ(www.amd.com)
ココまでの流れわ良い話が多かったすけど、SOI市場のニッチ具合と世界経済の危機的状況わ
甘くないす。IBMのSOI連合わ、IBM, Chartered, The Foundary Companyの3社体制での製造を行う
というの予定すけど、早速一角が崩れて、Charteredの身売りの噂が出てきたす。
URLﾘﾝｸ(www.eetimes.com)
オリジナルのソースわ、台湾Digitimesのこちらす。
URLﾘﾝｸ(www.digitimes.com)
CharteredのCEOが身売り交渉のために、台湾を訪問するとか。TSMCかUMCが買収することになる
という話す。
480:MACオタ
08/11/15 15:09:30 5OpFeaxx
ARMベースのノートPCをubuntuでサポートするというニュースす。
URLﾘﾝｸ(news.zdnet.com)
----------------
ARM-based processors have traditionally been used in small devices such as mobile
phones, but it emerged in October that ARM's technology would soon be used in netbooks,
the new breed of small, low-cost notebook PCs.
----------------
MS vs Linuxとか、Intel Atom vs ARMとか色々な視点で興味深いニュースすけど、上で書いた
IBMのSOIプロセス連合の報道とある意味でリンクしていると言えるす。
481:MACオタ
08/11/16 18:07:49 pou63Jfp
来週の国際会議SC2008で今年下期のTop500が発表されるす。で、下馬評を扱ったこのニュース。
URLﾘﾝｸ(www.computerworld.com)
- ORNL Jaguar (Cray XT5アップグレード), LANL Roadrunnerアップグレード, Blue Gene/Pが有力
- Jaguar: 45-nm Opteron 搭載ラックを200台増強 (192 chips/rack)。ピーク性能 1.64 PFlops。
消費電力 7MW
- Roadrunner: 軍用のためアップグレードの状況わ謎。消費電力わ3,9MW -> 2.5MWに改善とか。
- Blue Gene/P: 世界各地の計算機センターが導入中
482:MACオタ
08/11/17 21:22:14 1jCx7QC9
Top500の結果す。
URLﾘﾝｸ(www.top500.org)
1. LANL Roadrunner (PowerXCell 8i/3.2GHz) 1,105 TFlops (ピーク比 75.9%), 2,483 kW
2. ORNL Jaguar (QC Opteron/2.3GHz) 1,059 TFlops (ピーク比 76.7%), 6,951 kW
3. NASA Pleiades (QC Xeon/3.0GHz & 2.66GHz) 487 TFlops (ピーク比 80.0%) 2,090 kW
4. LLNL Blue Gene/L (PPC440/700MHz) 478 TFlops (ピーク比 80.2%) 2,330 kW
5. ANL Blue Gene/P (PPC450/850MHz) 450 TFLops (ピーク比 80.8%) 1,260 kW