o Ruby

Przez ostatnie dni miałem okazję zapoznać się z biblioteką FFI. (Swoją drogą, kenai.com, czyli strona na której jest hostowany projekt, to próba stworzenia przez firmę Sun systemu, podobnego do sourceforge, githuba itp. Całość zupełnie za darmo, o pełnych możliwościach można poczytać na stronie projektu. Aplikacja jest oparta o framework Ruby on Rails i uruchamiana przy pomocy JRubiego.) Biblioteka FFI służy do łatwego łączenia kodu Rubiego z bibliotekami C.

Rozszerzenia w C - różne podejścia

Zanim opiszę zalety i sposób wykorzystania FFI, chciałbym napisać kilka zdań na temat samych rozszerzeń C dla Rubiego. Otóż istnieje kilka możliwości w tej kwestii. Jedną z podstawowych jest wykorzystanie wewnętrznego API interpretera Rubiego napisanego w C (popularnie zwanego MRI lub cRuby). Jeśli zaglądałeś kiedykolwiek w kod źródłowy MRI i widziałeś źródła np. pliku array.c, to kod takiego rozszerzenia pisze się praktycznie tak samo. Z tego też powodu jesteśmy zmuszeni do poznania, choćby w minimalnym stopniu, wewnętrznego API C Rubiego (zobacz http://www.eqqon.com/index.php/Ruby_C_Extension).

Aby ułatwić choć trochę tworzenie takich rozszerzeń powstał projekt RubyInline. Jego dwoma największymi zaletami jest możliwość osadzania kodu bezpośrednio w kodzie Rubiego, a także automatyczna kompilacja takiego kodu dopiero w momencie odpalenia (skompilowane rozszerzenie jest zapisywane w katalogu ~/.ruby_inline/ by nie kompilować go za każdym uruchomieniem). Pozostałe zasady zostają takie same (ciągle operujemy na tym samym API).

require "rubygems"
require "inline"

class MyMath
  inline do |builder|
    builder.c "
      long add(int a, int b) {
        return a + b;
      }"
  end
end
math = MyMath.new
puts math.add(100, 300)

400

Z projektów, które starają się rozwiązać podobne problemy, wymienię jeszcze SWIG (który potrafi generować kod rozszerzenia na podstawie plików nagłówkowych .h) i Rice (pozwala na wygodne mapowanie klas C++ na klasy Rubiego). Zainteresowanych odsyłam jednak na strony domowe.

Wszystkie wymienione biblioteki wymagają napisania łączącego kodu (tzw. glue code) w C oryginalnej biblioteki C i języka Ruby. Być może nie wszyscy wiedzą, ale wraz z Ruby dostajemy bibliotekę, która pozwala na dynamiczne wywoływanie kodu z, już zbudowanej, współdzielonej biblioteki (pliki o rozszerzeniach so, dll, dynalib w zależności od platformy). Jest to biblioteka Ruby/DL. Oto przykład jej wykorzystania.

require "dl/import"

module Libc
  extend DL::Importable
  dlload "/lib/libc.so.6"

  extern "int strlen(const char *)"
end

puts Libc.strlen("foo")

3

Mam nadzieję, że jeszcze się nie niecierpliwisz, że piszę o wszystkim tylko nie o FFI. Rzecz jest jednak bardzo ważna, ponieważ chciałem zwrócić uwagę na pewną cechę, łączącą wyżej wymienione biblioteki - działają tylko z MRI (cRuby). Jeszcze do nie dawna nie było z tym problemów. Przy obecnym wysypie interpreterów Rubiego, fakt, że dana biblioteka działa tylko z jednym z nich, jest ogromną wadą. Pora zatem na przedstawienie tytułowego FFI, który jak się domyślacie, potrafi współpracować nie tylko z MRI.

FFI = Foreign Function Interface

Biblioteka ta pozwala na dynamiczne wywołanie metody z biblioteki współdzielonej, podobnie jak Ruby/DL, z tą różnicą, że na chwilę obecną dostępne są wersje działające z MRI 1.8/1.9, JRuby i Rubinius. Dodatkowo posiada bardzo ładne i wygodne API.

Oto prosty przykład użycia tej biblioteki.

require "rubygems"
require "ffi"

module Libc
  extend FFI::Library

  attach_function :strlen, [:string], :int
end

puts Libc.strlen("foo")

3

Jak już wspomniałem, FFI ma bardzo ładne API. Dotyczy to także callbacków (czyli w C wskaźniki do funkcji). Jak przystało na wersję w Rubym robimy to za pomocą bloków! Poniższy przykład wykorzystuje funkcję qsort ze standardowej biblioteki C, która do porównywania elementów tablicy wykorzystuje przekazany wskaźnik do funkcji.

require "rubygems"
require "ffi"

module Libc
  extend FFI::Library

  callback :cmp, [:pointer, :pointer], :int
  attach_function :qsort, [:pointer, :int, :int, :cmp], :void
end

ARRAY_SIZE = 5

p = MemoryPointer.new(:int, ARRAY_SIZE)
p.put_array_of_int32(0, [10, 20, 3, 9, 5])

Libc.qsort(p, ARRAY_SIZE, 4) do |p1, p2|
  p1.get_int32(0) <=> p2.get_int32(0)
end

puts p.get_array_of_int32(0, ARRAY_SIZE)

3
5
9
10
20

Mamy także możliwość bardzo łatwego mapowania struktur do klas Rubiego. Spróbujmy napisać własną bibliotekę dzieloną w C i użyć z poziomu Rubiego.

#include <stdlib.h>
#include <stdio.h>

struct user_info {
  char *name;
  int age;
};

struct user_info *user_info_create() {
  struct user_info *ui = malloc(sizeof(struct user_info));
  ui->name = NULL;
  ui->age = 0;
}

void user_info_free(struct user_info *ui) {
  if (ui->name) {
    free(ui->name);
  }
  free(ui);
}

void user_info_randomize_age(struct user_info *ui) {
  ui->age = random() % 100;
}

void user_info_print_array(struct user_info **users, int count) {
  struct user_info *ui;
  int i;

  for (i = 0; i < count; i++) {
    ui = users[i];
    printf("%s ma lat %d\n", ui->name ? ui->name : "(null)", ui->age);
  }
}

Do skompilowania powyższego kodu (plik mylib.c) posłużyłem się poleceniem gcc -O2 -fPIC -shared -Wl,-soname,libsimplemath -o mylib.so mylib.c

Naszym zadaniem jest zmapowanie struktury user_info do klasy w Rubym. Zaprezentowany poniżej kod nie powinien sprawiać trudności, chociaż sposób operowania na klasie FFI::MemoryPointer może wydawać się z początku dosyć dziwny.

require "rubygems"
require "ffi"

module Mylib
  extend FFI::Library

  ffi_lib File.dirname(__FILE__) + "/mylib." + FFI::Platform::LIBSUFFIX

  class UserInfo < FFI::Struct
    layout  :name, :pointer,
            :age, :int
  end

  attach_function :user_info_create, [], :pointer
  attach_function :user_info_free, [:pointer], :void
  attach_function :user_info_randomize_age, [:pointer], :void
  attach_function :user_info_print_array, [:pointer, :int], :void
end

users = []
5.times do |i|
  p = Mylib.user_info_create()
  ui = Mylib::UserInfo.new(p)
  ui[:age] = rand(50) + 10
  ui[:name] = FFI::MemoryPointer.from_string("foo%d" %i)
  users << ui
end

users_ptr = FFI::MemoryPointer.new(:pointer, users.size)
users.each_with_index do |user, i|
  users_ptr[i].put_pointer(0, user)
end
Mylib.user_info_print_array(users_ptr, users.size)

ui = users.first
puts "\n#{ui[:name].read_string} ma lat #{ui[:age]}"
Mylib.user_info_randomize_age(ui)
puts "#{ui[:name].read_string} ma teraz lat #{ui[:age]}"

foo0 ma lat 38
foo1 ma lat 14
foo2 ma lat 57
foo3 ma lat 52
foo4 ma lat 17

foo0 ma lat 38
foo0 ma teraz lat 83

Zagadnienia związane z FFI są zbyt obszerne (choćby kwestia zwalniania pamięci) żeby opisać je tu wszystkie, zatem na tym poprzestanę. Po więcej przykładów odsyłam na wiki projektu FFI oraz dodatkowe artykuły w języku angielskim (linki podam na końcu wpisu).

Wydajność

Do pisania takich rozszerzeń może zachęcić nas także wydajność, ale nie powinniśmy tego robić pochopnie (ktoś chętny na przepisanie railsów na C?;-)). Dla świętego spokoju zrobiłem mały (i zapewne naiwny) test wydajności. Jak zwykle w takim wypadku nie bierz tego zbyt dosłownie, zawsze dokonuj własnych pomiarów.

