Forum: Ruby Python on LLVM

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Aee77dba395ece0a04c688b05b07cd63?d=identicon&s=25 Daniel Berger (djberg96)
on 2009-04-10 13:34
(Received via mailing list)
Python on LLVM. Thought it might be interesting to some folks here:

http://arstechnica.com/open-source/news/2009/03/go...

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

http://use.perl.org/~Matts/journal/38786

Regards,

Dan
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-04-10 16:34
(Received via mailing list)
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/go...

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

-greg
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-04-10 17:41
(Received via mailing list)
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/go...
> >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.
Bec38d63650c8912b6ba9b557fb953b9?d=identicon&s=25 Roger Pack (rogerdpack)
on 2009-04-10 20:28
Daniel Berger wrote:
> Python on LLVM. Thought it might be interesting to some folks here:
>
> 
http://arstechnica.com/open-source/news/2009/03/go...

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-forum.com/topic/182852

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!
2f55791ab9018b4d01fb741fab21843d?d=identicon&s=25 Tony Arcieri (Guest)
on 2009-04-10 20:34
(Received via mailing list)
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.
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-04-10 22:29
(Received via mailing list)
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
Bec38d63650c8912b6ba9b557fb953b9?d=identicon&s=25 Roger Pack (rogerdpack)
on 2009-04-11 06:28
> 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-t...
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-04-11 08:23
(Received via mailing list)
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
Bec38d63650c8912b6ba9b557fb953b9?d=identicon&s=25 Roger Pack (rogerdpack)
on 2009-04-11 08:38
> 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
7414d86492d3ffad0feb5755ceb239f9?d=identicon&s=25 Kirill Kononenko (krokas)
on 2009-04-17 10:25
Hi


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

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


Thanks,
Kirill
Bec38d63650c8912b6ba9b557fb953b9?d=identicon&s=25 Roger Pack (rogerdpack)
on 2009-04-17 17:04
> I suggest everyone use libJIT instead of LLVM. See
> http://code.google.com/p/libjit-linear-scan-regist... for how
> much libJIT is better than LLVM overkill.

Nice to know that libjit is moving forward.  Any benchmarks? :)
-=r
7414d86492d3ffad0feb5755ceb239f9?d=identicon&s=25 Kirill Kononenko (krokas)
on 2009-04-17 17:13
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
>> http://code.google.com/p/libjit-linear-scan-regist... for how
>> much libJIT is better than LLVM overkill.
>
> Nice to know that libjit is moving forward.  Any benchmarks? :)
> -=r
7414d86492d3ffad0feb5755ceb239f9?d=identicon&s=25 Kirill Kononenko (krokas)
on 2009-04-17 17:13
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
7414d86492d3ffad0feb5755ceb239f9?d=identicon&s=25 Kirill Kononenko (krokas)
on 2009-04-17 17:19


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
7414d86492d3ffad0feb5755ceb239f9?d=identicon&s=25 Kirill Kononenko (krokas)
on 2009-04-17 17:24
The Russian language audience can have a look at this presenation with
benchmarks:

http://libjit-linear-scan-register-allocator.googl...

more papers about how it works are there:

http://code.google.com/p/libjit-linear-scan-regist...


Thanks,
Kirill


Kirill Kononenko wrote:
>
>
>
> 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
Bec38d63650c8912b6ba9b557fb953b9?d=identicon&s=25 Roger Pack (rogerdpack)
on 2009-04-21 17:19
Gregory Brown wrote:
...
>> Python on LLVM. Thought it might be interesting to some folks here:
>>
>> 
http://arstechnica.com/open-source/news/2009/03/go...
>
> 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).

http://antoniocangiano.com/2009/03/29/why-macruby-matters/
The comments say it will be cross platform.  Oh except windows, which is
where I actually want it (cygwin doesn't count :).

-=r
7414d86492d3ffad0feb5755ceb239f9?d=identicon&s=25 Kirill Kononenko (krokas)
on 2009-04-22 09:28
I hope they will consider use libJIT as an alternative.
This topic is locked and can not be replied to.