Ruby, Python i natywne wątki systemu operacyjnego

Jarosław Zabiełło — Sat, 26 Jul 2008 13:22:00 +0200

Wiele się mówi o tym, że Ruby jak i Python nie posiadają obsługi natywnych wątków systemu operacyjnego. Wbudowane, tzw. green threads, nie są w stanie wykorzystać zalet maszyn wyposażonych w procesory wielordzeniowe. Istnieją jednak implementacje obu języków w czystej Javie. Czy ich użycie daje jakieś znaczące przyśpieszenie?

Wszystkie testy były wykonywane na MacBook Pro Core2 Duo 2.16GHZ, 4GB RAM i systemie Mac OS X 10.5.4 Leopard + zainstalowana Java 1.6.0_05.

Python

from time import time
from random import Random
from threading import Thread
rand = Random().randint # alias

class Test(Thread):
   def __init__ (self): 
      Thread.__init__(self)
      print "Starting %s" % self.getName()
   def run(self): 
      a = [rand(0,SIZE) for x in xrange(SIZE)]
      a.sort()
      print "%s finished" % self.getName()      

print "Start"
start = time()
THREADS, SIZE = 20, 100000
threads = []             
for i in xrange(THREADS):
    t = Test()
    threads.append(t)
    t.start()     
while True in [t.isAlive() for t in threads]:
    pass
print "Time: %s s" % (time() - start)

Dla powyższego kodu Python i Jython uzyskały wyniki:

Jython 2.2.1 = 12.15 s.
Python 2.5.2 = 14.24 s.

Rożnica jakoś podejrzanie mała wskazująca na wciąż jeszcze niedojrzałą implementację Jythona. Dla pewności, zmodyfikowałem kod tak, aby korzystał z natywnych bibliotek Javy.

from time import time
from random import Random
rand = Random().randint # alias
from java.lang import Thread, Runnable

class Test(Runnable):
   def __init__ (self): 
      print "Starting %s" % self
   def run(self):         
      a = [rand(0,SIZE) for x in xrange(SIZE)]
      a.sort()  
      print "%s finished" % self

print "Start"
start = time()
THREADS, SIZE = 20, 100000    
threads = []             
for i in xrange(THREADS):
    t = Thread(Test())              
    threads.append(t)
    t.start()     
while True in [t.isAlive() for t in threads]:
    pass
print "Time: %s s" % (time() - start)

Tym razem

Jython 2.2.1 = 11.96 s.

Różnica jest minimalna. Na dodatek panuje trochę zamieszania co do sposobu odpalania wątków w Jythonie – mętna składnia i za dużo możliwych sposobów uzyskania tego samego efektu. Po SQLAlchemy, Jython jest kolejnym przykładam całkowitej ignorancji założeń języka Python (o istnieniu jednej, oczywistej drogi do tego samego celu). Na domiar złego, mój pierwotny test zakładał testowanie miliona liczb do sortowania. Jython nie był w stanie tego testu wykonać z powodu braku pamięci dla Javy. Ruszył dopiero jak mu zaalokowałem 1GB (słownie: jeden gigabajt pamięci) za pomocą opcji (-Xmx1024M), co jest po prostu chore! Po wymianie pierwotnego range() na generatorowy xrange() zapotrzebowanie na pamięć wyraźnie zmalało i wystarczyła już opcja -Xmx256M. Jednakże kod się wykonywał tak koszmarnie wolno, że nie starczyło mi cierpliwości i zmniejszyłem ilość iteracji do 100 tys.

Ruby

require "time"
require "thread"

THREADS, SIZE = 20, 100_000

start = Time.now
puts "Start"
threads = (1..THREADS).map do |i|
  puts "Starting Thread-#{i}\n"
  Thread.new(i) do |t|
    a = (1..SIZE).map {|e| rand(SIZE)}
    a.sort!
    puts "Thread-#{t} ended\n"
  end
end
while t = threads.find {|lt| lt.alive?}
  t.join
end 
puts "Time: #{Time.now - start} s."

Pierwsze, co mi się od razu rzuca w oczy, to o wiele czytelniejsza, zgrzebniejsza składnia Rubiego, który tu korzysta z bloków kodu. Po drugie, wyniki są dosyć ciekawe:

