Seven new VMs, all in a row

[Bill Guindon]

I'm very skeptical about the 30x faster claim.

I might be skeptical, but if I voice my skepticism loud enough, I may
discourage those who might try (and may succeed).

So yeah... I think that 30x faster is quite possible ;-)

 

[vruz]

OTOH, if it is 30x faster and makes an alternate implementation of socket

I'm very skeptical about the 30x faster claim.

Phil

For what I've seen, reusing something like the Mono native backend
(available for major processor architectures) can yield even higher
performance gains.
A custom tailored VM in assembler can provide 100x and possibly more
depending on the architecture.

30x actually looks very conservative to me, but may well be worth the
effort to reuse an already existing codebase.

 

[Phil Tomson]

I might be skeptical, but if I voice my skepticism loud enough, I may
discourage those who might try (and may succeed).

So yeah... I think that 30x faster is quite possible ;-)

Please, prove my skepticism to be wrong. A Ruby that was 30x faster (on
the same hardware) would be great. As I said in the other post
responding to Avi, if it's possible to speed things up that much with a
SmallTalk VM, maybe we should be studying said VM to figure out how to
make it happen in YARV (since matz has recently said that YARV is the
future VM for Ruby).

Phil

 

[Isaac Gouy]

This "20x to 30x speed increase" stuff is interesting. I would have
thought it would be closer to something like 5x.

More than 5x
http://www.lissett.com/ben/

 

[Bill Guindon]

Please, prove my skepticism to be wrong.

I leave that job to Peter, my job is to encourage him to try.

A Ruby that was 30x faster (on
the same hardware) would be great. As I said in the other post
responding to Avi, if it's possible to speed things up that much with a
SmallTalk VM, maybe we should be studying said VM to figure out how to
make it happen in YARV (since matz has recently said that YARV is the
future VM for Ruby).

Agreed, and I hope Peter considers that, but if he's hell bent on
building one on top of a SmallTalk VM, then I say go right ahead, and
if it works, we can dissect that later.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Seven new VMs, all in a row"
on Fri, 8 Apr 2005 13:19:41 +0900, (e-mail address removed) (Phil Tomson) writes:

|Please, prove my skepticism to be wrong. A Ruby that was 30x faster (on
|the same hardware) would be great. As I said in the other post
|responding to Avi, if it's possible to speed things up that much with a
|SmallTalk VM, maybe we should be studying said VM to figure out how to
|make it happen in YARV (since matz has recently said that YARV is the
|future VM for Ruby).

It's not impossible to make Ruby run 30x faster for some tasks, for
example, YARV runs more than 100x faster in some small benchmarks.
But I'm not sure if it's possible to make it 30x faster in average.

matz.

 

[Bill Guindon]

Hi,

In message "Re: Seven new VMs, all in a row"
on Fri, 8 Apr 2005 13:19:41 +0900, (e-mail address removed) (Phil Tomson) writes:

|Please, prove my skepticism to be wrong. A Ruby that was 30x faster (on
|the same hardware) would be great. As I said in the other post
|responding to Avi, if it's possible to speed things up that much with a
|SmallTalk VM, maybe we should be studying said VM to figure out how to
|make it happen in YARV (since matz has recently said that YARV is the
|future VM for Ruby).

It's not impossible to make Ruby run 30x faster for some tasks, for
example, YARV runs more than 100x faster in some small benchmarks.
But I'm not sure if it's possible to make it 30x faster in average.

Yes, and my point is that there's a fine line between "I'm not sure if
it's possible" and "I doubt it's possible". One challenges, the other
discourages. Btw, I admire that you're not sure, and if you aren't
sure, how can anyone else be sure until it's tried?

Not knowing if it's possible, if Peter wants to try, we should
encourage it. If he's right, and we're wrong, and we convince him not
to try, we all lose. If he's wrong, what has he wasted but his own
time? He's not on my payroll, so try he should! If he were on my
payroll, I might think differently ;-)

