ソフトウェア最適化を優先すれば、より多くの世界が旧型ハードウェアで動かせる可能性がある
(twitter.com/ID_AA_Carmack)- 多くの人が想像する以上に、非常に多くのシステムは 旧型ハードウェア 上でも十分に動作可能
- 真の ソフトウェア最適化 が実現されれば、このような効率性を達成できる可能性は高い
- 希少なコンピューティング資源 の市場価格シグナルが、ソフトウェア効率化への動機を与える
- 既存の インタープリタベースのマイクロサービス 製品を、ネイティブコードで構築されたモノリシックアーキテクチャ へ移行する必要がある
- 一方で、非常に安価でスケーラブルな計算資源がなければ、革新的な新製品開発 ははるかにまれになる可能性がある
1件のコメント
Hacker Newsの意見
バグが多く非効率なソフトウェアでも、完璧なソフトウェアと同じくらい売れると主張できる。両者のうち一方は、作るのに最も安いソフトウェアだ。これは「レモン市場」の話に似ている。つまり市場では、すべての商品が高品質であるかのように取引される一方、実際には品質を犠牲にしてコストを下げる。買い手は購入前に高品質と低品質を見分けられないため、両者の需要は人為的に似通ってしまう。これは情報の非対称性によるものだ。こうした現象はすでに現実であり、AIでもますます現実味を帯びている。ユーザーは洗練された機械学習アプリケーションと、「AI」という名前だけが付いた洗濯機を見分けられない。AIというラベルそのものが価格プレミアムを生む。だからユーザーは洗濯機に割高な金額を払う。買い手が「専門家が設計・記述したソフトウェア」だと思い込み、ひどいソフトウェアに金を払うのも本質的には同じだ。ほとんどすべてのソフトウェアは IC1-3 レベルで書かれ、QA担当者は大半の企業で、品質向上の唯一の指標を一人で背負っている。ときにはインターンが「LGTM」の呪文を唱えて改善を期待されるが、実際にはそれすらまれだ
品質で差別化されたソフトウェアスタートアップを作ろうとしたことがある。より良い製品なら人々が見抜いて成功すると確信していたが、実際はそうではなかった。成長はしたが遅すぎて、黒字化する前に資金が尽きた。学んだのは、低コスト、そしてそれに伴う低品質が競争市場で競争優位になるということだ。大学時代から聞いていた話だが、この経験で骨身にしみて理解した。これが市場であらゆるものが凡庸になっていく理由であり、人気が高まるほど高品質なものまで劣化していく理由だ。製品がスケールするほど、コスト削減への圧力は強まる。人は安く買いたがるので、誰かがコスト（品質）を削ってより安く提供する。企業は生存と利益のために最低限しか支払わない。もちろん例外はあるが、結局は漸進的なコスト削減へ流れていく。たぶんこの現象にも名前があるのだろうが、レモン市場とは少し違う。市場が崩壊するわけではないが、どこにでも安定した凡庸さが存在する構造だ
市場がすべての商品を高品質として売っている、という見方には反論がある。ここでの「高品質」の意味が重要だ。性能が悪ければ低品質、という意味にも聞こえるが、実際には Teams、Slack、Jira のような性能が悪いと評されるアプリには、競合よりはるかに優れた性能を持つ代替製品がある。だが、Slack の代わりにターミナルUIで、ビデオチャットもなく、絵文字もない Weechat を選べと言われたら、大半のユーザーは後者のほうを低品質と見るだろう。性能も一つの機能にすぎない。たとえば Chrome の初期の成功は高速だったからであり、Python 開発者も性能向上を理由に uv/ruff へ移行している。しかし Slack が5秒ではなく10msで起動したとしても、大半のユーザーは気にしない
非効率なソフトウェアが市場のレモン市場的構造によるものだという点には同意しない。それは情報の非対称性がある場合に限る。多くの場合、人は多少のバグなど気にせず、より安い価格を望む。非常に徹底した QA と複数エンジニアによるコードチェック手順を経た場合、料金を比べれば明らかだ。小さな話では、小さな書店向けソフトウェアを作った経験があるが、素早く作って、それほど高くも取らなかった。完璧でなくても、問題が出たらすぐ直し、顧客も良い取引だと分かって満足していた
大企業でひどい HR、経費精算、時間追跡、保険ポータルを使ったことがある。あまりにひどくて、支払いを決めた人が本当にこの製品を使ってみたのか疑わしかった。自分のチームがバグだらけで UI も悪夢のような製品を顧客に出そうとしたら、即座に叱責、左遷、あるいは解雇ものだ
市場が「バグだらけで非効率なソフトウェア」をよく買う本質は、市場が<i>サポート</i>を買っていることだ。これは Google や人的サポートが乏しい会社にも当てはまる。「サポート」はさまざまな形を取る — ドキュメント、動画、ブログ情報、助けてくれる人、自分の使う環境（OS、ブラウザなど）のサポート、自分がやりたい作業への対応などだ。最悪の ERP でも生き残れる最大の理由は、結局のところ実在する人間がいることだ。サポートの有無が製品の生死を分ける。小さなチームが勝負に勝つには、「サポートが必要になる場面」を減らし、別の次元でサポートを組み込むのが賢い。最も簡単なのは人を増やすことだ。そして強みをきちんと伝えなければならない。サポートの種類ごとに評価は異なるので、オープンソースコードと独占コードのような比較では、多くの人はコードそのものよりサポートが手厚いなら独占側を好む
Costco で買い物をするのが好きな大きな理由の一つは、あそこがだいたいゴミみたいな商品を売らないからだ。フィルターがいつも自分の基準と一致するわけではないが、それなりに意味のある品質フィルターになっている
たとえユーザーがソフトウェアの品質や性能を基準に判断できるとしても、自分の開いているアプリ一覧を見れば、単に性能が良いからといって置き換えられるものは一つもない。たとえば Docker、iterm2、WhatsApp などは、それぞれ具体的な理由があって使っている。単に最速のソリューションがあるだけでは乗り換えられない。そもそも自分の要件を満たしてくれるソフトウェアが存在すること自体が、性能基準を超えるもっと重要な要素だ
99%のソフトウェアは性能を考慮せずに書かれている。HN でも性能改善そのものがタブー視される傾向が強い。L4/5 レベル以上のエンジニアでさえ、性能感覚が乏しいことが多い。ビジネスの観点でも、ハードウェアがそのソフトウェアを動かせなくなるまでは効率性は気にされず、それすら追加ハードウェアで解決するのが先だ
今の市場構造では、いつでもハードウェアを買い足して回せるため、バグが多く非効率なソフトウェアが支配する。ソフトウェアはハードウェアの処理能力を埋めるように膨張する — 「Andy が与え、Bill が奪う」という法則だ。だから lean で高品質なソフトウェアを作るインセンティブがない。しかし最先端チップをもう調達できない世界が来たなら（たとえば地政学的危機や大規模工場の破壊など）、資源を節約するソフトウェアには経済的に大きな価値が生まれる。肥大化したソフトウェアはもう実行できなくなる。Carmack は、そうした状況でも最適化の余地は十分あるので、結局は旧世代のチップ上でもどうにかソフトウェアを動かせるだろうと言っている
よく設計されたソフトウェアは交換しやすい。一方で、バグだらけのスパゲッティコードの集合体は誰も触りたがらず、永遠に残る。純粋に進化論だけを見れば、悪いソフトウェアが結局支配する現象だ
中古車市場がレモン市場である理由は、よく整備された車と故障寸前の車を見分けにくいからだ。しかし新車市場は厳格に管理されているので当てはまらない。ソフトウェアは常に新品だ。自動車の品質が数十年にわたって向上したように、ソフトウェアも品質を高められる。一定基準を満たさなければ販売できないようにし、深刻なバグがあればリコールし、意図的に不良品を売れば処罰する。他のすべての産業はそう運営されている
Web 2.0 の「永遠のベータ」および SaaS モデルの導入によって、ユーザーの忍耐力も変わった。Microsoft は何世代にもわたり、「ソフトウェアは壊れていて当然だ」という認識を植え付けた。みんなが悪いソフトウェアに慣らされた結果、良いソフトウェアの価値をよく分からなくなっている
自分は実際にその AI マーク付き洗濯機を買った。マーケティングには笑ったが、価格が妥当だったので買った
たぶんセキュリティ欠陥のことだけを話しているのだろう。性能やその他のバグだらけの Excel や Photoshop ならすぐ使うのをやめるはずだ。しかしセキュリティは問題が起きるまでユーザーが気づかず、ハッキングされても原因が分からない。開発者にもインセンティブがない。性能については、ある程度使えるようになると、それ以上の最適化に資源を投じたがらなくなる。収穫逓減の法則だ
ユーザーは AI の洗練度と、見せかけだけの「AI 洗濯機」を見分けられないかもしれないが、優れた AI はユーザー自身が情報の非対称性を克服する助けにもなりうる。結局、良い AI を選ぶ方法さえあれば解決可能だ
自分は「最も安いソフトウェア」を作ることが必ずしも安くつくとは思わない。スタートアップ規模なら雑に作るほうが安上がりだが、規模が大きくなるとかえってコストがかかる。航空会社ですらオリーブを一つ減らしてコストを削ろうとするのに、なぜ開発者に最適化させるのが効率的でないのか疑問だ。私たちは新機能ばかり追加するが、そのたびにユーザーは更新のたびに遅くなったと感じる。逆に速くなれば歓声を上げる。エンジニアは MBA のように振る舞い、「価値がない」と繰り返す。しかしソフトウェアのバグ修正の「価値」はかなり主観的だ。エンジニアの任務はバグを直すことだ。ブランドも重要だが、今の大手ブランドはブランド価値を軽視している。たぶん消費者があまり乗り換えないからだろうが、乗り換えても増えるのは新しい UI と、学び直さなければならない手間だけだ（Apple ですら直感的ではない）
今の世界は、昔の旧世代ハードウェアでも動かせるかもしれないが、どうせ CPU とハードウェアは速くなり続けているのだから、わざわざコードをもっと効率的にする理由がない
情報の非対称性の問題は、FOSS あるいは独占的な「共有ソース」製品なら克服できる。コードを直接見れば、全体として質が良いか確認できる。実際のバグまでは見つけられなくても、関数の長さ、コメント、命名などから誠実な開発文化を見て取れる。本当に見れば、DB スキーマがひどい高価な独占製品に信頼は持てない
悪いソフトウェアは、長期的に見れば制作（維持）コストがより高い
だからブランドが品質の守護者の役割を果たす、という話になる
食品で毒性、期限切れ、中毒性のある添加物の販売を法律で禁じるように、ソフトウェアにも規制が必要だ。しかし GDPR が制定されるまでは規制はほぼ無意味で、今でも違反は日常的だ
1980年以降、コンピューティングパワーは約1000倍になった。もし動的配列の境界チェックによる性能低下を5%と見積もるなら（実際にはこれよりずっと小さい）、チェックを有効にしても私たちは950倍速いコンピュータを使えていたことになる。1980年に戻って、「バグが減り、デバッグが容易な950倍速いコンピュータ」と、「単に1000倍速いが、相変わらずバグが多く、デバッグもしにくいコンピュータ」のどちらかを選べと言われたら、多くの人は950倍のほうを選ぶだろう。しかし私たちは結局1000倍のほうを選んだ。個人的には、この1000倍派が状況を悪くしたと思っている
しかしその1000倍の性能は、境界チェックではなく、果てしない抽象化と非効率に浪費されている
以前、遅くてバグの多いソフトウェアを無理やり Sparc 20 で動かすようベンダーに求めたことがある。その結果、ソフトウェアは最適化され、会社が市場で成功する土台になった。最適化は競争優位だ
それが言えるのは1980年以降だけだ。最近の動画を要約すると、「今日のコンピュータは20年前のコンピュータよりそれほど速くなく、特別に最適化して初めて体感できる」という話だった。話者はコンパイラ最適化などを無視していたが、実際の性能向上幅は思ったほど大きくなく、15年で2倍にしかなっていないという
配列境界チェックが5%しかかからないと言っていたが、すべてのアルゴリズムがそんなに単純ではない。処理回数によっては、チェックを入れるだけでコストが3〜4倍に増えることもありうる。特定用途ではチェックを強制すると、その言語自体が競争力を失う。大半の場合は問題ないが、安全モードと通常モードで分けて使うのが望ましいと思う
単に境界チェックだけを考えればコストは低めだが、安全な言語そのもののオーバーヘッドはもっと大きい。GC 言語ではメモリ使用量が何倍にもなることがある
大数の法則を忘れてはいけない。一つのシステムで性能が5%落ちても大したことはないが、世界中のコンピューティング環境すべてに5%の損失が積み上がれば、非常に大きな影響になる
短期的利益を好む人間の性質には同意するが、動的境界チェックがセキュリティ問題そのものを解決するわけではない。究極の解決策はまだない
今こうなっている根本原因は、ブラウザに縛られていることだ
最初の返信が事実上の正解だ。C がいまだに広く使われているというだけでも、本質はスタックの下層に非効率がある構造だと分かる
「5%」という根拠が曖昧だ。どの基準で計算したコストなのか信用できない。配列に値を一つ入れるたびにチェックするなら、実際にはコストが2倍以上になるのではないかとも思う
現在のほとんどのプログラミング言語は配列境界チェックをデフォルトでサポートしている
Node.js が最初に出てきたときの状況を思い出す。クライアントとサーバーのコーディングをつなげられるのが大きな利点だったが、今ではセキュリティ上の悪夢になっている。コードベースの小さいミニマルな言語にも利点はある
文字列一つでギガバイト級のデータを持てることをもっと早く知っていれば、ヌル終端文字列は消えて、みんなの苦しみも少なかっただろう
1000倍速い製品を楽しんでいる 1000Xers はむしろごく少数派だ。一般ユーザーが使うデスクトップソフトウェアは依然として遅い
実際には10万倍くらい速くなっている。クロックだけで1000倍、コアも10倍、命令自体も AVX などで10倍、構造的には100万〜200万倍速い。それなのに体感速度には影響がない
ロバート・バートンがこういう人たちを「低級カルトの大司祭」と呼んだ言葉を引用する
1980年以降なら速いが、2005年以降だけを見るとせいぜい約5倍の向上だ
クロックは2000倍、SIMD などの IPC まで含めれば80倍、コアまで掛ければ結局100万〜200万倍速い。それでもほとんどのプログラムは、作者が単に「動けばその速度で十分」と考えて書いている。最適化そのものを考える人はごく少数で、HN ユーザーの中でも同じだ
2001年時点の 1GHz CPU を基本ソフトウェアの実行基準にすべきだったのに、AI 体験もかなり失望的だった。LLM なら言語変換やコード最適化くらい十分できるはずだと期待していたが、現実はそうではない。実際に AI に Unix の sed コードを JVM 言語へ移植させたこともあるが、初歩的なものを超えると中級以上はまったく駄目だった。結局この流れ全体の目的は「雇用削減」であって、ソフトウェア品質の向上ではない。AI は今後さらに多くの悪いソフトウェアを生み出すだろう
これがまさに JavaScript、そしてユーザーの未来だ
Google（そして Facebook）で働き、ハードウェア価格がいかに安く、コード最適化の大半がいかに価値を持たないかを実感した。10年以上前の Google では、データセンターのリソース管理が必須で、プロジェクトごとに予算があった。CPU、HDD、フラッシュなどの資源を相互に交換可能なものとして相対コストを計算していた。フラッシュが HDD より20倍高くても、実際のボトルネックを考えるとフラッシュのほうが安い場合が多かった。こうした資源はソフトウェアエンジニアの時間（1 SWE=1人年）などにも換算された。最適化で 5000 CPU コア以上節約できなければ、むしろ損になる。大規模プロジェクトでのみ最適化に意味があり、それ以外ではコードはどうせすぐ置き換わるので最適化は無意味だった。また Web の使い勝手という面では、マウスインターフェースは非常に非効率で、30〜40年前のテキストベース端末のほうがはるかに効率的だった。「Web が標準化されて次の段階へ進む」と期待していたが、そうはならなかった。今でも毎週新しいフレームワークが出てきて、同じスクロールバーですらハードウェア互換性を無視して再実装している。この問題の解決策は分からない
それはエンジニアリングコストが高く、マージンが大きく、複数プロジェクトを抱える会社でしか成り立たない判断だと思う。少しでも余剰資金があるなら、エンジニアを最適化に回すほうがいい。実際には各社が Google を真似しているだけで、経済合理性とは無関係な判断をしており、そうしたことが多くの問題を説明している
自分も Google 出身だが、Google が主に語るのは CPU ごとの使用量最適化でも、実際には二つのことを非常に重視していた — レイテンシと全サーバー利用率だ。どちらも上位組織の重要 KPI なので、莫大なエンジニアリングリソースが投入される。マシン数が増えるほど遊休化させたくないし、レイテンシに敏感なビジネスでは数ミリ秒でも削ろうとする
実際にはコア1個あたりのコストが大きい企業だからこそ Google の基準が成り立つ。大半の一般企業にはまったく当てはまらない。Facebook/Google/Netflix の規模でのみ通用するやり方だ
Google がより良い圧縮やバイナリ直列化フォーマットを考案したのも、自社の収益性改善のためだ
記事タイトルを見て、Carmack が低性能ハードウェア上でのソフトウェア最適化を批判しているのかと思った。実際にはそうではなく、ハードウェアの進歩が止まった場合の思考実験を語っており、結論では「安価でスケーラブルなコンピューティングがなければ、革新的な製品は減る」と述べている
昨日出たスレッドに関連する話だ
「安価でスケーラブルなコンピューティングなしではイノベーションが減る」という結論について、実際にはスマートフォン以降ほとんどイノベーションはなく、資本がハードウェアの進歩にばかり依存しているため、新製品も本質的に既存製品と変わらないものになっている
個人的にはその主張に同意しない。しばらく機能開発を止めるとしても、十分な準備の後には再びイノベーションは戻ってくるだろう。落ち込みはあっても、持続はしない
核心は、「肥大化（bloat）」が単なる浪費ではなく、経済的インセンティブから生まれる開発生産性の向上だということだ。より複雑でない言語で生産性を高めるほうが、より多くの人材採用やコスト削減につながる
ハードウェアの寿命を計画的廃棄より5年、10年延ばせるなら、膨大な電子廃棄物、希少鉱物使用、温室効果ガス排出を減らせる。しかしソフトウェア市場は、こうした外部効果のコストを負担していない。発売後にテスト・修正・反復するほうが、長期設計よりはるかに安い。ゲーム業界の一部は高性能＋高売上の方程式を見つけたが、広く普及したわけではない。エンタープライズ/コンシューマーソフトウェアは、性能よりもユーザーが「我慢してくれる限界」に合わせた最低要件しか気にしない。継続的な新機能追加と変化のせいで性能に気を配りにくく、予算にはエラー率を織り込んで余裕を持たせる。比較的「準備できた状態」で出す方式とは違い、複雑性と変化のリスクが大きい
過去10年以上、私たちは取引所全体のマッチングエンジンを単一スレッドで動かしている。直列化された取引処理に関しては、コンピューティングパワーはそれほど急速には伸びていない。数百万 TPS でもない限り、クラスターへスケールアウトする必要すらない。むしろ設計を単純化して単一マシンで処理できる
この点は本当にいら立たしい。多くのシステムアーキテクトが、自分の存在感を刻みつけるためにシステムを複雑にし、それに伴う新たな問題ばかり量産してきた。元の設計でも大半の要求は満たせるし、今の基準のローカル計算能力なら単一マシン処理でも十分だ
注文マッチングを並列化できない理由が気になる。ソートに似たログ短縮のようなものを適用すれば並列処理できるのではないか。それとも、マッチング過程では単純な並べ替え以外の計算があまりないからだろうか
単純な処理だけなら単一スレッドで可能だが、各トランザクションごとに複雑な演算が必要なら不可能だ。ただ、実際にそこまで複雑な処理が何なのか、ドメイン知識が足りず想像しづらい
もし開発ツールの進化が続いていたなら、昔は RAD で完全なネイティブ GUI を簡単に作れたのに、今は Electron が主流だ。複数の Web ブラウザがそれぞれ Chromium ベースの派生版としてインストールされている状況になっている
結局のところ、これは資源配分の経済問題だ。開発者にソフトウェア最適化へ時間を使わせるか、それとも新機能を作らせるかという話だ。後者のほうが収益を生むならそうするし、逆に最適化のほうが重要ならそれに合わせて行動する
経済問題であることには同意するが、本質的にはソフトウェア企業が社会全体に負の外部性を押し付けている事例だと思う。追加のエネルギー消費、浪費、電子廃棄物の増大などを気にしていない
技術的/金融的負債を他人に押しつけ、膨大なゴミだけを増やす構造だ。最適化に実益がない場合も多いだろうが、単にサーバーを追加するだけの慣行は残念だ
「機能追加のほうが重要」というのはケースバイケースだ。自分は最新の macOS、Windows、Android の新機能の大半を使っておらず、効率的な環境やセキュリティのほうを重視する。デザインソフトウェアでも新機能より効率改善のほうを期待する。むしろ10年前の Illustrator/Photoshop を使いたいと思うことさえある。音楽制作ソフトでは新機能が作業改善に必要なこともあるが、効率を損なうなら拒否感が強い。コードエディタは VSCode だけで十分で、もっと速く軽くなってほしい
自分の生活では効率化がとても重要だ。たとえば台所に何かを取りに行くときは、いつもゴミや食器も一緒に持っていって二度手間を避ける。ソフトウェアも同じだ。しかし「高価なエンジニア時間を使って最適化する」ことと、「RAM や資源を追加する」ことを比べると、後者のほうが常に安い。問題が十分大きくなったときにだけ、最適化のほうが得になる。市場がどちらの選択が有利かを最終的に決める。もしハードウェア追加で得られる利益が減るなら、最適化へ移るだろう。ムーアの法則が限界に達していないので、まだそうなっていないだけだ
究極的には需要の問題だ。消費者がより高速なソフトウェアを重要視するなら、喜んでより多く払うだろう。しかし実際には、性能が落ちても価格が安いほうを選ぶ
まさにこれが「enshitification」の定義だ
Electron アプリには性能面の不満が多いが、Linux ノートPCで職場環境を何とか成立させた中核的イノベーションでもある。たとえば Teams の会議にも、インストールなしで簡単に参加できる。みんなが Winamp のコード最適化を懐かしんでも、実際には Electron アプリのアクセシビリティのほうが便利だ
最近 Balatro というゲームを遊んで感じたのは、単純な計算と簡単なグラフィックしか扱わないように見えるゲームでさえ、90年代のハードウェア（Pentium II + 3dfx）でも動きそうなのに、実際には要求される最低スペックがどんどん上がっていることだ。最新ノートPCでないと動かないような過剰な要求仕様に驚く