Jarosław Zabiełło - BLOG

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) 

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) 

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."

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);
    }
  }
}

$ 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.  

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

$ 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 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 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

$ /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 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   

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) 

$ 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.

$ 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.

Tags java, jruby, jython, python, ruby | 25 comments

Comments

Leave a response

1. nukeedit
   Jacek Becela said about 6 hours later:
   

   Też jestem zaskoczony wynikami Ruby Enterprise. Ich implementacja (tak obiło mi się o uszy) różni się w miejscach związanych z obsługą pamięci, a Twój test prawdopodobnie (1GB dla Javy) testuje najbardziej właśnie ten aspekt działania interpretera / maszyny wirtualnej.

   Poza Ruby 1.8 wyniki są zbliżone, a to cieszy :)

   W wątkach w Rubym najbardziej denerwujące jest to, że operacje blokujące jeden wątek, blokują cały proces. To jedyny duży minus, który napotkałem podczas ich używania. Ten minus neguje największą korzyść z ich używania – np. odpalenie jakiegos wielowątkowego web crawlera jest na wątkach utrudnione – jeden sie przyblokuje i caly proces stoi i czeka na timeout.

   Czy ktoś z czytających pokonał w jakiś elegancki sposób ten problem?

2. nukeedit
   Drogomir said about 9 hours later:
   

   Jacek: Też mi się wydaje, że to może być przyczyna.

   Jak można przeczytać tutaj ruby uruchamia GC za każdym razem gdy zaalokuje się 8mb pamięci.

3. nukeedit
   Moro said 1 day later:
   

   Odnioslem wrazanie, ze uwazasz green watki za cos zlego? To ze implementacja jest wolna to nie oznacza wcale ze green watki sa gorsze od systemowych, wrecz sa duzo lepsze. Porownaj implementacje green watkow np. w erlangu.

4. nukeedit
   Jarosław Zabiełło said 1 day later:
   

   Erlang nie ma współdzielonej pamięci. To są lekkie procesy, a nie wątki.

5. nukeedit
   JO said 1 day later:
   

   w Ruby jest gem fastthread ktory daje ci “szybkie natywne wątki” panie Zabiełło

   co do range() to ma pan nawet w tutorialu dla n00bów ze do duzych zbiorów uzywa sie xrange :)

   Pozdrawiam :)

6. nukeedit
   Jacek Becela said 1 day later:
   

   Jakub: Czy fassthread rozwiazuje problem blokowania procesu przy zablokowaniu watku?

7. nukeedit
   Tomash said 1 day later:
   

   @Jacek: tak. Korzystałeś kiedyś z Capistrano, a jeśli tak to czytałeś jego komunikaty?

8. nukeedit
   Jacek Becela said 1 day later:
   

   Korzystam, ale nie wnikam bo mi cholera dziala bezblednie :)

   A wątki ostro męczyłem za czasów 1.8.4 i jestem po tyłach w tym temacie.

   Tym samym statni argument przeciwko Rubiemu w mojej głowie upadł.

9. nukeedit
   sprae said 2 days later:
   

   Niedawno Jarosław Zabiełło dokonał testu wydajności różnych interpreterów Pythona i Ruby w natywnych wątkach systemu operacyjnego. Zabrakło mi tam testów IronPythona, który natywne wątki jest w stanie obsłużyć w ramach tradycyjnej biblioteki Pythona. http://sprae.jogger.pl/2008/07/28/python-vs-ironpython-vs-watki/

10. nukeedit
    Adam Olsen said 2 days later:
    

    I apologize for commenting in english, but I’ve a few points I believe are important.

    1. The random implementation may be the dominant cost here. Creating a random list before creating the child threads, and having them copy it, should help mitigate it. You could also eliminate the threads and the sorting, just benchmarking the random number generation. 2. In the python versions the main loop is busy-waiting, which could be soaking up a lot of CPU time (although I doubt it matters much here). Use “for t in threads: t.join()” instead. 3. You should try disabling python’s tracing GC (gc.disable()). It behaves quite badly under certain conditions.

