Can you see me?

2008/12/11

Future of Ruby VM - RubyConf2008

1

Future of Ruby VM

Talk about Ruby VM Performance.

Ruby VMの未来，とかなんとか

SASADA Koichi <ko1@rvm.jp>
Department of Creative Informatics,
Graduate School of Science and Technology,
The University of Tokyo

2008/12/11

Future of Ruby VM - RubyConf20082

Summary of My Talk
“Scaling Ruby (without the Rails)“
Seems Interesting!
“Monkeybars: easy cross platformGUIs” Also Does!
On My Performance Interesting,
Former is Preferred ☺
Anyone make a Log?
2008/12/11

Future of Ruby VM - RubyConf2008

3

Summary
CRuby/YARV is
NOT a “BEST” Solution
for Ruby VM Performance.
However, CRuby/YARV is“GOOD” Enough Solution for Us,
the Pragmatic Ruby Programmers,
at least Several Years.
2008/12/11

Future of Ruby VM - RubyConf2008

4

Self Introduction
Recent Report about Mey ko1 - Koichi (Given Name) Sasada (Family Name)y From Japan, 5 th RubyConf since 2004, 4 th Speachy YARV Developery Lecturery Department of Creative Informatics, Graduate Schoolof Science and Technology, The University of Tokyo.
y Lecture: Programming System, but only 3 students
attendy SASADA-lab
y If you want to research about Ruby or Virtual Machine,
Systems Software in Japan, please contact me.
y 2 students are there, but no one want to hack YARV.
2008/12/11

Future of Ruby VM - RubyConf2008

5

Caution! (re-re-review)y I canʼt speak English welly If I say strange English, you can see the slide
page• Or ask another Japanese. They can speak English
well.
• My Slides uses Small Characters (against Takahashi-sanʼsPresentation Method)y If you have any question, ask me with:• Japanese (recommended)• Ruby, C, Scheme, Java, …, Python, Haskell, ...
• Or Easy English

2008/12/11

Future of Ruby VM - RubyConf2008

6

Agenday Perspective of Ruby VM Performancey VM Performance Discussion
y Our Performance Policyy Introduction of Our Researchy Hidden Optimization Techs.
y Ricsin Projecty Ruby to C AOT Compiler Projecty atomic-Ruby Projecty MVM Projecty Summary
2008/12/11

Future of Ruby VM - RubyConf20087

Remember The Evanʼs Classification
JRuby is for Java Programmers
IronRuby is for .Net Programmers
Rubinius is for Ruby Programmers
CRuby is for C Programmers

2008/12/11

Future of Ruby VM - RubyConf2008

8

OK.
Letʼs Talk about the “C”,
The Benefits and Limitation

2008/12/11

Future of Ruby VM - RubyConf2008

9

Evolution of VM Performance
My Prediction
Performance

Finally, Rubinius
is Best for Ruby’s
Pefromance
Now, CRuby isGood oneGood
at First

CRuby has
Limitation
CRuby
Question:
When get here?
???

JRuby, IronRuby
Rubinius
We are here
2008/12/11

Future of Ruby VM - RubyConf2008

Time / Effort / Money
10

Techniques for VM Performancey Simple Optimization Techniquesy C-level VM Techniquesy Advanced Optimization Techniquesy Dynamic Code Generation• Speed-up using Native Machine code Compiler• Just in Time Compilation• Polymorphic Inline Cache• Selective Inliningy Online Feedback Optimization• HotSpot JIT Compiler• Tracing JIT

2008/12/11

Future of Ruby VM - RubyConf200811

Pros and Cons of JRuby/IronRuby
y Using Awesome VM
y Pros.

y Many Clever People Working on each VM
y No Code is Good Code.
• No Bugs are Generated.

y Many Libraries on Each Environments
y Easy (?) to Use Parallelizationy Cons.

y Not Only Focused on Ruby, Semantics Gap
y Canʼt Use C Extensions Directly

2008/12/11

Future of Ruby VM - RubyConf2008

12

Pros and Cons of Rubinius
y Most of Code is Written in Rubyy Like Javay Pros.

y Ruby in Ruby
• Meta-Circular Interpretery Best Way to Improve Performance in the Long Run

Because They Can Analyze Most of Programs.
y Mainly Focus on Rubyy Cons.

y Long Way to Get High Performance VM

2008/12/11

Future of Ruby VM - RubyConf2008

13