Ruby 1.9.0 = 1.11 s
Ruby Enterprise = 2.77 s
JRuby 1.1.2 = 3.53 s
Ruby 1.8.7 = 21.82 s.

Ruby okazał się najwolniejszy w tym zestawieniu. Python był tylko trochę szybszy. JRuby, korzystający z javowych wątków systemowych, zdeklasował Rubiego, Pythona i niedojrzałego Jythona. Jednakże to nie JRuby okazał się tu zwycięzcą. Nie trzeba czekać na Ruby 2.0, wersja 1.9 posiada już natywną obsługę wątków POSIX i jest dodatkowo nieźle zoptymalizowana. Ruby 1.9 pokazał, że jest tu prawie 4x szybszy od JRuby. Nie sądzę, że tą szybkość uzyskał na lepszej implementacji wątków od Javy. Raczej ma mocno zoptymalizowany kod który był wykonywany w każdym z wątków.

Bardzo dobrze poradził sobie też Ruby Enterprise, zoptymalizowana wersja Ruby 1.8.6 przez twórców Passengera! Nie wiem jakim cudem Ruby Enterprise pobił JRubiego… no chyba, że jego twórcy dodali mu obsługę natywnych wątków systemu operacyjnego. Inaczej nie mogę sobie wytłumaczyć tak dobrego wyniku.

Updated

Dla pełniejszego obrazu uruchomiłem testy dla 1 wątku. Poprawiłem też błąd z ilością list do sortowania faworyzującą Rubiego. Ostateczne podsumowanie wygląda tak:

1 thread, 2,000,000 iterations

Ruby 1.9 = 1.69 s.
Ruby Enterprise = 3.38 s.
JRuby 1.1.2 = 7.06 s.
Jython 2.2.1 = 17.29 s.
Python 2.5.2 = 18.06 s.
Ruby 1.8.7 = 22.37 s.

20 threads * 100,000 iterations

Ruby 1.9 = 1.54 s.
Ruby Enterprise = 3.01 s.
JRuby 1.1.2 = 5.82 s.
Jython 2.2.1 = 11.86 s.
Python 2.5.2 = 12.32 s.
Ruby 1.8.7 = 22.68 s.

Czasy, kiedy Python był zawsze szybszy od Rubiego, to już przeszłość. Z wyników wynika, że to nie obsługa wątków zadecydowała o wynikach. Ruby 1.9 pobił wszystkich zarówno w teście 1 jak i wielu wątków.

Updated 2008-07-30

Poprawiłem trochę test, aby nie zużywał tyle pamięci. Wyrzuciłem więc generowanie list i sortownie. Zostało samo generowanie losowych liczb. Dodałem też kod dla Javy dla porównania.

Java

import java.util.Random;

public class Main {

  static Integer SIZE,  ITERATIONS;

  public static void main(String[] args) throws Exception {
    Integer[] threads_nr = {1, 10, 50, 100};
    SIZE = Integer.parseInt(args[1]);
    System.out.println(args[0]);
    for(Integer nr: threads_nr) {
      ITERATIONS = SIZE / nr;
      System.out.printf(" %3d thread(s) x %9s = ", nr, ITERATIONS);
      long start = System.currentTimeMillis();
      Thread[] threads = new Thread[nr];
      for(int i = 0; i < threads.length; i++) {
        threads[i] = new ThreadTest();
        threads[i].start();
      }
      while(threadsAlive(threads)) {}
      System.out.printf("%s s.\n", (System.currentTimeMillis() - start) / 1000.0);
    }
  }

  public static boolean threadsAlive(Thread[] threads) {
    for(Thread t: threads)
      if(t.isAlive())
        return true;
    return false;
  }

  static class ThreadTest extends Thread {

    @Override
    public void run() {
      Random rnd = new Random();
      for(int i = 0; i < ITERATIONS; i++)
        rnd.nextInt(SIZE);
    }
  }
}

Test:

$ java Main "`java -version`" 10000000
java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13-120)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_05-b13-52, mixed mode)
  1 thread(s) x  10000000 = 0.361 s.
 10 thread(s) x   1000000 = 0.18 s.
 50 thread(s) x    200000 = 0.186 s.
