A Better Python for the JVM

A better Pythonfor the JVM

Tobias Ivarsson <[email protected]>twitter: @thobeblog: http://journal.thobe.org

mailto:[email protected]


http://twitter.com/thobe


http://journal.thobe.org


$ whoamitobias (Tobias Ivarsson)• M.Sc. in Computer Science and Engineering

from Linköping University, Sweden

• Jython Committer / Compiler zealot

• Java developer at Neo TechnologyAsk me why our graph database (Neo4j) kicks assCheck out http://neo4j.org (it works with Python)

• High tech. / low traffic:twitter: @thobeblog: http://journal.thobe.orgwebsite: http://www.thobe.org - check for slides

http://www.liu.se

http://www.liu.se

http://neo4j.org

http://neo4j.org





http://www.thobe.org

http://www.thobe.org

• Overview of the “Advanced Compiler” project

• Performance figures

• Python / JVM mismatch

• Getting better

• Summary




• Getting better

• Summary

• The ultimate goal is a faster Jython

• The new compiler is just a component to get there

• Focus is on representation of Python code on the JVM

Project motivation

What does Code Representation include?• Function/Method/Code object

representation

• Scopes. How to store locals and globals

• Call frame representation

• Affects sys._getframe()

• The representation of builtins

• Mapping of python attributes to the JVM

Compiler tool chainParser Analyzer CompilerSource code AST

Code Infoper scope

ASTThe “spine” of the compiler. The main part. This is the same in any compiler in Jython, and similar to other systems, CPython in particular, as well.

Compiler tool chainParser Analyzer Compiler

JVM

Source code ASTCode Infoper scope

AST

Javabyte code

Jython runtime system

This is the structure of the compiler in Jython today.

Compiler tool chainParser Analyzer Compiler Transformer

Codegen

JVM


ASTIR

IR

Javabyte codeJython

runtime system

The advanced compiler adds two more steps to the compilation process.The analyzer and compiler step also change.


Codegen

Interpreter

JVM


ASTIR

IR

Python byte code

Javabyte codeJython

runtime system

This flexibility makes it possible to output many different code formats.Even bundle together multiple formats for one module.


Codegen

Interpreter

JVM


ASTIR

IR

Javabyte code

Jython runtime system

It is also possible to compile, and re-compile code with more information from the actual runtime data.

IR+ runtime

info

The Intermediate Representation

• “sea of nodes” style SSA

• Control flow and data flow both modeled as edges between nodes

• Simplifies instruction re-ordering




• Getting better

• Summary

Parrotbench

• 7 tests, numbered b0-b6

• Test b1 omitted

• Tests infinite recursion and expects recursion limit exception

• Allocates objects while recursing

• Not applicable for Jython

Running parrotbench

• Python 2.6 vs Jython 2.5 (trunk)

• Each test executes 3 times, minimum taken

• Total time of process execution, including startup also measured

• Jython also tested after JVM JIT warmup

• Warmup for about 1 hour...110 iterations of each test

The tests(rough understanding)

• b0 parses python in python

• b2 computes pi

• b3 sorts random data

• b4 more parsing of python in python

• b5 tests performance of builtins

• b6 creates large simple lists/dicts

Python 2.6

Test Time (ms)

b0

b2

b3

b4

b5

b6

Total* (incl. VM startup)

1387

160

943

438

874

1079

15085* Total time is for three iterations, other times is the best iteration of those three

Jython 2.5b(Preview version available at PyCon)

Test Time (ms)(without JIT warmup)

Time (ms)(with JIT warmup)

b0

b2

b3

b4

b5

b6


4090 2099

202 107

3612 1629

1095 630

3044 2161

2755 2237

51702 Not applicable* Total time is for three iterations, other times is the best iteration of those three

Jython 2.5+(Snapshot from June 24 2009)

Test Time (ms)(without JIT warmup)

Time (ms)(with JIT warmup)

b0

b2

b3

b4

b5

b6


2968 2460

202 124

2255 2030

875 742

4036 2291

2279 2276

57279 Not applicable* Total time is for three iterations, other times is the best iteration of those three

Jython 2.5.0 Final has an embarrassing performance issue on list multiplication that got introduced when the list implementation was made thread safe.

CPython2.6 vs Jython2.5

0

15,000

30,000

45,000

60,000

Total runtime Excluding VM startup

Python 2.6 Jython 2.5b Jython 2.5+

Work on thread safety and compatibility has made Jython *slower* but better. Performance is a later focus.


0

3,750

7,500

