アカウント名:
パスワード:
で、ベクトル化できるプログラムって結構限られてて、それは簡単に言えば、独立に並列処理できるコードなんですよね。
そんな感じで、僕の中ではベクトルマシンは通信オーバーヘッドの無いクラスタマシン、みたいな扱い
科学技術計算とは言え、オブジェクトや複雑なデータ構造を駆使するプログラム、ネットワーク、データベース、グラフィックスを組み合わせた技が必要になっているのに、ベクトルスーパーコンピュータ上のレガシーなソフトウエアに固執することによって進歩が阻害されてしまう。
ちっこいベクトルスーパーコンピュータを10人くらいでシェアしたとしたら、PC2-30台のクラスタと同じくらいの性能になってしまう。コモディティ部品でで自分で組み上げたのでは通信などいろいろボトルネックはあって、すぐにベクトルを置き換えるわけにはいかないけど、誰に気兼ねする事もなくいろんな使い方を試してみる事が出来る。MPI、グリッド的なもの、分散オブジェクト、Webサービスなど実にいろいろなものがある。相当な気合いとスキルが必要だけれど、得るものは非常に多いと思う。ベクトルコンピュータを使い続けるのはメリットよりデメリットが多いと思う。
個別の対象に依存すると思うけど、別の所にいる誰かが作った大きなデータを入力とした計算をしているが、その誰かも研究をしていて日々データが更新されているので、気が付いてみるとどういうデータを使って計算していたのかわからなくなっているというよう経験はないかなあ？ データベースとネットワークの技術はそういうこんがらがりを解決し、最も正しいデータをプログラムに直に取り込むために使う。
温度とか速度とか直観的な量じゃなくて、抽象的なデータを扱おうとすると、可視化を設計しないと仕事が始まらないことがある。出来上がった物を見るだけでなく、計算の実行途中にどこで何が起こっているか知りたいことも多い。計算が大規模で時間がかかる時はなおさら。
確かに、データベース、ネットワーク、グラフィックス自体は、ベクトルかクラスタか関係ないけど、だいたいクラスタの世界で語られるのでそちらの話みたいに言うというのはあるかも。
ベクトルとクラスタやPCの世界の微妙な違いを強調するのが良いか分からないけれど、僕の場合、最近データをwebサーバー配下に置く事が多い。Appletでwebページ上で可視化できるほか、リモートのJavaプログラムでローカルファイルシステムと同じようにアクセスできるから。コピーを作らないのは、入力データの場合と同じようにわけがわからなくならないようにするため。さらにサーバーサイドで可視化すると大きなデータを扱う時などの柔軟性が増す。開発環境の構築でつまづいてまだできていないけど。
ベクトルのシステムでもnfsで他のマシンとディスクを共有したり、フロントエンドでwebサーバーを立てても良いと思うが、nfsサーバーが倒れた時の面倒臭さとか、限界があると思う。
RISCとCISCのときも「RISCの優位は揺るがない」といわれていたのにもかかわらず，RISCが敗北していたように思うのですが
ベクトル型スーパーコンピュータの話題からは離れてしまいますが、現在純粋なCISCプロセッサというのも存在しないのでは？というかそもそもRISC/CISCの分類自体が意味のないものになってしまってます。
RISCプロセッサの特徴として一般によく挙げられるものに、
マイクロプロセッサ関連については、海外のアレゲな人が Great Microprocessors of the Past and Present [sympatico.ca] という文章（英文）をまとめてたりします。"For entertainment use only"なんて断り書きがありますが、非常に面白い内容ですので興味が湧いたらどうぞ読んでみて下さい。
＃ ベクトル型プロセッサとは関係ない文章になってしまったのでAC（といって、無益な内容でもないと思うんだけどね）
RISCとCISCのときも「RISCの優位は揺るがない」といわれていたのにもかかわらず，RISCが敗北していたように思うのですが.
時代が，クロック数の競争から，同じクロックでいかに性能を出すかという方向に 進みつつある現状をみると，あながち間違ってもいないのかな，とかおもったり。
それと、今後は専用チップの作成コストが下がって、特定の計算向けカスタムチップを作るのも現実解になってくるんじゃないでしょうか? こうなると CISC vs RISC とはちがう方向かな。 ただ、こういう専用チップを、たれこみネタの大規模シミュレーションに使えるかどうかというのは、また別かも知れない。GRAPEのように完全に対象を絞れば別ですが、比較的汎用を目指したシミュレーションを考える場合、どうしてもアルゴリズムとの擦り合わせが問題になってくる。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
スーパーコンピュータの分野で (スコア:4, すばらしい洞察)
(マルチメディア処理向け命令のあたりとか)
GPUがベクトルプロセッサ化しているという話 [impress.co.jp]もあるし
あぁ、「ン」が消えてるんですよ。「ビーフン・カレー」ね。
Re:GPUがベクトルプロセッサ化しているという話 (スコア:1)
ACM Workshop on General Purpose Computing on Graphics Processors
http://www.cs.unc.edu/Events/Conferences/GP2/program.shtml
まだまだ汎用とは行かないが。DB検索とか、昔のアイデアの
発掘とかあるようです。
ベクトル化 (スコア:3, 参考になる)
早くするにはプログラムをベクトル化 しなくちゃいけません。
で、ベクトル化できるプログラムって結構限られてて、 それは簡単に言えば、
独立に並列処理できるコードなんですよね。
そんな感じで、僕の中ではベクトルマシンは 通信オーバーヘッドの無いクラスタマシン、
みたいな 扱いなんですが、ベクトル化のプロみたいな人は 違うのかな。
Re:ベクトル化 (スコア:4, 参考になる)
ハードの資源(加算機やシフターなど)をうまく使い分けないと，
ベクトルが途切れて性能が出ないんで，結構大変でした．
ちょっと事情があって，使えるコンパイラがなかったんですよね．
命令列をうまいこと並べれば，並列処理以外でも使えますよ．
Re:ベクトル化 (スコア:1, 興味深い)
Re:ベクトル化 (スコア:2, 参考になる)
(基本的には)相互作用のないループなので、
Fortran で書くなら
do i=1,N
A(i) = B(i) + C(i)
enddo
みたいな感じですよね。これ、適当な範囲ごとに
きれば、そのまま並列化できるわけです。
逆に、並列化可能なループしかベクトル化できない、
という印象があります。特にソートができないのが
きつい。そういう意味でベクトル化と並列化は
似てるかなぁ、と思ったうえでの発言でした。
#ベクトル化されたソートライブラリはあるが、
#ベクトルパイプラインを全然活かしきって無いので遅い。
Re:ベクトル化 (スコア:1, 興味深い)
大学時代に他人の卒論研究のコードのデバッグをしてたのですが、
大型計算機センターでスーパーコンピュータが使えるというので、
それをネタにいろいろ遊んでました。
コンパイラ通すとベクトル化できる部分にVマークが付くので極力付くようにソースを書き換えたり、ループを解いて巻きなおしたりしてました。
ループ内はベクトル化できるくらいに短く、かつループ回数は極力長くなるように書くのがこつでしたっけ？
逆にクラスタ化というかマルチプロセッサ化はループの中は長く、かつ外のループは分割してパラレルに回しても大丈夫するってのが面倒だったような。。。
Re:こりゃまた香ばしい釣り師だな。 (スコア:1, 参考になる)
ベクトル化してもクラスタで性能出るはずないんですが。
ベクトル化の意味を間違えて覚えているとしか思えん。
ベクトルプロセッサで性能出したかったら、ちゃんと最適化されたライブラリを使うかアルゴリズム自体をベクトルプロセッサ向きのものにするのが当たり前でしょう。
なんかスカラープロセッサ向けのプログラムに小手先の修正を加えて性能でないと言っているようにしか見えんですな、この kaityo って人の話は。
HotWiredって (スコア:3, 興味深い)
このニュースも，クレイは実はNECのOEMを販売してましたなんてことには触れられていないし，
米国のベクトル型=クレイ社がどうなるかしか気にしてない感じがしなくもない．
というだけではなんなので，２年前ですが地球シミュレータがTop500に登場した頃の，日本における記事を．
科学技術計算で日本の優位が揺るがない理由 [nikkeibp.co.jp]
時流に流されなかった開発・地球シミュレータ [www.ne.jp]
Re:HotWiredって (スコア:1)
しかも、それを翻訳された文章で読めるなんて。
一時狭窄的に決定したことが「誤りであったかも」と認め、
対策が必要だが、しかし将来は不透明とする論調はなかなかよいですね。
危機感というか、そういうものが感じられて。
Re:HotWiredって (スコア:1)
> しかも、それを翻訳された文章で読めるなんて。
はい，そう思います．
そんな議論してんだ凄いなというのと，今更この人は何言ってるんだというのがあって，楽しめます．
タレコミは「米国の」を忘れて，一般化しているように思えたのが気になったりしたのでした．
Re:HotWiredって (スコア:0)
暗号を解読するのに高速な浮動小数点演算は要らなさそうだから
FLOP値が高いマシンを発注する意義がよくわからない。
大量の音声・画像データの解析を必要とする用途 [google.com]なら
グリッドのほうが低コストだろうし…。
Re:HotWiredって (スコア:1, 参考になる)
このとき高速な実数演算が必要となります。
今は昔 (スコア:2, 興味深い)
そのココロは工場の資材所要量計算や生産スケジューリング(所謂MRPですな)なんかを時間の掛かるディスクI/Oじゃなくて、でかい配列作って一気に計算で処理時間短縮のようでした。(普通のMRPはやたらにディスクI/Oが多くて、一晩位平気で掛かる)
スーパーコンピュータのフロントエンドエンジンがメインフレームだった頃に出来た力技でした。
Re:今は昔 (スコア:0)
鶏ですぜ (スコア:0)
オフトピ (スコア:0)
Re:オフトピ (スコア:0)
MRPが鶏とは思えない。
Re:オフトピ (スコア:0)
今日の応用物理学会スクールA (スコア:1, 興味深い)
*地球シミュレータはパソコン何台分か？
*答え：パソコンを何万台、何億台持ってきても、地球シミュレータにはならない
*理由：地球シミュレータはひとつの大規模な計算を行う装置、パソコンを何億台集めて繋いでも、ひとつの大規模な計算を行うことは実質的に不可能
・・・と、力説？してありました。この垂れ込みを見ていろいろあるんだよなあと・・・。
間違ってもハンドルで書けないのでAC
「いろいろあるんだよなあ」の意味がつかみかねますが (スコア:1)
> *答え：パソコンを何万台、何億台持ってきても、地球シミュレータにはならない
> *理由：地球シミュレータはひとつの大規模な計算を行う装置、パソコンを何億台
> 集めて繋いでも、ひとつの大規模な計算を行うことは実質的に不可能
>
> ・・・と、力説？してありました。この垂れ込みを見ていろいろあるんだよなあと・・・。
垂れ込みで示されているリンク先にも以下のようなものがありますよ。
< ... ホワイト氏によると、このような問題はクラスター型コンピューターでは
< 効果的に処理できないという。
<
< 「クラスターをどれだけ巨大にしても同じことだ。アプリケーションの速度は
< 落ち、同期や通信にばかり時間を費やすことになる」とホワイト氏。
<
< ホワイト氏は、クラスターを構築できる規模には限界があると考えている。...
そういうことじゃない?
コミュニケーション・コスト (スコア:1)
人が多い大きなプロジェクトほど、コミュニケーションに必要な時間は増えてゆく。
距離が離れれば離れるほど、情報交換(通信)に必要なコストは高くなる。
人間の質が低いと、いくら数が増えても成果は上がらない..
ベクトルプロセッサは、少数精鋭ですね。
必要な分野は確かにあるが (スコア:1, すばらしい洞察)
すアプリケーションは限られるし、少しばかり効率を落とそうとも、
遥かに安いクラスタで処理できるように出来る。民間企業は当然買わ
ないし、公的研究機関でも効率的な予算配分を考えれば買わない。
赤字になりながら作るか、補助金をもらって作るしかない。政府予算
による地球シミュレータの構築なんて、税金垂れ流しの典型。世界一
というプライドは保てるけど、それだけ。もうアメリカではベクトル
を作る会社は出ないだろうし、また、米国政府の無駄な予算だと判っ
ているので、そんなところに金はつぎ込まないだろう。そこで日本は
世界一と勘違いしているのは、とても痛い。
Re:必要な分野は確かにあるが (スコア:1, 参考になる)
> すアプリケーションは限られるし、少しばかり効率を落とそうとも、
> 遥かに安いクラスタで処理できるように出来る。民間企業は当然買わ
> ないし、公的研究機関でも効率的な予算配分を考えれば買わない。
なんで断言できるのかなあ。
そこそこ大きめの大学なら、必ずスパコン持っているし、
とくに地球シミュレータを切り売りしているような NEC SX7 を
導入したい大学なんてたくさんあるのに。
あと流体計算の必要な企業ならSX7は欲しいでしょう。
スパコンをパソコンの高機能版だと思っている人には、
要らないように思えるんだろうなあ。
スパコンじゃないとできない計算なんてたくさんあるのに。
Re:必要な分野は確かにあるが (スコア:1, 興味深い)
とりあえず昔と比べて台風の進路予測は格段に精度が上がった様に
見えますね。今回の16号の進路なんて「そこで右にカーブする？？」と
思った予測どおりに進みましたし、数日前でも予測が付けば
災害の備えってのはしやすくなるものです。
不測の針路変更で大被害！なんてのだと被害額に数億は軽く加算されますから、
そういう意味では気象予測に金を掛ける価値はありますね。
もっとも予測どおり来られても避けられない被害ってのは発生しますけど。
Re:必要な分野は確かにあるが (スコア:1, 参考になる)
> ベクトルプロセッサを生かすアプリケーションは限られるし、
普通は自分で計算プログラムを作るんですよ。
もちろん、ベクトル化、並列化もきちんと考えて。
それか、すでにベクトル化並列化された先人のプログラムを使います。
なければ自分で作るだけ。科学技術計算のプログラムなんて、
高々数万行程度なので頑張れば一から作れます。
> 少しばかり効率を落とそうとも、
> 遥かに安いクラスタで処理できるように出来る。
そんなことはありません。
高度にベクトル並列化されたプログラムを
クラスタに移しても計算は終りません。
ベクトル計算部分をさらに並列化しないといけないし、
PC間の通信速度がネックになって、それほど速くなりません。
Re:必要な分野は確かにあるが (スコア:1)
科学技術計算とは言え、オブジェクトや複雑なデータ構造を駆使するプログラム、ネットワーク、データベース、グラフィックスを組み合わせた技が必要になっているのに、ベクトルスーパーコンピュータ上のレガシーなソフトウエアに固執することによって進歩が阻害されてしまう。
ちっこいベクトルスーパーコンピュータを10人くらいでシェアしたとしたら、PC2-30台のクラスタと同じくらいの性能になってしまう。コモディティ部品でで自分で組み上げたのでは通信などいろいろボトルネックはあって、すぐにベクトルを置き換えるわけにはいかないけど、誰に気兼ねする事もなくいろんな使い方を試してみる事が出来る。MPI、グリッド的なもの、分散オブジェクト、Webサービスなど実にいろいろなものがある。相当な気合いとスキルが必要だけれど、得るものは非常に多いと思う。ベクトルコンピュータを使い続けるのはメリットよりデメリットが多いと思う。
Re:必要な分野は確かにあるが (スコア:1)
あくまでも、計算結果から得られるアウトプットをどうするか、という話なんで、
ベクトルマシーンの是非とは関係無いのでは？
見栄えの良いドキュメントを効率良く作って、世界にばらまけるようになったとしても、
そのドキュメントの種である、計算結果が得られなければ、どうにもならないのですし。
Re:必要な分野は確かにあるが (スコア:1)
個別の対象に依存すると思うけど、別の所にいる誰かが作った大きなデータを入力とした計算をしているが、その誰かも研究をしていて日々データが更新されているので、気が付いてみるとどういうデータを使って計算していたのかわからなくなっているというよう経験はないかなあ？ データベースとネットワークの技術はそういうこんがらがりを解決し、最も正しいデータをプログラムに直に取り込むために使う。
温度とか速度とか直観的な量じゃなくて、抽象的なデータを扱おうとすると、可視化を設計しないと仕事が始まらないことがある。出来上がった物を見るだけでなく、計算の実行途中にどこで何が起こっているか知りたいことも多い。計算が大規模で時間がかかる時はなおさら。
確かに、データベース、ネットワーク、グラフィックス自体は、ベクトルかクラスタか関係ないけど、だいたいクラスタの世界で語られるのでそちらの話みたいに言うというのはあるかも。
Re:必要な分野は確かにあるが (スコア:1)
ベクトルとクラスタやPCの世界の微妙な違いを強調するのが良いか分からないけれど、僕の場合、最近データをwebサーバー配下に置く事が多い。Appletでwebページ上で可視化できるほか、リモートのJavaプログラムでローカルファイルシステムと同じようにアクセスできるから。コピーを作らないのは、入力データの場合と同じようにわけがわからなくならないようにするため。さらにサーバーサイドで可視化すると大きなデータを扱う時などの柔軟性が増す。開発環境の構築でつまづいてまだできていないけど。
ベクトルのシステムでもnfsで他のマシンとディスクを共有したり、フロントエンドでwebサーバーを立てても良いと思うが、nfsサーバーが倒れた時の面倒臭さとか、限界があると思う。
Re:必要な分野は確かにあるが (スコア:0)
> したとしたら、PC2-30台のクラスタと同じくらいの性能になって
> しまう。
なんで「ちっこいベクトルスーパーコンピュータ」と比較するんで
しょうか？？ プロセッサ１個のやつとか？
普通のベクトル型スパコンと比較しましょうよ。
せめてプロセッサ16個ぐらいのやつと。
それに、計算に
使い道は限られているけど (スコア:1)
すごい電力と冷房が必要だった（空冷でしたけど）気が.......
でもベクトル型だと流体力学、気象シュミレーション、
その他物理学や経済学のモデル計算くらいかな。
やはり今だと政府機関や大学・研究所向けにしか
用途ないかしら？
co2masato
量子コンピュータ (スコア:1)
Re:量子コンピュータ (スコア:1)
#古典計算機と量子計算機をそういう視点で比べる意味は あんまりありませんが・・・
余談ですが以前、量子計算の研究者D. Deutschは、量子計算機が なぜ早いのかを問われ
「誤解を恐れずに言えば、たくさんの平行宇宙で 計算を分担しているから」
と言ってましたね。
僕自身は確率収束の考え方ですが、多次元世界解釈で 量子計算機を考えるというのは新鮮でした。 そういう意味でとるならスカラ型といえなくもないかな。
IBMのBlueGeneは (スコア:1)
RISCと同じ末路をたどるということは? (スコア:0)
RISCとCISCのときも「RISCの優位は揺るがない」といわれていたのにもかかわらず，RISCが敗北していたように思うのですが.
スパコンの場合，パソコンと違って価格よりも性能を重視するのかもしれませんから事情が違うのかもしれませんけど．
ただ，スパコンも無尽蔵に予算を使うわけにもいかないはずで最も売れ筋は30億円オーダーのクラスだと聞いたことがあります．
地球シミュレータの場合，「NECはあんまり儲かっていない」というハナシも聞いたことがあるのですが，どうなんでしょう？
RISCとCISC（おふとぴ） (スコア:3, 参考になる)
ベクトル型スーパーコンピュータの話題からは離れてしまいますが、現在純粋なCISCプロセッサというのも存在しないのでは？というかそもそもRISC/CISCの分類自体が意味のないものになってしまってます。
RISCプロセッサの特徴として一般によく挙げられるものに、
- （名前の由来になった）縮小命令セットの採用
- ロード-ストア型アーキテクチャ
- 固定長命令
- ワイヤードロジック
- 1命令処理が1クロックサイクル
- 豊富な汎用レジスタ本数
などいろいろのものがありますが、これらの特徴は一般にCISCプロセッサの代表とされるIntel/AMD系のプロセッサにも多かれ少なかれ採用されているものですし、例えばIBM/MotorolaのPowerPCなどはReduced Instruction Setというにはあまりにも命令数が多かったりします。マイクロプロセッサ関連については、海外のアレゲな人が
Great Microprocessors of the Past and Present [sympatico.ca]
という文章（英文）をまとめてたりします。"For entertainment use only"なんて断り書きがありますが、非常に面白い内容ですので興味が湧いたらどうぞ読んでみて下さい。
＃ ベクトル型プロセッサとは関係ない文章になってしまったのでAC（といって、無益な内容でもないと思うんだけどね）
Re:RISCとCISC（おふとぴ） (スコア:1, 興味深い)
Re:RISCとCISC（おふとぴ） (スコア:0)
Pentium Pro以降はCISCの皮をかぶったRISCです (スコア:2, 参考になる)
【特別企画】特別研究シリーズ：Banias＝Pentium Mはなぜ速いのか？ [ascii24.com] より：
Pentium Pro以降のインテル製CPUは、8086に始まり80386で完成を見たIA-32アーキテクチャに基づく「x86」命令を、RISCプロセッサライクな単純命令、μop(マイクロオペレーション)に変換してから実行するしくみになっている。トレースキャッシュとは、x86命令をμopに変換(デコード)した「結果」を保存するという点で、従来の＝x86命令をそのまま保存するキャッシュと異なる。
これによりPentium 4は、CPUにとってきわめてやっかいなx86命令の「デコード」作業をCPUコアから排除している。Pentium 4パイプラインは、すべてが「μopの実行のためのパイプライン」であり、言い換えれば「μopという、非x86命令を実行するRISCプロセッサ」である。そこに、x86命令をデコードするユニットが前座のようにくっついている。Pentium IIIまで、およびAthlonでは、x86命令のデコードはCPUコアにとっての一大作業であり、パイプラインの前半のかなりのステージを費やしていた。その意味で、そのコアはCISC-RISCハイブリッドと言うべきものだったが、Pentium 4のコアはもはやハイブリッドではない、より純粋なRISCコアと言える。
Re:Pentium Pro以降はCISCの皮をかぶったRISCです (スコア:1, 参考になる)
トレースキャッシュは(命令アドレスにかかわらず)分岐命令と分岐先の命令を同じキャッシュラインに載せるので分岐が成立する場合にはペナルティがないのが特徴。
デコード済みの命令をキャッシュするかどうかは別の話。
Re: RISCと同じ末路をたどるということは? (スコア:1)
そんなこと言われてましたっけ。
RISCとCISCの流行が交互に何度か来たってのが過去の歴史です。
今後も当分はそうなるんじゃないですかね。
Re: RISCと同じ末路をたどるということは? (スコア:0)
そんな過去はありません。RISCの流行ってのは1度あって、それが完全に定着しただけです。現在のいわゆるCISC CPUは表面上CISCなだけ。RISCが流行ったころのパラダイム(多段
Re:RISCと同じ末路をたどるということは? (スコア:0)
Re:RISCと同じ末路をたどるということは? (スコア:1, 興味深い)
>いわれていたのにもかかわらず，RISCが敗北していたように思うのですが.
MMXやらSSEやらの効率化に向かい，結局現在のCPUはRISC化する方向へ進んでいる。
技術やコストの問題でCISCが大勢になったけれど，問題が解決されたら
RISCの方向に進んでいくのではないのか。
と教授が言っていた記憶があります。
時代が，クロック数の競争から，同じクロックでいかに性能を出すかという方向に
進みつつある現状をみると，あながち間違ってもいないのかな，とかおもったり。
#習ったのが数年前の話で自信がないのでAC
Re:RISCと同じ末路をたどるということは? (スコア:1)
「同じくロック」を出せるなら、CISCの方がRISCより有利になる(少なくともRISCのメリット(回路を単純化して高クロックに対応)が少なくなる)じゃないでしょうか?
それと、今後は専用チップの作成コストが下がって、特定の計算向けカスタムチップを作るのも現実解になってくるんじゃないでしょうか? こうなると CISC vs RISC とはちがう方向かな。
ただ、こういう専用チップを、たれこみネタの大規模シミュレーションに使えるかどうかというのは、また別かも知れない。GRAPEのように完全に対象を絞れば別ですが、比較的汎用を目指したシミュレーションを考える場合、どうしてもアルゴリズムとの擦り合わせが問題になってくる。おそらくそのチューニングがプログラミングの大半を占めると考えると、特定シミュレーション用チップのメリットがどこまで発揮できるのか、まだまだわかりませんね。
Re:RISCと同じ末路をたどるということは? (スコア:2, 参考になる)
そこで、最近話題のリ・コンフィギュアラブル プロセッサですよ、あなた。
最近の Design Wave 誌 に入門解説が書かれています。
もうすぐ手の届くところにきています。
Re:RISCと同じ末路をたどるということは? (スコア:1, 参考になる)
GRAPEのプロセッサをそっくりFPGAに置き換えたハードウェアを開発して, それ用のコンパイラを開発するみたいです。 なんでも比較としてGRAPE同等のアルゴリズムをプログラミングすると30行程度で済んでしまうという話は聞いたことがあります。
ちょっとしたアルゴリズムをFPGAにのっけて高速化するのに、いちいちSystemCやVerilogやVHDLなんかでプログラミングしてたんじゃたまったもんじゃないですからね。
もうすぐ手の届くところまできています。
Re:RISCと同じ末路をたどるということは? (スコア:0)
こんなお題目をまだ信じている人がいるとは。
今日日CISCもRISCも中身はほとんど違いはありません。
Re:ベクトル型コンピュータ (スコア:1)
ベクトルには見えるが、
コンピュータには見えないぞ。
＃帰れる？
Kiyotan