Pros of “C” Rubyy Portabilityy Most of Environments have GCC Porting.

y Maintainabilityy Everyone Know C.

y Extensibility

y Easy to Write Extension with C.

y Performance Improvementy Easy to Write Simple (Machine Independent)

Optimization.

2008/12/11

Future of Ruby VM - RubyConf2008

14

Cons (Limitation) of “C” Rubyy C Extension Libraries or Methods written in C
y GC Problem• Conservative Mark & Sweep Stop The World GC
y Inlining Problem• Canʼt Inline C code into Ruby Codey Limitation of Program Analysis

2008/12/11

Future of Ruby VM - RubyConf2008

15

Our Performance Policyy CRuby is Not “Best” Solution but “Good” Oney Continue to Improve CRubyʼs Implementationy in Cy in Machine Dependent Way

y Pragmatic, Practical Selection
y at least several years

2008/12/11

Future of Ruby VM - RubyConf2008

16

Keywords for Successy “Embedding”

y Parallelization

2008/12/11

Future of Ruby VM - RubyConf2008

17

Introduction of Our Researchy To Take Advantage of “C”, Some Projects are

Runningy Hidden Optimization Techs on YARVy Ricsin: Mix-in C to Ruby Projecty Ruby to C AOT Compiler Projecty atomic-Ruby Projecty Multi-VM Project

2008/12/11

Future of Ruby VM - RubyConf2008

18

Hidden/Left Optimization Techs
y Turned Off on 1.9.1 by Default
y Tail call Optimizationy Optimization using Unificationy Stack Cachingy Left Easy Optimizationy Efficient Method Cachingy Efficient Fiber Implementation using Platform

dependent way such as makecontext()y These Optimizations will be Merged into 1.9.2

2008/12/11

Future of Ruby VM - RubyConf2008

19

Ricsin: Mix-in C to Rubyy Embed a part of C Program into Rubyy Like an RubyInline, but Embed Directly
y Usage Example

y Use C Libs Directly

y Replace All Built-in Classes/Methods
y Test Ruby C APIsy Performance Improvement Continuously

2008/12/11

Future of Ruby VM - RubyConf2008

20

Ricsin Notation
def open_fd(path) # Ruby
fd = __C__(%q{/* C */
return INT2FIX(open(RSTRING_PTR(path), O_RDONLY));})
raise 'open error' if fd == -1
yield fd
ensureraise 'close error' if -1 == __C__(%q{/* C */
return INT2FIX(close(FIX2INT(fd)));})end
2008/12/11

Future of Ruby VM - RubyConf2008

21

Ricsin Total View
rcb File（Ruby+C）

Makefile

RicsinTranslator

C File(C)

C Build Env.
(C compiler, etc)

rb File(Ruby)

so File(C Extension)
Needed for Execution

2008/12/11

Future of Ruby VM - RubyConf2008

Load/Exec

Ricsin-Ver
CRuby
22

RicsinTranslation and Execution# rcb
v = 42r = __C__(%q{/* Embed C Body */rb_p(self); /* show “main” */return INT2FIX(
FIX2INT(v) + 1);})
p r #=> show “43”Bytecode Compile[ADDR] [INSN]
0000 putobject
0002 setlocal
0004 opt_call_ricsin
0006 setlocal
0008 putnil
0009 getlocal
0011 send0017 leave
2008/12/11

Generate

Function Call
[OPERAND]
42v<funcptr>r/* A Part of Generated C Source */#define v (cfp->lfp[3])#define r (cfp->lfp[2])
VALUE ricsin_func_1(
rb_control_frame_t *cfp){
const VALUE self = cfp->self;{/* Embed C Body */rb_p(self);
return INT2FIX(FIX2INT(v) + 1);}
return Qnil;}#undef v#undef r

r:p, 1

Future of Ruby VM - RubyConf2008

Built to Extension Library23

Ricsin: Evaluationy Performance Evaluation (Not a Usability)
y Evaluation Environmenty Env.1：Intel Xeon E5335, Linuxy Env.2：SPARC T2, SunOS 5.10

y Evaluation Items

1. Calling C Function (null call)
2. Example on Iterator
3. Matrix Multiprior

2008/12/11

Future of Ruby VM - RubyConf2008

24

Ricsin
Evaluation of Calling Null Functiony Calling Null C Function
y Null C Method

y Null __C__ Embed

Env.1（Intel）
Env.2（SPARC）

2008/12/11