long fib(int n) {
  if (n < 2) {
    return n;
  } else {
    return fib(n - 1) + fib(n - 2);
  }
}

require "rubygems"
require "ffi"
require "inline"

class MylibFFI
  extend FFI::Library
  ffi_lib File.dirname(__FILE__) + "/libfib." + FFI::Platform::LIBSUFFIX

  attach_function :fib, [:int], :long
end

class MylibRuby
  def self.fib(n)
    if n < 2
      return n
    else
      return fib(n - 1) + fib(n - 2)
    end
  end
end

class MylibInline
  inline do |builder|
    builder.prefix %Q{
      long _fib(int n) {
        if (n < 2) {
          return n;
        } else {
          return _fib(n - 1) + _fib(n - 2);
        }
      }
    }
    builder.c_raw_singleton %Q{
      VALUE fib(int argc, VALUE *args, VALUE self) {
        if (argc != 1) {
          rb_raise(rb_eArgError, "1 argument expected");
        }
        VALUE n = args[0];

        return LONG2NUM(_fib(NUM2INT(n)));
      }
    }
  end
end

require "benchmark"

LOOP = 100000
n = 10

Benchmark.bmbm(15) do |make|
  puts "n = #{n}"

  make.report("pure ruby") do
    LOOP.times do
      MylibRuby.fib(n)
    end
  end

  make.report("ruby + inline") do
    LOOP.times do
      MylibInline.fib(n)
    end
  end

  make.report("ruby + FFI") do
    LOOP.times do
      MylibFFI.fib(n)
    end
  end