Here's the way I see it, in Ruby...

class Person
def initialize
srand Time.now.to_i
@wants = (rand(24) + 64).chr
end

# what a person wants is (somewhat) read only, and fairly random.
def wants
"Wants: " + @wants
end

# what a person works on is usually the same as what they want.
def works_on
"Works on: " + @wants
end
end

p = Person.new
puts p.wants
puts p.works_on

p.wants = "Z"

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Seven new VMs, all in a row"

|Yes, and my point is that there's a fine line between "I'm not sure if
|it's possible" and "I doubt it's possible". One challenges, the other
|discourages. Btw, I admire that you're not sure, and if you aren't
|sure, how can anyone else be sure until it's tried?

I take your point. I don't want to discourage anyone.
The world is before you, Peter, to be proved to be wrong.

matz.

 

[Lothar Scholz]

Hello Eric,

EH> On 07 Apr 2005, at 14:32, Lothar Scholz wrote:

EH> Wow, could you possibly be more negative?

Yes, but i don't think i was very negative. Its just the observation
that some of the most important parts of ruby are not written in ruby
and must be manually convert (Basic library, GUI Bindings, etc.)
The easy creation of binary extensions is a very important point for
me and the reason why i switched from TCL to Ruby.

EH> This kind of dismissive overlording behavior does not reflect the usual
EH> spirit of acceptance and togetherness found on this list, especially
EH> since so many projects of the same spirit are in progress at the same
EH> time (YARV, Rubidium, JRuby, MetaRuby and a few less-publicized ones).

The great number of projects which tries to do this and never come up with
anything useable yet (except JRuby which is an interpreter rewrite
in Java and does not belong to this list) should give anybody
a break to think about the problems a little bit more.

EH> This is a time for offering constructive criticism and helpful insight
EH> into the difficult problems ahead, not a time to say things are
EH> impossible!

I think it's extremely hard to do this task. And that's why i asked if
this is his Ph.D. to see if he has the huge amount of time to get this
up and running. And i did a google search and found only 5 postings from
Peter Suk since 2.Okt 2002 on this mailing list and some other
information - like that he did a port of the Smalltalk refactoring
browser. So it seems to be okay that i'm a little bit suspicious if
this is one of the many ruby newbie ideas that we see here every few
weeks or if we can start serious discussions.

I wish him good luck for this project and hope he is successful.
I'm sure i will try it out and offer constructive criticism in a later
stage of the project.

 

[Lothar Scholz]

Hello vruz,

v> For what I've seen, reusing something like the Mono native backend
v> (available for major processor architectures) can yield even higher
v> performance gains.
v> A custom tailored VM in assembler can provide 100x and possibly more
v> depending on the architecture.

No. You simply forget that the Mono/.NET VM's are optimized for static
typed languages and they compile a frontend language into a classic
3 register instruction machine, not a stack based machine like JAVA
giving much more chance for optimizations.
There i don't see a problem for such high performance boosts.

But if we can't come up with a type inference machine, the theoretical
improvements (and thats what is done by YARV or Parot) are far from
that. If you are willing to spend a huge amount of memory you can go
the python way and keep multiple compiled versions (based on
differently use types) of small code fragments translated.

In 1995 i've written an emacs lisp compatible interpreter and it was
easy to get 8x more speed then the current one with program flow
optimizations (a FORTH like direct threaded interpreter) and together with
integration of the Boehm-Weisser GC and more optimizations i think it's easy
to get even a 20x improvement (especially on Ruby where the implementation
is not very sophisticated).

We can use techniques like Eiffel's system wide optimizations to get the
cost of a method call down to a "call 0x05346403" in most cases, so with
elimination of a VMT we can be even faster then C++.

But then we still need cascaded "if (argument = TYPE(Integer)) x += VALUE(argument)".

 

[Lothar Scholz]

Hello Yukihiro,

