摘要:Ruby是一种简单快捷面向对象的脚本语言,而Rust是一种系统编程语言,它有着惊人的运行速度,能够防止段错误,并保证线程安全。本文作者以项目为例,结合大量的编程代码描述了如何借助Rust语言提高Ruby的性能,以下是译文。
几年前,在我的Rails(提供一个纯Ruby的开发环境)应用程序里发现了一些被调用数千次的方法,占了网站页面加载时间的30%以上。这些方法都完全地专注于文件路径名。
除此之外,我还看过一篇博客写“拯救Ruby的Rust”,这表明可以用Rust编写执行慢的Ruby代码,让Ruby变得更快。Rust还提供了一种安全、快速、高效的编写代码的方法。在用Rust语言重写了我的Rails站点上一些效率较低的方法之后,网站页面加载速度比以前快了33%以上。
如果想了解通过FFI集成Rust,那么建议看看上文中提到的那篇博客(“拯救Ruby的Rust”)。当前这篇文章的重点是分享我在过去两年整合Ruby和Rust所得到的经验教训。当方法被调用数千次,它的性能稍有改进都会对项目有很大的影响。
入门
这篇文章的相关代码可以在GitHub上看到,如果打算开始了解Rust和Ruby项目,可以创建一个ffi_example
项目,并把下面的代码添加到Cargo.toml
文件:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
添加如下代码到ffi_example.gemspec
文件:
- 1
- 2
- 3
- 4
- 5
- 6
由于构建的库需要在客户端系统上使用FFI,所以最好将FFI,Rake和Bundler作为常规依赖项包含在内。
用于这篇文章的例子,可以从FasterPath的repo历史记录中获取basename
方法代码,与File.basename
进行比较。
- 1
- 2
- 3
- 4
为了简单起见,将所有的Rust代码放入到src/lib.rs
。这是一个用Rust编写的basename代码副本(可以复制和粘贴它;在这里不再介绍它是如何工作的):
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
这个案例是为了模仿File.basename
返回结果的方式而写的。这里唯一需要注意的是在basename
方法开始的地方的边界情况。这有效地使方法在迭代给定输入的时间加倍,并且应该重构到现有的系统中去。
感谢Gleb Mazovetskiy,extract_last_path_segment
是一个有效的贡献。这个方法在其它方法中使用,并在边界情况已知之前就实现了。在本文的后面,将讨论有和没有边界情况下的基准性能的细节。
Rust FFI方法
用于处理字符串显示的打包类的Rust FFI代码如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
Ruby会通过FFI给出一个原始C类,并将其转换成可以在Rust中使用的字符串,然后再转换回来给到Ruby。
这里需要注意的重要的一点是assert!
。这个assert!
方法在本文的项目当中并不消耗任何时间,但如果它的求值为false,Rust就会崩溃,带来FFI段错误。所以这个assert!
方法有了保证nil
不提供输入是很好的。但Ruby是nil
友好的,你并不希望段错误发生,所以在这里使用assert!
方法是不明智的。
现在nil
在Rust中添加检查并不困难。为我们的代码使用同样的打包行为,我将提供basename的nil
检查版本。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
当执行这段代码的时候,如果Ruby给出一个nil
,不做任何操作将其返回,系统就会理解这是nil
。结果证明这样编写是有效的。
所以在这种情况下,Rust方法可以返回一个String类型或者nil
给到Ruby。Ruby甚至不会注意到这完全违背了Rust的类型强制设计; 因为在Rust语言中,只处理一种类型,就是从libc::c_char
到c_char
。
注意,用一种几乎不耗费时间的方法,做一个nil
guard稍微安全一点;然而,这使得我们的方法增加了4%的运行时间(这个时间在没有边界情况下变得慢下来)。如果用Ruby而不是Rust实现nil guard,又会增加4%的运行时间,总计慢下来8个百分点。
请记住,我们在这里吹毛求疵的东西已经极快。平均结果在+/-3%之间。
如果用Ruby提供的File.basename
实现相同的类型安全:
- 1
- 2
- 3
- 4
- 5
会比原来用Rust的实现慢17%左右。
我们甚至还没有将性能与Ruby的C语言实现进行比较。为了使代码完全兼容,这使得我们每种Type Safety Guard类型都要去实现。
释放内存
更糟糕的是,即使在学习进程的这一点上,我们也不知道垃圾回收被调用时内存中发生了什么。这需要对在线文档和博客进行更多的研究,以帮助了解这里面发生了什么。
根据我的经验,我会告诉你,通过挖掘可用的资源,现在并没有完全弄清楚垃圾回收被调用时内存中究竟发生了什么,但是我会给出输入的信息。
据称,当使用FFI时,如果没有实现自己释放内存的方法,那么FFI会尝试调用C的free
方法。在与一些Rust社团的讨论中,真的不希望free
被Rust代码以这样的方式调用,这通常是未定义的行为或未知发生的事情,或者可能已经发生。因此从几个方面建议你用Rust实现一个方法,它将负责收回原先由Rust所给出的内存所有权,并由Rust去释放它。需要告诉Ruby在代码执行完成时调用这个方法。
在FFI中,很容易链接到自己的“free”方法并手动调用它。或者可以让Ruby通过AutoPointer或ManagedStruct自动执行垃圾收集器。FFI Wiki或Rust Omnibus提供了很好的例子。
如果正在优化的代码方法被频繁的调用,那么实现这些代码的代价就是值得的。但是,如果正在优化的代码速度已经很快,那么这个性能优化的代价就相当高昂,在内存能够正确地提供服务的情况下,我的方法会多花费大约40%的时间。
这其中的原因很大程度上是因为FFI有一部分是用Ruby编写的,大部分是用C语言编写的,用Ruby-land处理逻辑的时间越多,那么从纯C语言或Rust语言的性能得到的益处就越少。
在这之后,当所有这些琐碎的事情加起来,花费的时间比节省的时间还要多的时候,我感到沮丧。那时候,我决定应该避免用Ruby 编写FFI,并尝试去寻求一个纯粹的Rust解决方案。
有两个这样的解决方案:一个叫ruru,另一个叫Helix。在这两者之间,出于以下原因,我最终选择了ruru。
- ruru是用Rust的风格写的, Helix的设计就像用Rust自身写Ruby一样。
- ruru非常接近1.0版本,看起来很稳定,而 Helix正处于周期性的快速发展之中,还有很多大的功能尚未开发出来。
切换到ruru之后,我收回了在实现safe guard 类型中失去的所有的时间。这有点跑题了,但如果没有为前面的例子提供Ruby代码,那么将是我的失职。
Ruby FFI用法
为了进行基准测试,在Ruby里添加一些方法。首先执行lib/ffi_example.rb
。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
Ruby在标准库中有Fiddle,通过外部函数接口直接调用外部C函数。但是,它基本上没有入门文档,缺少很多功能。这很可能是为什么FFI早就写出来了,但只有少量的文档,它仍然缺乏帮助初学者的条件,让他们可以对发生的事情有充分的了解。
这个ffi
提供了一些帮助,使得我们能够编写可以跨多个操作系统运行的代码。上面的ffi_lib
方法需要指向Rust建立的动态库。所以当运行cargo build –release
的时候,它将在target/release中创建库,并且这种扩展取决于操作系统。上述的begin/ end 代码块适用于Windows,Mac和Linux等操作系统。
ruru入门
Ruru现在相当直接地加入到我们的项目中。首先将其添加到Cargo.toml
文件。
- 1
- 2
- 3
- 4
然后在外部crate库中使用ruru ,并加入到src/lib.rs
文件。
- 1
- 2
- 3
Ruru有一些不错的宏,这些宏有助于我们的方法与特定的类一起工作。首先,定义一个想要创建的类,然后在宏中定义方法,将它们与Ruby类关联起来。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
在methods!
宏中,首先选择要使用的类。下一个环节是将在methods!
宏块内使用的变量来引用Ruby版本的 self
。由于在这个项目里根本就不使用它,在它前面加下划线_itself
。
Ruby有用C语言实现的自己的类系统,每个类都有一个用VALUE
设置的类标识。Ruru将这些类中的某些类戏称为Rust类,所以对于Ruby的String
类,我们使用RString
类。
当用methods!
宏编写方法时,知道宏的作用域内的方法不能相互调用是非常重要的。因此,要重复使用的任何方法都必须在宏之外编写,并在那里调用它们。另外,当创建动态库时,可能很容易出现命名冲突,所以将额外的字符添加到方法名中是极好的,这样就不会混淆了。接下来会演示…
为了使方法可以从Ruby中调用,必须首先让Ruby调用Rust代码来获取实例化的对象。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
前面的Init_
目的是遵循Ruby的惯例,允许直接从库文件中导入一个Ruby C语言风格的编译库。
因此,需要重命名Cargo.toml
文件中的库以避免与ruby中名为ffi_example
的名称发生冲突,并将target/release
路径添加到加载路径,然后应该可以直接请求require "ruru_example"
来请求它(如果命名了ruru_example
库)。再加载ruru Rust代码就好像它是用Ruby写的。
有关将C语言代码与Ruby相连的更深入的了解,请阅读用于编写C语言扩展的文档。
加载代码的另一种方法是直接使用Fiddle来调用它。在这个例子中,仍然使用FFI的动态库辅助方法。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
现在将代码加载到Ruby中,一切都按预期运行。
基准测试
在之前包含的gemspec中,包含了benchmark-ips
。为了对方法进行基准测试,首先放入一个Rakefile使得命令行执行变得更简单。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
现在在test/benches/basename_benchmark.rb
创建基准测试。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
在运行上述基准测试之前,先从basename
方法中评估边界情况。边界情况仅仅是为了通过Ruby Spec Suite。按照文件路径中可接受的标准,不需要将多个斜杠压缩到一个(从///
到/
),操作系统会很好地识别路径。
现在运行基准测试rake bench
产生以下输出结果(确保cargo build --release
在运行基准测试之前运行):
注:Ruby 2.4.2和Rust 1.23.0
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
不是Ruby或ruru的方法,而是FFI版本。现在可以看出细微变化的差别。使用ruru,能够获得C语言的性能,而不必担心编写C语言代码的相关风险。
如果一个方法没有被多次调用,那么做这些更改就不会在整体基准测试中发现任何差异。但是,对于那些被过度使用的方法,这些更改确实起了作用。
另一个关于在Ruby中对比Rust语言和C语言的有趣的事实是,CPU的缓存量可能会影响到Rust的结果。更多的CPU缓存将提高Rust的性能,可以超越C语言。
这是在FasterPath项目中,其他一些开发人员和我自己之间所观察到的信息。目前还没有对这些数据进行集中编目,但是将来应该会有一个系统做这件事。
总结
Ruru和Helix不是功能完备的系统。在ruru系统中,我观察到了在整个系统中整数,字符串和数组完美地工作,以及从ruru到Ruby的新对象的初始化过程。
在写这篇文章的时候,ruru和Helix都没有实现的一个领域是允许Ruby的垃圾收集器处理从Rust代码生成的Ruby对象。原因可能是Rust语言存在VALUE属性,但Ruby GC(垃圾收集器)不知道如何释放它。当从Rust的Pathname.entries
目录条目中调用Pathname.new
时发现这个问题,这导致了基准测试期间的段错误,而不是测试套件(足够在退出之前触发GC)。跟踪这个问题是ruru#75和helix#50。
Ruby现在已经是一种成熟的语言了,Rust语言还很年轻并在不断地发展中。ruru和Helix可能还需要一段时间才能完全兼容Ruby。这一切都取决于社团的发展和参与。
未来是如此美好。与此同时,已经有了大量可以完成的工作。鼓励大家涉足这些强大的领域,分享所学到的东西,为他人和将来的自己做好文档,不久的将来,会让年轻的开发人员更好地实现他们在性能编程方面的目标。