100 thread(s) x    100000 = 0.189 s.

Java, co nie dziwi, jest najszybsza. Nie ma znaczącej różnicy między 10 czy 10 wątkami, bo mój procesor posiada tylko dwa rdzenie.

Ruby/JRuby

require "time"
require "thread"

SIZE = ARGV[1].to_i  
puts ARGV[0]   
[1, 10, 50, 100].each do |nr|
  iterations = SIZE / nr
  print " %3d thread(s) x %9s = " % [nr, iterations]
  start = Time.now
  (1..nr).map do |i|
    Thread.new(i) do |t|
      iterations.times {rand(SIZE)}
    end
  end.each {|t| t.join}
  puts Time.now - start
end

Ten sam kod w Ruby/JRuby wygląda znacznie krócej (i ładniej) ale kosztem wydajności. To też nie dziwi. Ruby jest bardzo produktywnym językiem, lecz oczywiście nie tak szybkim jak Java.

Wyniki testów:

Ruby 1.9:

$ ruby1.9 main.rb "`ruby1.9 -v`" 10_000_000
ruby 1.9.0 (2008-06-20 revision 17482) [i686-darwin9.4.0]
  1 thread(s) x  10000000 = 2.858588
 10 thread(s) x   1000000 = 2.832928
 50 thread(s) x    200000 = 2.845377
100 thread(s) x    100000 = 2.852745

JRuby:

$ jruby main.rb "`jruby -v`" 10_000_000
jruby 1.1.3 (ruby 1.8.6 patchlevel 114) (2008-07-28 rev 6586) [x86_64-java]
   1 thread(s) x  10000000 = 3.58
  10 thread(s) x   1000000 = 3.4290000000000003
  50 thread(s) x    200000 = 3.442
 100 thread(s) x    100000 = 3.516

Ruby Enterprise:

$ ruby-enterprise main.rb "`ruby-enterprise -v`" 10_000_000
ruby 1.8.6 (2008-03-03 patchlevel 114) [i686-darwin9.4.0]
  1 thread(s) x  10000000 = 3.510694
 10 thread(s) x   1000000 = 3.552756
 50 thread(s) x    200000 = 3.586885
100 thread(s) x    100000 = 3.574564

Ruby 1.8.6 (installed with Leopard):

$ /usr/bin/ruby main.rb "`/usr/bin/ruby -v`" 10_000_000
ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0]
   1 thread(s) x  10000000 = 6.586917
  10 thread(s) x   1000000 = 6.78801
  50 thread(s) x    200000 = 6.951003
 100 thread(s) x    100000 = 6.907087

Ruby 1.8.7 (installed from MacPorts):

$ ruby main.rb   "`ruby -v`" 10_000_000
ruby 1.8.7 (2008-06-20 patchlevel 22) [i686-darwin9.4.0]
   1 thread(s) x  10000000 = 36.329174
  10 thread(s) x   1000000 = 36.808753
  50 thread(s) x    200000 = 36.715717
 100 thread(s) x    100000 = 36.499772

To co niepokoi, to koszmarnie wolna praca Ruby 1.8.7 w porównaniu do Ruby 1.8.6. To jest bardzo podejrzana sprawa. Cieszy za to dobra wydajność Ruby Enterprise.

Python/Jython

from random import Random
from sys import argv
from time import time
from threading import Thread
rand = Random().randint # alias

class ThreadTest(Thread):
   def __init__ (self, iterations): 
      Thread.__init__(self)              
      self.iterations = iterations
   def run(self): 
      [rand(0,SIZE) for x in xrange(self.iterations)]

SIZE = int(argv[2])
print argv[1]
for nr in [10, 50, 100]:
  iterations = SIZE / nr
  print " %3d thread(s) x %9s = " % (nr, iterations),
  start = time()
  threads = []
  for i in range(nr):
     t = ThreadTest(iterations)
     threads.append(t)
     t.start()
  for t in threads:
     t.join()
  print "%s s." % (time() - start)

Test:

