🖲️ 🙅 🚽 SwiftとRustを比較する 🧙🏾 🕵🏿 📫

この記事を書いた理由は、Swift言語のソースコードの公開でした-それをよりよく知ることが私にとって興味深いものになりました。 Rustと呼ばれる別の若いプログラミング言語との構文の類似性はすぐに私の目を引きました。また、類似の構文構造に加えて、これらの言語の類似の応用分野も見られました。どちらの言語も、ローカル型推論による強力な静的型付けを備えており、両方ともマシンコードに直接コンパイルされます。両方の言語は、関数型プログラミングの世界から多くのトリックを吸収しました。 SwiftとRustの両方に、Cで記述されたコードを実行するツールがあります。これにより、膨大な数のライブラリのラッパーを簡単に作成できます。両方の言語は、C、C ++、ObjectiveCなどの既存のシステム言語の代替と見なされます。それでは、それらに共通するものと、何が違うのでしょうか？

構文の基本

すぐに2つのプログラミング言語の基本を読者に伝えようとはしていないと言わなければなりません。何か不明な点がある場合は、 RustbookまたはSwiftbookに問い合わせることをお勧めします。

最初に、最も単純なプログラムを比較してみましょう。

さび

fn main() { let i:i32 = 16; let mut f = 8.0; f *= 2.0; println!("Hello Rust! within vars {} and {}", i, f); }

スイフト

 let i:Int = 10 var f = 15.0 f /= 2 print("Hello Swift within vars \(i) \(f)")

letはあちこちで同じことを意味し、SwiftのvarキーワードはRustのlet mutの組み合わせに似ていることに気付くかもしれません。ただし、違いがあります。Rustでは、すべての数値型でサイズが明確に示されますが、SwiftはCの伝統に従います。この質問では、Rustはより低いレベルのようです。

Rustの文字列補間は、println！の腸で呼び出されるformat！、マクロを使用して行われます。Swiftでは、これは言語自体の機能ですが、同時にドキュメントで書式設定オプションを設定する方法が見つかりませんでした。

「;」の解釈の違いは興味深いです。Rustの場合、これは式の終わりの兆候です。これにより、エレガントなことを行うことができます。たとえば、関数内の最後の式が自動的に戻り値になります。 Swiftは、パスカルの伝統に従います。セミコロンは、同じ行で演算子を単純に分離します。

次に、2つの引数の関数を取り、それを1つの関数に変換する関数を作成してみましょう。

さび

 fn apply<F: 'static>(f: F, v1: i32) -> Box<Fn(i32) -> ()> where F: Fn(i32, i32) -> () { Box::new(move |v2| f(v1, v2)) } fn print_sum(a: i32, b: i32) -> () { println!("Rust: sum a and b is {}", a + b); } fn main() { let a = 2; let b = 5; print_sum(a, b); let f = print_sum; let f2 = apply(f, b); f2(a); }

すばやい

 func apply(f: (_: Int, _: Int) -> (), _ v1: Int) -> (_: Int) -> () { return {(c: Int) -> () in return f(v1, c) } } func print_sum(a: Int, second b: Int) -> () { print("Swift: sum a and b is \(a+b)") } let a = 2; let b = 5; print_sum(a, second:b) let f2 = apply(print_sum, b) f2(a)

ここで違いはすでに顕著であるため、Swiftの名前付きパラメーターの外部名やRustの一般化などの純粋に構文上の違いを除外し、さらに重要な違いを検討します。 Swiftのアプローチは明らかに高レベルです。コンパイラーは結果の関数を保存する方法を決定しますが、移動したクロージャーは無次元型であるため、Rustをボックスに明示的にパックする必要がありました。

誰のラムダ関数が速いかを確認しましょう：

ベンチマークコード

さび

 fn apply<F: 'static>(f: F, v1: i32) -> Box<Fn(i32) -> i32> where F: Fn(i32, i32) -> i32 { Box::new(move |v2| f(v1, v2)) } fn make_sum(a: i32, b: i32) -> i32 { a + b } fn main() { let a = 2; let b = 5; let c = make_sum(a, b); println!("Rust: c is {}", c); let f2 = apply(make_sum, b); let mut d = 0; for i in 0..1000000000 { d = f2(i); } println!("Rust: d is {}", d); }

