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
I don't know anyhting about the details, but isn't MacRuby also heading to LLVM?
-greg
···
On Fri, Apr 10, 2009 at 7:33 AM, Daniel Berger <djberg96@gmail.com> wrote:
Python on LLVM. Thought it might be interesting to some folks here:
Google searches for holy grail of Python performance | Ars Technica
Daniel Berger 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!
···
--
Posted via http://www.ruby-forum.com/\.
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 Friday 10 April 2009 09:32:01 Gregory Brown wrote:
On Fri, Apr 10, 2009 at 7:33 AM, Daniel Berger <djberg96@gmail.com> 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?
Hmm. Looks somewhat like Python psyco. Except psyco boasted to boost
python performance by only 4x, not 5
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.
···
On Fri, Apr 10, 2009 at 12:28 PM, Roger Pack <rogerpack2005@gmail.com>wrote:
--
Tony Arcieri
medioh.com
Gregory Brown 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
···
--
Posted via http://www.ruby-forum.com/\.
Tony Arcieri 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
I hope they will consider use libJIT as an alternative.
···
--
Posted via http://www.ruby-forum.com/.
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/
···
--
Posted via http://www.ruby-forum.com/\.
Roger Pack 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
···
--
Posted via http://www.ruby-forum.com/\.
Hi
I suggest everyone use libJIT instead of LLVM. See
http://code.google.com/p/libjit-linear-scan-register-allocator/ 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
···
--
Posted via http://www.ruby-forum.com/.
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
···
--
Posted via http://www.ruby-forum.com/\.
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 Pack 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
--
Posted via http://www.ruby-forum.com/\.
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
···
--
Posted via http://www.ruby-forum.com/.
Take a look at this:
http://www.mail-archive.com/gcc@gcc.gnu.org/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
--
Posted via http://www.ruby-forum.com/\.
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:
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
--
Posted via http://www.ruby-forum.com/\.