11. nukeedit
    Peter Cooper said 3 days later:
    

    I’m confused why Ruby 1.8.7 is so slow on this. I get similar numbers to you for the Python version, but my Ruby 1.8.6 (which is little different to 1.8.7) gets 2.85s.

12. nukeedit
    david koblas said 3 days later:
    

    Wrote a blog post, but most of the performance difference in this benchmark is because random is a native python library which is slow.

    http://www.skitoy.com/p/python-vs-ruby-performance/172

13. nukeedit
    Jarosław Zabiełło said 3 days later:
    

    @Adam Olsen: I have updated the article. I got rid off sorting and list creation. I have only random number generation. But as David Koblas pointed out, it looks like Python has slow random number generator.

    @Peter Cooper: I have no idea why Ruby 1.8.7 is so slow. On my MBP Core2Duo, 2.16 GHz & Mac OS X 10.5.4, Ruby 1.8.7 is even 6x slower than Ruby 1.8.6!

14. nukeedit
    Marek Kubica said 3 days later:
    

    Jeszcze wymienie ze Python uzywa juz od dawna watki POSIX:

    http://docs.python.org/lib/module-thread.html

15. nukeedit
    JO said 3 days later:
    

    Ps. Ten test polega na samym sortowaniu i roznice / zyski sa na poziomie 10%-14% to oznacza ze pana test panie Zabiełło jest ładnie pisząc do bani, bo implementacja sort może być różna proponuje aby wykorzystał pan jakis text albo strone i ją parsował jakas swoja metoda która jest powtarzalna i katująca mocno dla procesora, wtedy będzie można efekty porownywać.

    Jak u nas ktos na programowaniu rownoleglym przyniosl program ktory po zrownolegleniu mial przyrost szybkosci < 25% to w ogole prowadzacy mowil mu “nara” :)))

    Prosze poprawic test !!!

16. nukeedit
    Jarosław Zabiełło said 4 days later:
    

    @Marek Kubica: co z tego, że Python używa wątków skoro GIL nie pozwala im wykorzystać pełni możliwości maszyn wieloprocesorowych/wielordzeniowych?

    @JO: Widzę, żeś nie zauważył, że w update do tekstu zmieniłem kod i już nie ma sortowania. Zostało samo generowanie liczb losowych. Niestety, jak nie urok to sraczka. Okazało się że tym razem Python ma (ponoć) wolny generator liczb losowych. Co nie wybrać, to problem. Panie Oboza, sam sobie napisz dokładne i obiektywne testy jak masz na to czas.

    Z innej beczki. Zapuściłem ostatnio ten mój kod na Solarisie (Sparc, 32GB, 64 rdzeni) Mam tam tylko Javę i JRuby więc ograniczyłem się do tego. Zauważyłem, że JRuby nie wykorzystuje pełnych zasobów maszyny. Java, bez problemu pochłonęła pełne 100% czasu rdzeni.

17. nukeedit
    wysek said 16 days later:
    

    “Co nie wybrać, to problem.”

    Ano, nie ma letko;) Testowanie to nie jest taka prosta czynność, że się napisze test i odpali. Trzeba jeszcze czasem trochę pomyśleć ;)

18. nukeedit
    jc said 17 days later:
    

    “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ł.” – nie sprawdzałem i nie wiem, jak działa Django na Jythonie, ale wysnuwanie takich wniosków na podstawie mikrotestu generatora liczb losowych jest co najmniej komiczne ;)

    Tak z ciekawości, jakiego algorytmu używa Ruby/JRuby do generowania liczb losowych?

19. nukeedit
    lopex said 17 days later:
    

    W tej chwili java.util.Random (MRI używa Mersenne Twister’a który, btw, jest dużo szybszy – shufluje duże słowo co 624 wołań a normalnie robi 4 xory i 4 przesunięcia co powoduje doskonałą utylizację cache’a). W tej chwili JRuby nie używa arity split dla Kernel#rand (a więc jest narzut sprawdzania arności i bardzo duży narzut “boxingu” w tablicę argumentów). W wolnej chwili zakomituję javową wersję MT i dużo szybszy dispatch w Kernel#rand (w zasadzie to on jest wąskim gradłem tutaj a nie generator).

