How It's Been Ending (5) - Software Development

ハードウェアがあまり速くならない世界で、ソフトウェア開発はどうあるべきか。

マルチコア化や GPU 対応みたいのは、ある程度は進んでいるが「Many core が来るぞー」といっていた時に想像していた、全てのループとデータ構造が並列化される、みたいな勢いには至っていない。(知り合いもそんなことを言っていた。)

これは、端的にいうとクライアントサイドだとコア数がそんなに増えなかったからで、サーバサイドだと serving の inherent な concurrent nature を exploit すれば足りたから。Big data 方面の data parallelism は進展があったけれど, functional にしましょうね (Spark),  Stream も相性いいよ (Kafka), でもできれば declarative にしましょうね (SQL) というあたりでアプリケーションプログラマの用は足りた。こうした data processing や cloud のインフラを開発している人は色々難しい問題と戦っているだろうけれど、そういう人たちは別に many core とかいう前から大変だったはずなので、がんばってくださいね。

GPGPU についてはほんとに "general purpose" なコードを書く必要に迫られる人は少なく、何らかの(グラフィクスでない) specific purpose ごとに定型的なやりかたが生まれ、人々は分野ごとにそのパターンを使いまわしている印象。具体的には何らかのデータフローのフレームワークがあり、プログラマはそのノードを埋める CUDA のコードを書く。ML はそうだし、画像処理も似た感じ。他の分野はどうなのだろう。ゲームとかは general purpose してる人がけっこういるのかもしれない。物理エンジンとか、どうなのかな?

ある分野の専門家として上を目指すならそのドメインの定形フレームワークを自分で実装できた方がよいだろうけれど、それはなんでもかんでも GPU に追い出すぞ!みたいな勢いとは違う感じがする。一方でそんなフレームワークををかけるくらい CUDA に精通すればなんでも GPU に追い出せる能力を持っている気もする。


要素技術の話はさておき、プログラミングやソフトウェア開発の慣習は Moore's Law 時代の暗黙の前提がまあまあ残っていると思う。

たとえば「まずは正しく動くものを綺麗に書いて遅かったら高速化する」("premature optimization is the root of all evil.") というアイデア。Knuth のもともとの premise は正しいといえば正しいが、その「正しさ」はどんどん速くなるハードウェアによって割増されていたと思う。つまり書いたものがちょっと遅いことはよくあったが、ほっておくとハードウェアの高速化によって解決してしまった。

「綺麗に書いたらあとはハードウェアの進歩がなんとかしてくれる」というこの期待は、昨今はよく裏切られる。けれど、どうしたら code hygine と性能のバランスをとれるのかの答えは出ていない。Go, Rust, Swift のようなモダンで速い言語は答えの一部なのだろうけれど。特に Rust は zero overhead abstraction とかいってるし。

こうしたプログラミングの所作だけではなく、ソフトウェアの製品デザインにも暗にハードウェアの進歩を期待している。具体的には、人々は既存のソフトウェアにどんどん新しい機能を詰め込んでいく。ソフトウェアはじりじり遅くなる。

モニタリングやベンチマークといった fitness function enforcement によって性能低下を防ごうとするのがモダンソフトウェア開発ではあるけれど、新機能の追加によるちょっとした遅さを deliberate choice として受け入れる場面はしばしば目にする。つまり「この機能は重要だから」とトップダウンな判断でちょっと遅くなる。また完全な fitness function は存在しないので、気づかないところで色々おそくなったりしがち。たとえばウェブブラウザでいうとページの中で使うプリミティブはよくベンチマークされているがページの外側の UI は相対的にザル。

ハードウェアは今でもいちおう速くなり続けているので、こうした小さい性能低下は今のところあからさまでない。ただし「速くなった」と主張する新しいハードウェアの性能をエンドユーザが体感できる機会は減った。伸びしろをソフトウェアが食いつぶしてしまうから。

クライアントサイドはモバイル、サーバサイドはクラウド。ここ 5-10 年でユーザの性能に対する期待値は一旦リセットされた。だから「コンピュータは速くならない、遅い」という時代の空気はまだそれほど高まっていない。でも PC をとりまく倦怠感に似た空気は、そろそろ現世代のコンピューティングにもやってくるんじゃないの?

というかモバイルには「退屈なハイエンド新製品」という形で倦怠期が来ている。毎年 CPU が(ベンダー公称でなく実際に) 1.5 倍はやくなってたら別にカメラとか AI とかがんばらなくてもみんなスマホ買い替えてくれるよたぶん。クラウドも「自分でサーバを持たなければ自動的にハードウェアの進歩がやってくる」みたいな初期の約束はうやむやにされてるじゃん。それは別に AWS 鞘抜きでぼったくってるからではなく、ハードウェアが言うほど速くなってないからだよね。

話が逸れた。

プログラミングにしろソフトウェア製品のデザインにしろ、CPU 性能バブル期になんとなく染み込んだハードウェアの進歩に対する暗黙の期待が今でもあちこちに残っていると思う。Many core parallelism や GPGPU みたいなわかりやすくてかっこいい取り組みは気にされているけれど、日々の細々とした営みの中にも unlearn した方がよいものが色々あるんじゃないかな。


意図せず環境の sustainability を巡る議論とよく似た論調になった。子どもたちの未来のために限りある資源としての性能を大切にしていきましょう・・・というのは半ば冗談として、限られた機能の速いソフトウェアは、今も色々あるけど今後いっそう存在感がましてくる、かもね。Environmentally responsible products ならぬ responsibly performant software.