これらの比較で、SwiftはどのようにObjective-Cよりもずっと速くできますか？

Apple はWWDC14で新しいプログラミング言語Swiftを発売しました。プレゼンテーションでは、Objective-CとPythonのパフォーマンスを比較しました。以下は、これらのスライドの1つで、複雑なオブジェクトの並べ替えを実行するこれら3つの言語の比較の写真です。

RC4暗号化アルゴリズムを使用したパフォーマンス比較について、さらに驚くべきグラフがありました。

明らかにこれはマーケティングの話であり、彼らはこれがそれぞれにどのように実装されているかについては詳しく説明しませんでした。私は私が疑問に思うままにします：

1. 新しいプログラミング言語はどのように高速化できますか？
2. Objective-Cの結果は不良なコンパイラが原因ですか、Objective-CではSwiftよりも効率が悪いものがありますか？
3. 40％のパフォーマンス向上をどのように説明しますか？ガベージコレクション/自動化された参照制御は、追加のオーバーヘッドを生成する可能性があることを理解していますが、これだけですか？

まず、（IMO）Pythonと比較することはほとんど無意味です。Objective-Cとの比較のみが意味を持ちます。

• 新しいプログラミング言語はどのように高速化できますか？

Objective-Cは遅い言語です。（C部分のみが高速ですが、それはCであるためです）極端に高速になったことはありません。それは彼らの（Appleの）目的に対して十分に速く、古いバージョンよりも高速でした。遅いのは...

• Objective-Cは不良なコンパイラの結果ですか？Objective-CではSwiftよりも効率が悪いものがありますか？

Objective-Cは、すべてのメソッドが動的にディスパッチされることを保証しました。静的ディスパッチはまったくありません。そのため、Objective-Cプログラムをさらに最適化することはできませんでした。おそらく、JITテクノロジーは助けになるかもしれませんが、Appleが予測できないパフォーマンス特性とオブジェクトの有効期間を本当に嫌っています。私は彼らがJITのものを採用したとは思わない。Swiftには、Objective-Cとの互換性のために特別な属性を設定しない限り、このような動的なディスパッチ保証はありません。

• 40％のパフォーマンス向上をどのように説明しますか？ガベージコレクション/自動化された参照制御は、追加のオーバーヘッドを生成する可能性があることを理解していますが、これだけですか？

ここではGCやRCは関係ありません。Swiftはまた、主にRCを採用しています。GCはありません。また、GCテクノロジーに大きな飛躍がなければ、GCもありません。（IMO、それは永遠です）Swiftには静的最適化の余地がもっとあると思います。特に低レベルの暗号化アルゴリズムは、通常、膨大な数値計算に依存しているため、静的ディスパッチ言語にとっては大きな勝利です。

実際、40％が小さすぎるように見えるので驚いた。もっと期待した。とにかく、これは最初のリリースであり、最適化は主な関心事ではなかったと思います。Swiftは機能が完全ではありません！彼らはそれを改善します。

更新

GC技術が優れていると主張するように私を悩ませ続ける人もいます。以下のものは議論の余地があり、私の非常に偏った意見ですが、この不必要な議論を避けるために言わなければならないと思います。

保守的/トレース/世代別/増分/並列/リアルタイムGCが何であり、どのように異なるかを知っています。ほとんどの読者もすでにそれを知っていると思います。また、GCはある分野では非常に優れており、場合によっては高いスループットを示すことにも同意します。

とにかく、GCスループットの主張は常にRCよりも優れていると思います。RCのオーバーヘッドの大部分は、参照カウント操作と、参照カウント変数を保護するためのロックによるものです。また、RC実装は通常、カウント操作を回避する方法を提供します。Objective-Cで、あります__unsafe_unretained（それはまだ私にはやや不明だが）、スウィフトにしてunowned詰め込むが。参照カウントの操作コストが許容できない場合、メカニックを使用して選択的にオプトアウトすることができます。理論的には、非保持参照を非常に積極的に使用してRCオーバーヘッドを回避することにより、ほぼ一意の所有権シナリオをシミュレートできます。また、コンパイラーがいくつかの明らかな不必要なRC操作を自動的に除去できると期待しています。

AFAIKのRCシステムとは異なり、参照タイプの部分的なオプトアウトはGCシステムのオプションではありません。

GCベースのシステムを使用している多くのリリースされたグラフィックやゲームがあり、それらのほとんどが決定論の欠如に苦しんでいることも知っています。パフォーマンス特性だけでなく、オブジェクトのライフタイム管理も目的です。UnityはほとんどがC ++で書かれていますが、小さなC＃部分がすべての奇妙なパフォーマンスの問題を引き起こしています。HTMLハイブリッドアプリであり、どのシステムでも予測できないスパイクに悩まされています。広く使用されているということは、それが優れているという意味ではありません。それは、それが多くの選択肢を持たない人々にとって簡単で人気があることを意味します。

更新2

ここでも、不必要な議論や議論を避けるために、さらに詳細を追加します。

@Asikは、GCスパイクに関する興味深い意見を提供しました。それは、value-type-everywhereアプローチをGCの内容をオプトアウトする方法と見なすことができるということです。これは非常に魅力的であり、一部のシステムでも実行可能です（たとえば、純粋に機能的なアプローチ）。これは理論的には素晴らしいことです。しかし、実際にはいくつかの問題があります。最大の問題は、このトリックを部分的に適用しても、真のスパイクフリー特性が得られないことです。