YM> It's not impossible to make Ruby run 30x faster for some tasks, for
YM> example, YARV runs more than 100x faster in some small benchmarks.
YM> But I'm not sure if it's possible to make it 30x faster in average.

Since Smalltalk has only very few binary implemented functions i think
we should set the benchmark at something like the REXML parser which
does a lot of pure ruby processing.

And yes i think for tasks like this it is possible to get 30x faster,
but i think it might even be possible for YARV to get 20x faster.

 

[Peter Suk]

This "20x to 30x speed increase" stuff is interesting. I would have
thought it would be closer to something like 5x. Can anyone elaborate
on
how those increases are being acheived in the SmallTalk VMs? I'm
wondering
if it might also be worthwhile to incorporate some of these ideas into
YARV -
parhaps that would get us to high-speed Ruby even faster than trying to
put Ruby on top of a SmallTalk VM?

Phil,

30X speed increase is for "Real World Applications" and is highly
dependent on Garbage Collection. I have seen many dozens of Smalltalk
business programs in my time as a consultant. One of the things they
do a lot of is create objects and garbage collect them. In fact,
memory management is probably the biggest single factor that comes up
in the performance of business apps after IO and DB access.

The Generational GC in VisualWorks is truly fantastic. I can sit
around all day with an infinite loop that allocates copies of some
random string like "Doo-Dah, Doo-Dah, All the live long day" running in
the Smalltalk image I am developing in, and there's no obvious effect.
(Yes, I did this earlier this week!) I can crank up this loop until it
is producing a billion new objects in several minutes, and my image is
fine, until I try to do something serious like have the Refactoring
Browser rename all implementors of the method #add: in the image, and
even then, it;s fine, it just does it slowly.

Another thing you should know in terms of anecdotes. A fellow
Smalltalker implemented a bunch of Encryption algorithms a few years
back in VisualWorks Smalltalk. (So we're talking lots of low-level bit
& byte slewing.) He benchmarked them against the reference DLLs from
RSA Data Security, which were written in C. The Smalltalk algorithms
ran at a comparable speed. One of them ran 3% faster! Again, this was
partly due to memory management. The DLLs naively malloc'd & free'd
everything immediately, while the Generational GC in Smalltalk provided
what amounted to a buffer cache optimization for free! (The other part
was he had our VM guys implement some bit & byte slewing primitive
ops.)

And lastly, please remember that VisualWorks and most of the commercial
Smalltalk implementations are actually JIT compilers. Most of the
time, we're running native machine language instructions.

If YARV out does Smalltalk VMs for speed of Ruby execution, then all
the better. The competitive pressure will ultimately be good for the
Ruby community. We'll just settle for providing all of the other great
benefits I've mentioned. (Like the fastest Ruby-In-Ruby!)

--Peter

 

[Peter Suk]

Agreed, and I hope Peter considers that, but if he's hell bent on
building one on top of a SmallTalk VM, then I say go right ahead, and
if it works, we can dissect that later.

Bill,

I'm not *building* a Ruby VM on top of a Smalltalk VM. The Smalltalk
VM will be allocating Objects and JIT-ing bytecodes natively. There is
almost no Smalltalk in the Smalltalk VMs, and what semantics there are
are a very good fit for Ruby anyhow. All I'm doing is providing enough
meta-Ruby to enable the Smalltalk VMs to run Ruby (including a Ruby
compiler written in Ruby).

