[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

[OT] Python on LLVM

Daniel Berger

4/10/2009 11:34:00 AM

Python on LLVM. Thought it might be interesting to some folks here:

http://arstechnica.com/open-source/news/2009/03/google-launches-project-to-boost-python-performance...

On a related note, regarding Perl, LLVM and performance:

http://use.perl.org/~Matts/jou...

Regards,

Dan
16 Answers

Gregory Brown

4/10/2009 2:32:00 PM

0

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:
>
> http://arstechnica.com/open-source/news/2009/03/google-launches-project-to-boost-python-performance...

I don't know anyhting about the details, but isn't MacRuby also heading to LLVM?

-greg

David Masover

4/10/2009 3:38:00 PM

0

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:
> >
> > http://arstechnica.com/open-source/news/2009/03/google-launches...
> >o-boost-python-performance-by-5x.ars
>
> I 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.

Roger Pack

4/10/2009 6:29:00 PM

0

Daniel Berger wrote:
> Python on LLVM. Thought it might be interesting to some folks here:
>
> http://arstechnica.com/open-source/news/2009/03/google-launches-project-to-boost-python-performance...

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] http://www.ruby-...to...

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

Tony Arcieri

4/10/2009 6:34:00 PM

0

[Note: parts of this message were removed to make it a legal post.]

On Fri, Apr 10, 2009 at 12:28 PM, Roger Pack <rogerpack2005@gmail.com>wrote:

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

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.

--
Tony Arcieri
medioh.com

Charles Oliver Nutter

4/10/2009 8:29:00 PM

0

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

Roger Pack

4/11/2009 4:28:00 AM

0


> 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-f...
--
Posted via http://www.ruby-....

Charles Oliver Nutter

4/11/2009 6:23:00 AM

0

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

Roger Pack

4/11/2009 6:39:00 AM

0

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

Kirill Kononenko

4/17/2009 8:26:00 AM

0

Hi


I suggest everyone use libJIT instead of LLVM. See
http://code.google.com/p/libjit-linear-scan-register-... 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/0...

and here
http://lists.gnu.org/archive/html/dotgnu-libjit/2004-05/...


Thanks,
Kirill
--
Posted via http://www.ruby-....

Roger Pack

4/17/2009 3:05:00 PM

0


> I suggest everyone use libJIT instead of LLVM. See
> http://code.google.com/p/libjit-linear-scan-register-... 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-....