序

題名に十分な情報を込めることが難しかったので、ここでなんの話をしようとしているのか説明する。

一般的に消費電力はアイドル時、またはベンチマーク中の消費電力を計測することで論じられている。 だが、人々は通常、PCをアイドル状態のままにするために使うわけでもなければ、いつもベンチマークを回しているわけでもない。

実際のワークロードにおいてどの程度の電力を必要とするかということが重要なのだが、Linuxでは「省電力でいてほしい」のか、「性能を出してほしいのか」ということを一般的にはcpupowerを用いて、governorによって指定する。

従来、AMD CPUをLinuxで使うと、powersave governorにおいては性能が極度に抑制される割にIntel CPUよりも消費電力が大きく、「エクスペリエンスが悪いのに省電力でもない」ということに悩まされてきた。

performance governorを使う場合、特にCPUをフル稼働させる場合はAMDのほうが優れているが、実用的にはIntelのほうが良いバランスで動くため、実用上の電力パフォーマンスはIntelのほうが良いのではないか、というふうに長らく言ってきた。

しかし、2024年4月にamd-pstate-eppを検証した結果、逆に「LinuxならIntelより絶対にAMD」という真逆の状態になってしまった。 それも、新しいハードウェアにおいてではなく、ハードウェアは変わっていないのに、だ。

前提

本記事において検証で動かしているラップトップのプロセッサは、Intel Core i5-72000U, Intel Core i7-10510U, Intel Core i7-1360P, Ryzen7 5700U, Ryzen7 5800Uである。 他にもいくつかのラップトップをちょろっとだけ触って確認している。

CPU負荷から利用状況を考える

現代においてはウェブブラウザ及びウェブプラットフォームアプリの負荷がかなり大きな意味を持つため、まずはこれらが起動されていない状態を考える。

Ryzen9 5950Xにおいて私の環境でデスクトップアイドリングしている場合のCPUs利用率は0.2%くらい。 なお、Ryzen9 5950Xは32スレッドで動作するため、load 1.0 = 3.125%である。

%CPU(こっちは100%でload1.0)で見ると(speex-float-10を使っている)PulseAudioが8%と最も重く、次いでX.orgが3〜5%である。

これらの記述は分かりづらいため、以下1CPUがフル稼働であることが100%になるものを[CPU]、全CPUがフル稼働で100%になるものを[CPUs]と表記する。

常駐アプリ + Code OSS + mpv(音楽再生)でだいたい0.6〜1.6% [CPUs]。 ElectronアプリのWireが際立って重く、6〜14% [CPU]くらいある。 また、Code OSSも文字入力中は14〜18% [CPU]とかなり重くなる。

ウェブページはほとんどの場合100%に近い負荷がかかる。 参考までにウェブコンテンツ負荷(CPU)はだいたい以下:

• YouTube¹ / Firefox : 10〜146% [CPU]
• X / Vivaldi : 18〜80% [CPU]
• X / LibreWolf : 24〜105% [CPU]
• Misskey / Firefox : 4〜26% [CPU]
• Misskey / Vivaldi : 14〜39% [CPU]
• Akkoma / Vivaldi : 12〜26% [CPU]
• Chienomi / Librewolf : 0.3〜2% [CPU]

念の為に言っておくが、ブラウザ外の拡張機能はオフにしている。

もちろん起動時やページロード時はもっとずっと重い。 基本的にページロードなどはCPUが速ければ速いだけ短縮される。

基本的にウェブページロードではシングルスレッド性能(実際にはウェブブラウザとウェブコンテンツで2スレッドだが)が高ければ高いだけ良い。 が、SNSの場合は仮に100%に張り付いていたとしてもとても体験が悪い感覚はあまりない。 (タイムラインロードなどで感じることはあるにはある) 一方、YouTubeはとにかくコンテンツロードが重いため、性能の問題は顕著に出る。

メッセンジャー系は表に出しておくと10〜25%くらい。 操作していると70%とかになる。

オフィス系については、Libreoffice Calcで操作中14%くらい。

このことからわかるように、ほとんどの時間はCPUs利用率はせいぜい2%程度、PCに向かっててさえ常に操作しているわけではないため実際にはもっと低く、さらにPCから離れている時間はやはりもっと低い。 一方で、操作中は瞬間的に負荷がかかるため、「普段の負荷」に合わせた性能だと体験はかなり悪い。

解説

CPUスケーリング周波数ドライバー

通常、Linuxで使われるCPUドライバがacpi-cpufreqである。

acpi-cpufreqはCPUの状態を取得し、CPU周波数を設定することができる。 acpi-cpufreqの主な動作としては、CPUの利用状況に応じてCPU周波数を段階的に上げたり下げたりするか、もしくは最小または最大に固定するかである。