すばやい

 func apply(f: (_: Int, _: Int) -> Int, _ v1: Int) -> (_: Int) -> Int { return {(c: Int) -> Int in return f(v1, c) } } func make_sum(a: Int, second b: Int) -> Int { return a + b } let a = 2; let b = 5; let c = make_sum(a, second:b) print("Swift: c is \(c)") let f2 = apply(make_sum, b) f2(a) var d = 0; for i in 0...1000000000 { d = f2(i); } print("Swift: d is \(d)");

最終結果：Rustで4.0秒、Swiftで1.17。より抽象的なコードの場合、コンパイラーは最適化の機会が多くなりますが、ruRust / generalチャネルでは、それほど美しく見えないかもしれないメソッドでプロンプトが表示されましたが、オプティマイザーはすべてを完全に与えることができます。最終的に、Rustはコンパイル時にループ全体を見つけました。これは非常にクールです。

熟練した手で、Rustは不思議なことができます。

クイックバージョンコード

 struct Curry<'a> { f: &'a Fn(i32, i32) -> i32, v1: i32 } impl<'a> Curry<'a> { fn new<F: 'static>(f: &'a F, v1: i32) -> Curry<'a> where F: Fn(i32, i32) -> i32 { Curry { f: f, v1: v1 } } fn call(&'a self, v2: i32) -> i32 { (*self.f)(self.v1, v2) } } fn make_sum(a: i32, b: i32) -> i32 { a + b } fn main() { let a = 2; let b = 5; let c = make_sum(a, b); println!("Rust: c is {}", c); let borrow = &make_sum; let f2 = Curry::new(borrow, b); let mut d = 0; for i in 0..1000000000 { d = f2.call(i); } println!("Rust: d is {}", d); }

列挙とパターンマッチング：

両方の言語には、パターンマッチングの大きな可能性があります;両方の言語には、代数データ型があります。これらの機能を使用した簡単な例を作成してみましょう。数学演算を実装してみてください。これを行うには、転送を再帰的にする必要があります。ボーナスとして、プロトコル（特性）を使用して、操作の名前を画面に印刷しようとします。

さび

 enum MathOperation { Value(i32), Sum(Box<MathOperation>, Box<MathOperation>), Mul(Box<MathOperation>, Box<MathOperation>) } trait HasName { fn name(&self) -> &'static str; } impl HasName for MathOperation { fn name(&self) -> &'static str { match *self { MathOperation::Value(..) => "Value", MathOperation::Sum(..) => "Sum", MathOperation::Mul(..) => "Mul" } } } impl MathOperation { fn solve(&self) -> i32 { match *self { MathOperation::Value(i) => i, MathOperation::Sum(ref left, ref right) => left.solve() + right.solve(), MathOperation::Mul(ref left, ref right) => left.solve() * right.solve() } } } fn main() { let op = MathOperation::Sum(Box::new(MathOperation::Value(10)), Box::new(MathOperation::Mul(Box::new(MathOperation::Value(20)), Box::new(MathOperation::Value(2))))); ; println!("Rust: op is {} solved {}", op.name(), op.solve()); }

スイフト

 enum MathOperation { case Value(Int) indirect case Sum(MathOperation, MathOperation) indirect case Mul(MathOperation, MathOperation) func solve() -> Int { switch self { case .Value(let value): return value case .Sum(let left, let right): return left.solve() + right.solve() case .Mul(let left, let right): return left.solve() * right.solve() } } } protocol HasName { func name() -> String; } extension MathOperation : HasName { func name() -> String { switch self { case .Value(_): return "Value" case .Sum(_, _): return "Sum" case .Mul(_, _): return "Mul" } } } let op = MathOperation.Sum(MathOperation.Value(10), MathOperation.Mul(MathOperation.Value(20), MathOperation.Value(2))) print("Swift: op is \(op.name()) solved \(op.solve())");

