如何使用Rust提高Ruby性能

2017-12-07 12:17:01来源:http://blog.csdn.net/dev_csdn/article/details/78706758作者:CSDN人点击

分享


原文:Improving Ruby Performance with Rust



作者:Daniel P. Clark


翻译:无阻我飞扬


摘要: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
文件:


[lib]
name = "ffi_example"
crate-type = ["dylib"]
[dependencies]
array_tool = "*"
libc = "0.2.33"


添加如下代码到ffi_example.gemspec
文件:


spec.add_dependency "bundler", "~> 1.12"
spec.add_dependency "rake", "~> 12.0"
spec.add_dependency "ffi", "~> 1.9"
spec.add_development_dependency "minitest", "~> 5.10"
spec.add_development_dependency "minitest-reporters", "~> 1.1"
spec.add_development_dependency "benchmark-ips", "~> 2.7.2"

由于构建的库需要在客户端系统上使用FFI,所以最好将FFI,Rake和Bundler作为常规依赖项包含在内。



用于这篇文章的例子,可以从FasterPath
的repo历史记录中获取basename
方法代码,与File.basename
进行比较。


请记住,Ruby用C语言实现了这个功能,所以这并不是你通常会用Rust重写的那种方法。
大多数FasterPath都会为Pathname类重写Ruby代码,这就是可以显着提高性能的地方。
我们正在使用File.basename作为纯粹的比较基准。


为了简单起见,将所有的Rust代码放入到src/lib.rs
。这是一个用Rust编写的basename代码副本(可以复制和粘贴它;在这里不再介绍它是如何工作的):


mod rust {
extern crate array_tool;
use self::array_tool::string::Squeeze;
use std::path::MAIN_SEPARATOR;
static SEP: u8 = MAIN_SEPARATOR as u8;
pub fn extract_last_path_segment(path: &str) -> &str {
// Works with bytes directly because MAIN_SEPARATOR is always in the ASCII 7-bit range so we can
// avoid the overhead of full UTF-8 processing.
// See src/benches/path_parsing.rs for benchmarks of different approaches.
let ptr = path.as_ptr();
let mut i = path.len() as isize - 1;
while i >= 0 {
let c = unsafe { *ptr.offset(i) };
if c != SEP { break; };
i -= 1;
}
let end = (i + 1) as usize;
while i >= 0 {
let c = unsafe { *ptr.offset(i) };
if c == SEP {
return &path[(i + 1) as usize..end];
};
i -= 1;
}
&path[..end]
}
pub fn basename(pth: &str, ext: &str) -> String {
// Known edge case
if &pth.squeeze("/")[..] == "/" { return "/".to_string(); }
let mut name = extract_last_path_segment(pth);
if ext == ".*" {
if let Some(dot_i) = name.rfind('.') {
name = &name[0..dot_i];
}
} else if name.ends_with(ext) {
name = &name[..name.len() - ext.len()];
};
name.to_string()
}
}


这个案例是为了模仿File.basename
返回结果的方式而写的。这里唯一需要注意的是在basename
方法开始的地方的边界情况。这有效地使方法在迭代给定输入的时间加倍,并且应该重构到现有的系统中去。



感谢Gleb Mazovetskiy
,extract_last_path_segment
是一个有效的贡献。这个方法在其它方法中使用,并在边界情况已知之前就实现了。在本文的后面,将讨论有和没有边界情况下的基准性能的细节。


Rust FFI方法

用于处理字符串显示的打包类的Rust FFI代码如下:


extern crate libc;
use libc::c_char;
use std::ffi::{CStr,CString};
#[no_mangle]
pub extern "C" fn example(c_pth: *const c_char) -> *const c_char {
let pth = unsafe {
assert!(!c_pth.is_null());
CStr::from_ptr(c_pth).to_str().unwrap()
};
let output: String = // YOUR CODE HERE
CString::new(output).unwrap().into_raw()
}

Ruby会通过FFI给出一个原始C类,并将其转换成可以在Rust中使用的字符串,然后再转换回来给到Ruby。



这里需要注意的重要的一点是assert!
。这个assert!
方法在本文的项目当中并不消耗任何时间,但如果它的求值为false,Rust就会崩溃,带来FFI段错误。所以这个assert!
方法有了保证nil
不提供输入是很好的。但Ruby是nil
友好的,你并不希望段错误发生,所以在这里使用assert!
方法是不明智的。



现在nil
在Rust中添加检查并不困难。为我们的代码使用同样的打包行为,我将提供basename的nil
检查版本。


