おはにゃん
でも香港式ワンタン麺は極細麺(日本の中華麺とも違うボソボソの麺)にワンタン乗せてるらしく、これはうまそうなんで食べてみたいんだよな https://www.expedia.co.jp/stories/%E6%B5%B7%E8%80%81%E3%81%B7%E3%82%8A%E3%81%B7%E3%82%8A%EF%BC%81%E9%A6%99%E6%B8%AF%E3%81%A7%E8%A1%8C%E3%81%8F%E3%81%B9%E3%81%8D%E7%B5%B6%E5%93%81%E6%B5%B7%E8%80%81%E3%83%AF%E3%83%B3%E3%82%BF%E3%83%B3/
酒田ラーメン、Wikipediaに記事まであるんだ https://ja.wikipedia.org/wiki/%E9%85%92%E7%94%B0%E3%83%A9%E3%83%BC%E3%83%A1%E3%83%B3
このアカウントは、notestockで公開設定になっていません。
あんまり真面目に意識したことなかったけど、async/awaitは並列処理を手続き的に記述する(callback hellやFutureの煩わしさを避ける)ための手段であるという立場と、並列実行したい処理をスレッドプールやepollの存在を意識せずに(グローバルな)ランタイムにdispatchするための構文であるという立場があり得るのか
自分でも前者の気持ちでasync/await使ってるときは割と快適だけど、後者の気持ちのときはdispatchを隠蔽するのやめちくり~~と思っているような気がする
そう考えるとJSランタイムのdispatchは隠蔽されてるけどPromiseが返ってくるためcallback hellは発生するというデザインは最悪っぽいな
並列処理と並行処理の言葉の使い分け、個別事例を超えた一般的な部分がどうなっているのかいまいち分かってない
個別事例というのは、たとえば物理的にたくさんのCPUに明示的にタスクを振り分けるのなら「並列」と呼ぶらしい、くらいの粒度です
私の理解では、依存関係がない処理Aと処理Bがあるとして、これらの片方を完了してからもう片方を開始する様式を順次/sequential、何らかの方法で両方を同時に実行する様式を並行/concurrent、それぞれの処理を別々の処理器/processorで実行する様式を並列/parallelと呼ぶ。単一の処理器でも並行処理はできる(時分割方式)が、並列処理はできない。
別の観点として、以前tanakhさんが「並行アルゴリズムは必ずしも速くなることを意味しないが、並列アルゴリズムは(適切なハードウェアリソースが割り当てられている状況で)速くならなければ意味がない」といった趣旨の発言をしていた記憶がある。
この観点だとまず処理を同じprocessorの時分割で走らせるか違うprocessorで走らせるかを選択できない、現代的な普通のアプリケーション開発において「並行」と「並列」を区別する必要があるのか、そもそもできるのかという疑問が出てくる。
あとCPUまで降りたときの振る舞いがどうであれ、JSでasync/awaitを使うときのメンタルモデルは普通はPromiseごとに別々の(仮想的な)processorが割り当てられて真に同時に走っている状態だと思うんだけど、これをもって並列というのはまずいんだろうか?
parallelでないconcurrentな例でのasync/awaitはマルチスレッドやFiberのyieldに相当すると思われるけど、そういう意図でPromiseを使ってる例はあるんだろうか。確かにsetTimeoutを使って定期的にUIに制御を返しつつ逐次処理するパターンはたまに見るけど
並行/concurrentの「同時に」という概念は非自明っぽいというか、何を「同時」とみなすかを定義できないと意味がない言葉になっていて、その意味で並列/parallelより上位レイヤの概念なのかな
2つのプログラムがある時点tにおいて「並列に実行されている」とは「2つのプログラムそれぞれについてあるprocessorが存在し、プログラムカウンタがそのプログラムの命令列を指している」と言い換えられそうだけど、カーネルのスケジューラの話をしているとかMPIを叩いているとかでない限り、自信を持ってこの性質を満たしていると言うのはかなり難しそう
このアカウントは、notestockで公開設定になっていません。