(But this language defined in itself is a weird concept to most
programmers, and I'll probably go blue in the face repeating this.)

--Peter

 

[Lothar Scholz]

Hello Peter,


PS> I'm not *building* a Ruby VM on top of a Smalltalk VM. The Smalltalk
PS> VM will be allocating Objects and JIT-ing bytecodes natively. There is
PS> almost no Smalltalk in the Smalltalk VMs, and what semantics there are
PS> are a very good fit for Ruby anyhow. All I'm doing is providing enough
PS> meta-Ruby to enable the Smalltalk VMs to run Ruby (including a Ruby
PS> compiler written in Ruby).

Is there a public available technical specification for the VM ?

 

[why the lucky stiff]

I take your point. I don't want to discourage anyone.
The world is before you, Peter, to be proved to be wrong.

matz.

I feel impossibly good right now. Go now, Peter the young-breasted.
Defeat is an accomplishment not even the best of us could achieve.

_why

 

[Jonas Hartmann]

Hello Peter, hello List,


Slightly OT: Does Python ship with a JIT or JIT option?

Personally I always wondered why interpreted languages dont ship with any kind of JIT.
From a newbies point of view I understood this, before you mentioned the JIT, like the idea to take the ruby language and put it onto a very fast, general purpose VM, instead of using its own interpreter, which might be great but maybe not so fast.
If that's the point, then its a great thing - as long as security and features are kept more speed is always better.

[...]
Ruby will be
running on top of a Just-In-Time compiler, translating the bytecodes
into native machine instructions. The VisualWorks JIT has been in
development since 1989, so is one of the most mature JIT interpreters
around. Its speed rivals Hotspot in real-world situations where GC is
significant. Object allocation will be native -- Objects will just be
Objects to the VM/garbage collector, with the Ruby/Smalltalk
implementation language being moot.
[...]
No. I want to make the world safe for Pure-OO. A way I can help
Pure-OO development is to vastly increase the power of the Ruby
community by giving it access to the great technology developed for
Smalltalk.

The Smalltalk MT environment can produce native Windows DLLs that are
indistinguishable from C++ DLLs. We would theoretically be able to do
the same for Ruby when we can host Ruby on that VM.
[...]

 

[George]

I'm not *building* a Ruby VM on top of a Smalltalk VM. The Smalltalk

VM will be allocating Objects and JIT-ing bytecodes natively. There is
almost no Smalltalk in the Smalltalk VMs, and what semantics there are
are a very good fit for Ruby anyhow. All I'm doing is providing enough
meta-Ruby to enable the Smalltalk VMs to run Ruby (including a Ruby
compiler written in Ruby).

I'm curious - how good a fit are Ruby semantics for Smalltalk VMs? Do
Smalltalk VMs/bytecode provide the following Ruby facilities, and, if
not, how easily can they be emulated?

- blocks (with Ruby semantics in case they're different from
Smalltalk's)
- mixins
- instance variables that don't need to be predeclared with the class
- class variables & constants
- throw/catch
- exceptions
- continuations
- support for OS facilities like select, signals etc

Too great a mismatch between Ruby and Smalltalk semantics will mean
that an emulation layer will be needed, which will presumably reduce
the performance gains. Of course, I hope that's not true! Good luck
with the project.

-- George

 

[gabriele renzi]

Phil Tomson ha scritto:

I'm very skeptical about the 30x faster claim.

well, take a look at the OO Richards Benchmark
http://pws.prserv.net/dlissett/ben/
the VW vms is something like 70x faster than ruby, so if not too much is
wasted in the layering, there is still a fast vm.
IIRC there is also someone working on a python port on top of VW, which
should be quite fast.

(btw, remember the usual "lies, damn lies & benchmarks"

 

[gabriele renzi]

vruz ha scritto:

For what I've seen, reusing something like the Mono native backend
(available for major processor architectures) can yield even higher
performance gains.

I disagree. The IronPython implementation, on mono/x86 runs just 1.2
times faster than CPython.
On PPC IronPyrthon/mono runs even slower than the real CPython.
Surely there are still work to do, but I guess those "the clr is not
great for dynamic languages" claims may be true (I still think you may
found value in using it for interoperability)

 

[Lothar Scholz]

Hello George,

G> I'm curious - how good a fit are Ruby semantics for Smalltalk VMs? Do
G> Smalltalk VMs/bytecode provide the following Ruby facilities, and, if
G> not, how easily can they be emulated?

I would like to add

- singleton methods

to this list as i think this does not exist in SmallTalk, and this is
a feature that could knock out the whole method compilation algorithm.