#[no_mangle]
pub extern "C" fn basename_with_nil(c_pth: *const c_char, c_ext: *const c_char) -> *const c_char {
if c_pth.is_null() || c_ext.is_null() {
return c_pth;
}
let pth = unsafe { CStr::from_ptr(c_pth) }.to_str().unwrap();
let ext = unsafe { CStr::from_ptr(c_ext) }.to_str().unwrap();
let output = rust::basename(pth, ext);
CString::new(output).unwrap().into_raw()
}


当执行这段代码的时候,如果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
实现相同的类型安全:


def self.basename(pth, ext = '')
pth = pth.to_path if pth.respond_to? :to_path
raise TypeError unless pth.is_a?(String) && ext.is_a?(String)
// Call original Rust FFI implementation without nil guards here
end

会比原来用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


require "ffi_example/version"
require "ffi"
module FfiExample
# the example function from earlier but with two parameters
def self.basename_with_pure_input(pth, ext = '')
Rust.basename_with_pure_input(pth, ext)
end
def self.basename_nil_guard(pth, ext = '')
return nil if pth.nil? || ext.nil?
Rust.basename_with_pure_input(pth, ext)
end
def self.basename_with_nil(pth, ext = '')
Rust.basename_with_nil(pth, ext)
end
def self.file_basename(pth, ext = '')
pth = pth.to_path if pth.respond_to? :to_path
raise TypeError unless pth.is_a?(String) && ext.is_a?(String)
Rust.basename_with_pure_input(pth, ext)
end
module Rust
extend FFI::Library
ffi_lib begin
prefix = Gem.win_platform? ? "" : "lib"
"#{File.expand_path("../target/release/", __dir__)}/#{prefix}ffi_example.#{FFI::Platform::LIBSUFFIX}"
end
attach_function :basename_with_pure_input, [ :string, :string ], :string
attach_function :basename_with_nil, [ :string, :string ], :string
end
private_constant :Rust
end

Ruby在标准库中有Fiddle,通过外部函数接口直接调用外部C函数。但是,它基本上没有入门文档,缺少很多功能。这很可能是为什么FFI早就写出来了,但只有少量的文档,它仍然缺乏帮助初学者的条件,让他们可以对发生的事情有充分的了解。



这个ffi
提供了一些帮助,使得我们能够编写可以跨多个操作系统运行的代码。上面的ffi_lib
方法需要指向Rust建立的动态库。所以当运行cargo build –release
的时候,它将在target/release中创建库,并且这种扩展取决于操作系统。上述的begin/ end 代码块适用于Windows,Mac和Linux等操作系统。


ruru入门


Ruru现在相当直接地加入到我们的项目中。首先将其添加到Cargo.toml
文件。


[dependencies]
ruru = "0.9.3"
array_tool = "*"
libc = "0.2.33"


然后在外部crate库中使用ruru ,并加入到src/lib.rs
文件。


#[macro_use]
extern crate ruru;
use ruru::{RString,Class,Object};

Ruru有一些不错的宏,这些宏有助于我们的方法与特定的类一起工作。首先,定义一个想要创建的类,然后在宏中定义方法,将它们与Ruby类关联起来。


class!(RuruExample);
methods!(
RuruExample,
_itself,
fn pub_basename(pth: RString, ext: RString) -> RString {
RString::new(
&rust::basename(
pth.ok().unwrap_or(RString::new("")).to_str(),
ext.ok().unwrap_or(RString::new("")).to_str()
)[..]
)
}
);


在methods!
宏中,首先选择要使用的类。下一个环节是将在methods!
宏块内使用的变量来引用Ruby版本的self
。由于在这个项目里根本就不使用它,在它前面加下划线_itself



Ruby有用C语言实现的自己的类系统,每个类都有一个用VALUE
设置的类标识。Ruru将这些类中的某些类戏称为Rust类,所以对于Ruby的String
类,我们使用RString
类。



当用methods!
宏编写方法时,知道宏的作用域内的方法不能相互调用是非常重要的。因此,要重复使用的任何方法都必须在宏之外编写,并在那里调用它们。另外,当创建动态库时,可能很容易出现命名冲突,所以将额外的字符添加到方法名中是极好的,这样就不会混淆了。接下来会演示…


为了使方法可以从Ruby中调用,必须首先让Ruby调用Rust代码来获取实例化的对象。


#[allow(non_snake_case)]
#[no_mangle]
pub extern "C" fn Init_ruru_example(){
Class::new("RuruExample", None).define(|itself| {
itself.def_self("basename", pub_basename);
});
}


前面的Init_
目的是遵循Ruby的惯例,允许直接从库文件中导入一个Ruby C语言风格的编译库。