C (sec)0.44

Ricsin (sec)
0.05

C/Ricsin
8.8

4.56

0.44

10.4

Future of Ruby VM - RubyConf2008

25

Ricsin
Evaluation: Iterator Optimizationy Rewrite Iterators with Ricsin
y C: Current Iteratory Ricsin: Rewriting with __Ccont__y Ruby: Rewriting with Pure Ruby

Env.1 (Intel)
2008/12/11

Env.2 (SPARC)
Future of Ruby VM - RubyConf2008

26

Ricsin
Evaluation: Matrix Multipliery Matrix Multiplier with Fixnum Elementsy Replace 12 Lines Ruby Code to 36 Lines C

Code Directly

Env.1（Intel）
Env.2（SPARC）

2008/12/11

Ruby (sec) Ricsin (sec) Ruby/Ricsin
10.57
0.57
20.33
85.31

Future of Ruby VM - RubyConf2008

6.73

12.68

27

Ricsinsvn cohttp://svn.ruby-lang.org/
repos/ruby/branches/ricsin

2008/12/11

Future of Ruby VM - RubyConf2008

28

Ruby to C AOT Compilery Translate Ruby Script to C Source Code at

Ahead of Timey Compile Ruby to Bytecodey Translate Bytecode to C Source Codey Performance Improvement byy Eliminate VM Instruction Dispatchy Optimization by C Compiler

y Eliminate Parse/Compile Time2008/12/11

Future of Ruby VM - RubyConf2008

29

Ruby to C AOT Compilery Ahead of Time Compilation

1. Compile Ruby Script to VM Bytecode
2. VM Bytecode to C

2008/12/11

Ruby script

VM Bytecode

AOT compiler

Native codeC
compilerCsource code

Future of Ruby VM - RubyConf2008

30

Ruby to C AOT Compilery Execution with Ruby VM

Ruby script

Native code
（AOTed）

VM Insns
evaled String

VM

2008/12/11

Future of Ruby VM - RubyConf2008

Extension
written in C

31

Evaluation Environment
Env
32bit
Linux
64bit
Linux
cygwinPS3

2008/12/11

CPUIntel PentiumD
2.80GHzIntel Xeon
3060 2.40GHzIntel Core Duo
U2400
1.06GHz
Cell
Broadband
Engine3.2GHzMemoryOS
C CompilerLinux
gcc 4.2.3
2.6.24Linux
gcc 4.1.2
2.6.182 GB
1 GB
1.5 GB

Windows
Vista SP1

gcc 3.4.4

256 MB

Linux
2.6.16

gcc 4.1.1

Future of Ruby VM - RubyConf2008

32

Ruby to C AOT Compiler
Evaluation Results
32bit Linux
64bit Linux
cygwinPS3

6
5.26

Speedup Ratio

5

5.17

4
3.40

3
2

2.85

1.66
1.46

1

1.38

1.34

1.44

1.02
1.26
1.36

0
while loop
2008/12/11

fibonacci number
Future of Ruby VM - RubyConf2008

pentomino
33

Related Worky ruby2c by Eric, Ryany Subset Ruby to Cy yajit by Shinhy JIT (yarv bytecode to IA-32 with Xbyak)y yarv2llvm by Miura-sany JIT (yarv bytecode to LLVM asm)

2008/12/11

Future of Ruby VM - RubyConf2008

34

atomic-Ruby Projecty Issue: Ruby is too Fat

y Involves Convenient Functions.

y Complex and Rational will be Built-in at Ruby 1.9→ Difficult to Use “Embedded” Environmenty “Embedded”

y Embedded System such as Resource Limitation

Devs.

• In Many Case, Numeric Tower or m17n are not needed.

y Application Embedded Ruby
• Application needs “DSL Engine”, doesnʼt Full-set Ruby

2008/12/11

Future of Ruby VM - RubyConf2008

35

atomic-Ruby Project (cont.)y We Need Slim Ruby Interpretery atomic-Ruby makes “Suitable Ruby Interpreter”
y Ruby Interpreter for Applicationy Ruby Interpreter for Environment (such as Embedded

Systems)y Ruby Interpreter for Driver Applicationy Utilize CRubyʼs Portabilityy 3 Sub-Project with 3 Studentsy Plug-in/out Built-in Classes/Methodsy Pre-Compilation and Remove Parser/Compilery Switch Core-Feature such as GC, Regex, Thread, etc
2008/12/11