end

                     user     system      total        real
pure ruby       17.200000   5.690000  22.890000 ( 23.281636)
ruby + inline    0.130000   0.020000   0.150000 (  0.147392)
ruby + FFI       0.150000   0.010000   0.160000 (  0.171384)

Jak widać nie powinno być dużej różnicy między klasycznym rozszerzeniem a takim napisanym przy pomocy FFI. Różnica ta jeszcze bardziej będzie się zacierać im więcej czasu upłynie bezpośrednio na poziomie kodu C.

Dla kogo FFI?

Chyba nie trzeba przekonywać nikogo o korzyściach płynących z wykorzystania tej biblioteki, zamiast jednego z wymienionych na początku wpisu sposobów. Brak dodatkowej kompilacji, krótszy kod (który najczęściej w rozszerzeniach polegał na przekształcaniu typów między C a Ruby), przenośność między różnymi interpreterami Rubiego, niezależność od wewnętrznego API interpretera (ile rozszerzeń w C działały bez zmian w ruby 1.9?) to jego główne atuty. Jeśli kiedykolwiek przyjdzie Ci napisać takie rozszerzenie to w pierwszej kolejności wypróbuj FFI.

Linki.

• Strona projektu FFI (polecam przejrzeć źródła, w szczególności "speki")
• Przykłady na wiki FFI
• Bridging MRI, JRuby & Rubinius with FFI
• FFI for Ruby Now Available
• Rubinius' Foreign Function Interface
• On the Rubinius FFI - bardzo obszerny artykuł, polecam!
• Ruby FFI Brings Native Library Access to JRuby, MRI