因此,需要重命名Cargo.toml
文件中的库以避免与ruby中名为ffi_example
的名称发生冲突,并将target/release
路径添加到加载路径,然后应该可以直接请求require "ruru_example"
来请求它(如果命名了ruru_example
库)。再加载ruru Rust代码就好像它是用Ruby写的。



有关将C语言代码与Ruby相连的更深入的了解,请阅读用于编写C语言扩展
的文档。


加载代码的另一种方法是直接使用Fiddle来调用它。在这个例子中,仍然使用FFI的动态库辅助方法。


require 'fiddle'
library = Fiddle.dlopen(
begin
prefix = Gem.win_platform? ? "" : "lib"
"#{File.expand_path("../target/release/", __dir__)}/#{prefix}ffi_example.#{FFI::Platform::LIBSUFFIX}"
end
)
Fiddle::Function.
new(library['Init_ruru_example'], [], Fiddle::TYPE_VOIDP).
call

现在将代码加载到Ruby中,一切都按预期运行。


基准测试


在之前包含的gemspec中,包含了benchmark-ips
。为了对方法进行基准测试,首先放入一个Rakefile使得命令行执行变得更简单。


# Rakefile
require "bundler/gem_tasks"
require "rake/testtask"
Rake::TestTask.new(:test) do |t|
t.libs << "test"
t.libs << "lib"
t.test_files = FileList["test/**/*_test.rb"]
end
Rake::TestTask.new(:bench) do |t|
t.libs = %w[lib test]
t.pattern = 'test/**/*_benchmark.rb'
end
task :default => :test


现在在test/benches/basename_benchmark.rb
创建基准测试。


require 'test_helper'
require 'benchmark/ips'
BPATH = '/home/gumby/work/ruby.rb'
Benchmark.ips do |x|
x.report('Ruby/'s C impl') do
File.basename(BPATH)
File.basename(BPATH, '.rb')
end
x.report('with pure input') do
FfiExample.basename_with_pure_input(BPATH)
FfiExample.basename_with_pure_input(BPATH, '.rb')
end
x.report('ruby nil guard') do
FfiExample.basename_nil_guard(BPATH)
FfiExample.basename_nil_guard(BPATH, '.rb')
end
x.report('rust nil guard') do
FfiExample.basename_with_nil(BPATH)
FfiExample.basename_with_nil(BPATH, '.rb')
end
x.report('with type safety') do
FfiExample.file_basename(BPATH)
FfiExample.file_basename(BPATH, '.rb')
end
x.report('through ruru') do
RuruExample.basename(BPATH, '')
RuruExample.basename(BPATH, '.rb')
end
x.compare!
end


在运行上述基准测试之前,先从basename
方法中评估边界情况。边界情况仅仅是为了通过Ruby Spec Suite
。按照文件路径中可接受的标准,不需要将多个斜杠压缩到一个(从///
到/
),操作系统会很好地识别路径。



现在运行基准测试rake bench
产生以下输出结果(确保cargo build --release
在运行基准测试之前运行):


注:Ruby 2.4.2和Rust 1.23.0
Warming up --------------------------------------
Ruby's C impl41.849k i/100ms
with pure input31.766k i/100ms
ruby nil guard29.974k i/100ms
rust nil guard31.812k i/100ms
with type safety27.103k i/100ms
through ruru41.124k i/100ms
Calculating -------------------------------------
Ruby's C impl683.942k (± 1.5%) i/s -3.432M in 5.018615s
with pure input480.551k (± 1.6%) i/s -2.414M in 5.025184s
ruby nil guard443.185k (± 2.6%) i/s -2.218M in 5.008595s
rust nil guard489.863k (± 1.9%) i/s -2.450M in 5.002297s
with type safety382.805k (± 1.7%) i/s -1.924M in 5.028345s
through ruru667.268k (± 2.6%) i/s -3.372M in 5.057512s
Comparison:
Ruby's C impl: 683941.9 i/s
through ruru: 667268.5 i/s - same-ish: difference falls within error
rust nil guard: 489863.3 i/s - 1.40xslower
with pure input: 480551.2 i/s - 1.42xslower
ruby nil guard: 443185.2 i/s - 1.54xslower
with type safety: 382805.2 i/s - 1.79xslower

不是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。这一切都取决于社团的发展和参与。


未来是如此美好。与此同时,已经有了大量可以完成的工作。鼓励大家涉足这些强大的领域,分享所学到的东西,为他人和将来的自己做好文档,不久的将来,会让年轻的开发人员更好地实现他们在性能编程方面的目标。


相关文章

    无相关信息

最新文章

123

最新摄影

闪念基因

微信扫一扫

第七城市微信公众平台