- Windows NT 3.51 を動かす古いコンピューターと Windows 11 を動かす新しいコンピューターの速度を比較した動画を Twitter に公開したところ、かなり大きくバズった
- どちらも同じ動作をする。コマンドプロンプト、エクスプローラー、メモ帳、ペイントを開いて閉じること
- 古いコンピューターでは即座に実行されるが、新しいコンピューターでは遅い
- 現代のコンピューターのユーザーインターフェース遅延は非常に悪く、さらに悪化している
- 比較に使われたハードウェアがデスクトップとノートPC（Surface Go）で不公平だという指摘があった
- K7-600 マシンに Windows 2000 を入れ、Mac Pro 2013（6 コア Xeon + 32GB）に Windows 11 を入れて再比較したが、結果は似たようなものだった
コンピューターの進歩
- 2000年代以降、多くの面で進歩してきた。驚異的なグラフィックス、高解像度モニター、超高速ネットワーク、リアルタイム動画編集など
- I/O の面でも大きく進歩し、昔のシステムではディスク I/O は常に最も弱い部分だった
- フロッピーは不安定で遅く、CD/DVD はもう少し信頼できたがやはり遅く、HDD は多くの場面でボトルネックだった
- ランダム I/O は物理的限界に達し始めていた
- SSD が登場し、デスクトップでも使われるようになって、このランダム I/O の問題を解決し始めた
- 突然すべてが速くなった。起動、ゲームのロード、大量のファイルがあるフォルダーを開くことなど
- 新しいハードウェアの導入も簡単になり、無線接続が一般化し、テキストやアプリの国際化も進んだ（Unicode が簡単でも安価でもなかったことは認める）
- 多くの面で状況は改善され、これまでになく大きな力を手にした。そうでなければ、2000年代には想像もできなかったような、小さな携帯電話で ML を使った写真処理のような作業はできなかっただろう
ひどいレイテンシ
- しかし、こうした進歩のどれも、なぜ今日の UI レイテンシがこれほど極端に遅いのかを説明しない
- ハードウェアの進歩は、この状況を改善しているはずだった
例
- メモ帳は最近までネイティブアプリで起動が速かったが、UWP アプリとして書き直されて遅くなった。非常に遅くなったのに、依然として機能は不足している。ユーザーには何の利益もない速度低下だ
- Windows Terminal は以前よりずっと良くなったが、目に見えて重い。PowerShell を追加すると、最上位クラスのハードウェアを使っていない限り、新しいターミナルウィンドウが開くのに数秒かかることがある
- macOS は Windows よりはましだが、やはり問題がある。設定ウィンドウを開く速さは昔のマシンのほうがずっと速い
- Linux はおそらくこの種の問題の影響を最も受けにくい。11 年前の PC でも、2023 年 4 月にリリースされた Fedora Linux 38 は問題なく動く。だが、これも錯覚にすぎず、Linux 専用に開発されていない最新アプリを実行すると、アプリの起動時間は遅くなり、全体的に性能が低下する
- 私が最も大きな衝撃を受けたのは、2009 年に Google に入社したときだった
- 当時の Google 検索と Gmail は卓越した性能を誇り、他の模範となっていた
- しかし、社内で使うインハウスのコマンドラインツールがどれほど遅いかを見て、大きな衝撃を受けた
- 彼らがどんな代償を払ってでも Web アプリをひたすら推し進めた結果、今日の私たちの状況が作られたのだと思う
原因
- なぜこれらすべてが起きたのだろうか？ 「Bloat」と言うのは簡単だが、定義するのは難しい
- Bloat は正当化されうる。人によって Bloat に対する考え方が違うからだ
- 遅くしているのは「優先順位」の問題だ
- 誰も、ゲームや動画トランスコーディングのような重要なケースを除けば、もはや性能を優先しない
- 人々（企業）が優先するのは「開発者の時間」だ。Rust と Electron
- それぞれのネイティブアプリを開発するのは重複作業なので、Electron が使われる
- 使うのは簡単だが、これがデスクトップのレイテンシに大きな影響を与える
- 1Password や Spotify の例のように、統一された体験を提供し、コストを下げるために Electron へ書き直された
- しかし、コスト削減は企業のためのものであって、ユーザーのためではない
- このコスト削減は、毎日使う私たちに課される税のようなものだ
- レイテンシを増やすもう一つの判断は、Managed 言語と Interpreted 言語を大規模に受け入れたことだ
- JDK/CLR は長時間動くプロセスの最適化は得意だが、高速な起動時間についてはうまく扱えていない
一度きりの改善は食いつぶされた（One-off improvements eaten away）
- 最後にハードウェアの進歩の話に戻って、悲観的な話で締めくくろう
- SSD がもたらした特別な改善は、一度きりの変化だった
- HDD は継続的に高速化したが、デスクトップに必要な高速ランダム I/O は提供できなかった
- SSD への移行は次元の違う改善をもたらしたが、その恩恵は一度しか享受できなかった
- このような革新的な体験をもたらす別の技術はない
- したがって、この新技術がもたらした恩恵が不注意なソフトウェアによって食いつぶされれば、私たちは元の地点に戻ってしまう
- もちろん SSD はますます高速になっているが、HDD から SSD に変わったときのような巨大な差は生まれない
- SSD のない最新バージョンの Windows や Mac を使ってみれば、直接確認できる
- だからこそ Apple Silicon について心配になる
- M1 発売時の優れた性能、非常に長いバッテリー駆動時間、ファンノイズのないことを覚えていますか？
- 私たちがこの不注意な歩みを続けるなら、こうした利点も消え去り、そのときにはもう手遅れだろう
- 既存アプリケーションの性能を底上げするのは技術的に非常に難しく、組織内で優先順位をつけるのもほとんど不可能だ
- では、コンピューターアーキテクトが別の革新的な技術変化で私たちを救ってくれるのだろうか？ 私はそんなものに頼りたくない。そうした変化が不可能かもしれないからではなく、そもそもそんな変化を必要とすべきではないからだ
GN⁺ が要約した版（記録のため残しておきます）
- Twitter スレッドが古いコンピューターと新しいコンピューターの応答性を比較した内容で、8.8K のいいねを集めた。
- 動画では、古いコンピューターのアプリは即座に開く一方で、新しいコンピューターのアプリにはかなりの遅延があった。
- ハードウェアの進歩にもかかわらず、なぜ現代のコンピューターのユーザーインターフェース遅延がさらに悪化したのかについて、著者が疑問を投げかけた。
- 比較の欠陥は修正されたが、結果は同じだった。
- グラフィックス、高解像度モニター、高速ネットワークのような技術進歩が論じられた。
- 現代のコンピューターのユーザーインターフェース遅延は非常に悪く、悪化しているという主張が示された。
- Windows、macOS、Linux における遅いアプリの例が提示された。
- 重いソフトウェア、フレームワーク、管理言語が遅延問題の原因として提案された。
- 不注意なソフトウェアによって SSD の利点が相殺され、Apple Silicon の将来への懸念が示された。
- 既存アプリケーションの性能改善は、技術的にも組織的にも難しい。
- コンピューターアーキテクトによれば、革命的な技術変化が私たちを救えない可能性もある。
- 遅延問題に対してリモートワークは解決策にならない。
- 1990年代と 2000年代のオープンソース開発は、すでに完全な分散・非同期作業を可能にしていた。
- コンピューターの遅延は少なくとも 1977 年から問題だった。
- Dan Luu が見つけた、遅延の面で最も優れていたコンピューターは 1983 年の製品だが、現代のワークロードには対応できない。
11件のコメント
性能ではなく保守性を選び、そのコストをハードウェアの進歩で埋め合わせようという発想が、ここまで来てしまったのではないでしょうか。
2010年のMacBook Airがあまりにも遅くなったとき、なんとかSnow Leopardを入れてみたら、言葉にできないほど速かったんです。もちろん実用にはしていませんが……
もはや会社が性能を優先しなくなっているという話が、実感として伝わってきますね。
しかし、コスト削減は会社のためであって、ユーザーのためではない
という部分にはいろいろ考えさせられますね。
ありがとうございます。共感しながら読みました。
Windowsのデスクトップでコンテキストメニューを開くと、20年前も今も砂時計を見せられて遅いんですよね（最初の後は少しマシですが、すごく気になります）。
ハードウェアは確実に速くなっているのに、ソフトウェアはそうではないように思います。
似たような話をしながら、軽いアプリケーションばかりを集めたサイト（たぶんLinux系だった気がします）を見たことがある気がするんですが……いざ探してみると出てこないですね（笑）
ありがとうございました。
何が大事なんだ？
WinAPIだけで実装されていた時代のUIは、すっきりしていて軽快でしたね。
最近は統一感のないUIフレームワークに、なんだかWebベースのアプリまで……。Webエンジンやフレームワークのエンジンが動くには、どうしても多くのリソースが必要ですよね。
GN⁺ に上がっていた記事ですが、AIの要約では理解しにくい気がしたので、私が改めて整理しました。
ほら、やっぱり私の言ったとおりじゃないですか（笑）...
イ・セドルが勝利したあの気分ですね… 私たちのジョブセキュリティ…… まだ大丈夫ですよね？ うぅ
Hacker Newsの意見