Computer Algorithm and Information Technology

全73件の内、新着の記事から10件ずつ表示します。

電気回路

投稿者：DO++ 投稿日：2004年 9月24日(金)23時43分14秒

とかは詳しくないんです。常識として知っておかなければならないんですけどね。 60GB/SECというのは魅力的ですね。魅力的というかCPUの処理速度超えているような。素人考えですけどもし今の汎用CPUでは効果発揮できないですね。。今、データ圧縮で、復元をぎりぎりまで速くしようとして、IOアクセスがオーバーヘッドで、だいたい数10MB/SECが限界ですね。なので、今のCPUを簡単に1GHzとして1G/10M = 100ということで、1byteあたり100クロックで処理できればcopyと変わらない速度で復元ができることが理想的な状態で期待できます。結構現実的な数字ですね。

SRAMは46トランジスタ？

投稿者：和投稿日：2004年 9月24日(金)09時09分52秒

よくSRAMのフリップフロップは4トランジスタで出来ると聞きますがINTELは6トランジスタで構成されているようです。4と6の違いってわかりますか？

60GB/SECというのは

投稿者：和投稿日：2004年 9月24日(金)09時08分12秒

ここのことですね。まずはビデオメモリから。

http://pc.watch.impress.co.jp/docs/2004/0716/kaigai103.htm

(無題)

投稿者：DO++ 投稿日：2004年 9月16日(木)22時54分8秒

>そういえばメモリ帯域の限界を超えるにはやっぱりキャッシュがいるんでしょうか。別ス>レッドで使うメモリがキャッシュに入っていれば並列に動かせるし。整合性が複雑さをあ>げそうですが。 >486を100個乗せたマルチコアが最速かも。　問題に自明な並列性があればそれでうまくいくでしょうけど、そう簡単にはいかないでしょうねぇ。 >数年はメモリ帯域に関してはCPUの性能向上に離されないみたいですね。　そうですね。でも元々離されていて、今多くのアプリケーションがCPUの性能をもてあませて、メモリアクセスの方がネックとなっているようです。でも、60GB/Secというのは、魅力的ですね >プログラマブルシェーダのプログラムは新鮮でした。 >また興味がわいてきました。　プログラマブルシェーダは興味ありますね。また新しいのを覚えないといけないのがつらいですけど

DirectXとか

投稿者：S 投稿日：2004年 9月16日(木)09時34分22秒

今、画像関係を扱う企業の研究所で研修しています。 t-potはそこでもよい参考書として重宝されています。 DirectX は 2 だか 3 だかのころに触って以来だったので、プログラマブルシェーダのプログラムは新鮮でした。また興味がわいてきました。見せてもらったデモの紹介 http://www.sdl.hitachi.co.jp/japanese/results/pas/ 一昔前のPC環境で動いてました。計算能力の向上もうれしいですが、それに見合う能力も身に着けないといかんなーと自戒

うわー

投稿者：和投稿日：2004年 9月16日(木)09時03分7秒

字間違えまくり。失礼しました。

メモリ帯域

投稿者：和投稿日：2004年 9月16日(木)09時02分32秒

XDR-DRAMというのが企画であるらしいです。PCI-EXPRESSのようにシリアルレーンを複数並べたやつで1本あたり8ビット遅れるらしいです。60GByte/Secも視野に入っているらしく、最初はやっぱりビデオメモリからやるらしいです。 CPUの性能向上も鈍くなってきているし、数年はメモリ帯域に関してはCPUの性能向上に話されないみたいですね。

GPUを使うといえば

投稿者：和投稿日：2004年 9月16日(木)08時59分40秒

やっぱり大量のデータをビデオメモリに転送してベクトル演算をして結果を戻す。速いかもしれないけど転送にオーバーヘッドがかかりそうですね。AGPメモリ(これからはPCI EXPRESSメモリ？)に置けばいいのかも。ベクトル演算のメリットの一つに1つの命令でたくさんのデータが処理できるから命令を読み込むメモリ帯域を減らせることもあるんでしょうかね。そういえばメモリ帯域の限界を超えるにはやっぱりキャッシュがいるんでしょうか。別スレッドで使うメモリがキャッシュに入っていれば並列に動かせるし。整合性が複雑さをあげそうですが。 486を100個乗せたマルチコアが最速かも。

ちょっともりあがってきた

投稿者：DO++ 投稿日：2004年 9月16日(木)00時59分48秒

>日本語の資料だとここがあります。 >"t-pot" >http://if.dynsite.net/t-pot/program/90_BitonicSort/index.html 　あるんですね。GPUを用いて他にどのような数値演算を高速化できる可能性があるんでしょうか？ >分岐予測、キャッシュ、シングルスカラーにしてダイナミックスケジュールをなくせば減>った回路分をSMPの為に使えばスループットはめちゃくちゃ向上しそうですね。　メモリ帯域が今は問題になっているから、そう簡単にいかないでしょうね。　ただ、CPUのアーキテクチャの複雑さは発熱とかで限界にきているみたいですし、プログラムあたりから制約を加えた（例えばGPUに使われる形式みたいに）もので速く動かす方法がでてきてもいいころですね。

SMP

投稿者：和投稿日：2004年 9月15日(水)19時10分10秒

分岐予測とSMPは相反するものですよね。予測が外れたときは実行したものは全て無駄になる。しかし分岐があったときに別のスレッドに渡せば確実に実行されるしボトルネックになるのは完全にメモリの帯域だけになるしスレッドが多くなればキャッシュも減らせそうです。多分各スレッドが分岐やメモリアクセスで町になったときにメモリコントローラ(かどうかわからないが)にアクセスの要求のみを投げておいてそれらの要求をキューで持っておく。メモリアクセスが完了したスレッドから実行を始める。分岐予測、キャッシュ、シングルスカラーにしてダイナミックスケジュールをなくせば減った回路分をSMPの為に使えばスループットはめちゃくちゃ向上しそうですね。限界はメモリ帯域を使い切るコア数しか載せれないということですね。

以上は、新着順61番目から70番目までの記事です。

1 2 3 4 5 6 7 8 | 《前のページ | 次のページ》