Rustでは、再帰的な列挙を整理するために、ボックスコンテナーにパックする必要がありました。サイズは任意であり、コンパイル段階でこれに必要なメモリ量がわからないためです。 Swiftは間接的な単語を使用して再帰的な列挙を指しますが、そのメモリモデルを考えると、疑問が生じます：コンパイラはメモリを割り当てる方法を理解できませんか？どうやらこのキーワードは、その人にとってより可能性が高いと思われます。

また、原則としてimplとextensionがほぼ同じ作業を実行し、タイプがプロトコルに似ていることもわかります。しかし、Swiftでは、アプローチはより妥協的です。メソッドを拡張機能として追加する必要はなく、リスト宣言で直接指定できます。

次に、パターンマッチングの例をいくつか見てみましょう。

Rust （例によるRustの例）

 match some_value { Ok(value) => println!("got a value: {}", value), Err(_) => println!("an error occurred"), } enum OptionalTuple { Value(i32, i32, i32), Missing, } let x = OptionalTuple::Value(5, -2, 3); match x { OptionalTuple::Value(..) => println!("Got a tuple!"), OptionalTuple::Missing => println!("No such luck."), } let x = 1; match x { 1 ... 5 => println!("one through five"), _ => println!("anything"), } let x = 1; match x { e @ 1 ... 5 => println!("got a range element {}", e), _ => println!("anything"), }

Swift （Swiftbookから取得したサンプルコード）

 let count = 3000000000000 let countedThings = "stars in the Milky Way" var naturalCount: String switch count { case 0: naturalCount = "no" case 1...3: naturalCount = "a few" case 4...9: naturalCount = "several" case 10...99: naturalCount = "tens of" case 100...999: naturalCount = "hundreds of" case 1000...999999: naturalCount = "thousands of" default: naturalCount = "millions and millions of" } print("There are \(naturalCount) \(countedThings).") //  "There are millions and millions of stars in the Milky Way." let somePoint = (1, 1) switch somePoint { case (0, 0): print("(0, 0) is at the origin") case (_, 0): print("(\(somePoint.0), 0) is on the x-axis") case (0, _): print("(0, \(somePoint.1)) is on the y-axis") case (-2...2, -2...2): print("(\(somePoint.0), \(somePoint.1)) is inside the box") default: print("(\(somePoint.0), \(somePoint.1)) is outside of the box") }//  "(1, 1) is inside the box let anotherPoint = (2, 0) switch anotherPoint { case (let x, 0): print("on the x-axis with an x value of \(x)") case (0, let y): print("on the y-axis with ay value of \(y)") case let (x, y): print("somewhere else at (\(x), \(y))") } //  "on the x-axis with an x value of 2

ここでは、一般的に、すべてが非常に似ています。比較にディップがないはずです。値の範囲を指定できます。値をバインドでき、比較でタプルを使用できます。 Rustでは、一致時に構造全体を使用することもできます。それぞれifとwhereで追加の条件を指定できます。しかし同時に、Swiftには追加のフロー制御演算子があります。それらを使用するのが良いアイデアかどうかはわかりませんが。

より現実的な例

Bresenhamラスター化アルゴリズムを記述してみましょう。通常の形式ではなく、n次元ベクトルの形式で実数を使用しません。これはすべて、コンピュータグラフィックスの短期コースを勉強するときに役立ちます。

まず、3次元ベクトルを作成して、インデックスの取得と比較の操作を決定してみてください。

さび

 #[derive(Copy, Clone, PartialEq)] struct Vec3 { x: i32, y: i32, z: i32 } impl Index<usize> for Vec3 { type Output = i32; fn index<'a>(&'a self, i: usize) -> &'a Self::Output { match i { 0 => &self.x, 1 => &self.y, 2 => &self.z, _ => panic!("Wrong index"), } } } impl IndexMut<usize> for Vec3 { fn index_mut<'a>(&'a mut self, i: usize) -> &'a mut Self::Output { match i { 0 => &mut self.x, 1 => &mut self.y, 2 => &mut self.z, _ => panic!("Wrong index"), } } }

