自作PC@ふたば
[ホーム]

[掲示板に戻る]
レス送信モード
おなまえ
E-mail
題  名
コメント
添付File []
削除キー(記事の削除用。英数字で8文字以内)

画像ファイル名:1580372476211.png-(44418 B)
44418 B無題Name名無し20/01/30(木)17:21:16 IP:60.86.*(bbtec.net)No.633431+ 5月12日頃消えます
非同期式コンピュータという技術
これからはクロックパルスに依らない非同期式コンピュータの時代が来ると思うんだが。
どうだ??
削除された記事が2件あります.見る
1無題Name名無し 20/01/30(木)21:51:32 IP:220.27.*(bbtec.net)No.633437+
ENIACもそうだよな
2無題Name名無し 20/01/31(金)02:03:32 IP:58.188.*(eonet.ne.jp)No.633440+
>非同期式コンピュータ
何故非同期にできないかというとシステムの検証(デバッグ)ができないから。同期式なら任意のクロックの時点でのシステムの状態を全てチェックできるが(なんならクロックを停止させてでも)非同期だとシステムを停止させる手段が無い。

クロックの限界を突破する有力な手段ではあるんだけどね、非同期。
3無題Name名無し 20/01/31(金)13:13:37 IP:153.131.*(ocn.ne.jp)No.633450+
クロックジェネレーター複数必要じゃね?ってのと送受信バッファが大きくなりそうに思う
性能差が大きいコア纏めるならアリかもだ
4無題Name名無し 20/02/01(土)08:48:34 IP:220.147.*(infoweb.ne.jp)No.633489+
書き込みをした人によって削除されました
5無題Name名無し 20/02/01(土)08:49:50 IP:220.147.*(infoweb.ne.jp)No.633490+
>同期式なら任意のクロックの時点でのシステムの状態を全てチェックできるが
>(なんならクロックを停止させてでも)非同期だとシステムを停止させる手段が無い。
そうなのwwwwwwwwww
いかにクロック信号が無いとわいえ、さすがに非同期処理をN個並列に走らせたときに、
一番遅い処理が完了するまで待ち合わせる(同期をとる)回路ぐらい
備わっていると思うがwwwwwwwwww
(因果がノンストップで非同期に伝染しまくりだとそんなもん人類には制御できないwwwwwwwww
そこで止めれば有限状態機械として扱いうるんじゃないのwwwwwwwwwww

既存のデバッグツールが対応していないのは同意(キリ
6無題Name名無し 20/02/01(土)15:17:27 IP:180.145.*(eonet.ne.jp)No.633498+
↑無駄なレス.
7無題Name名無し 20/02/01(土)16:27:43 IP:219.100.*(toshima.ne.jp)No.633499+
過去に2値(0/1)ではない10値(0〜9)のコンピュータも研究されたことがあった。
もちろん失敗した。
8無題Name名無し 20/02/01(土)17:30:09 IP:180.145.*(eonet.ne.jp)No.633502+
今でも多値論理回路の研究は続いてる.
ダイナミック論理は実用化されている多値論理や様相論理のコンピューティングの一例.
9無題Name名無し 20/02/01(土)22:55:13 IP:218.229.*(infoweb.ne.jp)No.633508+
>No.633498
うっせwwwwwwwwwwwwwww
非同期コンピューターは
・グローバルクロックは見当たらない
・前段の処理結果が到着しだい後段が動く
というだけであって普通に同期要素はあるはずwwwwwwwwwwwwwww
wwwwwwwwwwwwwww
10無題Name名無し 20/02/02(日)10:06:09 IP:2400:4172.*(ipv6)No.633522+
>というだけであって普通に同期要素はあるはず

非同期でロジックを作れる個所は限られるので、当然同期をとる個所は存在する
だが、同期すると非同期で稼いだパフォーマンスが無駄になるため、実際につくるのは難しい

そもそも、昔の回路は非同期で設計されていた
が、i4004の規模で非同期で設計するのが困難になり、同期クロックが持ち込まれたって経緯がある
商用になったのは、SHARPの独自チップとかぐらいだそうな
11無題Name名無し 20/02/02(日)10:33:33 IP:2400:4172.*(ipv6)No.633523+
そもそも同期とは、準備が全部整うのを待つ仕組み

学校のスケジュールを例してみるとこんな感じになる
登校は生徒がばらばらに到着しても構わない
が、朝礼や授業は揃ってからでないと始められない
なので、時間割にしたがって行動をするようになっている
これが同期方式
12無題Name名無し 20/02/02(日)10:33:52 IP:2400:4172.*(ipv6)No.633524+
非同期で学校を運営しようとすると、以下のようになる
例えば、朝礼
チャイムに合わせて一斉に行うのではなく、揃ったクラスから朝礼を始める
だが、クラスの人数が多いと、揃う時間が遅くなりやすい
クラスあたりの人数を少なくしないと効果が得られないことが想定される
次に授業も揃ったクラスから始めたとする
今度は授業を担当する教員の出勤時間を早める必要もでてくる
さらにいつ次授業が始まるか判らないので、担当教科の教師を逐次呼び出す必要もでてくる
また、クラスごとに授業タイミングがずれるので、教師の使いまわしが困難となる
例)クラスBが国語の授業を開始したいが、すでにクラスAが国語を受けており、あと10分授業が残っている場合、国語教師は2人必要
もっとも、どんなに頑張っても全校集会は全員揃う必要があるので、こちらは同期となってしまう
13無題Name名無し 20/02/02(日)10:43:48 IP:2400:4172.*(ipv6)No.633525+
どれだけ、運営が高コストになるか、設計が難しいかイメージしてもらえただろうか?

なので粒度を荒くして実装しようという方法論もでてくる
先ほどの例でいえば、学校の中では同期をとるけど、別の学校と同期をとらない
ってなイメージに相当する

こちらは実用(主流)になっている、マルチスレッドやマルチコアそのものだったりする
14無題Name名無し 20/02/02(日)13:29:21 IP:2400:2650.*(ipv6)No.633528+
メタい話をいえばWWWが世界規模の非同期式コンピューティングじゃないの
(グリッドは同期取ってるので不適)
15無題Name名無し 20/02/02(日)14:05:40 IP:219.100.*(toshima.ne.jp)No.633529+
人間の脳は非同期処理ですね。
準備が出来たところからどんどん処理していく。
16無題Name名無し 20/02/02(日)14:12:30 IP:218.229.*(infoweb.ne.jp)No.633530+
書き込みをした人によって削除されました
17無題Name名無し 20/02/02(日)14:13:33 IP:218.229.*(infoweb.ne.jp)No.633531+
>No.633522
>実際につくるのは難しい
という箇所は素子数を食うと言う意味では真だが
>同期すると非同期で稼いだパフォーマンスが無駄になる
は偽である
待ち合わせにおいて最も遅い処理が終わり次第即
(次のクロックパルスなど待たずに)次の処理を開始する回路
は作れるし、スレ画のやつはそうであるはず、

もっとも、待ち合わせ自体不要とか、待ち合わせが一切無いのが非同期とか言う人が居るとしたら
何をかいわんやだがな、
申し上げる言葉もございません
18無題Name名無し 20/02/02(日)16:55:11 IP:180.145.*(eonet.ne.jp)No.633535+
>待ち合わせにおいて最も遅い処理が終わり次第即
だから,それでも上の説明にあるように,非同期で確率的に稼げたパフォーマンスの大半は失ってるでしょ.
パフォーマンスが落ちない場合は「非同期の最も遅い処理が早期処理の該当部分よりも常に速い」という状況だけ.
それに,確率的要素がないなら,確定的な処理が現れたときに,(Max,+)代数でいずれ定常化することが証明されるから,その後は同期処理とさほど変わらない.
確率的変動があって分散が大きい場合に違いが意味を持つんだろう?
19無題Name名無し 20/02/02(日)17:30:46 IP:2400:4172.*(ipv6)No.633538+
>(次のクロックパルスなど待たずに)次の処理を開始する回路

No.633535さんの述べていることの焼き直しでしかないけど、このようになる
A+B=C、D+E=F、C+F=Gという処理(割とある状況)を挙げると
CができてもFが計算できるまで、Cはラッチ(保持)される
つまり結果的に同期をとっているので、マスタークロック方式と結果に差が生まれない

さらに非同期に不利な点は、状態が一意に確定し難く、結果回路設計が困難ってこと
実は、非同期で設計した場合、温度やチップの個体差で回路ごとの出力順が入れ替わるなどということが起こり得たりする
これ一つで取りうる状態が指数的に増えることを示唆する
なので、設計が困難なのですよ
20無題Name名無し 20/02/02(日)17:33:33 IP:2400:4172.*(ipv6)No.633539+
>は作れるし、スレ画のやつはそうであるはず、

どうも齟齬があるようで・・
言いたいことは、あなたとそう変わらなかったりする

作れる(だからSHARPの実装があることを述べた)
少しでのもパフォーマンスを伸ばす必要があり、コストを無視できるのであれば選択肢としてあり得ると思うんだ
が困難なので、今後主流となるとは思えないって、点があなたと異なるだけ

- GazouBBS + futaba-