レイテンシーの問題は常にすべてまたは何の問題もないからです。10秒間に1つのフレームスパイク（= 600フレーム）がある場合、システム全体に明らかに障害が発生しています。これは、どれだけ良くも悪くもありません。合格または不合格です。（または0.0001％未満）では、GCスパイクの原因はどこですか？これはGC負荷の不適切な分散です。それは、GCが根本的に不確定だからです。ガベージを作成すると、GCがアクティブになり、最終的にスパイクが発生します。もちろん、GC負荷が常に理想的である理想的な世界では、これは起こりませんが、私は想像上の理想的な世界ではなく現実の世界に住んでいます。

スパイクを避けたい場合は、システム全体からすべてのref-typeを削除する必要があります。しかし、.NETコアシステムやライブラリなどの取り外し不可能な部分のために、困難であり、非常識で、不可能です。GC以外のシステムを使用する方がはるかに簡単です。

GCとは異なり、RCは基本的に決定論的であり、スパイクを回避するためだけに、この非常識な最適化（純粋な値型のみ）を使用する必要はありません。あなたがしなければならないことは、スパイクの原因となる部分を追跡して最適化することです。RCシステムでは、スパイクはローカルアルゴリズムの問​​題ですが、GCシステムでは、スパイクは常にグローバルシステムの問題です。

私の答えはトピックから外れすぎており、ほとんどの場合、既存の議論の繰り返しに過ぎないと思います。GC / RCの優位性/劣性/代替またはその他の何かを本当に主張したい場合、このサイトとStackOverflowには多くの既存の議論があり、そこで戦い続けることができます。

Pythonよりも3.9倍高速であるため、一貫してかなりのマージンでほとんどのベンチマークを失っている言語です（わかりました、Perl、Ruby、PHPと同等ですが、静的に型付けされたものには負けません）。

ベンチマークゲームは桁以上速く、ほとんどの場合、PythonプログラムよりもC ++のプログラムを示しています。Java、C＃（Mono）、OCaml、Haskell、さらには静的に型付けされていないClojureと比較しても、それほど良くありません。

したがって、本当の問題は、Objective-Cがpythonの2.8倍しか速くないことです。どうやら彼らは、ObjCのゆっくりと完全に動的なディスパッチが多くを傷つけるベンチマークを慎重に選択したようです。静的に型付けされた言語は、より良くできるはずです。複雑なオブジェクトの並べ替えでは、オブジェクトを比較するためのメソッド呼び出しが多数あり、実際の比較自体はおそらくそれほど複雑ではありませんでした。そのため、Swiftが型情報を少なくともある程度活用すると、メソッド呼び出しで簡単に改善でき、ObjCで改善できる他の操作が十分にありません。

もちろん、ベンチマークゲームが明確に示しているように、さまざまなタスクの相対的なパフォーマンスは大きく異なるため、1つのベンチマークは実際には代表的ではありません。彼らがより大きな利点を持っているベンチマークを持っているなら、彼らは代わりにそれを私たちに示していたでしょう。

Objective-Cは、すべてのメソッド呼び出しを動的にディスパッチします。

仮説：ベンチマークでは静的型付けを使用して、Swiftコンパイラーがcompareメソッド検索をsortループ外に引き上げます。これには、Complexのサブクラスではなく、配列内のComplexオブジェクトのみを許可する狭い型制限が必要です。

（Objective-Cでは、言語ランタイムサポートを呼び出してメソッドポインターを検索することで、本当に必要な場合はメソッド検索を手動で上げることができます。配列内のすべてのインスタンスがまったく同じクラスであることを確認してください。 ）

仮説： Swiftは、ループからの参照カウント呼び出しを最適化します。

仮説： Swiftベンチマークは、Objective-Cオブジェクトの代わりにComplex構造体を使用しているため、動的なメソッドディスパッチ（サブクラス化できないため）または参照カウント作業（値型であるため）をソート比較に必​​要としません。

（Objective-Cでは、Objective-Cオブジェクトを含まない限り、パフォーマンスのためにC / C ++にフォールバックできます。たとえば、構造体のC配列をソートします。）

正直なところ、彼らが使用しているテストのソースを公開しない限り、この件に関してAppleが言わなければならないことは信用できない。覚えておいてください。これは、6か月前にIntelがコマーシャルでIntelバニーを吸って実際に放火したと言っていたときに、電力の懸念に基づいてPPCからIntelに切り替えた会社です。単なるソートよりも多くのカテゴリで、SwiftがObjCよりも高速であるという反論の余地のない証拠が欲しいと思います。

さらに、WWDCで公開されているすべての統計情報についても質問する必要があります。

そのすべては、私は自分自身でSwiftとObjCの間でテストを実行していないと言われていますが、私が知っていることから、Swiftには独自のLLVM IR拡張機能があり、ObjCよりもコンパイル時に多くの最適化が行われている可能性があります。

完全な開示：https://ind.ie/phoenix/にあるオープンソースのSwiftコンパイラを書いています。

SwiftがAppleのハードウェアだけで利用できるわけではないことを確認したい場合は、お知らせください。喜んでお知らせいたします。

私はSwiftチュートリアルで苦労してきましたが、Swiftはより現実的なもの（Visual Basicを考えさせる）であり、Objective-Cよりも「オブジェクト化」が少ないように思えます。CまたはC ++を考慮に入れた場合、コンパイル時のみであるため、後者が勝ったと思われます。

この場合、Objective-Cはオブジェクト指向の純粋さ（およびオーバーヘッド）の犠牲になっていると思います。