20. nukeedit
    rmz said 22 days later:
    

    1. Test jest skopany, generowanie liczb losowych to nie taka prosta sprawa, test może tylko rodzić przypuszczenie że w Pythonie zastosowano lepszy algorytm a w Rubym gorszy do generowania liczb losowych. (Może w Rubym jest skopany?) Element losowy należy w tego rodzaju testach wyeliminować. Zrozumiał bym gdybyś np. testował bazy danych a tylko zestaw danych przykładowych był by generowany.

    2. Od kiedy to “Jython jest kolejnym przykładam całkowitej ignorancji założeń języka Python (o istnieniu jednej, oczywistej drogi do tego samego celu)” myślałem że “istnienie jednej drogi” to filozofia Rubiego a nie Pythona, ale może coś przeoczyłem.

21. nukeedit
    Jarosław Zabiełło said 22 days later:
    

    @rmz: Zdecydowanie ci się pomieszało. Jest dokładnie odwrotnie. Istnienie “jednej drogi” to filozofia Pythona, a nie Rubiego. Zobacz PEP20, pkt.13.

22. nukeedit
    iddqd said 23 days later:
    

    Spoko blog ale za przeprowadzanie testów to raczej się nie bierz bo wygląda na to, że góry zakładasz wynik i nie znasz wystarczająco bebechów.

    Generator liczb losowych Ruby jest stosunkowo mało losowy( w porównaniu do Pythona) a przez to szybki. Produkcja takich testów i takich http://blog.zabiello.com/articles/2007/04/02/postgresql-vs-mysql-vs-mssql2k obniża wartość bloga.

23. nukeedit
    lopex said 24 days later:
    

    @iddqd “Generator liczb losowych Ruby jest stosunkowo mało losowy”. Jak to ? MT to jeden z najlepszych generatorów pseudolosowych jakie istnieją (o ile nie najlepszy w swojej klasie) i przeszedł wszystkie die hard testy i choć nie przydaje się w kryptografi, znakomicie sprawdza się choćby w Monte Carlo.

24. nukeedit
    jellonek said 24 days later:
    

    uzywanie jythona 2.2.1 w czasie gdy nie jest od dobrych kilku miesiecy rozwijany jest conajmniej dziwne… trzeba bylo probowac 2.5.1a, choc teraz mozna spokojnie wersji z trunka sprobowac (dopiero “na dniach” wersja 2.5.1 przeszla do trunka z branch/asm). roznica jest ogromna, nawet przy tescie specjalnie przygotowanym by pokazac wyzszosc ruby nad pythonem ;) tak wiec – czekam na aktualizacje, tudziez nowy wpis do bloga ;)

25. nukeedit
    lopex said 25 days later:
    

    Lepsza wydajność 2.5.1a to głównie praca nad runtimem. ASM wnosi tylko tyle że po refactoringu i użyciu api ASM kod jest czytelniejszy, wcześniej w źródłach jythona były tragiczne addByte(234), itp.

RSS feed for this post

Your name	(leave url/email »)
Your blog
Your email
Your message
Comment Markup Help Preview comment

Tags

activerecord ajax apache apple benchmark cheetah datamapper django eclipse edytory fastcgi git google haml java javascript jruby jython leopard lighttpd linux mako merb mongrel mvc myghty mysql netbeans nginx orm osx php plone polityka polska prototype pylons python rack radrails rails ruby sequel smalltalk sqlalchemy subversion templates typo wybory yarv

Subskrypcja kanału RSS

Artykuły:
Komentarze:

Kanały IRC

#rubyonrails.pl #ruby.pl #merb #datamapper #sequel #python-pl

Forum dyskusyjne

Grupy dyskusyjne (Usenet)

Moje serwisy

Linki

Archives

• August 2008 (1)
• July 2008 (1)
• June 2008 (8)
• May 2008 (4)
• April 2008 (4)
• March 2008 (10)
• February 2008 (8)
• January 2008 (3)
• December 2007 (12)
• November 2007 (4)

Ostatnie komentarze