>>773
　　-------------------
　　海外の後藤だと俺は考えている。
　　-------------------
それはCarlieに失礼ではないでしょうか？しょせん後藤氏は、
　・技術的素養なし
　・取材費は雑誌社持ち
　・インタビューで仕入れたネタ以外何も無し
ですが、Carlieは映画に出てくる新聞記者並みに取材してますよ。もちろん最近の代表先はコレ。
http://www.theinquirer.net/inquirer/news/052/1050052/nvidia-chips-show-underfill-problems
「ペンは剣より強し」という言葉をこの現代で繰り返すことになるとは思いませんでした。

東芝の諫早はどうなっちゃうの？エロイひとおしえて

>>802
英語圏のライターと日本語圏のライターというハンデもあるだろうに

>>804
配線層の断面写真程度なら、取材費があって、そこそこの大学や研究所にツテがあるなら
撮影はできます。
言語の問題とは思えませんが…

後藤氏に関しては、そもそも業界のツテと英語が出来るというのが唯一の取り得のような気が.…
結局その『ツテ』もジャーナリズムとはとても呼べない広報レベルに過ぎないということで。

息を吐くように嘘をつく典型的ゴシップ記者じゃん

>>803
「え？あそにおると？！」って諫早のエロい人が言ってたよ。

ペンは剣より強しの意味を調べた方がいいんじゃね

>>804
それがハンデになるようじゃただの無能者だな。いや、言うまでもなかったか

ハンデはハンデだろ

>>813&814
ここでクダ巻かずに、impressに連絡するといいよ
もちろん、公開質問状(呼び方はさておき)としての2ch書き込みならわかるが

どうでもいいじゃん、どうせ失敗作なんだし

Larrabeeなんていつ出るんだよ
いつまで経っても出ないんだろどうせ

GK参上かよ

LarrabeeってCGのどっかとスパコンのどっか既に契約取ってなかったっけ？

ララビーよりビラビラのが好きだな

理解力がないな。むしろ学が無いな

128ビット全ベクトル操作して1要素分の結果だけを使うのをスカラ処理って言っていいなら
この世のベクトルプロセッサは全てスカラプロセッサだな（笑）




誤答の今回の詭弁「コントロールフローのムダ」について
もうちっとフォローしとこうか。

必要なのは32ビットだけであっても、128bitのSIMD演算しか使えないから、残りの96ビット分、
捨てられるデータがALUに投入され、演算処理が行われ、デスティネーションレジスタに吐き出される。
これは明らかに「ムダ」なんだよ。

さて、IntelのCPUでは、SSEはもちろんAVXでも相変わらず、スカラ演算専用命令がサポートされます。
理由はもちろん、「コントロールフローのムダ」（笑）を省くためです。
結局無駄が生じるかどうかは、ベクトル長ではなく、サポートするインストラクションによって決まる
ものであって、全エレメントきれいに埋められないのであれば、よりデータフローの小さい命令を
明示的に使うことで、無駄は省けるわけだ。
256ビットで大きすぎるなら128ビット、それでもまだ粒度が必要ならスカラですよ。

その点において常に128ビット単位でしか演算できない上に命令間のレイテンシすら他のCPUと比べても
大きい、「コントロールフローのムダ」の塊のCellを引き合いに出すのはお門違いなわけで。

また始まったよ
死ねばいいのに

でもこの人詳しいなあ
感心する

http://pc.watch.impress.co.jp/docs/2009/0305/kaigai08.pdf

このへんの図って本人解って書いてるのかってたびたび思うんだけど
IBMのマニュアルにまったく同じダイアグラムが書いてあるんだよね。

まあそのまま転載すれば権利問題でうるさいから自分で頑張って手作業で描きました
ってところなんだろうけど、理解して書いてるのか、最近の言動見てると怪しい

>>822
　　-----------------
　　この世のベクトルプロセッサは全てスカラプロセッサだな（笑）
　　-----------------
自慢しているのはIBMなんですから、文句を言う先は別だ…という話です。
それともおなじクレームを英語で書くのは無理でしたか(笑)