すばやい

 struct Vector3 { var x: Int; var y: Int; var z: Int; subscript(i: Int) -> Int { get { precondition(i >= 0 && i < 3, "Index out-of-bounds") switch i { case 0: return self.x case 1: return self.y case 2: return self.z default: return 0 } } set { precondition(i >= 0 && i < 3, "Index out-of-bounds") switch i { case 0: self.x = newValue case 1: self.y = newValue case 2: self.z = newValue default: break } } } } func == (left: Vector3, right: Vector3) -> Bool { return (left.x == right.x) && (left.y == right.y) && (left.z == right.z) } func != (left: Vector3, right: Vector3) -> Bool { return !(left == right) }

実際、Rustでは、演算子は特性を介して実装されます。構造体がインデックス特性を実装する場合、[]演算子を使用できます。Swiftでは、インデックスを取得する演算子はキーワード添え字を使用して記述され、特別な前提条件を追加できます。 Rustは通常のアサーションに依存しています。他の演算子の場合、Swiftを使用すると、既存の演算子を再定義し、さらに独自の優先度、結合性を示す定義を行うことができます。これはすべて、数学ライブラリを作成するときに非常に役立ち、コードを元の数学式により類似させます。ただし、Rustは、deriv属性を介して一部のタイプの実装を自動的に作成できます。これにより、多くのささいなケースでコードを自分で記述することを回避できます。

次に、インデックス演算子を使用して任意のピクセルの色にアクセスできるように、画像を保存するための便利なバッファーを作成してみましょう。同時に、ピクセルマップが異なる色深度に対応できるという要件を提唱するため、一般化することにします。

錆び

 struct GenericPixmap<T> { w: usize, h: usize, data: Vec<T> } impl<T> GenericPixmap<T> where T: Copy + Clone { fn new(w: usize, h: usize, fill_value: T) -> GenericPixmap<T> { GenericPixmap { w: w, h: h, data: vec![fill_value; w*h] } } } impl<T> Index<usize> for GenericPixmap<T> where T: Copy + Clone { type Output = [T]; fn index<'a>(&'a self, i: usize) -> &'a Self::Output { let from = i*self.w; let to = from+self.w; &self.data[from..to] } } impl<T> IndexMut<usize> for GenericPixmap<T> where T: Copy + Clone { fn index_mut<'a>(&'a mut self, i: usize) -> &'a mut Self::Output { let from = i*self.w; let to = from+self.w; &mut self.data[from..to] } } type Pixmap = GenericPixmap<u32>;

すばやい

 struct GenericPixmap<T> { let w: Int let h: Int var data: [T] init(width: Int, height: Int, fillValue: T) { self.w = width self.h = height self.data = [T](count: w*h, repeatedValue: fillValue) } func indexIsValid(x: Int, _ y: Int) -> Bool { return x >= 0 && x < w && y >= 0 && y < h } subscript(x: Int, y: Int) -> T { get { precondition(indexIsValid(x, y), "Index out-of-bounds") return data[x * y + y] } set { precondition(indexIsValid(x,y), "Index out-of-bounds") data[x * y + y] = newValue } } } typealias Pixmap = GenericPixmap<UInt32>

Rustの一般化のルールはより厳密であり、テンプレートタイプが独自のコピーをコピーおよび作成できる必要があることを明示的に示す必要があります。 Swiftでは、構造体フィールドに対して、その可変性を明示的に設定できます。 initキーワードにも注目できます。これはクラスまたは構造のコンストラクターであり、それらのいくつかが存在する可能性があり、それらは互いに力を委任できます。結果として、これはかなり複雑で多段階のプロセスに変換されますが、それでも各メンバーが初期化されることを正確に保証します。 Rustでは、静的関数newによってオブジェクトを作成するという用語ごとの初期化と合意があります。プロセスが複雑になると予想される場合は、工場を使用することをお勧めします。静的関数に関しては、この意味でのRustの構文はpythonの伝統に従いますが、SwiftはC ++です。

Swiftのインデックス演算子は任意の型の引数をいくつでも取ることができるので、配列の特定の要素をすぐに受け取る演算子を書くことができますが、Rustではスライスを作成する必要があります。

次に、プロセス自体の実装を考えずに描画できるCanvasトレイトを作成しましょう。

錆び

 trait Canvas { fn set_pixel(&mut self, x: usize, y:usize, color:u32); } impl Canvas for Pixmap { fn set_pixel(&mut self, x: usize, y:usize, color:u32) { self[x][y] = color; } }

