アカウント名:
パスワード:
CPUのシリアル化ってどういうのを言うのでしたっけ?
やはりそうでしょうね。ところで、何でハードディスクのインターフェースが シリアルで高速化しているかというと、同期の問題だそうで、 どちらにせよ同期の問題がネックというのは共通しているように 思えます。
low costで data転送の bus幅が増えることがとても大切です。 特に data間の結合がよわくて同じような計算を多量にする場合は、とても便利です。
よく processor powerで演算unitの性能だけを見ることがありますが、その演算unitへの I/O性能もまた重要だという良い実例かと。 designerとしては、data処理において必要な resourceの balanceをとることで cost(経済, 電力, chip面積など)を下げられるというのを忘れないようにしたいですね。
画像処理だと特に近傍のデータを集中的に使う傾向がありますから, 物理(結線)的に近い演算unit同士が互いに相手の演算結果を次の処理に使う, 言ってみれば2次元パイプラインの様な感じで性能を上げるということもあるかもしれませんね.
最近の流れとして、I/Oまわりはシリアル化で高速化しているのに、CPU内部ではパラレル化で高速化していくんですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
要するに (スコア:2, 興味深い)
人の脳もクロック低くて、超並列処理な感じでしょうから、それに近づいて行くのかな。面白いですね。最近の流れとして、I/Oまわりはシリアル化で高速化しているのに、CPU内部ではパラレル化で高速化していくんですね。
超並列というには まだまだのような。 (スコア:2, 参考になる)
128x128 の画像を処理する場合でも、128 回繰り返しが必要です。
所詮このCPUもノイマン型な訳で、
処理速度を考えると、動作クロックが100MHzはかなり弱点だと思います。
だから、処理速度だけでなく 消費電力もセールスポイントとしてあげているのでしょう。
実際、NECはかなり昔からこの手のCPUを開発し、
画像処理ボードに積んだりして販売しています。
でも、昔は消費電力の単語はありませんでした。
実際に、処理速度の問題は重要で、
昔は、画像処理といえば 今回のようなCPUを積んだ画像処理専用ボードを使うのが主流でした。
しかし、最近はほとんど intel のCPUを使う方法に切り替わっているように思います。そっちのほうが、速い!安い!なのです。
intel のCPUは MMXを考えても 4並列、
HyperThreading で なんちゃって2並列なわけで、
NECの目指しているであろう*超*並列には足下にも及ばないのですが、
もうしばらくはクロックを上げて処理速度を稼ぐのが一番ベストな方法なのかもしれません。
まだまだ、脳みそは作れないっす。
これは組込用のチップです (スコア:3, すばらしい洞察)
組込の場合、特定の処理のみを可能な限り低消費電力で行わないと落第点が付きます。
(電源ユニットの容量やコンデンサの数が製品コストを決めるため)
要するに、制限時間内に一応の解が出る性能があればよいのです。
・制限時間よりも消費電力の方が優先されるケースもあります。
# 電話機組込の仕事で14kのクロックでCMOSのZ80を動かした事がありました。
このチップは自動車用のようですが、他の応用例は幾らでも思いつきます.
自走式掃除機とか、手話→音声変換機能付き携帯電話とかに高性能チップが必要ですか?
# 自動車用でも、エンジン停止時に電力を馬鹿食いするようでは困ります。
notice : I ignore an anonymous contribution.
Re:超並列というには まだまだのような。 (スコア:2, 参考になる)
SCEの【特開2002-366534】なんかも用途やアプローチは違いますが、似たような構成になってますね。
これは1コアにコントロールプロセッサ+(演算器+RAM)*8という構成
のように見えますが、DMAでマイクロプログラムを演算器にディスパッチして
スループットを上げようという風に見えます。
もっとも、どちらかと言うとチップ単体よりもさらに複数チップ
を継いで、LANやらWAN全体でグリッドコンピューティングを...と
いう風な狙いのようですが、チップ単体でみればキャッシュを
持たずに、RAMをぶらさげて個々に処理させるあたりは似たよう
な構成かなぁと。
Just a whisper. I hear it in my ghost.
Re:要するに (スコア:1)
CPUのシリアル化ってどういうのを言うのでしたっけ?
Re:要するに (スコア:1)
でも、実際、電圧などとは性質が全く異なるんで、高速化するには、並列させるしかない気がしなくもない
Re:要するに (スコア:1)
やはりそうでしょうね。ところで、何でハードディスクのインターフェースが シリアルで高速化しているかというと、同期の問題だそうで、 どちらにせよ同期の問題がネックというのは共通しているように 思えます。
Re:要するに (スコア:2, すばらしい洞察)
従来のパラレルATA/SCSIは、各ビット間の位相ずれ(スキュー)の影響で今以上に高速化しにくい、という話でした。
#多芯ケーブルのハンドリングやコストなどももちろんありますが。
>どちらにせよ同期の問題がネック
高速インタフェースのビット同期とマルチプロセッサ間の同期というのとは問題が違うんでは?
タレコミのプロセッサは画像処理向けなので並列処理時の同期問題は比較的小さくできるように思いますが、プレスリリースによると確かにコンパイラの方でも頑張って高速化に寄与しているのでしょうね。
Re:要するに (スコア:1)
パイプラインやアウトオブオーダ...
はちょっと違うけど、横(並列)に対して縦(行列)といえなくもない。
Just a whisper. I hear it in my ghost.
こういう processorで大切なのは (スコア:1)
low costで data転送の bus幅が増えることがとても大切です。
特に data間の結合がよわくて同じような計算を多量にする場合は、とても便利です。
よく processor powerで演算unitの性能だけを見ることがありますが、その演算unitへの I/O性能もまた重要だという良い実例かと。
designerとしては、data処理において必要な resourceの balanceをとることで cost(経済, 電力, chip面積など)を下げられるというのを忘れないようにしたいですね。
Re:こういう processorで大切なのは (スコア:1)
画像処理だと特に近傍のデータを集中的に使う傾向がありますから, 物理(結線)的に近い演算unit同士が互いに相手の演算結果を次の処理に使う, 言ってみれば2次元パイプラインの様な感じで性能を上げるということもあるかもしれませんね.
分かってるんだけど (スコア:0)
内部のベースクロックが違うからそうなるのは当然ってのは分かるけど、こうして言葉にしてみると不思議な感慨を感じてしまうのは私だけ?
10年以上前に (スコア:0)
あの頃はシリコン回路の周波数限界からムーアの法則の危機が予想されて, ガリウム砒素半導体なんかの研究開発がHOTだったな~(遠ひ目)
#たんなる思ひ出話なのでAC
10年後… (スコア:0)
あなたのパソコンは痴呆症が始まっていますとか、
数演算器バカでも交換は致しませんとか、
言われるようになっているのだろうか?
Re:10年後… (スコア:1)
するのが常識になってたりして。
ユーザマニュアルに「工場出荷検査時に、CPU検出プロトコルに応じた数は
規定数(32Kモル)以上ありましたが、お客様の御使用環境によっては、これ
より増減することがあります。演算速度が急激に遅くなった場合は、少し
休ませるか栄養剤を補給してCPUの再生を待って下さい」と書いてあるとか。
#さすがに10年では無理っぽい感じ。
もる・・・ (スコア:0)
= 19,264,000,000,000,000,000,000,000,000 個
ヨタの次まで逝ってしまいますか
大脳の神経細胞の数を約100億個、世界の人口を約100億として
15,000,000,000 * 10,000,000,000 = 1.5 * 10^10 * 10^10 = 1.5 * 10^20 個
人類の全脳細胞の約10^8=1億倍の個数のCPUがワンチップに・・・
Re:もる・・・ (スコア:0)