質問: swiftをこれらの比較でobjective-cよりもはるかに高速にするにはどうすればよいですか? appleは新しいプログラミング言語 swift at wwdc14 を発表しました。プレゼンテーションでは、objective-cとpythonのパフォーマンスを比較しました。以下は、スライドの1つで、複雑なオブジェクトの並べ替えを実行する3つの言語を比較した図です。 rc4 暗号化アルゴリズムを使用したパフォーマンス比較について、さらに驚くべきグラフがありました。明らかにこれはマーケティングの話であり、彼らはこれがそれぞれにどのように実装されているかについて詳細には触れませんでした。しかし、私は疑問に思います: 新しいプログラミング言語はどのようにしてはるかに速くなりますか? objective-cの結果はコンパイラの不良が原因ですか、それともswiftよりもobjective-cで効率が悪いものがありますか? 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テクノロジーに大きなアーキテクチャ上の飛躍がない限り、そうではありません。(imo、それは永遠です)私は信じていますswiftには静的最適化の余地が非常にあり、特に低レベルの暗号化アルゴリズムは、通常、巨大な数値計算に依存しているため、静的にディスパッチする言語にとっては非常に有利です。実は40%は小さすぎてビックリしました。私ははるかに期待していました。とにかく、これは最初のリリースであり、最適化は主な関心事ではなかったと思います。 swiftは完全な機能でもありません!彼らはそれをより良くします。更新gcテクノロジーの方が優れていると主張するように私を悩ませている人もいます。以下のものは議論の余地があるかもしれませんが、私の非常に偏った意見ですが、私はこの不要な議論を避けるために言わなければならないと思います。保守的/トレース/世代別/増分/並列/リアルタイムgcとは何か、それらがどのように異なるかを知っています。ほとんどの読者もすでにそれを知っていると思います。また、gcは一部の分野では非常に優れており、場合によっては高いスループットを示すことにも同意します。とにかく、gcスループットの主張は常にrcよりも優れていると思います。 rcのオーバーヘッドの大部分は、参照カウント操作と、参照カウント数変数を保護するためのロックによるものです。また、rc実装は通常、操作のカウントを回避する方法を提供します。 objective-cには__unsafe_unretainedとswiftでは(まだはっきりしていませんが)unownedもの。参照カウントの運用コストが許容できない場合は、メカニズムを使用して、それらを選択的にオプトアウトすることができます。理論的には、非保持参照を非常に積極的に使用してrcオーバーヘッドを回避することにより、ほぼ一意の所有権シナリオをシミュレートできます。また、コンパイラーが明らかな不要なrc操作を自動的に削除できることも期待しています。rcシステム、afaikとは異なり、reference-typesの部分的なオプトアウトはgcシステムのオプションではありません。gcベースのシステムを使用している多くのリリースされたグラフィックスとゲームがあり、それらのほとんどが決定論の欠如によって苦しんでいることも知っています。パフォーマンス特性だけでなく、オブジェクトのライフタイム管理も行います。 unityは主にc++で書かれていますが、小さなc#の部分がすべての奇妙なパフォーマンスの問題を引き起こしています。 htmlハイブリッドアプリであり、どのシステムでも予測不可能なスパイクが発生しています。広く使用されていても、それが優れているとは限りません。それは、それが多くのオプションを持たない人々にとって簡単で人気があることを意味します。アップデート2ここでも、不必要な議論や議論を避けるために、もう少し詳しく説明します。@asikは、gcスパイクについて興味深い意見を述べました。 value-type-everywhereアプローチは、gcをオプトアウトする方法と見なすことができます。これはかなり魅力的で、一部のシステムでも実行できます(たとえば、完全に機能的なアプローチ)。これは理論的にはニースであることに同意します。しかし、実際にはいくつかの問題があります。最大の問題は、このトリックを部分的に適用しても、スパイクのない真の特性が得られないことです。レイテンシの問題は常にall or nothingの問題だからです。 1フレームのスパイクが10秒間(= 600フレーム)ある場合、システム全体が明らかに失敗しています。これはどれほど良いか悪いかではありません。合格または不合格です。 (または0.0001%以下)では、gcスパイクの原因はどこにあるのでしょうか。これはgc負荷の分散が悪いです。そしてそれは、gcが根本的に不確定であるためです。ガベージを作成すると、gcがアクティブになり、最終的にスパイクが発生します。もちろん、gc負荷が常に理想的な理想的な世界では、これは起こりませんが、私は架空の理想的な世界ではなく、現実の世界に住んでいます。次に、スパイクを回避する場合は、システム全体からall ref-typesを削除する必要があります。しかし、それは難しく、非常識で、.netコアシステムやライブラリなどの取り外しできないパーツのために不可能ですらあります。 非gcシステムを使用する方がはるかに簡単です。gcとは異なり、rcは基本的に決定論的であり、スパイクを回避するためだけにこの非常識な最適化(純粋な値型のみ)を使用する必要はありません。あなたがしなければならないことは、スパイクを引き起こす部分を追跡して最適化することです。 rcシステムでは、スパイクはローカルアルゴリズムの問題ですが、gcシステムでは、スパイクは常にグローバルシステムの問題です。私の答えはあまりに話題外になりすぎていると思います、そしてほとんどは既存の議論の繰り返しです。 gc/rcの優れている点、劣っている点、またはその他の点について本当に主張したい場合は、このサイトとstackoverflowで多くの既存の議論が行われているので、そこで戦い続けることができます。