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


115

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

ここに画像の説明を入力してください

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

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

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

13
@MathewFoscarini Obj-Cはアセンブラーに送られますが、高価なオブジェクトメッセージディスパッチメカニズムがあります。ほとんどのGUI作業では重要ではありませんが、ソートでは非常に重要です。
ドナルドフェローズ14年

17
Pythonとの比較は、ここで実際に頭を悩ます人です。
asthasr

9
@syrion marketing、および言語はpythonの構文(golangによく似ています)を借用しているようです。彼らは言って、「ねえ、Pythonの開発者は、あなたがより速くあなたが本当にのこつをやったことがなかったのObjective Cよりも、Mac上であまりにも外国人ではない何かを書くと、それはそんなに速くなることができます」しようとしている

4
@MichaelTそれはわかりますが、まだ奇妙です。言語について何かを知っている人は誰でも、Pythonがインタープリター言語として、Objective-Cまたは他のコンパイル済み言語(ほとんどのタスク)と同じ球場にいるわけではないことに気付くでしょう。ベンチマークとして使用するのは奇妙です。
asthasr

7
彼らはおそらく...それはコードを書くのにかかる時間を意味する
ルーカス・エダー

回答:


62

まず、(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には多くの既存の議論があり、そこで戦い続けることができます。


4
ガベージコレクション、特に世代別コレクションは、通常、参照カウントより大幅に高速です。
ヤンHudec 14年

9
@JanHudec 大幅に高速化されているのは、リアルタイムグラフィックスの分野ではまったく意味がありません。だからこそ、GCには大きな飛躍が必要だと言っています。世代別GCは、理論的にも実際的にもスパイクフリーではありません。
エオニル14年

5
より速くスパイクフリーは完全に直交するカテゴリーです。世代別ガベージコレクターは高速です。スパイクフリーではありません
ジャン・ヒューデック

4
あなたが話しているのはスループットです。より高速は常に曖昧な用語であり、文脈によって何を意味してもかまいません。用語の意味について議論したい場合、特に現在のコンテキスト、リアルタイムグラフィックスを考慮すると、より速くよりも正確な用語を使用する必要があります。
エオニル14年

11
@JanHudec:モバイルデバイス、またはリソースに制約のあるデバイスでGCはそれほど高速でなく、実際に問題の主要な部分です。
メイソンウィーラー

72

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

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

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

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


13
この答えの要点がよくわかりません。「ベンチマークに欠陥がある」と言って、「いかに迅速に処理するか」に答えていますか?それがあなたが作っているポイントですか?私はそれがどのように求められていたのかを理解していない。
ブライアンオークリー14年

15
@BryanOakley:ベンチマークに欠陥があるとは思いませんが、Swiftがより高速であるベンチマークを選択した可能性を確実に考慮する必要があります。
ジャン・ヒューデック

23
「Swiftはどのように高速ですか?」に対する回答があります。「実際にはそうではない」@BryanOakley; それが私がヤンの答えから得た要点です。「嘘、いまいましい嘘、そして統計」、結局。
ジョシュキャスウェル14年

4
しばらく前に、iOSで実行しているCodename Oneのベンチマークを行い、Java実装はObjective-C codenameone.com/blog/よりもはるかに高速でした。1月は正しいです。大きな改善を示します。ARCをほんの少しでも改善した場合(コード分析の改善のおかげで)、途方もない量の複雑さを取り除くことができます。言語が制限されるほど、コンパイラは最適化(Javaを参照)するためにできることが多くなり、Swiftは制限を追加します。
シャイ・アルモグ14年

7
Janの答えは、Q1およびおそらくQ2に対する完璧な答えです。マーケティングイベントのベンチマークを基調講演と見たとき、「選択されたベストケースではわずか1.3倍です。平均結果は0.3倍ですか?」と思いました。
アミンネグム-Awad 14

5

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

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

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

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

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

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


3

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

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

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

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

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


2
これは、より多くのrantyのコメントのように読み、見回答する方法
ブヨ

2
今はいいですか?:)
greg.casamento

0

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

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


13
「複雑なオブジェクトの並べ替え」ベンチマークを行うことは、オブジェクトのネイティブ実装を持たないCなどの言語では少し難しいでしょう。この講演の聴衆は100%Objective-Cプログラマーである可能性が高いことを考えると、C ++のような言語と比較してもあまり意味がありません。迅速のポイントは「ねえ、これはこれまでで最高の言語です!」ではありません。むしろ「ねえ、これは現在OSX / iOS開発に使用している言語よりも高速です」。
ブライアンオークリー14年

10
Cはqsort複雑なオブジェクトの並べ替えを可能にする完全に素晴らしいです。手元のオブジェクトを理解するコールバックを使用するだけです。std::sortSwiftを困らせるため、C ++が欠落していると思われます。(テンプレートであるため、C ++コンパイラは、ループの展開まで、テンプレートを大幅に最適化できます。)
MSalters 14年

@MSalters:あなたに完全に同意します。CとC ++の両方に、Swiftを上回る機能があります。実行されたテストを取得することは可能でしょうか?私はスウィフト、のObjective-C、C ++およびCと同じベンチマークを実行するために喜ん以上だ
ブラック塗装

また、@ BryanOakleyは、「この言語は、より少ない角括弧を必要とします!」
ニックベッドフォード14年

1
この答えはまったく水を保持せず、恐ろしく誤解を招きます。オブジェクト指向は実際には遅くありません。実際、最速のシステムはC ++、Java、C#であり、プログラミングのスタイル(オブジェクト指向かどうかに関係なく)は結果の速度とほとんど関係がありません。悪いコード。
ビルK
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.