11,250

15,000

Python 2.6 Jython 2.5b with warmup Jython 2.5+ with warmup

b0 b2 b3 b4 b5 b6

UnJITed performance improved due to lower call overhead and better dict. JITed performance worse due to thread safety fiixes.


0

1,250

2,500

3,750

5,000

b0 b2 b3 b4 b5 b6

Python 2.6 Jython 2.5b Jython 2.5b with warmupJython 2.5+ Jython 2.5+ with warmup

Is JRubyfaster than Jython?

JRuby is a good indicator for the performance we could reach with Jython.It’s a similar language on the same platform.Therefore a comparison and analysis is interesting.

Adding two numbers# Jythondef adder(a,b):

return a+b

# JRubydef adder(a,b)

a+bend

Execution times(ms for 400000 additions)

0ms

175ms

350ms

525ms

700ms

Without counter

466ms

697ms

Jython JRuby

Why is JRuby faster?

• JRuby has had more work on performance

• Jython work has been focused on 2.5 compatibility

• Next release will start to target performance

• JRuby has a shorter call path

• JRuby does Call Site caching

Counting the number of additions - Jython

from threading import Lockcount = 0lock = Lock()def adder(a,b):

global countwith lock:

count += 1return a+b

Counting the number of additions - JRuby

class Countingdef adder(a,b)

@mutex.synchronize {@count = @count + 1

}a + b

endend

Execution times(ms for 400000 additions)

0ms

12,500ms

25,000ms

37,500ms

50,000ms

With counter

2,981ms4,590ms

46,960ms

Jython (Lock) JRuby (Mutex) Jython (AtomicInteger)

I included AtomicInteger to verify that the problem was with the synchronization primitives.

Why is JRuby faster?

• JRuby has had more work on performance

• JRuby has lower call overhead

• JRuby Mutex is easier for the JVM to optimize than Jython Lock

• Because of JRubys use of closures

Call overhead comparison

• Python wrapper around Java primitives

• Call to Python code

• Reflective Java call

• Lock

• Execute actual code

• Call to Python code

• Reflective Java call

• Unlock

• Java code implementing the Ruby logic

• Lock

• Direct call to closure

• Unlock




• Getting better

• Summary

Call frames

• A lot of Python code depend on reflecting call frames

• Every JVM has call frames, but only expose them to debuggers

• Current Jython is naïve about how frames are propagated

• Simple prototyping hints at up to 2x boost

Extremely late binding

• Every binding can change

• The module scope is volatile

• Even builtins can be overridden

Exception handling

• Exception type matching in Python is a sequential comparison.

• Exception type matching in the JVM is done on exact type by the VM.

• Exception types are specified as arbitrary expressions.

• No way of mapping Python try/except directly to the JVM.

Blocks of Code

• The JVM has a size limit

• The JVM JIT has an even smaller size limit




• Getting better

• Summary

Call frames

• Analyze code - omit unnecessary frames

• Fall back to java frames for pdb et.al.

• Treat locals, globals, dir, exec, eval as special

• Pass state - avoid central stored state

• sys._getframe() is an implementation detail

Late binding

• Ignore it and provide a fail path

• Inline builtins

• Turn for i in range(...): ... into a java loop

• Do direct invocations to members of the same module

JVM Code analysis

• Create faux closures

• Separate code blocks that evaluate in same scope

• Will also help with the code size limit

Exception handling

• The same late binding optimizations+ optimistic exception handler restructuring gets us far

Reaping the fruits of the future JVMs

• Invokedynamic can perform most optimistic direct calls and provide the fail path

• Interface injection make all java objects look like python objects

• Gives improved integration between different dynamic languages even more

• The advanced compiler makes a perfect platform for integrating this




• Getting better

• Summary

The “Advanced Jython compiler” project

• Not just a compiler - but everything close to the compiler - code representation

• A platform for moving forward

• First and foremost an enabling tool

• Actual improvement happens elsewhere

Performance• Jython has decent performance

• On some benchmarks Jython is better

• For single threaded applications CPython is still slightly better

• Don’t forget: Jython can do threading

• Long running applications benefit from the JVM - Jython is for the server side

• We are only getting started...

• Most of the problems comes from trying to mimic CPython to closely

• Future JVMs are a better match

• Break code into smaller chunks

• Shorter call paths

• Optimistic optimizations are the way to go

Python / JVM mismatch- Getting better -

Thank you!

Questions?

Tobias Ivarsson <[email protected]>twitter: @thobeblog: http://journal.thobe.org