$ python main.py "`python -V`" 10000000
Python 2.5.2
  1 thread(s) x  10000000 =  34.5188429356 s.
 10 thread(s) x   1000000 =  52.3496830463 s.
 50 thread(s) x    200000 =  53.9406650066 s.
100 thread(s) x    100000 =  58.3923280239 s.

Co ciekawe, Python 2.5.2 okazał się najwolniejszy. Im więcej wątków tym jeszcze wolniej działał. Był wolniejszy nawet od (dziwnie wolnego) Ruby 1.8.6. Ale, być może to jest wina bardzo wolnej biblioteki generowania losowych liczb. Ech, jak tu cokolwiek porównywać między językami jak takie odkrywa się takie babole w bibliotece standardowej Pythona.

Jython był jeszcze wolniejszy. Dla 10 mln. iteracji, mimo że nie były tworzone w pamięci żadne listy, wlókł się tak wolno, że przerwałem test. Po zmniejszeniu iteracji o rząd wielkości (do 1 miliona) uzyskał wyniki takie jak Ruby 1.8.6 dla 10 milionów iteracji. Jython jest najwyraźniej jeszcze bardzo słabo zoptymalizowany. Pomysły aby na nim odpalać frameworki takie jak Django, to na razie raczej przedwczesny pomysł.

Iterations: 1,000,000 instead of 10,000,000:

$ jython main.py "`jython --version`" 1000000
Jython 2.2.1 on java1.6.0_05

  10 thread(s) x    100000 =  6.391000032424927 s.
  50 thread(s) x     20000 =  4.368000030517578 s.
 100 thread(s) x     10000 =  4.352999925613403 s.

Słoneczna przyszłość dla Jythona

Jarosław Zabiełło — Mon, 03 Mar 2008 17:15:00 +0100

Od czasu odejścia twórcy Jythona, Jima Hugginsa, do firmy Microsoft (do prac na IronPythonem), rozwój Jythona , (javowej implementacji Pythona) mocno zwolnił i został sporo w tyle za wychodzącymi kolejnymi wersjami CPythona. Dlatego sympatycy Pythona z pewnością się ucieszą wiadomością o tym, że firma Sun zatrudniła na pełen etat Franka Wierzbickiego, będącego głównym developerem Jythona od grudnia 2005. Jest zatem spora szansa że projekt nabierze porządnego rozpędu tak, jak to się stało z JRuby.

Od jakiegoś czasu developerzy Django także pracują nad uruchomieniem swego frameworka pod Jythonem. Niestety aktualnie Jython jest zgodny ze starym Pythonem 2.2 i z tego powodu raczej nie zanosi się aby szybko podobne działania podjęli developerzy frameworka Pylons (który wymaga do pracy minimum Pythona 2.4). Ale to wszystko może się wkrótce zmienić, skoro Jython dostał się pod skrzydła Suna.

Django on Jython

Jarosław Zabiełło — Tue, 08 Jan 2008 04:34:00 +0100

Pythonistas chyba pozazdrościli możliwości odpalenia Railsów w JRuby. Trwają prace nad uruchomieniem frameworka Django w Jythonie, implementacji Pythona w czystej Javie.

Zapytałem się na kanale #pylons odnośnie podobnego ruchu ze strony Pylons, ale okazuje się że Jython jest dosyć zacofany. Od czasu przejścia jego twórcy do Microsoftu i pracy na IronPythonem projekt dosyć powoli się rozwija. Jython zatrzymał się na implementacji Pythona 2.2. To dosyć stara wersja zważając, że w międzyczasie wyszły wersje 2.3, 2.4 i 2.5. Pylons wymaga zgodności min. z Pythonem 2.4. Nie wiem jak ten problem rozwiążą przy przenoszeniu Django, bo coś nie chce mi się wierzyć że jest w pełni zgodny ze starym Pythonem 2.2.

Jython 2.2beta1

Jarosław Zabiełło — Fri, 09 Feb 2007 22:51:00 +0100

Pogłoski o przedwczesnej śmierci Jythona (javowej implementacji Pythona), są chyba przesadzone. Właśnie wyszła kolejna wersja 2.2 beta1. Instalacja:

java -jar jython_installer-2.2b1.jar

Jarosław Zabiełło - BLOG: Tag jython