先日、たまたま、てんかんの症例や治療についてのセミナーがあった。
てんかんは、自分とは直接関係する研究ではないが、脳研究に携わると話を聞く機会が結構ある。
病気というのは、正常に機能すべき部分が、うまく働かないために起きるから、そもそもどのようにして働いているかわからない対象(脳とか遺伝子)を研究をする人にとっては、その情報を得ることは対象の機能の解明する助けとして非常に重要である。
そういうわけで、てんかんのお話に対して、脳の研究する人は非常に関心を持つもので、実際、セミナーは大盛況であった。
興味や関心を持つといっても、症例を聞くとなかなかつらい気持ちになる。てんかんの患者さんは本当に大変である。いきなり意識を失うような場合、命にかかわるような事故にあう危険もある。
てんかんには、実に様々な症例がある。というのも、脳というのは、感情、想起、学習、感覚、意識など、本当にいろいろな情報処理をつかさどっているため、いろいろな機能と関連したてんかんが起きるのだ。たとえば、笑いながらてんかんになるとか、物を食べるとてんかんになるということがあるらしい。
てんかんというのは、おおざっぱにいえば、神経細胞が共同して発火しすぎる現象だ。脳は莫大な数の神経細胞で並列処理を行うので、そういう危険はもともと起きやすいのだと思う。ちょっと違うかもしれないが、たとえば惑星が集まりすぎて、つぶれてブラックホールになるとか、並列計算機で一つのノードにデータ転送が集中して、その処理が律速するとか、ネットのブログが炎上するとか、並列な現象があるところで起きる危機的な現象と似ている。
ここまで進化してきた脳が、こういう危機を克服できず、患者数も世界で膨大にいるらしい。逆にこれだけ進化したから、こういう問題は起きてきたともいえるが。このように脳は並列処理をするが故に、難題を抱え続けているといえるだろう。同じ問題は、これからのマルチコアのコア増加においても発生するのだろうと思う。まず、コア間のバスの転送速度が速くなる限界というのにぶち当たっていくというのがあるだろうが、それをなんかしらの手段で克服すると、次には動的にトラフィックが一か所に集中したとき、クライシスが起きるということが問題になり始めるんじゃないだろうかと思う。そういうことは、もちろん、もうインターネットの世界では普通にアクセス集中という形で起きているし、現時点でも下手なコードを書くとマルチコアプロセッサでは効率低下が起きる。GPUでは、その実体験を自分もしたんだけどね。
こうして考えていくと、やっぱり、並列計算では、個々のプロセッサの処理能力というのはそこそこでいいのだと思う。問題は、いかに結合を作り、データ転送をするかなのだと思う。または、ネットワークでうまく働くような、プロセッサの質的変化を考えるべきなのかもしれない。神経細胞はそうだし。
ということで、本日の主張:
プロセッサ業界よ、脳研究者を雇用するのだ!!!
2009年1月6日火曜日
昔のMacintosh
たまたま昔のMacの仕様をみかけた。
CPU:68000
クロック周波数:7.83MHz
RAM:512KB
フロッピーディスク:400KB
RAMが512KBしかなかったんだなあ。
でもこうしてみてみると、性能が桁違いに増えて、できることは変わったかというと、桁違いには変わってないんじゃないかと思う。
もちろん質的変化というか、格段にやれることは増えたけど、千倍とか100万倍とかっていう感じじゃない気がする。
そうやって考えると、15年後の世界も少し見えてくるかな。
CPU:68000
クロック周波数:7.83MHz
RAM:512KB
フロッピーディスク:400KB
RAMが512KBしかなかったんだなあ。
でもこうしてみてみると、性能が桁違いに増えて、できることは変わったかというと、桁違いには変わってないんじゃないかと思う。
もちろん質的変化というか、格段にやれることは増えたけど、千倍とか100万倍とかっていう感じじゃない気がする。
そうやって考えると、15年後の世界も少し見えてくるかな。
2009年1月3日土曜日
LSとレジスタ
最近、Cellでまたプログラムを組んでいる。今回は、あるニューラルネットみたいなもんなんだが、今までになく、演算が軽くてデータ転送は多い。
なんとか、データ転送が律速にならないように、まとめてLSに転送したり、何回も利用したりして、なるべく転送を減らしている。
そうこうして、LS<->DRAM間のDMA転送はかなり量を減らして、こりゃいけると思ったら、今度はLSからレジスタへのロード/ストアが律速になっていることが判明。
LSとレジスタの間の転送量ってそこまで気にしてなかったので、調べるとどうやら片方向16B/cycleらしい。
ということはだ、spu_maddで、毎サイクルLSにある違うベクトルに対して、2命令同時実行で読み書きはできないっちゅうことだ。なんてこったい!
これは結構きつい。まえから、なんとなく、うすうす感づいてはいたのだが、そこまでロードと演算の比が厳しいアプリケーションは今までなかったのだ。画像処理で少しあったけど、ここまで厳しくはなかった。
それで、いろいろどうすっぺかとコードを見て、結局なるべくレジスタにデータを乗せといて、ぐるぐる使えるようにするのがいいということに行きつく。うう…、辛い。だって、のせないと性能が1/5~1/10とか平気で落ちるが、そんな努力をしろと(涙)。しかし、いろいろやってるとちょっとずつ改善したりして、なんだかんだいって、まだいける、まだいけると、どんどんどつぼに。
どうやら、Cellのスカラデータのロードストアはかなり遅いらしい。たしかに、スカラデータを使っていたら、予測以上に性能が落ちていて謎だったのだ。
そんでスカラをベクトルデータにしたりするが、今度は、LSの容量が足りなくなってくる。
はー、もういや
なんとか、データ転送が律速にならないように、まとめてLSに転送したり、何回も利用したりして、なるべく転送を減らしている。
そうこうして、LS<->DRAM間のDMA転送はかなり量を減らして、こりゃいけると思ったら、今度はLSからレジスタへのロード/ストアが律速になっていることが判明。
LSとレジスタの間の転送量ってそこまで気にしてなかったので、調べるとどうやら片方向16B/cycleらしい。
ということはだ、spu_maddで、毎サイクルLSにある違うベクトルに対して、2命令同時実行で読み書きはできないっちゅうことだ。なんてこったい!
これは結構きつい。まえから、なんとなく、うすうす感づいてはいたのだが、そこまでロードと演算の比が厳しいアプリケーションは今までなかったのだ。画像処理で少しあったけど、ここまで厳しくはなかった。
それで、いろいろどうすっぺかとコードを見て、結局なるべくレジスタにデータを乗せといて、ぐるぐる使えるようにするのがいいということに行きつく。うう…、辛い。だって、のせないと性能が1/5~1/10とか平気で落ちるが、そんな努力をしろと(涙)。しかし、いろいろやってるとちょっとずつ改善したりして、なんだかんだいって、まだいける、まだいけると、どんどんどつぼに。
どうやら、Cellのスカラデータのロードストアはかなり遅いらしい。たしかに、スカラデータを使っていたら、予測以上に性能が落ちていて謎だったのだ。
そんでスカラをベクトルデータにしたりするが、今度は、LSの容量が足りなくなってくる。
はー、もういや
ガンズアンドローゼズ
このまえ近くのジャスコにいったら、ガンズの新譜のポスターが貼ってあった。
その前で5才くらいの子が、
「お母さんこれ、かっこいい、かっこいい~」
と、泣きながらお母さんに訴えていた。
お母さんはわかった、わかったからもういくよと、泣き叫ぶ子を無理やり引っ張っていきました。
やっぱ、ガンズすげー!!!
その前で5才くらいの子が、
「お母さんこれ、かっこいい、かっこいい~」
と、泣きながらお母さんに訴えていた。
お母さんはわかった、わかったからもういくよと、泣き叫ぶ子を無理やり引っ張っていきました。
やっぱ、ガンズすげー!!!
2008年12月17日水曜日
LarrabeeとCell
http://pc.watch.impress.co.jp/docs/2008/1217/kaigai481.htm
抜粋
仮想マシンを走らせるCPUコア間では、キャッシュの間でコヒーレンシを保つ必要がない
なるほど、そりゃそうだ。そういう発想はなかったわ~(おれ、あほ?)。
コヒーレンシを限定的にするという方向が、究極までいくとLSになるわけか。これはいいかもしれない。でも、それって実装はそんなに簡単にできるもんなんだろうか…?
まあ、それは置いとくとして、思ったのはLarrabeeはCPUとCellの間なんだなってことだ。
CPU -Larrabee -Cell- GPU
でも、CellはCPUで、LarrabeeはGPUと。
Cell2はGPUとCPUのどっちの方向にむかうだろう。PPE強化という点では、CPU的な性能が強化される。SPEの数が増えるので、GPU的になるといえばなるが本質じゃない?はて。
LSが増えたら、どっちだろう?どんなインパクトを持つだろう?1MのLSを持つSPEって意味あるだろうか?うーん、本質的ではないような気もするが。まあ、どうせ無理かな。よくて倍増だろう。いやそれもないな。
それにしても、ここまで似てるなら、OpenCLでCellとLarrabee用で同じ最適化オプションとかできそう。どうなることやら。
抜粋
仮想マシンを走らせるCPUコア間では、キャッシュの間でコヒーレンシを保つ必要がない
なるほど、そりゃそうだ。そういう発想はなかったわ~(おれ、あほ?)。
コヒーレンシを限定的にするという方向が、究極までいくとLSになるわけか。これはいいかもしれない。でも、それって実装はそんなに簡単にできるもんなんだろうか…?
まあ、それは置いとくとして、思ったのはLarrabeeはCPUとCellの間なんだなってことだ。
CPU -Larrabee -Cell- GPU
でも、CellはCPUで、LarrabeeはGPUと。
Cell2はGPUとCPUのどっちの方向にむかうだろう。PPE強化という点では、CPU的な性能が強化される。SPEの数が増えるので、GPU的になるといえばなるが本質じゃない?はて。
LSが増えたら、どっちだろう?どんなインパクトを持つだろう?1MのLSを持つSPEって意味あるだろうか?うーん、本質的ではないような気もするが。まあ、どうせ無理かな。よくて倍増だろう。いやそれもないな。
それにしても、ここまで似てるなら、OpenCLでCellとLarrabee用で同じ最適化オプションとかできそう。どうなることやら。
2008年12月16日火曜日
2008年12月7日日曜日
ぼーっとしていると今年も終わり
最近、いろんな忙しさが少しおさまり、燃え尽きちまったぜな感じ。でも本当はぼーっとばかりもしていられないんだけどなあ。もう疲れた。
そんなときは、何も考えずに、OSでもインストールすりゃいいんですと、PS3×6台にLinuxインストール。いまだにFedora core 6とSDK2.1を使っている私。
そんで、久し振りOpenCV on the Cellもインストール。やり方を忘れてたが、まあすんなりできた。よかった、よかった。このまえ、質問してきた人はうまくできたんだろうか?すこし気になるが、返事がないからできたんだろう。
今年はずいぶんPS3にLinuxをインストールしたな。20台近くしているな。なんも偉くもないけど、えらい気がするよ。少し空しいけど。
あと、CUDAもずいぶんインストールしたな。今、GT200がまわりに10枚以上はあるので、10TFLOPSですね。自慢。俺のじゃないけど。CUDAはインストール簡単だから別にそんなに苦労してない。
Cell×15=3TFLOPSとあわせて13TFLOPSくらい。すげー。
しっかし、GPUの進化は本当に早い。去年の今頃初めて、いつのまにかCUDAのバージョンも2.0になっちゃって、環境も知らないうちにいろいろ進化している。Global memoryのCoalesceさせる条件とか変わってて、知らずに最適化するところだった。わりと条件がゆるくなってよいな。Bank Conflictの条件も変わった?もともとあんまりそこら辺を把握してなかった可能性もある。もう一回くらい、プログラミングテキスト読んだほうがいいな。
GT200って、やれることは、G80世代から大きくは進化しているように見えない。見えない部分で根本的に変えているところとかあるんだろうけど、つかってる側からしたら、規模が倍に増えただけにしか感じない。もちろん倍精度ができるようになったとかあるけど。
今度はどうなるかなっていうのが、やっぱり気になってくる。個人的には、Shared Memoryが増えてくれないかなといっつも思う。CellでもLS増えないかなともいっつも思うように。これは、みーんな思っていることだけど、なかなかかなわない。互換性の問題?十分だという判断?うーむ。
あと、SM間の直の通信とか、SMの独立性をあげるとか、より汎用的なマルチコアみたいになる可能性ってあるんだろうか?これに舵を切ったら、完全にCellみたいになってしまうので、意味があるのかわからないけど、どうなんだろう。でも、そんな能力はGPUでは無意味だろうか?
やっぱり、GPUである以上、そのメインの使い方がどうなるかっていうのが、まずありきで、そこから汎用的な使用にすり合わせられるわけだから、そこがどうなるかという、市場の要請みたいなのを一番に考えて予測するべきだろうか。だとすれば、unreal engineの人の講演の話ででている、より柔軟なGPUの道がこれからのメインストリートだろう。だとすれば、やっぱりCell的にならざるを得ない。
そうすると、やっぱりCPUとGPUとの汎用性の差というのの境界がどんどん近付いてきて、GPUが消滅するっていう話になったりするが、そうなんだろうか?そしてCPUとGPU混合というストーリー。
でも、GPUとCPUの割合が、固定っていうのがうまくいくのだろうかと、いつも思う。それは、人やアプリケーションによって全然変わってくるから、難しい。
だから、FPGAみたいに一部のロジックを可変にして、ある時はCPU、ある時はGPUみたいなのを動的に変えられないだろうか。CPUの有利な処理のときは、大きなCPUを10個。GPUの有利な処理のときはCPU2個、GPU1000個とか。
そしたら、結局、全部FPGAでやれってことになるんだろうか。っていうか、そんな動的なシステムできるわけないか。
いや、そもそも、CPUとGPUの違いって言ったら、逐次か並列化ってのが大きな違いで、CPUは多くても数個で事足りる?どんどんわけがわからなくなってきた。
そんなときは、何も考えずに、OSでもインストールすりゃいいんですと、PS3×6台にLinuxインストール。いまだにFedora core 6とSDK2.1を使っている私。
そんで、久し振りOpenCV on the Cellもインストール。やり方を忘れてたが、まあすんなりできた。よかった、よかった。このまえ、質問してきた人はうまくできたんだろうか?すこし気になるが、返事がないからできたんだろう。
今年はずいぶんPS3にLinuxをインストールしたな。20台近くしているな。なんも偉くもないけど、えらい気がするよ。少し空しいけど。
あと、CUDAもずいぶんインストールしたな。今、GT200がまわりに10枚以上はあるので、10TFLOPSですね。自慢。俺のじゃないけど。CUDAはインストール簡単だから別にそんなに苦労してない。
Cell×15=3TFLOPSとあわせて13TFLOPSくらい。すげー。
しっかし、GPUの進化は本当に早い。去年の今頃初めて、いつのまにかCUDAのバージョンも2.0になっちゃって、環境も知らないうちにいろいろ進化している。Global memoryのCoalesceさせる条件とか変わってて、知らずに最適化するところだった。わりと条件がゆるくなってよいな。Bank Conflictの条件も変わった?もともとあんまりそこら辺を把握してなかった可能性もある。もう一回くらい、プログラミングテキスト読んだほうがいいな。
GT200って、やれることは、G80世代から大きくは進化しているように見えない。見えない部分で根本的に変えているところとかあるんだろうけど、つかってる側からしたら、規模が倍に増えただけにしか感じない。もちろん倍精度ができるようになったとかあるけど。
今度はどうなるかなっていうのが、やっぱり気になってくる。個人的には、Shared Memoryが増えてくれないかなといっつも思う。CellでもLS増えないかなともいっつも思うように。これは、みーんな思っていることだけど、なかなかかなわない。互換性の問題?十分だという判断?うーむ。
あと、SM間の直の通信とか、SMの独立性をあげるとか、より汎用的なマルチコアみたいになる可能性ってあるんだろうか?これに舵を切ったら、完全にCellみたいになってしまうので、意味があるのかわからないけど、どうなんだろう。でも、そんな能力はGPUでは無意味だろうか?
やっぱり、GPUである以上、そのメインの使い方がどうなるかっていうのが、まずありきで、そこから汎用的な使用にすり合わせられるわけだから、そこがどうなるかという、市場の要請みたいなのを一番に考えて予測するべきだろうか。だとすれば、unreal engineの人の講演の話ででている、より柔軟なGPUの道がこれからのメインストリートだろう。だとすれば、やっぱりCell的にならざるを得ない。
そうすると、やっぱりCPUとGPUとの汎用性の差というのの境界がどんどん近付いてきて、GPUが消滅するっていう話になったりするが、そうなんだろうか?そしてCPUとGPU混合というストーリー。
でも、GPUとCPUの割合が、固定っていうのがうまくいくのだろうかと、いつも思う。それは、人やアプリケーションによって全然変わってくるから、難しい。
だから、FPGAみたいに一部のロジックを可変にして、ある時はCPU、ある時はGPUみたいなのを動的に変えられないだろうか。CPUの有利な処理のときは、大きなCPUを10個。GPUの有利な処理のときはCPU2個、GPU1000個とか。
そしたら、結局、全部FPGAでやれってことになるんだろうか。っていうか、そんな動的なシステムできるわけないか。
いや、そもそも、CPUとGPUの違いって言ったら、逐次か並列化ってのが大きな違いで、CPUは多くても数個で事足りる?どんどんわけがわからなくなってきた。
登録:
投稿 (Atom)