一方、CPUのパワーマネジメントはかなり進化していて、プラットフォーム(IntelまたはAMD製の)のパワーマネジメントを使えば、より柔軟にパフォーマンスと省電力を両立させている。 対して、acpi-cpufreqのコントロールはだいぶぎこちない上に、そもそもCPUの潜在的な能力をフルに使えず、限られた範囲と段階で上下させるためうまく機能しない。

これは、省電力性に不満があるだけでなく、シングルスレッドの負荷が高いときに特定のコアだけをブーストする機能の有効性の差にもなっている。 acpi-cpufreqでブーストが機能しないわけではないが、かなり鈍い。

このCPUスケーリングドライバーの問題に起因し、WindowsとLinuxを比べたときに、システム全体での効率から処理能力はLinuxのほうが高く感じられるが、ブラウザなどシングルスレッドパフォーマンスが重要な用途ではWindowsのほうが高性能であった。²

また、普段の省電力性を重視したgovernorを設定した場合に、アプリを立ち上げるとき、ウェブページをロードするときやYouTubeなど、多くの場面で性能が低すぎるように感じられるため、省電力性と体験を両立させようとするとこまめなgovernor切り替えが必要になる。

P-stateとLinux

これに対して、CPUがパフォーマンス/電力のヒントを与えられることでCPU自ら速度を決定させる方法がある。 これがP-stateである。 Intel CPUに関しては、結構前からLinuxにおいてデフォルトでP-stateを利用するようになっていた。

これを背景として、intel_pstateドライバのIntel CPUとacpi_cpufreqドライバのAMD CPUで比較した場合、powersave governorではAMD CPUの場合周波数が高すぎて省電力性がいまひとつ。 しかも、パフォーマンスがあまりに低く、ウェブページやブラウザが非常に重く感じられるために実用性がなかった。

対して、Intel CPUではpowersave governorでももっさり程度の感覚で動作し、小電力性能も良好であった。

この「もっさり程度」が大きなポイントで、Intel CPUのPowersave governorだとデスクトップで最低限は使えるし、ブラウザももっさりしてはいるけれど一応使えるくらいである。 対して、AMD CPUのPowersave Governorでは「何世代前のPCだよ」と思うくらいの性能³ぶりで、ちょっと使い物にならない。そのためバランスを取ろうとするとSchedutil Governor⁴を使うことになる。

しかしSchedutilはPerformance寄りであり、結構電力を使う。 エクスペリエンス的にはSchedutilにしておけばおおよそ不満はないが、特にラップトップではpowersaveで運用できないことにストレスがある。 Intelもpowersaveがそんなに実用的なパフォーマンスをしているわけではないが、28Wプロセッサだとベースパフォーマンスの高さから多くの時間をPowersaveで過ごすことができ、これが「実用上の電力パフォーマンス的にはIntel、特に28Wがよさそう」⁵と言う背景にあった。

また、デスクトップPCにおいても、Intel CPUのPerformance governorよりもAMD CPUのSchedutils governorのほうが常時電力を使うため、つけっぱなしを想定するなら⁶Intel CPUに分があった。

amd_pstate_eppの効果

この状況を以て「ピークパフォーマンス以外⁷はIntelのほうが良さそう」という話になっていたわけだ。

ところが、amd_pstate_eppが追加されたことにより、この事情がまるで変わってくる。

従来のacpi-cpufreqやamd_pstateのpowersaveは、消費電力は少なかったものの、処理能力を著しく低下させるものだった。 つまり、デスクトップエクスペリエンスを考えると実用的ではなかった。

このため、governorを利用状況に応じてこまめに切り替えるか、あまりにも低い処理能力に耐えながら使うか、あるいは電源につなぐ前提でマイレージ性能を捨てるかになっていた。

対して、amd_pstate_eppのpowersaveは、要求されれば従来のperformanceに近い性能を発揮するため、省電力性はacpi-cpufreqやamd_pstateのpowersaveに対して大きく劣るものの、デスクトップ利用全般がpowersave固定で実用的になった。

ここで大きく変わったのがラップトップでの事情。

デスクトップPCなら、多少の不満⁸はありつつも「まぁ、schedutilでいいか」が割と通用しており、schedutilなら体験としても文句はなかった。

ところがバッテリー駆動のラップトップでschedutilにしておくと明らかにバッテリーの消費が激しく、powersaveにしているIntel CPUのラップトップと比べてマイレージ性能がかなり厳しい。

かといってpowersaveにするとウェブブラウジングが相当厳しいし、ありとあらゆる場面で処理能力が低すぎると感じる。 ラップトップ用Ryzenの場合、最低周波数が1.2GHzくらいあって、当たり前のように800MHzとかになっているIntel CPUよりも高め(なので省電力性もやや微妙)なのにもかかわらず、「本当にそんなクロックで動いてる?」と思うような性能で、それはそれは微妙なものであった。

