Anukari開発者、Appleに助けを求める macOSでのGPU問題
引用元：https://news.ycombinator.com/item?id=43901619
AnukariのShow HN投稿をここで見た人もいるかもね：https://news.ycombinator.com/item?id=43873074
あのスレッドで、macOSのパフォーマンスの話題が出たんだ。基本的にはApple silicon、ベースモデルのM1ハードウェア含め、ほとんどの人にはAnukariはうまく動くよ。俺はM1ベースで全部テストしたけど、素晴らしく動くんだ。ハードウェアは信じられないくらいすごいね。
でもそれを動かすために、オーディオ処理を十分に速くするためにmacOSがGPUクロックレートを上げるように、ひどい回避策の集合体を実装しなきゃならなかったんだ。macOSがGPUのパフォーマンス状態に使う普通のヒューリスティクスは、Anukariの変わったワークロードを理解してくれないんだよね。
とにかく、やっと時間ができて、この状況を恐ろしく詳しく書き出したよ。Appleの適切な人、たぶんMetal APIを担当してる人と連絡を取る手伝いを求められるようにね。
助けて！ ：）
＞これは超長くて超技術的な投稿になるよ、だからシートベルトを締めるか、まだ間に合ううちに去るかしてね。
えっと、全部読んだけど、全然長くないし、めちゃくちゃ明確でよく書けてるし、勉強になったよ！文章力すごいね。
Macは一度も持ってないし、PCも古いGPUなしのやつだから、Anukariすぐには使えそうにないんだけど、それが超残念。だって、とんでもなくクールに見えるからね。
この問題が早く解決するといいね！
このエンタイトルメント試してみた？ https://developer.apple.com/documentation/bundleresources/en…
com.apple.developer.sustained-executionも逆の方向で効くのかな？って思うんだけど…
考えてくれてありがとう。残念ながら、プラグインとして動かすときはAnukariはホストアプリケーションが使うどんなplist.txtにも左右されちゃうんだ。スタンドアロンのバイナリでは一度試したと思うけど、残念ながらメモを取ってなかったみたい！それはたぶん成功しなかったってことだろうね。
超クールな仕事だね…そしてメーカーが課す壁にぶつかるのはイライラするだろうな、想像つくよ！俺もGPUベースのオーディオプラグインに長い間取り組んでて、その件でいくつかの公開資料も作ったよ。
ちょっとした意見だけど：DAWの外で独立して（したがってより制御しやすく）動くサーバー/デーモンプロセスを使うのは考えた？プラグインのインスタンスをクライアント-サーバーアプローチにするんだ。それはもう少しOSベースの制御を可能にするかもしれないね。
あなたの資料へのリンクはある？
＞DAWの外で独立して（したがってより制御しやすく）動くサーバー/デーモンプロセス
GPUでのオーディオプラグインについて、俺もだんだん同じ結論に至ってきてるんだ。
興味深い投稿と問題だね。タスクを同じキューで実行するのが失敗する理由が、そもそも問題を抱えている理由と同じなのかな？って思うよ - 可変クロックレートだと正確にスケジュールするのが不可能で、OSがGPUのクロックをどう決めるかに基づいて、スピンストップ時間の理想時間とエイリアスが生じるんだね。でもそれは、スピンジョブがGPUを最高クロックで動かすのに十分なほど複雑じゃないってことを示唆してる。もし最大で動いてるなら、ソフトウェアPLL（これも悪くないアイデアかもしれない）がなくてもスピンの停止時間を確実に計れるはずだからね。スピンがどう実装されてるかの詳細な説明はなかったけど、GPUを継続的にもっと徹底的に駆動するスピンループの方が、クロックレートを最大パフォーマンスに維持するのに効果的かもしれないね。
Show HNは見逃したんだけど、それを見て真っ先に頭に浮かんだのは、これがすごくクリエイティブなASMRサウンドスケープや、没入感のある多次元オーディオを作るのに合いそうだなってことだったよ。自分勝手だけど、あなたかユーザーの誰かがデモを作ってくれるといいなと思ってる。プロジェクトおめでとう！そしてAppleの問題、手助けが得られるといいね。
素晴らしい投稿だね。説明は明確で分かりやすかったよ。あなたが説明してる問題には、他の状況で間違いなくぶつかったことあるよ。
hw/swの連携に関するこういう細かいことまで知らなくていいプログラマーの半分以上にとっては、これは技術的すぎるね。
feedback出した？次のステップとしてはそれが良さそうだね。
記事は以下のTL；DR：から始まってるよ、短くしてるけどね：
＞誰かAppleの中にいる適切な人に繋いでくれるか、僕のfeedbackリクエストFB17475838とこのdevlog記事を見てくれると嬉しいな。
feedbackはだいたい届かないブラックホール行きだけど、みんなで報告するか、Apple社員が社内で推すか、Twitter/Xでバズらせるかのどれかがあれば別。投稿主は社員に届くのを狙ってるみたいで、それが一番可能性高いね。
他のやり方としては、WWDCの時にAppleエンジニアとの時間を予約して、そこで事情を訴えるって手もあるよ。
僕もこれを勧めようと思ってたんだ。既存のmetalでどう改善できるかのヒントももらえるかもしれないしね。
feedbackなんて、change.orgで政治家に「犯罪やめてください」って嘆願書作るのと同じくらい効果ないよ。何か月も経ってから「それは実際の問題ですね」って返事もらえたら運が良い方だよ。
みんな、うまくいったよ！Metalチームのまさに適切な人とすごく有益な話ができたんだ！Appleに注目してもらうのを手伝ってくれてありがとう。こんなにたくさんのサポートは全然期待してなかったからさ。https://anukari.com/blog/devlog/productive-conversation-appl…
技術詳細は秘密だけど、短期的に解決するヒントはもらえたっていいね。でも回避策すら共有できないのは、いかにもAppleの秘密主義っぽいね。回避策を実装する時は、リバースエンジニアリングでわかるような関数名にして、他の開発者にもヒントがいくようにしてくれると嬉しいな。
アイデアは好きだけど、多分やらないかな。でも、もし本当に同じ問題抱えてる人がいたら、俺に連絡してくれよ。Appleの詳しい人に繋いであげるから、情報シェアできるかもね。
またしても、HNはその真の目的を果たしたね。大企業のカスタマーサポートの前にあるお役所的な壁をぶち破ってくれたんだ。おめでとう、そして君のプロジェクト頑張って！
Apple App Storeで有名なアプリ開発会社で働いたけど、Appleの担当チームは俺らの問題を全然気にしなかったな。WWDCの新機能サポートはゴリ押ししてきたけど。バグの解決にはテクニカルサポートチケット使いまくり。
Appleの開発者向け担当は真面目じゃないね。
君の経験が普通じゃなくて良かった。
10年前に、有名アプリ会社で働いてた時、Appleアップデートでアプリのパフォーマンスが壊れたんだ。ちょうどその頃出た競合アプリは大丈夫だった。結局、競合開発者がAppleを辞めてて、Appleのビデオドライバーに未公開の仕掛けを残して俺らのアプリを壊してたんだ。
競合バイナリを逆アセンブルして未公開の変更を見つけて直すのに苦労したよ。そいつはCEOに挑発メールまで送ってきた。ひどい世界だね。
＞ Metal profilerには信じられないほど便利な機能があるんだ。アプリケーションをプロファイリング中にMetalの“Performance State”を選べるんだよ。これはprofiler以外では設定できない。
これ、private APIがあるのかもね。もしかしたら、リバースエンジニアリングする方が簡単かも？SIPを無効にしないと回避できない特別なEntitlementが必要になる可能性もあるけど。
これ、private APIがあるに決まってるよ。記事にもこう書いてるし：
＞ Metal profilerには信じられないほど便利な機能…
private APIなかったらprofilerはどうやってそれやるんだ？（デバッグツールで監視すれば分かるかな？）
これをAPIとして公開することの問題点は、あまりにも多くの開発者が常に最高パフォーマンス状態を強制しちゃうことだね。それをするのを止めて、同時にAPIを提供する良い方法があるのかは分からないな。
バッテリー駆動デバイスでは、アプリ一つが無駄にバッテリーを消費する方法は無限にあるんだよ。全部、開発者が意図的にしろ、事故にしろ、エネルギー集約的なタスクを不必要に実行しないことにかかってるんだ。不適切に使われるとエネルギーを無駄にする可能性のあるAPIを一つ追加しても、何も変わらないよ。
macOSにはこういうの知らせる機能がいっぱいあるよ！確かバッテリーメニューで電力使いまくるアプリ教えてくれるんだ（僕のiTermはいつもそこに出てくる！）
僕の勘違いかもだけど、iTermって中で動かしてる処理がエネルギー食ってる時にだけ出るんじゃない？コマンドラインでシミュレーションとかCPU負荷高いことやる時にだけバッテリーメニューに出てくるよ。
記事でゲームモードに触れてるね。あれは最新のApple OSの機能で、こういうケースに最適化されてるんだ。ゲームモードは有効になると通知が出るんだけど、たいていのアプリはこれを出したくないだろうね。今のところ悪用してるのは見てないよ。
フルスクリーンウィンドウ必須にすれば、ほとんどの悪用は防げるんじゃない？だってバックグラウンドからは無理だからね。
もっとコメントを表示（1）
デベロッパーは（まだ）audio workgroupsを悪用してpcoreスケジューリングとか高優先度を得てないね。だからもしaudio workgroupがGPUにコマンド送ってるなら、最後に送った時間でGPUダウンクロックにタイムアウトとか設けるべきかも。GPUオーディオは今かなりニッチだけど、記事の会社がSDK出して普及するかも。でも僕は反対だな。GPUでやるってことはレイテンシ気にしないってことなんだから、バッファサイズ増やせばいいだけだし。
＞ GPUで何かやってるなら、レイテンシ気にしないってこと
これは違うよ。明らかに、今日のGPUでも低レイテンシのオーディオ処理はできるんだ（SDKによると）。
audio workgroupsはあんまり詳しくないんだけど、XNUの初期からpthreadsを疑似リアルタイムで設定する低レベルAPIはあったんだ。
これでユーザーのTime Machineバックアップより高優先度では動くだろうけど、バッテリー駆動中でアプリがフォーカス持ってないなら、p-coreで動く保証はないよ。
APIを悪用する方が、同じことするのに偽のビジー状態作るより効率的だろうね。偽のビジー状態なんて、API（や必要な権限）なしでもアプリはもうできることだし。
手動で許可？多分どこか隠されてるんだろうね、すごくニッチなアプリには必要かも。
OSレベルでZoomとかTeams、ウェブブラウザはデフォルト拒否でいいよ笑
でも筆者が言ってるみたいに、もうプロセスを延々と動かすことで悪用はできてんだよ。もし悪用したいなら、もうできるしできるだろうね。信用した方がマシだよ、悪用しない人の数はする人をはるかに上回るから。
こうするのが一番いいやり方だよ：1．WWDCの動画を見て、直面してる問題について一番詳しそうなエンジニアを見つけるんだ。2．その人たちに直接このフォーマットでメールするんだ：Michael Thomsonならmthomson@apple.comみたいにね。
余談だけどさ：AnukariはMick Gordonのサウンドパックを出して、彼と収益を分け合うべきだよ。あの人はマジですごいもの作ってるからね；彼のデモは最高。こんな強力なツールができたら、アーティストと組むのはビジネスとしても良いし、世のためにもなるよ。もしMick Gordonが好きならね。俺は好きだけど。
このアプリ全く必要ないけど、マジでクールだね。こういうアプリがコンピューティングに「楽しさ」を取り戻してくれるんだ。今つまらないってわけじゃないけど、昔のグラフィカルで実験的なプログラムが色々あった頃とか、デモシーンを思い出すよ。
最後から2番目の段落にあるMick Gordonが作ったデモへのリンク（https://x.com/Mick_Gordon/status/1918146487948919222）を見逃すなよ、@anukarimusicはそれにこう返信してるんだ＞笑 リリースして2日目なのに、俺が2年間毎日使って作ったデモ全部をもう完全にぶっ壊しちまったな
1024個のオブジェクトを48khzでアップデートするのはCPUでも可能そうだけどねーコードの書き方次第かな。毎秒48M回アップデート？OpenMPを使ってコア間で並列処理するのに使えるかもね。
Anukariはポリフォニーで物理モデル16個動かすから、実際の負荷は計算よりもっと高いんだ。オブジェクト間の接続処理や同期、機能の多さでCPUだと難しい。GPUなら完全に並列処理できて、このワークロードに最高なんだよ。
俺の計算が正しければ、サンプル1つ計算するのに83クロックサイクル使えるってことか。16コアなら理論上1333サイクル。CPUを常にほぼ100％使えるわけじゃないと考えたら、大した数じゃないな。
一つわかんないんだけど、もしレイテンシが大事なら、なんでCPUってGPUが処理中に次のGPUの”仕事”を準備しないの？
それってオーディオプラグインAPIの制限なのかな？
ブログ記事で「GPUを飽和させるためにGPUコードをパイプライン処理しないの？」って疑問に先回りして答えようとしたんだけど、説明不足だったかも。
メインの理由は、AnukariはMIDIとかオーディオをリアルタイムで処理するから、入力データがまだないのにCPUより先に進めないんだ。
あなたが言ってるのはダブルバッファリングに近くて、それも検討したけどレイテンシが増えちゃう。
それに、GPUクロックが低すぎると、パイプラインやダブルバッファリングは意味がないんだ。
リアルタイムに追いつく必要があるし、処理は前の結果に依存してるからね。
GPUクロックが低いと、レイテンシじゃなくてスループットが問題になるんだ。
それはパイプライン処理ってやつで、スループットにはいいけど、レイテンシを犠牲にするんだ。
オーディオは連続したビットストリームじゃなくて、小さなパケットの連続だよ。
CPUで次のパケットを処理し始めるには、GPUが前のパケットを処理してる間に、2つのサンプルが同時に処理中ってことになって、必然的にレイテンシが高くなるんだ。
そうかなあ。
CPUがパケット#1の終了を待たずに、GPU処理中にパケット#2の処理を始めたら、パケット#2用のGPUデータが早く準備できて、早く送れるはずだよ。
GPU処理が終わった瞬間に送れるかも（パワフルならもっと早く）。
だからプラグインAPIについて聞いたんだ。
APIは非同期で、”パケット”処理完了を待たずに、早くデータを受け付け可能になったらすぐに返るべきかもね。
オーディオは非同期だけど、前のバッファ処理が終わる前に次の処理はできない。
処理は状態を持つからデータ競合するし、リアルタイムでロックはダメ。
事前バッファリングはレイテンシ増やすだけ。
因果関係で、パケット#1処理中にパケット#2は無理。まだデータがないから。
オーディオデバイスはバッファを一定間隔で交換する。
パケット#1は現在のバッファ、パケット#2は次。
パケット#1処理にNサンプルより多く必要な場合、必要なデータが揃うまで待つけど、出力は遅延させる。
処理はできるが、ストリームが遅れるんだ。
あなたはパケット#1が終わる前にパケット#2が必要と言ってるけど、それは目標よりレイテンシが高いよ。
目標は、パケット#2が到着する前にパケット#1を処理して出力することなんだ。
MIDI楽器みたいな入力イベントがあることを見落としてない？
これは「入力」→「エフェクト」→「出力」のシーケンスなんだ。
レイテンシ最小化には、「エフェクト」部分が小さく、「入力」データ供給より速く終わるのが理想だよ。
これって、ヒューリスティクスを正しい方向に騙せるかもね。
つまり、GPUに大きなタスクじゃなくて、小さなタスク（例えば少ないサンプル数のやつ）をたくさん与えるってこと。
つまり、CPUはまだ存在しないサンプルのための仕事を準備できないってこと。
もし1ミリ秒分のオーディオを処理するのに0.5ミリ秒かかるとしたら、どうしても常に止まったり始まったりすることになるんだ。
GPUを連続して供給し続けることはできないよ。
問題がよくわかんないんだ。
実際のユーザー症状は何？
アプリはどのくらいレイテンシを許容できて、実際はどのくらい見てる？
もしその情報が最初にあれば、解決策を考えるのに役立つんだけど。
もしかしたら、このビデオに役立つ何かがあるかもね。
M3世代でスケジューリングとリソース割り当てをかなり変えたみたいだから。
https://developer.apple.com/videos/play/tech-talks/111375/
リアルタイムオーディオアプリだから、もしリアルタイムに遅れたら、オーディオが出なくなるんだ。
プチプチとかノイズが出て、全体が使い物にならなくなる。
もしユーザーが48 kHzでオーディオをやってるなら、必要なレイテンシはサンプルあたり1/48,000秒。
現実的には、ばらつきとかオーバーヘッドを考慮してそれより少し少ないくらいかな。
＞Audio Workgroupのスレッドで管理されるMTLCommandQueueはリアルタイムとして扱えて、GPUのクロックはそれに合わせて調整できるって？＞Metal APIにMTLCommandQueueがリアルタイムに敏感だって示すオプションを付けるだけで、そのキューを扱うGPUチップレットのクロックを調整できるようにしたら？
GPUでのリアルタイムスケジューリングとGPUのクロック速度は別の概念だよ。記事を読むと、問題はクロック速度にあって、ワークがどうスケジュールされるかじゃないみたいだね。GPUのクロックを高くするリクエストのヒントを出すために、別の何かが必要みたいだよ。
＞GPUでのオーディオ計算と並行して、AnukariはGPUで2番目のワークロードを実行するんだ。これは高い負荷平均を作り出してmacOSを騙してGPUをクロックアップさせるように設計されてる。このワークロードは、GPUを可能な限り少しだけ使いつつ、クロックヒューリスティクスをトリガーするのに十分な大きな人工負荷を作成するように調整されてるんだね。
これはかなりのハックだね、開発者の気持ちわかるよ。投稿で彼らが言ってるように、GPUでのオーディオは本当に新しい分野だし、Appleがこれに対応してくれるのを期待しない方がいいだろうね。
面白いトレードオフだね。何十年も、信頼できるWindowsパソコンを持つための答えは、できるだけ多くの省電力機能をオフにすることだった。例えば、USBポートの省電力をオンにするとマシンがクラッシュしたりする。CPUの状態を最低限に落とすと、3000ドルのデスクトップがキー入力に反応するのに約1秒かかったりする。省電力効果は本当じゃないかもしれないけど、クラッシュやひどいパフォーマンスはすごく現実的なんだ。
ここで何を願ってるか、気をつけてね。Appleを知ってる限り、どんなAPIリクエストも無視するだろうし、記事で説明されてるプライベートAPIの回避策でアプリを閉め出す可能性も十分あるよ。
AnukariはMac App Storeにはないと思うし、ああいうプラグインがApp Storeに適してるなんて絶対ないと思うから、あなたが何を心配してるのか正直よくわからないな。
全然違うけど、Apple silicon（iPhoneもね）でまともに性能出すのは昔からトリッキーだったよ。Abletonのエンジニアも評価してた。
Appleの”フィードバック支援”不足の不満はわかるけど、問題自体は難しい。昔Pro Audio PCショップで働いてたけど、ドライバとか電源管理とか全部大変だった。今でもCPUとかBIOS調整が必要かも。壊れたドライバの報告は大変だよ:)
もっとコメントを表示（2）
問題のこと聞いて残念だよ、でもAppleのこういうことに関してのこれまでの実績を考えるとそんなに驚かないな（いまだにプロセスを特定のCPUコア スレッドに固定することすらできないんだぜ）。でもAnukariは本当にクールだね、Linux版があったらいいのに :)
これは全部ストックホルム症候群がひどすぎるだけだよ。AppleのDX（開発者体験）は昔からひどすぎたし、こういうブログ投稿が続くのがその証拠。
独自技術、ドキュメント不足、API廃止、WWDCの遅さ、基本的なことすら許さない。
UI、Core data、NetworkingといったAPIはめちゃくちゃ。Xcodeは最低評価のIDE。
SwiftはApple以外では使われてない。サーバーサイドは死んだ。
でもApple開発者は虐待されるのが好きみたい。DTSやWWDCセッションもひどいらしいよ。「こうやれば動くんだ、ドキュメントにないけどね！」って感じ。
このプラットフォームを離れてクロスプラットフォームにするのが、Appleが反省する唯一の方法だよ。
君に異論はないけど、プロオーディオ開発者にとって替えがきかないんだよ。ユーザーがいる場所に行くしかないし、収入で見ると市場の多数派はMacユーザーだからね。これに「WindowsだってASIOとかWASAPIとかあるじゃん」とか「Linuxのpipewireがjackいらずに変えつつある」とか言う人もいるかもだけど（C言語以外でpipewireネイティブソフト書きたいなら神に祈るレベルだけど）、そういう変化があっても、収益があるところ、つまりmacOSに行くしかないんだよ。
Appleの最悪な点の一つは、サポートしようとすると彼らのプラットフォームに閉じ込めるために費やす時間と労力。言い訳の余地なし。一度システムに入っても、彼らはワークフローや開発環境に閉じ込めるためにあらゆる手を使ってくる。OSXがこんなに露骨に敵対的とか正気の沙汰じゃない。
正直、多くの開発者がMacOSでソフト作ろうとし続けるのはクレイジーだよ。今のハードの魅力はわかるし、昔はユーザー体験も大好きだったけど、MacOSでソフト作ろうとするのは砂上の楼閣に家を建てるようなもんに見えるね。Appleは開発ターゲットとしての彼らのプラットフォームへの信頼を育むために何もしてこなかったし、今もしてない。
確かに完璧じゃないし、ひどいとこもいっぱいあるけど、せめて事実だけは確かめようよ。
AppKitとかauto layoutはまだ全然動くし、すぐ消えるわけじゃない。UIコード全部書き直す必要なんてない。
Core Dataのスレッド問題？まあ、落とし穴はあるけど、それは知られてることだし、とにかく使うのが強制されてるわけじゃない。
Xcodeは最近かなりスリムになったよ。ダウンロードは3GBくらいだし、解凍に1時間もかからないし、 developer websiteからDLできる。
Swift？いくつかの新しいフレームワークには必要になるかもしれないけど、Objective-Cもすぐにはなくならない。
あと、Linuxデスクトップだってこれらの違反行為のほとんど、いやもっとひどいことを犯してるってことも忘れちゃいけないね。
Core Dataのスレッド問題？LinuxはCore Dataみたいなものに挑戦すらしてる？それはどううまくいってる？
Swift？Linux狂信者がValaを発明したのを覚えてるよ。Linux版Swiftだけど、全然採用されてない。
UIコードについては、Linuxはやっとちょっと安定してきたとこだ。GTK 2から3は災害だったし、Qtはメジャーアップグレードの間は楽しくなかったし、フレームワーク使ってなかったら、Xorgの変な癖を楽しく学ぶ必要があったし、Linux向けにビルドしてる奴でMacのUI安定性について説教できる奴なんていないね。
というか、アプリの安定性全般についてもそう。Blenderの特定のビルドがFlatpak以外で2リリースサイクル経った後もLinuxデスクトップでまだ動くか？動かないだろ？だったら良いプラクティスについて俺に説教するなよ。俺のウェブサイトやアプリが依存関係があるからって雑に設計されてるなんて説教するな。
昔のMac OSや初期のOS Xの頃はドキュメントは素晴らしかったんだけどな、ドキュメントチームに何があったのかわからない。サーバー上のSwiftはAppleエコシステムの開発者向けで、コード共有するためでしょ、サーバー上で何かまともなものじゃなくてJavaScriptを使う理由と同じように。
その日のディストリビューションを相手にしたり、サウンド、グラフィックススタック、UIなどをイチからやり直すよりは、まだエンジニアリングがマシだよ。
昔々、GNOMEかKDEのどちらかが勝って、みんなで一つのLinuxディストリビューションを楽しめると思った時があったけど、それが間違いだとわかったね。
とはいえ、Windows 7以降はずっとWindowsをメインOSにしてるけど。
Apple独自のハードウェアを最大限に活用するために、独自のフレームワークを作成する以外に、一体彼らは何をすべきだって言うんだ？彼らのシステムに最適化されていないクロスプラットフォームフレームワークを使ってほしいのか？
問題は特別なAPIが登場するずっと前から始まってるんだ。Macをサポートしてた時、他のシステムと同じようにAPIをラップしてただけ。問題は俺がMacを使ってないってこと。だからMac向けにソフトを作るのは本質的に面倒なんだ。LinuxやOpenBSDからはWindows向けにビルドもテストもできるけど、Macはできない。
Appleはサードパーティ開発者がプラットフォームを条件付きコンパイルされた抽象化でロックするのは嫌がるって言うかもしれないけど、システムAPIなんて普通の抽象化の理由でラップされるもんだろ。それに、それは完全に問題ないし、Appleの問題であって俺の問題じゃない。彼らのプラットフォームをサポートするのは構わないし、開発者フィーを取ってひどいドキュメントとサポートを提供してる大胆さにも目をつぶる。でも、へりくだって特権をお願いするつもりはないね。
”最適化されてないクロスプラットフォームフレームワークを使ってほしいのか？
”みんなそうしてるし、大して問題にならないからさ。Appleランドの外では、Intel、AMD、NvidiaはSPIR-Vをそれぞれのマイクロアーキテクチャに書き換えて全然うまくやってる。CPUはAMD64や様々なARMのような抽象的な命令セットをマイクロアーキテクチャに書き換えて全然うまくやってる。コードはデフォルトで命令互換性のためにコンパイルされるんだ。CUDAやROCmみたいなAPIは明らかにベンダーロックインのために存在する。これらのAPIのスループットがコンピュートシェーダーに一般的に適用できない理由なんて全くない。ハードウェアベンダーはただ市場を囲い込みたいだけなんだ。
Appleは別にエキゾチックなハードウェアを使ってるわけじゃない。M1はまた別のARMチップで、変なグラフ縮約マシンじゃない。これらの標準は問題なく、様々なハードウェアで広範囲に使われてて何の実害もない。彼らが”特別に最適化されたAPI”っていう考えをどれだけ気にしてるか、君は過大評価してるかもよ。AppleがOSXでソフトを出荷するのに”使うべき”主要言語としてSwiftを推してるのに、ガベージコレクションがまだソフトウェアで処理されてるの考えてみろよ。それがエンジニアリング目的の垂直統合の姿じゃない。
繰り返すけど、そんなことは大した問題じゃない。これらのAPIをラップするだけなら気にしないよ、彼らのハードウェア以上に特別とかエキゾチックなわけじゃないから。でも、現実として、非Macユーザーとして、彼らはプラットフォームにソフトを載せるのをできるだけ魅力的でなくするためにめちゃくちゃ努力してるね。
Wikipediaだってwhataboutismは当然の時もあるって言ってるぜ。ここではまさにそうだよ — Appleは100フィートの塔を建てて、ここ数十年間でボサボサになった。Linuxは同じ期間に階段なしで7本の30フィートの塔を建てたんだ。なのに、100フィートの塔のボサボサについて文句言うのはどういうわけか正当化されちゃうんだな。
自分たちがちゃんと塔を建てられないなら、メインの塔が自分たちのより悪く建てられたみたいに振る舞う権利なんてないだろ。(追記、投稿早すぎたな: Appleがお金持ってるっていう文句についてだけど、Linuxだってそうだよ。Linuxの仕事の90%以上は企業からの資金援助だし、最初に集計された2004年からずっとそうだ。もっとちゃんとできるはずだよ)
”Appleは何もしなかったし、開発ターゲットとしてのプラットフォームに信頼を生み出すために何もし続けてない”だって？
木を見て森を見てないな。Appleは確かに一緒に仕事するのはすごく難しいけど、金を払うユーザーが死ぬほどいるんだぜ。今でもiOSはAndroidより収益性が高い。macOSもWindowsと同じだよ。稼ぎたい？macOSでリリースしろって。そこにいる人たちはソフトにお金出すんだよ。
WASAPIの何が足りないの？FL Studioのビートメイカーがいっぱいいるの見ると、今のオーディオ作業ならWindowsって全く問題ないって証明されてると思ったんだけど。
”Stockholm syndrome”か。それは適切じゃないと思うな。君が”虐待”だって思ってることも、他のプラットフォーム/エコシステムにもある普通レベルの障害/問題だって思う人もいるんだ。
たぶん、最初からAppleを特別な存在だって思わなければ助けになるよ。だから、彼らが避けて通れない不完全さを見せた時に、特別な失望もしない。
とにかく、開発者は大人なんだから、Appleのエコシステムで働く価値があるかどうか、自分で判断できるんだ。君はもう決めたみたいだね。じゃあ、他の人にも自分で決めさせてやれよ。
これは”芝刈り機を擬人化するな”って領域だと思うね。Appleは3rdパーティ開発者に積極的に敵対してるとか、閉じ込めようとしてるとは思わないな。単に無関心なんだと思うんだ - あるいは、組織内で個々の開発者が気にかけてたとしても、会社として気にかけるキャパがないとか。
Appleの開発者体験がひどすぎるのは、価値の高いアプリケーションをAppleデバイス向けに開発できる人はみんなApple社内にいるか、これからAppleで働くと思ってるからだろ。3rdパーティ開発者は、彼らのサービスやデバイスにとって核となる付加価値じゃなくて、我慢してる迷惑な存在なんだ。Apple社内ならマシなんだろうけど、マジで分からないな。
ここでなんで低評価されてるか分かんないわ。
Linuxデスクトップのエンジニアリング基準とか、コロコロ変わる感じとか、マジで笑えるくらいひどいからな。
node_modulesが依存関係だらけでJavaScriptアプリが脆いとか文句言ってる奴らには、それを言う資格はないんだよ。彼らの自慢のLinuxデスクトップだって、Flatpakなしだと3年後には同じソフトビルドがクラッシュして動かなくなるかもしれないぜ。
ドキュメント不足については、QtとかGTKとかクロスプラットフォームのソリューションを使わないで、完全ネイティブのLinuxアプリ書くのに必要なもの全部集めるのにどれだけ苦労するか想像してみろよ。Macなら比較的簡単な要求だ。そんな特権的なルートから外れると、Linuxのドキュメント不足はAppleのドキュメントがゴールドスタンダードに見えるレベルになるぜ。まあ、特権ルートに留まってても、たぶんろくなことにならないんだろうけどな。
Logic以外のほぼ全てのソフトはWindowsでも使えるのに、ユーザーはまだMacを買ってるんだよな。そういうユーザーの中でも、DirectsoundやwasapiバックエンドじゃなくてASIOにフォールバックする人が多い。
WASAPIはプロ用アプリで使うには排他モードが必要なんだ。そうしないとレイテンシがひどくなるし、裏でリサンプリングされてる可能性もあるしな。
言い訳は一つ：株主だよ。囲い込みが強ければ強いほど、シャンパンがじゃんじゃん開くんだ。
Appleに出荷するのとWindowsに出荷するのを比べたら、敵対的かどうかが分かるって。MicrosoftはMSVCスイートをWine環境にコピーして彼らのプラットフォーム向けにソフトをビルドしても気にしないし、SignToolだって動く。簡単じゃないけど、それはMSVCスイートが他のMicrosoft製品みたいにひどいごちゃ混ぜだからってだけだ。
Appleは利用規約でクロスコンパイルを明確に禁止してるんだよ。Unix上でMac用にclangでコンパイルできたとしても、OSX以外でアプリバンドルに署名する方法を見つけたとしても、利用規約違反だってことで開発者ライセンスを取り消されて証明書も無効にされる。サードパーティ開発者を気にしてないってのは君の言う通りだけど、Macでのdevopsで乗り越えなきゃいけない障害の量は、ほぼ間違いなく囲い込みのための罠として設計されてると思うね。