Future of Ruby VM - RubyConf2008

36

atomic-Ruby
Incremental GC
y Switch GC Algorithmy Mark Partiallyy Execute App and Mark partiallyy Reduce Application Stop Time
Start GC

Finish GC

ApplicationGC

2008/12/11

Future of Ruby VM - RubyConf2008

37

Auto Write Barrier Detection
y Write Barrier is Needed for Several GC

Algorithms.

y Need Interpreter and Extensions.

y Need Special Knowledge of VM and GC.

y Cause Critical Bugs if WB Insertion Miss.

y Automatically WB Detection Extension
SystemW
B

Extension

Extension
W
B

WB
WB
2008/12/11

Ruby
VM

WB
WB
WB

Future of Ruby VM - RubyConf2008

38

Snapshot (Real Time) GC
y Stop Time of Application (Mark Phase)y Insert Many WBs.

40

Stop Time [ms]Snapshot GC
従来のGC
Current GC
スナップショットGC

20

0
0

10

20

30

40

50

60

70

Heap Size [KB]

2008/12/11

Future of Ruby VM - RubyConf200839

By The Way,
Other CRuby GC Related Projects
y Generational GC (Kiyama)

y 1 bit Reference Count GC (Matz)y Floating as Special Constant (ko1)y Lazy Sweep (autherNari)y Bitmap GC (Enterprise Ruby, autherNari)y Mostly Copying GC (Ugawa)2008/12/11

Future of Ruby VM - RubyConf2008

40

Multi-VM (MVM) Projecty Multi Virtual Machine in One Process
y Each VMs are able to run in Parallely Each VMs have Giant VM Lock.

y High Speed Inter-VM Communicationy Inner Process Communication

2008/12/11

Future of Ruby VM - RubyConf2008

41

Multi-VM Overview
Ruby (YARV) VM1

VM2

RT

Native Thread
System S/W

・・・

RT

NT

NT

RT

・・・

NT

Thread Scheduler

S/W
H/W
Processor(s)
PE

PE

・・・

PE

PE: Processor Element, UL: User Level, KL: Kernel Level
42

Multi-VM (MVM) ProjectSponsored by
Sun Microsystems, Inc.
Nobu (a.k.a Patch Monster)is Working for This Project
2008/12/11

Future of Ruby VM - RubyConf2008

43

MVM

svn cohttp://svn.ruby-lang.org/
repos/ruby/branches/mvm

2008/12/11

Future of Ruby VM - RubyConf2008

44

Summary
CRuby/YARV is
NOT “BEST” Solutuin
for Performance.
However, CRuby/YARV is“GOOD” Solution for Us,
the Pragmatic Ruby Programmers,
at least Several Years.
2008/12/11

Future of Ruby VM - RubyConf2008

45

Summary (cont.)
y CRuby is Enable to Evolve Moreovery Some Projects to Take advantage of CRuby
y Ricsin: mix-in C to Ruby Projecty Ruby to C AOT Compiler Projecty atomic-Ruby Projecty Multi-VM Project

2008/12/11

Future of Ruby VM - RubyConf2008

46

Fin.
Thank You for Your Attention.
Any Questions?
SASADA Koichi<ko1@rvm.jp>

Department of Creative Informatics,
Graduate School of Science and Technology,
The University of Tokyo

2008/12/11

Future of Ruby VM - RubyConf2008

47

2008/12/11

Future of Ruby VM - RubyConf2008

48

Accepted Method:
Ruby Thread and Native Thread (1:1) ← Ruby 1.9/YARV
Ruby (YARV)Native Thread
System S/W

RT

RT

NT

NT

・・・

・・・

RT

NT

Thread Scheduler

S/W
H/W
Processor(s)
PE

PE

・・・

PE: Processor Element, UL: User Level, KL: Kernel Level

PE

49

Evaluation
Result (Micro-benchmark)x 7.4
w/8 Cores

50

Discussion
How to Embed 64 bit Double?
y VALUE embed Object doesnʼt need memory

overheady 64bit CPU have 64 bit pointer type
→ Use 64 bit CPU
y At least we need 1 bit for TAG bit
y From Mantissa?
• Decrease Precisiony From Exponential?
• Decrease Representation Range

51

Evaluation
Toy-Program

Reduce Mem Time
Encode/Decode don’t
affect to Performance52

Evaluation
Compared with other Ruby Impl.

From Comp. Lang. Shootout [4]53