このため、LinuxだとRyzenラップトップはかなり微妙な存在になっていた。 Intel CPUはP-stateが比較的よく機能する上に、28Wプロセッサならpowersave固定でもまあまあやれる(15Wはきついが、我慢できなくもないレベルではある)のに対し、AMD CPUはpowersave固定での利用は苦行なのでgovernor切り替えが必須となるという違いがあまりにも大きい。

AMDもgovernor固定での運用が可能に

ところが、amd_pstate_eppを使うと従来のschedutil並の性能が出る。 こうなると、ラップトップCPUとはいえ普段遣いで不満が出ることはあまりない。 Intelのpowersave governorはそれなりにパフォーマンスが出ると言っても省電力寄りではあるので、さすがにacpi-cpufreqなAMD CPUのschedutilよりは体験は悪く、このためamd_pstate_eppのpowersaveとIntelのpowersaveを比べると性能差⁹を感じることになる。

なのでIntel側はperformance[^intel-performance]にして比較することになるのだが、ウェブページロード時のような高負荷な瞬間の消費電力が高すぎるのか、実稼働マイレージは割とちゃんと低下する。 また、アイドリング消費電力もpowersaveのほうが低いため、大部分を放置で使う場合もマイレージ性能は低下する。

実稼働マイレージは同一条件を揃えることができないため感覚的な話になってしまうが、amd_pstate_epp powersaveなラップトップのほうが、Intel performanceなラップトップよりも良好なマイレージ性能を持っているように感じられる。 さらに言えば、acpi-cpufreq powersaveとamd_pstate_epp powersaveでの実稼働マイレージは、ずっとブラウジングしてるとかでなければ違いを感じられないので、体験と省電力性を両立しているAMD CPUのほうが良いと感じられる。

もちろん、Intel CPUとAMD CPUのどちらがマイレージ性能に優れているかという話は、CPUだけ違うラップトップが用意できない以上比較できない。

だが、ブラウジングで次々とページをロードしているとバッテリーはゴリッと減っていくのだが、その減り具合がIntel CPU (performance)のほうが激しく感じる。

それがCPU自体に由来するのか、P-state実装に由来するのか、あるいはLinuxの電源管理に由来するのかは分からないが、Intel CPU performance vs AMD CPU amd_pstate_epp powersaveの比較ではAMDのほうが良さそうに感じられる。

少なくとも、従来のように「LinuxラップトップならIntelのほうが良さそう」と言う根拠がなくなった。 IntelとAMDのどちらが良いかを明確に答えられるだけのサンプル数が私にはないが、それでも事情、力関係が大きく変わったことだけは確かなのだ。

注意書き

この記事の主旨は 「Linuxにおいては機能しないAMD P-stateと、Windowsほどではないがある程度機能するIntel P-state」という状況から、「Linuxにおいて非常によく機能するAMD P-stateと、Windowsとはだいぶ差があるIntel P-state」になってしまった ことによって逆転したということである。

つまり割とタイミングの話で、もし将来的にLinuxでのIntel P-stateがより機能するようになればハードウェア変更なしに話がまた変わってくることになる。

なお、Intelはintel_pstateドライバを使用している。 このドライバは一般的な環境で(利用可能であれば)自動で選択されるものである。

その結果

明らかに言えるのは、Linuxラップトップを用意する上で、CPUにAMDを避ける理由がなくなった。¹⁰

また、ラップトップの処理性能を比較検討する上で、Windowsでの計測データがある程度参考になるようになった。

2025-03-21 追記

本記事は2024年6月に書き始め、長く下書きで放置されたものを書き上げて公開したものであった。

このため、長く放置された記事特有の非常に読みにくい記事となっていたが、なんだかこの記事結構読まれているようなので、説明を大量に追加して分かりやすくした。 また、いくつか存在した誤記を修正した。

ついでに、いくつか誤解のあるコメントが届いたので、(そのような人がこの記事を最後までちゃんと読んだとは思わないが)補足しておく。

まず、本記事はLinuxのCPU周波数スケジューリングドライバによるパフォーマンスと消費電力の話なので、Intel CPUとAMD CPUのハードウェアの優劣の話は一切していない。 governor切り替えのような面倒な要素なしに両立できるかどうかが焦点だ。

また、実用上のマイレージと体験という観点の話なので、よくあるベンチマークで測れるような内容を話しているわけでもない。

そして、Ryzen7 5700Uでacpi-cpufreqのpowersave governorを使うと、Intel Core i5-2520Mや、Intel Xeon W3565¹¹と同じようなレベル、AMD A10-7870Kよりはマシとかいうレベルの遅さなので、powersave固定での運用は相当な忍耐が必要である。 対して、amd_pstate_eppのpowersave governorではRyzen5 5600Xのacpi-cpufreq powersave governorより速い。 Antutu Webのスコアで言うと約1.59倍。