IBM自体は何もおかしなことは言ってないよ。
スカラ「命令」なんていってるのは誤答だけだし。



ちなみに別に英語で聞く必要もないね。
土居さんあたりにでも聞けばいいと思うよ

>>827
　　------------------
　　ちなみに別に英語で聞く必要もないね。
　　土居さんあたりにでも聞けばいいと思うよ
　　------------------
論文のトップネームに価値があるように、この世界には『文責』という概念があるのですよ。
>>821のリンク先の文章の場合、連絡先が書いてあるMichael Gschwind氏に質問するのが
正当というものです。

大物ですので、もし相手をしてもらえればよい経験になると思いますよ。
http://domino.watson.ibm.com/comm/pr.nsf/pages/bio.gschwind.html

くどいようだが【何も間違ったことは言ってないぜ】
曲解してるのはお前と五等だけだよ。

いかくさい。あっち池。しっし

MACオタは相変わらず揚げ足取りみたいな事しかしないなぁ

>>830
馬鹿だから仕方ない

揚げ足取りするのはどっちも得意だけどね

"scalar layering"
って、高級言語レベルのスカラ演算を、高級言語のコンパイラが、プリファードスロットを用い
残りの要素スカスカのSIMD命令のシーケンスに展開しますよ的な、当たり前の話で、
別に技術的に見所の有る話ではない。
ネイティブ命令セットレベル・アーキテクチャレベルでどうこうするって話じゃないよ。

その「ハード支援なきスカラ・レイヤリング」の結果が、ロード・ストアがクソ遅いという
現実だったり、常に128ビットのデータフローが発生するけど電力効率的にどうよ？
って話しなわけ。

そんなに英語が自慢なら俺へのレスは全て英語で書いてくれ。
日本語もどきを喋られるのは目障りでしょうがない。

今回に限っては団子支持。MACオタは見苦しい。

そうでもない
面と向かったケンカから逃げるいつもの団子が見られただけｗ

限るなよ

喧嘩にすらなってねーけど。敗走したのは負け犬

冷静に読んでくれればわかるが俺にはMichael Gschwindに文句を言う理由は微塵もないわけで
自分がやりもしないことを他人に要求するのは言い出しっぺの法則通りだな。

いいや。

スカラ演算を自動的にベクトル化するなら実用性はあるけど、第一要素以外使わないベクトル化が
イノベーションなんてギャグの範疇でしょ
そのたった2行で笑い飛ばせるような内容にわざわざ長文メールなんて送る価値は無いよ。
所詮その程度だし


俺は後藤は大衆に影響力のある記事を書ける人間と評価してます。
評価してるからこそ挑む価値があるのです。
そもそも今回のは動機が>>815だし、突っ込みどころが満載すぎた。

いやしかし、その発想でいいならほとんどの整数演算をSSE化できるわｗｗｗ
max/minや簡単な比較・選択命令ならx86スカラよりは若干速くなりそうだけどな

それって石から見ると普通の演算と節約された演算はどうやって見分けるん

っと、ハードから見た「見分け」だったかな。
できないよ。だから常に128ビットのデータフローが発生するって言ってるの。

てか、CellのSPEってあからさまに1コアをPowerPC未満のトランジスタ数で実装することしか
考えてないでしょ。コアサイズを削ってSIMDとマルチコアに賭ける理想主義。
多コア化によるスケーラビリティの向上に行き詰ったらその時点で終了なアーキテクチャ。

その意味でLarrabeeは現実主義なんだよね。
1コアあたりのトランジスタ数をリッチに割り振ったCore系列のアーキテクチャにも
Larrabeeの命令セットは実装できる。
ムーアの法則がもたらす進化を、コア数を増やす以外の方向に割り振れる。
ModRM+SIB+DISPによるアドレッシングって直列方向のコード密度を高める点で
かなりパフォーマンスに寄与してる。

>>847
英語は割とダメダメみたいだな。ま、実にどうでもいい事だが

そういうのは英語で言うと説得力が出るんじゃね