Python on LLVM. Thought it might be interesting to some folks here:
On a related note, regarding Perl, LLVM and performance:
http://use.perl.org/~Matts/journal/38786
Regards,
Dan
On Fri, Apr 10, 2009 at 7:33 AM, Daniel B. [email protected]
wrote:
Python on LLVM. Thought it might be interesting to some folks here:
Google searches for holy grail of Python performance | Ars Technica
I don’t know anyhting about the details, but isn’t MacRuby also heading
to LLVM?
-greg
On Friday 10 April 2009 09:32:01 Gregory B. wrote:
On Fri, Apr 10, 2009 at 7:33 AM, Daniel B. [email protected] wrote:
Python on LLVM. Thought it might be interesting to some folks here:
Google searches for holy grail of Python performance | Ars Technica
o-boost-python-performance-by-5x.arsI don’t know anyhting about the details, but isn’t MacRuby also heading to
LLVM?
I believe MacRuby is on LLVM, but is Mac-bound, as it also relies on
some
Apple-specific stuff that’s been built on LLVM.
Am I right?
What I’d really rather see is something like Rubinius targeting LLVM,
but in a
cross-platform, open way. But I have no idea how long that would take –
I
don’t think there’s any Google funding for it.
On Fri, Apr 10, 2009 at 12:28 PM, Roger P.
[email protected]wrote:
Hmm. Looks somewhat like Python psyco. Except psyco boasted to boost
python performance by only 4x, not 5At least it will work for
Python 3.0 code (psyco only works on 2.4-6).
It could potentially work for Python 3.0, but that is not one of their
priorities at the moment. They’re targeting Python 2.x.
Note that their speed increase is because they are translating the
python code to bytecode, NOT just compiling python’s original
interpreter using the LLVM compiler. LLVM encompasses a lot of things,
including both a compiler and also a JIT bytecode emitter. They’re
using the latter. The perl folks were using the former. Some rubyists
have had a little success with it [1]
Actually I believe they’re doing both: trying to build the interpreter
itself with LLVM, and then adding an LLVM-based JIT, or at least that’s
what
I gathered from their roadmap.
They’re basically trying everything they can to make CPython faster.
Daniel B. wrote:
Python on LLVM. Thought it might be interesting to some folks here:
Google searches for holy grail of Python performance | Ars Technica
Hmm. Looks somewhat like Python psyco. Except psyco boasted to boost
python performance by only 4x, not 5 At least it will work for
Python 3.0 code (psyco only works on 2.4-6).
Note that their speed increase is because they are translating the
python code to bytecode, NOT just compiling python’s original
interpreter using the LLVM compiler. LLVM encompasses a lot of things,
including both a compiler and also a JIT bytecode emitter. They’re
using the latter. The perl folks were using the former. Some rubyists
have had a little success with it [1]
Anyway if somebody wants to come up with an equivalent for Ruby I’d be
very happy I’d even chip in some money. $500 anyone? Any matchers?
Cheers!
-=r
[1] Ruby 1.9.1-p0, llvm: all tests pass! - Ruby - Ruby-Forum
Note: googling for “ruby llvm” reveals a few hesitating first looks in
that direction. rumble.withoutpenandink.com:4559 also reveals a libJIT
attempt that “almost works well” with 1.9 or what not. GL!
It’s probably also worth pointing out that the majority of Ruby
application performance problems are due to the core classes, object
churn, and GC overhead, none of which are easy to improve with a better
compiler or execution engine. JRuby’s had much better execution
performance than CRuby for well over a year, but only recently are we
comfortably faster at running applications like Rails. That’s largely
because it takes a lot longer to optimize all the core classes,
certainly longer than optimizing execution.
Interesting. Now that you mention it, I do remember seeing a comparison
of django and django + psyco before (similar to [1]) and it didn’t speed
up more than 50%.
Still take what you can get I suppose. That’s still a 50% speedup
It’s also unclear whether Psyco or Unladen Swallow actually help
application performance; in both cases they usually post perf numbers on
execution-bound microbenchmarks. When the bulk of your application’s
time is spent manipulating Strings or Arrays, faster code execution can
only help so much.
- Charlie
[1]
http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/
Tony A. wrote:
Actually I believe they’re doing both: trying to build the interpreter
itself with LLVM, and then adding an LLVM-based JIT, or at least that’s what
I gathered from their roadmap.They’re basically trying everything they can to make CPython faster.
It’s probably also worth pointing out that the majority of Ruby
application performance problems are due to the core classes, object
churn, and GC overhead, none of which are easy to improve with a better
compiler or execution engine. JRuby’s had much better execution
performance than CRuby for well over a year, but only recently are we
comfortably faster at running applications like Rails. That’s largely
because it takes a lot longer to optimize all the core classes,
certainly longer than optimizing execution.
It’s also unclear whether Psyco or Unladen Swallow actually help
application performance; in both cases they usually post perf numbers on
execution-bound microbenchmarks. When the bulk of your application’s
time is spent manipulating Strings or Arrays, faster code execution can
only help so much.
- Charlie
Roger P. wrote:
Interesting. Now that you mention it, I do remember seeing a comparison
of django and django + psyco before (similar to [1]) and it didn’t speed
up more than 50%.
Still take what you can get I suppose. That’s still a 50% speedup
Very true…we’re happy to be posting 10-20% faster Rails numbers over
MRI these days, especially considering that getting Rails to run faster
is like chipping away at granite.
- Charlie
Very true…we’re happy to be posting 10-20% faster Rails numbers over
MRI these days, especially considering that getting Rails to run faster
is like chipping away at granite.
No joke. Rails is a tough one. AR does things like regenerate the
query string every single time you run a query (this would be the exact
OPPOSITE of using stored procedures), and does n^2 searches across the
before and after filters as you run through a request. It also
re-generates sql escaped copies of each column name for all tables used
for every single query. That’s as far as I went in my profiling before
mostly giving up on it.
Good luck with your optimizations. I will admit that it is nice to have
jruby on the alioth benchmarks since it makes the ruby contingent look
better 
-=r
Hi
I suggest everyone use libJIT instead of LLVM. See
Google Code Archive - Long-term storage for Google Code Project Hosting. for how
much libJIT is better than LLVM overkill.
For instance, these are just a few things with LLVM does not support for
.NET and Microsoft Common Intermediate Language implementation:
- the whole spectrum of ECMA 335 for CLR types and operations
- async exception handling
- precise stack marking
- multiple custom call conventions
All these things are supported in libJIT.
See more information here:
http://lists.ximian.com/pipermail/mono-devel-list/2009-April/031640.html
and here
http://lists.gnu.org/archive/html/dotgnu-libjit/2004-05/index.html
Thanks,
Kirill
We everyone is that interested in benchmarks? All results that we
usually get on internet are flowed. Why not simply try use libJIT in
your task, and check how well it works for you, and then give an advice?
I can tell that for .NET it beats Mono JIT in pnetmark.
Thanks,
Kirill
Roger P. wrote:
I suggest everyone use libJIT instead of LLVM. See
Google Code Archive - Long-term storage for Google Code Project Hosting. for how
much libJIT is better than LLVM overkill.Nice to know that libjit is moving forward. Any benchmarks?
-=r
I suggest everyone use libJIT instead of LLVM. See
Google Code Archive - Long-term storage for Google Code Project Hosting. for how
much libJIT is better than LLVM overkill.
Nice to know that libjit is moving forward. Any benchmarks?
-=r
Take a look at this:
http://www.mail-archive.com/[email protected]/msg42700.html
for an improvement it gives.
But the point is that a benchmark is flowed by definitation - the score
it should get on an “ideal” engine is infinity. Which is non-sense. One
simply need to undestand how simply something works for his work. “A set
of all sets does not exist”
Thanks,
Kirill
Why everyone is that interested in benchmarks? All results that we
usually get on internet are flowed. Why not simply try use libJIT in
your task, and check how well it works for you, and then give an advice?
I can tell that for .NET it beats Mono JIT in pnetmark.Thanks,
Kirill
Why everyone is that interested in benchmarks? All results that we
usually get on internet are flowed. Why not simply try use libJIT in
your task, and check how well it works for you, and then give an advice?
I can tell that for .NET it beats Mono JIT in pnetmark.
Thanks,
Kirill
Gregory B. wrote:
…
Python on LLVM. Thought it might be interesting to some folks here:
Google searches for holy grail of Python performance | Ars Technica
I don’t know anyhting about the details, but isn’t MacRuby also heading
to LLVM?
Appears that macruby “intends” to use LLVM JIT for its next release
(with some good looking potential for speed).
The comments say it will be cross platform. Oh except windows, which is
where I actually want it (cygwin doesn’t count :).
-=r
The Russian language audience can have a look at this presenation with
benchmarks:
more papers about how it works are there:
http://code.google.com/p/libjit-linear-scan-register-allocator/downloads/list
Thanks,
Kirill
Kirill Kononenko wrote:
Take a look at this:
http://www.mail-archive.com/[email protected]/msg42700.html
for an improvement it gives.
But the point is that a benchmark is flowed by definitation - the score
it should get on an “ideal” engine is infinity. Which is non-sense. One
simply need to undestand how simply something works for his work. “A set
of all sets does not exist”Thanks,
KirillWhy everyone is that interested in benchmarks? All results that we
usually get on internet are flowed. Why not simply try use libJIT in
your task, and check how well it works for you, and then give an advice?
I can tell that for .NET it beats Mono JIT in pnetmark.Thanks,
Kirill
I hope they will consider use libJIT as an alternative.