すばやい

 protocol Canvas { func setPixel(x: Int, _ y: Int, color: UInt32); } class MyCanvas : Canvas { var pixmap: Pixmap init(width: Int, height: Int, fillValue: UInt32) { self.pixmap = Pixmap(width:width, height:height, fillValue:fillValue) } func setPixel(x: Int, _ y: Int, color: UInt32) { pixmap[x, y] = color } }

残念ながら、GenericPixmap型の拡張機能を実装する方法をすばやく理解できなかったため、SwiftのRustとは異なり、プロトコルなどから継承できるCanvasプロトコルを実装する新しいMyCanvasクラスを作成することにしました。

次に、最も興味深いのは、ブレゼンハムアルゴリズムの実装です。ポイント（x1、y1、z1）からポイント（x2、y2、z2）に線を引きたいので、方向に（| x2-x1 |、| y2-y1 |、| z2-z1 |）ステップを踏む必要があります。、式の符号（x2-x1、y2-y1、z2-z1）に依存します。

したがって、方向（sx、sy、sz）で（rx、ry、rz）ステップを実行する必要があります。これにより、最大数のステップを作成する必要がある軸が見つかります。各ステップでの変位は（rx / r [max、ry / r [max]、rz / r [max]）に等しく、ステップは総変位dが1より大きくなった場合にのみ発生し、軸に沿ってステップが作成されます。総変位控除ユニット。それは：

 d[i] += r[i] / r[max] if d[i] >= 1 { r[i] -= s[i]; d[i] -= 1; }

条件にrmaxを掛けると、除算操作を行わなくてもよいことがわかります。

 d[i] += r[i] if d[i] >= r[max] { r[i] -= s[i]; d[i] -= r[max]; }

その結果、このアルゴリズムの変形は、任意の数の座標で機能し、浮動小数点演算を回避します。これは、ほとんどの場合、整数による演算よりも高価です。

エンドノードaとbの間に一連のポイントを作成するジェネレーターを作成してみましょう。この場合、ポイントaがシーケンスに含まれます。

錆び

 struct RasterState { step: Vec3, d: Vec3, major_axis: usize, } struct LineRasterizer { from: Vec3, to: Vec3, state: Option<RasterState> } impl LineRasterizer { fn new(from: Vec3, to: Vec3) -> LineRasterizer { LineRasterizer { from: from, to: to, state: None } } fn next_point(&mut self) -> Option<Vec3> { match self.state { None => { let mut state = RasterState { step: Vec3 { x: 0, y: 0, z: 0 }, d: Vec3 { x: 0, y: 0, z: 0 }, major_axis: 0 }; let mut max = 0; for i in 0..3 { let d = self.to[i] - self.from[i]; state.step[i] = if d > 0 { 1 } else { -1 }; let d = d.abs(); if d > max { max = d; state.major_axis = i as usize; }; } self.state = Some(state); Some(self.from) }, Some(ref mut state) => { if self.from == self.to { None } else { let from = self.from; let to = self.to; let calc_residual_steps = |axis| { (to[axis] - from[axis]).abs() }; self.from[state.major_axis] += state.step[state.major_axis]; let rs_base = calc_residual_steps(state.major_axis); for i in 0..3 { let rs = calc_residual_steps(i); if rs > 0 && i != state.major_axis { state.d[i] += rs; if state.d[i] >= rs_base { state.d[i] -= rs_base; self.from[i] += state.step[i]; } } } Some(self.from) } }, } } }

すばやい

 class LineRaster { class State { var step: Vector3 var d: Vector3 var majorAxis: Int init() { self.step = Vector3(x: 0, y: 0, z: 0) self.d = Vector3(x: 0, y: 0, z: 0) self.majorAxis = 0 } } var from: Vector3 let to: Vector3 var state: State? init(from: Vector3, to: Vector3) { self.from = from self.to = to } func next_point() -> Vector3? { if let state = self.state { if (self.from == self.to) { return nil } else { let calsResidualSteps = {axis in return abs(self.to[axis] - self.from[axis])} self.from[state.majorAxis] += state.step[state.majorAxis]; let rsBase = calsResidualSteps(state.majorAxis); for i in 0..<3 { let rs = calsResidualSteps(i); if rs > 0 && i != state.majorAxis { state.d[i] += rs; if state.d[i] >= rsBase { state.d[i] -= rsBase; self.from[i] += state.step[i]; } } } return self.from } } else { let state = State() var max = 0; for i in 0..<3 { let d = self.to[i] - self.from[i]; state.step[i] = d > 0 ? 1 : -1; let da = abs(d); if da > max { max = da; state.majorAxis = i; }; } self.state = state return self.from } } }

ジェネレーターの状態をオプションの値の形式にすることにしました。これにより、追加のフラグを必要とせずに、ジェネレーターから開始点を簡単かつ即座に返すことができます。 Rustでは、オプション値は単にenum Optionで作成されますが、Swiftではそれらは言語の一部であるため、構文上のノイズがあまりなく、オプションのコールチェーンを簡単に記述できます。

Rustは、参照によって列挙からStateを借用していることを伝えるために、高度な所有権システムを使用しています。キーワードrefを記述する必要があります。 Swiftでは、状態はデフォルトで参照データ型であり、言語では移動のセマンティクスがまだ観察されていないため、何も心配することなく状態を取得および展開できます。

次のようなコードを記述します。

 while let Some(point) = rasterizer.next_point() { ... }

私にはあまりエレガントではないようですが、これははるかに論理的に見えます。

 for point in generator { ... }

幸いなことに、forループを使用するために、ジェネレーターにいくつかのタイプを実装するのは非常に簡単です。

錆び

 impl Iterator for LineRasterizer { type Item = Vec3; fn next(&mut self) -> Option<Self::Item> { self.next_point() } }

すばやい

 extension LineRaster : GeneratorType { func next() -> Vector3? { return self.next_point() } } extension LineRaster : SequenceType { func generate() -> LineRaster { return self } }

さらに、Swiftの場合、最大2つのプロトコルを実装する必要がありますが、Rustの場合は1つで十分ですが、根本的な違いはありません。

パフォーマンスを少し測定しましょう

コードの実行速度は、異なるプログラミング言語を比較する際の重要な要素の1つであり、パフォーマンスを測定せずに記事を書くのは愚かなことです。

単純な比較オプション：

錆び

 fn test_code(canvas: &mut Canvas) { let a = Vec3 { x: 0, y:0, z:0 }; let b = Vec3 { x: 50, y: 55, z: -20 }; let rasterizer = LineRasterizer::new(a, b); for point in rasterizer { let color = std::u32::MAX; canvas.set_pixel(point.x as usize, point.y as usize, color); } } for _ in 0..1000000 { test_code(&mut canvas) }

すばやい

 func testCode(canvas: Canvas) -> () { let a = Vector3(x: 0, y:0, z:0) let b = Vector3(x: 50, y:55, z:-20) let raster = LineRaster(from: a, to: b) for point in raster { let color = UInt32.max canvas.setPixel(point.x, point.y, color: color) } } ... var myCanvas: Canvas = canvas for _ in 0..<1000000 { testCode(myCanvas) }

Canvasへのリンクをテストする関数に渡すだけで、時間を測定します。

Rustでは0.86、Swiftでは5.3でした。 Swiftは動的ディスパッチのレベルに留まっている一方で、Rustは何らかの形で呼び出しをインライン化する可能性があります。これを確認するために、一般化された関数を書きます。

錆び

 fn test_code_generic<T: Canvas>(canvas: &mut T) { let a = Vec3 { x: 0, y:0, z:0 }; let b = Vec3 { x: 50, y: 55, z: -20 }; let rasterizer = LineRasterizer::new(a, b); for point in rasterizer { let color = std::u32::MAX; canvas.set_pixel(point.x as usize, point.y as usize, color); } }

すばやい

 func testCodeGeneric<T:Canvas>(canvas: T) -> () { let a = Vector3(x: 0, y:0, z:0) let b = Vector3(x: 50, y:55, z:-20) let raster = LineRaster(from: a, to: b) for point in raster { let color = UInt32.max canvas.setPixel(point.x, point.y, color: color) } }

Rustの結果は0.83でしたが、Swiftの4.94と比較すると、Swiftの方がコードを最適化できたことがわかりますが、他のどこかにボトルネックが見つかりませんでした。

次に、Canvasをボックスにパックしてみましょう。Swiftには、inout修飾子を使用します。これは、効果が＆mutに似ています。

錆び

 fn test_code_boxed(canvas: &mut Box<Canvas>) { let a = Vec3 { x: 0, y:0, z:0 }; let b = Vec3 { x: 50, y: 55, z: -20 }; let rasterizer = LineRasterizer::new(a, b); for point in rasterizer { let color = std::u32::MAX; canvas.set_pixel(point.x as usize, point.y as usize, color); } }

すばやい

 func testCodeInout(inout canvas: Canvas) -> () { let a = Vector3(x: 0, y:0, z:0) let b = Vector3(x: 50, y:55, z:-20) let raster = LineRaster(from: a, to: b) for point in raster { let color = UInt32.max canvas.setPixel(point.x, point.y, color: color) } }

結果はRustで0.91、Swiftで6.44です。

ボクシングはコードの実行を少し遅くしましたが、それほど大きくはありませんでしたが、inoutの追加はSwiftに非常に大きな影響を与えました。どうやらキャンバスへのリンクを変更する機能により、手がオプティマイザーにバインドされます。

一般的に、Rustは同様のコーディングスタイルでより生産的です。所有権の概念により、コンパイラーはコンパイル段階でプログラムの正当性をチェックするだけでなく、必要でない場合に参照カウンターの使用を避けることもできます。反対に、必要な場合は明らかに使用する必要があります。 Swiftは、デフォルトで、すべての場所でクラスの参照カウンターを使用しますが、これは多くの場合パフォーマンスの低下につながります。コンパイラーがいくつかの些細なケースで参照カウントを削除できたとしても、わずかに複雑なケースで実行できることを保証しません。 Rustはコードをコンパイルしません。これは、コンパイラの成熟度とそれに含まれる概念の有効性の両方を示しています。

結論として、RustとSwiftが古いC ++を背景にどのように見えるかを比較したいと思います。

かなり一般的なベンチマークコード

 #include <iostream> #include <vector> #include <cassert> #include <memory> #include <cstdlib> template <typename T> struct GenericPixmap { size_t w, h; std::vector<T> data; GenericPixmap(size_t w_, size_t h_, T fill_data = T()) : w(w_), h(h_), data(w_*h_, fill_data) { } T* operator[] (size_t i) { return &data[i*w]; } }; struct Vec3 { int x, y, z; int& operator[] (size_t i) { assert(i >=0 && i < 3); switch (i) { case 0: return x; case 1: return y; case 2: return z; default: break; } return z; } }; bool operator== (const Vec3 &a, const Vec3 &b) { return ax == bx && ay == by && az && bz; } bool operator!= (const Vec3 &a, const Vec3 &b) { return !(a == b); } struct RasterState { Vec3 step; Vec3 d; size_t majorAxis; }; struct LineRaster { Vec3 from; Vec3 to; bool firstStep; RasterState state; LineRaster(const Vec3 &f, const Vec3 &t) : from(f), to(t), firstStep(true), state{} {} bool next_point() { if (firstStep) { size_t max = 0; for (int i = 0; i < 3; ++i) { auto d = to[i] - from[i]; state.step[i] = d > 0 ? 1 : -1; d = std::abs(d); if (d > max) { max = d; state.majorAxis = i; } } firstStep = false; return true; } else { if (from == to) return false; else { auto calc_rs = [this](auto axis) { return std::abs(to[axis] - from[axis]); }; from[state.majorAxis] += state.step[state.majorAxis]; auto rs_base = calc_rs(state.majorAxis); for (int i = 0; i < 3; ++i) { auto rs = calc_rs(i); if (rs > 0 && i != state.majorAxis) { state.d[i] += rs; if (state.d[i] >= rs_base) { state.d[i] -= rs_base; from[i] += state.step[i]; } } } return true; } } } }; using Pixmap = GenericPixmap<uint32_t>; void test_code(Pixmap &pixmap) { Vec3 a { 0, 0, 0 }; Vec3 b { 50, 55, -20 }; LineRaster raster(a, b); while (raster.next_point()) { const auto &p = raster.from; pixmap[px][py] = 0xFFFFFF; } } int main(int, char **) { Pixmap pixmap(300, 300, 0); Vec3 a { 0, 0, 0 }; Vec3 b { 10, 5, -4 }; LineRaster raster(a, b); while (raster.next_point()) { const auto &p = raster.from; uint32_t color = 0xffffff; pixmap[px][py] = color; std::cout << "C++: point x:" << px << " y:" << py << " z:" << pz << " color:" << color << std::endl; } for (size_t i = 0; i < 1000000; ++i) test_code(pixmap); }

執筆の過程で、いくつかのセグメンテーションエラーが発生し、結果を取得する前にlldbでデバッグする必要がありました。

Rustでは0.79、gccでは0.31。

結果は非常に興味深いものです。一方で、Rustはclangとほぼ同じ速度を示しますが、他方では、gccは単にすべてを上回りました。つまり、一般に、llvmプラットフォームには多くの努力が必要ですが、そのフレームワーク内では、Rustは既に背後でclangを吸い込んでいます。つまり、パフォーマンス要件に重要なセクションを作成するために既に安全に起動できます。

完全なベンチマークコードはgithubにあります。パフォーマンスの改善に関する提案は受け入れられます。

残念なことに、エラー処理、インフラストラクチャ、CまたはObjectiveCコードとの通信、プロパティなど、興味深いものを1つの記事ですべて考慮することは困難であり、今後これらに触れることができることを願っています。

結論

Swiftの開発者は、多くの構文糖を言語に追加することにより、コードの読み取りにより多くの時間を費やします。 Rustはこの問題でより禁欲的で、エンティティの数を最小限に抑えようとします。ただし、マクロまたはプラグインを使用してコンパイラに多くのものを追加できます。効果的なゼロコストの抽象化により、Rustコードの生産性は向上しますが、理解が難しくなります。 Swiftを使用すると、メモリ管理にあまり注意を払わずにプログラムを作成できますが、コードは非常に効果的ですが、この点ではRustに劣ります。

インフラストラクチャに関しては、Swiftには優れたXcode IDEがありますが、OS Xでのみ使用可能であり、CocoaバインディングはiOSまたはOS X用のグラフィカルアプリケーションを記述およびリリースできるようになりました。Rustは、cargoおよびcrates.io膨大な数のライブラリとアプリケーションが存在し、開発されていますが、これまでのところ、開発されたIDEも優れたGUIフレームワークもありません。

残念ながら、SwiftにはまだGrand Central Dispatchによるネイティブサポートがないため、マルチスレッドプログラミングについては何も言えませんが、Rustのアプローチにより、高速で信頼性の高いアプリケーションを作成できます。厳密なコンパイラは、同期エラーからあなたを単に救います。

Swiftの求人ははるかに大きくなり、学習も容易になりましたが、これはRustのスペシャリストが近い将来に需要がないという意味ではありません。世界には、これらの言語の両方が容赦なく互いに競合する多くの問題があると思います。

あとがき

Rustは妥協を許さず禁欲的です。Light側に有利です。Swiftはその構文糖をDark側に持ち込むことができます。

更新する

ユーザーYarryがプルリクエストを送信しました。これにより、クラスを構造体に置き換えることで、Swiftバージョンを半分に高速化することができました。Swiftの構造体はCの世界の対応物として動作し、スタック上で際立っており、関数に渡されるときにリンクがコピーされるため、リンクをカウントする必要はありません。しかし同時に、Swiftのドキュメントでは、実際には、コピーは必要な場合にのみ発生すると主張しています。したがって、このような微妙な知識があると、コードを大幅に高速化できます。一方、Rustでは、学習曲線をより急にしますが、明示的に考えることを余儀なくされますが、プロファイリングやあらゆる種類の実験でコードを最適化する手間を減らす必要があります。

SwiftとRustを比較する

構文の基本

列挙とパターンマッチング：

より現実的な例

パフォーマンスを少し測定しましょう

結論

あとがき

More articles: