確率的コンピューティングでパフォーマンスをブースト 86
ストーリー by soara
円周率はだいたい3 部門より
円周率はだいたい3 部門より
capra 曰く、
本家「Sacrificing Accuracy For Speed and Efficiency In Processors 」より
現代のコンピューティングは正確さが重要視されているが、米ヒューストンのライス大学のKrishna Palem教授は将来のアプリケーションは「確率的コンピューティング」によって大きく変わるかもしれないと考えている。米国時間15日、Palem教授はサンフランシスコでのコンピュータサイエンスの会合にて確率的コンピュータチップの実験結果を発表するとのことだが、ランダムエラーによってパフォーマンスを向上させているこのチップは最先端のチップよりも1/30の電力で7倍のスピードで稼動するという。
現在のチップは高密度なトランジスタによりバックグラウンドノイズが発生するため、回路への電圧を高め、ノイズを抑え、正確な演算を確実にしている。しかしPalem教授は演算のクオリティをどれだけわずかに落とせばスピードの向上と省エネを実現できるかという観点で考えているそうだ。
情報の重要さには差があり、例えば銀行の残高の「$13,000.81」を算出するには「13」を正しく導き出す方が「.81」を導き出すよりも大事であり、「$13,000.57」という計算結果は、「$57,000.81」と導き出されるよりもずっと正解に近い。Palem教授の開発しているチップは火星へのミッションで必要となる演算を行うには適さないかもしれないが、携帯端末の音楽や動画ストリーミングには展開できるかもしれないとのこと。銀行の残高の例は極端かもしれないが、本家のコメントにあるよう「選択的な正確さ」というのには道があるのではないだろうか。
ノイズ・イミュニティを削る (スコア:4, 興味深い)
タレコミ文を見る限りでは、
という、従来デジタル回路の「前提」だった一線を踏み越えちゃっても許される範囲を探る発想のように見えます。 この場合、起きる事象は、アルゴリズム上の演算精度を下げるというよりは、ときどきビットが化けるということになります。
回路全体をそのようにすると上のビットも下のビットも均等に化けやすくなってしまうので、下の方の桁だけ選択的に低電圧駆動するなり、上の方のビットに冗長ビットを追加して誤り訂正するなり、またアルゴリズム上ゲートディレイが長くなるパスと重要度の低いパスが一致するように回路設計を頑張る(できるのかそんなこと)など、対策を打った上で全体としてどれだけメリットが出るかというのが評価ポイントかと思います。
ただ、ビット位置による重要度の偏りの有無は結局はアルゴリズムと切り離せないので、計算の基本アルゴリズムに重要度指示ビットを追加して許容ノイズレベルを動的制御するとか、回路の部分によってクロックまで変えちゃうならいっそ非同期論理(値と一緒にクロックを持って歩く方の)で全体を組み直したりなど、相当なハード量の増加とセットでプログラムの書き方の転換が必要でもあり、それはそれで面白そうではあるけど、入っていくのに結構敷居の高い世界なような気がします。
アレゲ的にはこのようにルールが見えてきたらシミュレータ作って遊んでみるとその先の世界の片鱗が見えてきて面白いのでしょうけど。
Re:ノイズ・イミュニティを削る (スコア:2, 興味深い)
これまでの設計の主流は、回路内のばらつきを考慮した最悪値に対して、余裕のあるクロックや駆動電圧を設定するものでした。
しかし、近年の微細化による駆動電圧の低下で余裕が無くなり、そんな最悪値を考慮してたらとても設計できないという状況になりつつあります。
これを受けて、回路内のばらつきを統計的に考えて、製造後に何%のチップが何MHzのクロックで動作するといった設計ができるツールが研究されています。
適当な推測ですが、タレコミの用途にもこれらは応用できないでしょうか。
Re:ノイズ・イミュニティを削る (スコア:2)
回路に論理的な冗長性を持たせる代わりに、消費電力を下げるようにイミュニティを調整する という技は普通の方法として実用化されてもおかしくないと思います。ISSCCの季節ですし。
微細化の恩恵を生かすためにいい方法じゃないでしょうか。ゲート数を増やして消費電力を下げる。
一部のサーバでは、常にパリティを計算するという方法は取られているので、多少エラーすることを前提に設計するということだけならそれほど目新しい気はしません。
計算機の汎用的な部分に使って、ユーザに見えるレベルでエラーが残るのはちょっとやりすぎかも。まともにプログラムが動くとは思えない。特定の用途の回路に絞って、たとえばデジタルテレビで、ちょっと画面がちらつく、色調がなんとなく変 という程度ならありかも。
ハードウェアやチップ関係には詳しくないですが (スコア:3, 興味深い)
のように、アルゴリズム/ソフトウェアのレベルでは既に主要な研究分野として認められるほどよく知られたものです。
なので、今回の研究の目新しい点は、そのような工夫をハードウェア（チップ）レベルで実現しようという発想にあるのだと思われます。
ただ、私もハードウェアや数値計算の分野には明るくないので素人考えになってしまいますが、累積誤差の問題や、最終的な演算結果の精度保証などはどのように解決するつもりなのでしょう？仮に大雑把な計算結果で充分な場面であっても、あまりにも大雑把すぎる計算結果ではやはり使い物にならないでしょうし。
あと、演算速度はともかく省エネという観点からは、件のチップを追加搭載するのに要するエネルギーを上回る省エネ計算を実現しないとトータルで省エネにならないわけで、その壁を突破できるかどうかも興味深いところです。
Re:ハードウェアやチップ関係には詳しくないですが (スコア:1)
>累積誤差の問題や、最終的な演算結果の精度保証などはどのように解決するつもりなのでしょう？
応用例に出されているように、音声や動画の再生ならば、定期的にキーフレームが出現するので、累積誤差はリセットされます。
また、もし精度が保たれなかったとしても、画像が乱れたりノイズが入るだけで、動作そのものに大きな影響は出ません。
あと、ゲームの3D表示とかも、フレーム毎の計算ですから誤差の累積は心配ありませんし、多少の誤差が出てても動いてりゃ気になりません。
Re:ハードウェアやチップ関係には詳しくないですが (スコア:2)
つまり、ひとつのプログラム中で「正確であることが必要な部分」と「誤差があっても能率を優先してよい部分」をどうにか分ける必要があると思います。プログラミングのノウハウも変えるのか、何らかの方法で自動的に分けることができるのか、興味深いと思います。
誤差を認めるのは浮動小数点演算に限るとか、あるいはプログラミング言語としてroughly{ ... }キーワードを作って、くくったところだけ誤差を認めるとか思いついたのですが、どうでしょうね。
人生は七転び八起き、一日は早寝早起き
Re:ハードウェアやチップ関係には詳しくないですが (スコア:1)
MMXとかSSEみたいに、専用命令持てばいいのでは？
あと、動画再生に特化するなら、CPUとは別にデコーダー専用のチップとして載せるんでは？
今の携帯電話とかって、H264とか再生できますけど、あれはCPUでデコードしてるわけじゃないだろうし。
Re:ハードウェアやチップ関係には詳しくないですが (スコア:2)
float{2} var;
なんて書いて有効数字2桁ということを明示すると、その後の計算は仮数部3桁以上は計算しないので不定です、その代わり速いor電力消費が少ないです、ということなら具体的な用途がありそうに思います（実現可能かどうかはしりませんが）。これは計算しないということであってちょっと誤差とは違うと思うのですが……
人生は七転び八起き、一日は早寝早起き
Re:ハードウェアやチップ関係には詳しくないですが (スコア:1)
わたしも近似アルゴリズムの端っこを齧ったことがあります．
今回のコレにインスピレーションを受けて，
「計算結果に確率的に誤りを含むオラクル（計算機）」を使った計算量クラス
というのが考えられそうで面白そうですね．
#既にあったりして・・・
Re:ハードウェアやチップ関係には詳しくないですが (スコア:2)
＞「計算結果に確率的に誤りを含むオラクル（計算機）」を使った計算量クラス
ドジッ娘アンドロイドの実現に、また一歩近づくのですね。
(狂うことを前提とした)時計の法則で (スコア:3, 興味深い)
本当に1/30の消費電力で7倍の速度っていうなら、
3つセット(とか、奇数)にして演算させて、
多数決理論で補強すればけっこう魅力的に思えなくもない。
それでも1/10程度の消費電力と7倍の速度ってことになるし。
#2つはダメだ。3つにするんだ。
マルチコアを確率的コンピューティングのポリシーで設計して、
求められる精度に合わせて何個のコアで多数決させるかを動的に調整しながら動かす、
なんてのは、精度よりもスピードが要求される分野では面白かもしれない。
生き残れるかどうか (スコア:2)
・生き残れないよ派
「件のチップを使っていかに正確に計算させるか」という分野が立ち上がるかもしれないが、そのようなコストをかけるくらいなら普通のチップを使った方が良い（速度のメリットが生きない）
確率的に計算することでパフォーマンスを稼いでも、通常チップ陣営がそのパフォーマンスに到達したら意味を失う
・生き残れるよ派
「コストが安い」の一点で特定分野で生き残れるかも（DSP とか）
# 自分は前者かな…
Re:生き残れるかどうか (スコア:3, 興味深い)
「確率的」というとキワモノという印象が強いですが、高速・低消費電力・精度が低い、と考えれば何でも倍精度が必要というわけではありませんから演算コプロセッサ的としてハマる使い道があるのではないでしょうか。
例えば、厳密さよりも時間的な縛りの方が優先される分野：
・計算による気象予測など：「厳密に計算できるがメッシュが荒い」と「確率的に計算するがメッシュが細かい」との比較で後者に勝ち目があるかも知れない。
・組み込み系：音声認識、画像認識、自動車の衝突予測など、厳密さがさほど意味をなさず、かつ高速応答・低消費電力が要求される分野
・ゲーム：演算が高速になって消費電力 96%カットなら物理現象シミュレーションなどで重宝しそうです。チェス、将棋、囲碁のようなゲームで計算しきれない分野にも良いかもしれません。
自然現象相手や人間相手だと処理するデータが厳密でない or 厳密である意味が少ないので、相性が良い気がしてきましたが、どうでしょう。
Re:生き残れるかどうか (スコア:2)
あるシステムの特性を、さっとシミュレーションしたいときとか
携帯デバイスで、色とか音の再現性は大体でいいので動画をサクサク見たいときに使えそうかも。
# シミュレーションの方は精度を落とせってツッコミは無しで:p
元コメでは『確率的』とあるが、それを『選択的』と解釈すれば
我々もまた、日ごろからミーティングなどで精度を犠牲にして概算することを
しているわけだし、なんら不思議はないと思う。
で、最初捨てた精度を後で補間することができるなら、かなり使ってみたい。
円周率を3で最後まで計算しておいて、後で3.14とするみたいに。
これが出来れば、前述の動画なんかだとサクサク見れる限界の精度が選択出来ることになるよね。
# もちろん再計算のオーバヘッドが課題になるが。
占い専用 (スコア:2)
------------
惑星ケイロンまであと何マイル？
Re:占い専用 (スコア:1)
先生っ。
西軽井沢 [nishikaru.com]辺りでは的中率90%を誇るらしい私のお天気占いプログラムには、クオリティを落とす余地がありません！
HW乱数生成回路 (スコア:2)
これでもう疑似乱数使う必要ありませんね！
完全なソフトウェアはない (スコア:2)
ソフトウェアが潜在的に持つバグに比べて統計的に無視できる程度の信頼性の低下ならば実用上は問題ない「筈」だし、
真面目なソフト屋ならばバグ曲線ぐらいわかっているだろうから、システム全体としての品質にも問題ないと理解できる「筈」なんだけど、
ソフト屋にもハード屋にも受け入れられないだろうね。
人間って、自分の失敗は許容することを平気で要求しながら他人の失敗は許せない、という性質を持ってるから。
Re:完全なソフトウェアはない (スコア:2)
「全体としては品質に問題はありません」と説明したとして、お客さんにとってはブラックボックスに見えるわけですし、信用してもらえるかどうか…… そういうところでは使わないということかもしれませんが。
人生は七転び八起き、一日は早寝早起き
Re:完全なソフトウェアはない (スコア:1)
某社の「仕様です」はけっこう許容してます。
# いや、許容以外の選択肢がないんですけど。
# yes, fly. no, fry.
Re:完全なソフトウェアはない (スコア:2)
> ちょっと待ってくださいよ。
> ・ソフトウェアが潜在的に持つバグは設計が仕様と相違している(あるいは仕様が意図せず曖昧だった)ので失敗と言えますが、
> ・デメリットを認識した上で確率的コンピューティングを導入するは失敗とは言いきれませんよ。
わかりにくい表現ですみません。私が言いたかったのは、ソフト屋やハード屋自身が失敗するのはいいけど、
機械が失敗するのは許せないという感情が出てくるだろう、ということです。
クオリティアシュアランスの視点に立てば、機械がある確率で失敗するのは太古の昔からの事実であって、受け入れるも受け入れないもないのですが、
感情としてそれを受け入れたくないというのが大勢ではなかろうかと。
「王様はハダカだ」と言ってみるテスト (スコア:2)
ポインタの下位数ビットが不安定にふらふらされたら illegal stomping が起こりまくるじゃないか。
一方で、浮動小数点でも仮数部の下位数ビットがふらついてもいいのは、指数部がほとんど変化しないときだけだ。指数部が増えたり減ったりする場合に仮数部の下位数ビットがふらつくと、指数部がたまたま大きな値だった場合にはとても大きな影響になる。影響がコントロールできないので数値計算にも怖くて使えない。
というわけで、使えるのは固定小数点演算の場合だけでしょうが…数値計算を固定小数点でやるか? わざわざポインタ計算用の整数演算回路とは別に不安定な回路を組み込んでまで…???
というわけで、これは「判っているようでわかっていない人の妄想」って奴じゃないのか??!?? という気がしてならないのですが。
fjの教祖様
えええええ (スコア:1)
> 算出するには「13」を正しく導き出す方が「.81」を導き出すよりも大事であり
銀行でそれはありえない。残高の数字は全部間違えずに出す必要があるだろ。
俺は預金なんてないけどな!
物理・数学であたりまえだたことがchipでも？ (スコア:1)
#タレこみ文がほぼ抄訳だたのでリンク先は斜め読みでしゅ^^。
##実験結果がでるまでは眉唾ぽいなぁ…ｗ
#ハードウェアやチップ方面は詳しくないので、電力の件はご容赦ください；；
ぱっとの印象で申し訳ないのですが、誤差を気にしなくて良くなるのかなぁ。
物理・数学では"数値計算"は誤差との闘いです。それが、"確率"で"保障"されるの
なら、すっごく大変な誤差計算を気にしなくて済む。
数値計算での殆どは誤差評価です。元々のコンピュ～タの計算結果があてにならな
からです。
#あっていないものを、さも解答として出してきますからね、CPU/MPUは;；。
物理・数学での数値計算は
・このときはこの値を超えない。
・このときはこの値をしたまわらない。
・このときはこの範囲に納まる。
で、計算しますから。
誤差範囲が予想内なら数値計算のプログラムが大分楽になりますね。
誤解無きよう。コンピュ～タで計算できない物は多数あります。
#等式はその最たる物であたりして^^。
誤差が確率で決まっているならば、有用な技術になるかと。
#整数計算が誤差? そなもの間違えるなら頭丸めてでなおしてらしゃい!!w
そな、希望をもっていいのでしょか^^
#やぱり、実験結果とやらがでるまでは眉唾ぽいなぁ…ｗ
閑話休題
精度保証付き数値計算 (スコア:2)
精度保証付き数値計算 [google.com]をやってくれるソフトウェアならそこここに見つかるのに、確率に頼る必要は無いでしょう。
Re:精度保証付き数値計算 (スコア:1)
その、精度保証付き数値計算って、"ソフト"でやっているのでしょうから、
内部でCPU/MPUに対して誤差計算をすっごくやっていますでしょう。
CPU/MPUは正確な値を出してくれませんから数値計算は、ほぼ全てが誤差評価です。
これ、ソフトでやるのはすごく大変です；；。
私が期待したのは、出力の"誤差"がチップ内での評価から"確率的"に出てくれるの
かなぁ～です。出力は計算結果でも同じです。
出力の誤差が確率的に解っているのならば、その後の評価は楽になります。
#私、どこか読み違えてるかなぁ;;
#やぱり、実験結果とやらがでるまでは眉唾ぽいなぁ…ｗ
閑話休題
「あるビット以下のビットが信用できない」というのは (スコア:1)
そのビット以下をを計算していないのとあんまり違わない。となればそもそもその分を計算しなければその分の消費電力は0。
信用できない計算をさせるくらいならその回路の電源を切った方が良くないか？残りのビットだけなら高速＆省電力で計算できるんだし。
Re:「あるビット以下のビットが信用できない」というのは (スコア:1)
ﾔﾚﾔﾚ。自分がオカルトオーディオと同じ発想してると認識できてないとは...アナログじゃねーんだよ。
ビットごとの転ぶ確率がきれいに傾斜しているなら話は別だが、信用できないのが「あるビット以下」であればそのビットの挙動が支配的だろうが。
確率といえば (スコア:0, オフトピック)
最近はそうでもないですが、昔のWindowsだと「一定の確率で」画面が青くなって、再起動までの時間に休憩をとれるような機能が搭載されていましたね。
という冗談は置いとくとして、これって実装するとしたらどんな感じになるんでしょう。
普通のプロセッサ以外に「精度は低いけど速いプロセッサ」も搭載して、用途によって使い分ける感じなんでしょうかね？
神社でC#.NET
Re: (スコア:0)
ただし、もうちょっと煮詰まってくれないとどんな用途に使えるのか？の判断は難しいですね。
リアルタイム系には使いやすそうだ、くらいは見えますが。
プログラムは変えないけどハードで精度・速度が変わるという視点は面白いと思います。
今までだとハード変えても出る差というのは価格的になだらかだったので、
それがもっと急になるなら、この手のプロセッサのメリットは生まれますね。
#逆を言えば、価格差がそんなに無ければ出る幕は無い。
えーと (スコア:0)
整数型が狂ったら流石にまともに動かないだろうし
……不同小数点数の導入ですね！
ヨタはさておき、浮動小数点数の精度なんて使い切ってない事が多々あるわけで
頭から数桁が高確率で合ってればそんなに支障は無いのかも
ファジーな音感とかいって音楽用PCに受けるぜ？
アナログ計算機能が入るのかな (スコア:0)
数表が入っていて適当に補完するのかどっち？
ビット長 (スコア:0)
現状、精度は低くていいが大量に計算したいときはSSE等、ビット数が少ないものを集めて一回で計算するような
仕組みがあるようですがそれより有望なんですかね？
素人考えだと誤差有り倍精度を2倍周波数で演算するよりは誤差無し単精度を通常クロック(但し1クロックに2個計算できる)で計算した方が計算結果に安心感があるのですが詳しい人解説お願いします。
MPEG２あたりのまでの動画形式だと丸め誤差の積み重ねで画がおかしくなることがあったっけ。
Re:ビット長 (スコア:2, すばらしい洞察)
>1/30の電力で7倍のスピード
これなら、GPUに応用してほしい。
ゲームの３Ｄ描画なんて多少の誤差出ても良いから、省電力と低価格化は魅力的。
特に、携帯ゲーム機とか、携帯電話にとって、省電力は重要かもしれない。
Re:ビット長 (スコア:2)
>ゲームの３Ｄ描画なんて多少の誤差出ても良いから、省電力と低価格化は魅力的。
GPGPUを目指している現状ではちょっと厳しいかもしれませんね。
Re:ビット長 (スコア:1, 興味深い)
小数点以下何桁の差なんてラスタライズしたら表面化しないんじゃない？
# 全然知らないのでAC
Re:ビット長 (スコア:2)
恐怖感がむしろ増幅ですね！
人生は七転び八起き、一日は早寝早起き
Re:ビット長 (スコア:1)
えーと、ほら、それは空気の揺らぎとかですよ。
え？宇宙だって？
それはきっと、エーテルの揺らぎですよ。
Re:ビット長 (スコア:1)
大昔は描画速度が遅いのをカバーするために(画面上で)動いている部分だけ再描画というような手法がとられることもありましたが、今では皆無でしょう。
Re:ビット長 (スコア:2)
実際、演算精度がそれほど必要でないシーンでは重宝します。
が、プログラミングする側が演算精度に神経を尖らせる必要があります。
Re:ビット長 (スコア:1)
> もともとはパイプラインを有効に使うためのものでした。
一応、SSE でもそう言う思想の命令だったかとは思いますが、rcpps（半分精度の逆数）を使って近似計算を行うステップの合計クロックがdivps（除算）と同じになる（上に当然精度も劣る）ので、私は（私も？）基本的にはdivpsを出来るだけ効率よく使う（データを4つ詰め込んで使う）方向で最適化することにしています。
なので rcpps は高速な逆数命令として使う以外は、divps ほどは精度は要求しないけれど rcpps 単体よりは欲しい、そして実行リソースが余っている、と言うような激レアケースでのみ rcpps で近似の精度を上げる計算を行っています（＾＾；
どこに使うか (スコア:0)
>携帯端末の音楽や動画ストリーミングには展開できるかも
なんか、どこに使うと良いのか思いつかないけど、AD 変換とかを 考えているのかなぁ。
Re:どこに使うか (スコア:1, すばらしい洞察)
普通に、音楽や動画のデコードでしょ。
多少の誤差があっても、質が微妙に下がるだけで、大きな影響は出ない。
なんと恐ろしい事を（Re:どこに使うか (スコア:2, おもしろおかしい)
そんなピュアオーディオの人々にケンカを売るような事を
ずけずけと書くなんて ……
// ゲームのような、グラフィックス主体のアプリケーションなら、
// この手のチップの応用が可能かもしれませんね
Re:教育の現場ですでに使われている (スコア:1, すばらしい洞察)
ゆとり教育の一番の問題は、こういうウワサを鵜呑みにするだけで、
なんら自分で調べてみることをしない無気力受動的人間を
大量に生み出したことだろうな。
Re:教育の現場ですでに使われている (スコア:1, すばらしい洞察)
でもそれ、ゆとり教育に落ち度はないよね。
生み出したんじゃなくて、元から大量にいるだけのことだし。
Re:教育の現場ですでに使われている (スコア:1, 参考になる)
そうそう、円周率は3 [wikipedia.org]にあるように、かなり煽りの入った意見だよね。
でも、電子回路の設計では円周率なんて、３で近似するのが普通に行われてるんだよな。
だいたい、部品の精度がそんなに高くないんだから、小数点以下何桁も計算する理由がない。
Re:教育の現場ですでに使われている (スコア:1, すばらしい洞察)
> ゆとり教育が問題だったというのは本当なんですか。
> 私はこの件に関する客観的で公平な定量的検討結果というものを見たことがありません。
完全に主観評価で恐縮ですが、
「円周率3.14」世代が、自分達も「ゆとり教育世代」であるにも関わらず、
「円周率3」でない事をもって「自分達は違う」と誤認し、
下の世代を嘲笑するのを見ると、
「ゆとり教育を取り巻く言論の弊害」だと感じます。
（これは「ゆとり教育そのものの直接的な影響」ではなく、）
ちなみに私は「円周率3.14」での計算を求められた「ゆとり教育世代」です。
私達の世代の学習指導要領が私達に習得を要求していた『範囲』が、
それ以前の世代より大幅に縮小されていて、かつ、
その後の「円周率3」世代とあまり変わらない事を知っています。
私達より前の世代の学習指導要領と、
私達の世代の学習指導要領を比較すると、
確かに大きな差があると（主観的に）感じるのですが、
これらの世代に関係無く「レッテル貼りにより馬鹿になる」人々を見ると、
案外些細な差なのだと気付かされます。
Re:教育の現場ですでに使われている (スコア:1, すばらしい洞察)
円周率は3.14と言い切ってしまうことは、円周率を3と言い切ってしまうことと同じくらい、間違ったことだと思います。
その場その場の必要に応じて、何桁まで計算すればよいかを判断できることが、重要なことです。
そういう意味で、円周率は3.14に決まってるだろという人よりも、場合に応じて円周率は3でもいいよ
という人のほうが、ずっと優れています。
Re:原点回帰 (スコア:1)
その理論の発展系が、量子コンピュータじゃないの？