Swiftについて最初に思ったこと

Share on Facebook
このエントリーをはてなブックマークに追加

swift-hero

WWDC 2014において、電撃的に発表された新言語Swift。その瞬間、Twitterの開発者TL上では爆笑が巻き起こった。まったく予想してなかったよ、うひー。

Swiftに関しては早速、言語仕様が公開(iBooks Store)されたりしている。それらはこれからすべてしゃぶりつくすとして、とりあえず基調講演が終わった時点での感想とかを書いてみたい。

Swiftのコンセプトは「Objective-C without the C」。Cベースではないモダンな言語である。その上で、CocoaとObjective-C runtimeを使うので、フレームワークのサポートも問題ない。ここだけ聞けば、夢のような話だよね。

Swiftの特徴として上げられていたのは、Modern、Safe、Interactive、Fast。これらを検証してみよう。

swift0

「Modern」に関しては、文法がモダンになった。これは言語仕様を見てもらえば明らか。昨今のトレンドを十分に取り入れたものになっている。Genericまであっててんこ盛り気味。Objective-Cにない仕様として紹介されたのが、名前空間(笑。聴衆は喝采。いかにObjective-Cが古臭かったかという例だな。

swift2

「Safe」は、変数が初期化される、配列のインデックスがチェックされる、ARCによってメモリが管理される、ポインタがない、と言ったとこだろう。初心者にとってはありがたいところだ。熟練者は、ほぼオートマティックにこれらは対処しているので、あぁ言語仕様レベルでサポートされるのね、というもの。

swift3

「Interactive」は、Playgroundと呼ばれる新しい実行環境を指す。基調講演のデモでも印象的だった、グラフを表示したり、アニメーションを動かしたりしていたものだ。確かにデモとしては見栄えがいい。でも、開発ワークフローを考えると、使うシチュエーションがあるかどうかは疑問だ。

swift5

で「Fast」なんだけど、これが悩ましい。普通に考えれば、C言語ベースからスクリプトになったら、実行速度は遅くなる。でもSwiftは、PythonやObjective-Cより速くなったと主張している。

swift1

まず考えられるのは、Swiftは純然たるスクリプトというよりは、コンパイルする言語であること。ビルド時か実行時か知らないが、ネイティブコードに変換する。これでPythonなんぞよりはバカっ速になる。

しかし、Objective-Cより速いとはどういうことか?基調講演では、ソート処理がObjective-Cより速いと主張していた。ソートはアルゴリズムが固まっているので、純然たる実行速度の差だ。Objective-Cのボトルネックとしてまず考えられるのは、メソッド呼び出し。objc_msgSendだ。Swiftはこれを使わないで、もっと効率的なメソッド呼び出しをやっているのでは?たとえば動的束縛をやめたとか?そうだったら、Objective-CではなくSwiftを使う積極的な理由が出てくる。

ソートのグラフでは、「Complex object sort」とある。つまり、複雑なオブジェクトで、比較するときにメソッドをいくつか呼び出す必要があるのかもしれない。だからObjective-Cでは遅くなってSwiftでは速くなるんだよ…というシナリオなら、納得できる。(Complexが複素数ってことはないよな?)

あと、既存のObjective-Cコードと混在もできるらしい。こちらで詳しく解説されている。これは朗報。

 

swift4

つまり、モダンな言語で、いまあるフレームワークをサポートできて、過去の資産も引き継げる。結論としては、乗り換えを検討する価値はある。もしかすると、絶対に乗り換えるべきかもしれない。では調査に入ります〜。

    • yuki
    • 2014年 6月3日

    >objc_msgSendだ。Swiftはこれを使わないで、もっと効率的なメソッド呼び出しをやっているのでは?たとえば動的束縛をやめたとか?そうだったら、Objective-CではなくSwiftを使う積極的な理由が出てくる。

    id型がベースだったObjective-Cでしたが。
    Swiftは型が導入されたので、メソッドの呼び出しや最適化が効くようになったのではと予測します。

      • mkino
      • 2014年 6月3日

      Objective-Cのやり方だと、id型に加えてそれぞれのクラス型があったとしても、メソッド呼び出しの速度はたいして改善されないと思うんですよ。

      id型って数万のメソッドを持つ単一クラスみたいなもので、メソッド呼び出しはハッシュテーブルから検索している。これが、数百のクラスに分割されたとしても、検索のステップ数自体はそんなに変わらないと思う。

      C++と比べると、動的にメソッド検索しているところがオーバーヘッドなんで、そこを変えるしかないと思うんですけどね。

    • k
    • 2014年 6月4日

    ランタイムが同じなのに Obj-C より Swift が速いのであれば、コンパイル時の最適化がより効いているのでしょう。

    たとえば let s = “foobar”; s.doSomething() というコードがあった場合、s の型は正確に String クラスであって、String のサブクラスではないことがこの場合は保証できます。そういう場合は method lookup を省略するようなコードをコンパイラが生成するのではないでしょうか。
    (そういう最適化は、LLVMが得意とするところだと聞いた覚えがあります。)

      • mkino
      • 2014年 6月4日

      メソッドの検索を省略して関数ポインタを直接保持するっていうのは、Objective-Cでもよく提案されてました。その場合、動的にメソッドが追加されたり、method swizzlingされたらどうするという問題があって、結局毎回検索しにいかなきゃダメだよね、という結論になります。

      Swiftは、その辺をレガシーとして切り捨ててくるのかもしれない。

    • kitamura
    • 2014年 10月27日

    出版されている楽しいSwiftプログラミングの正誤表を早く更新してください。
    せっかく、語りかける口調のわかりやすい書籍なのに、エラーが発生するソースコードのせてしまったことで、一気に残念な書籍に変わりました。

    売るために、早く出版したい気持ちはわかりますが、それでは、ホンダのHV車と同じですよ・・。結果的に損をすることになると思います。

    Swift1.1で結構変わるという情報を知らなかったということはありえないと思うのですが、
    できれば経緯を教えてほしい。

      • mkino
      • 2014年 10月27日

      経緯はこちらにまとめました。

      http://hmdt.jp/blog/?p=1255

      Swift 1.1で変わるとは言われても、いま現状の環境で動かないものを出すわけにはいかないし、
      校了から発売までは一ヶ月のラグがあるし、最悪のタイミングに重なったな、という気持ちです。

      Cocoa APIに対するオプショナルのぶれはいつまで続くんだ? とは思います。
      1.1で収まるとも思えないですし。

      正誤表と電子版でキャッチアップしていくしかないと考えています。

        • kitamura
        • 2014年 10月28日

        経緯はよくわかりました。
        返信ありがとうございます。

  1. トラックバックはまだありません。