Strongtalk and Ruby
Richard
Does anyone know how suited the ruby language is to run on the
strongtalk VM? I see that the ruby community has a couple of efforts
to develop virtual machines (jruby and yarv), but I guess so far these
have not lead to much of a speed increase, and it seems that they
don't have the techniques employed in the strong talk VM. Being a
rubyist myself, I often miss being able to specify types and have the
feeling that ruby would benefit significantly having optional static
typing. Hence a second argument for wanting to target the stongtalk
VM.
One of the things that makes languages like ruby so popular is that
they make it very easy to plug into existing C libraries. This is
important because there are tones of existing C libraries out there
that are non-trivial to duplicate (.e.g. openssl library), and why
would you want to duplicate them anyway if you can produce a nice ruby/
smalltalk interface to them. The interface to the operating system is
C.
Recently there was the question of how to get more people interested
in the project in a way that they can contribute. From my perspective
I would say: more documentation, more communication. They way to get
more people up to speed is communicating the how, what and why of
strongtalk and its VM. The few documents on the wiki seem to be good
start, but there's lot more needed for people to get to the point
where they can contribute. The PDF presentations on VM design are
interesting, but without the accompanying lecture one is left without
details.
What is the situation with threads and strongtalk? Is there any chance
that strongtalk will have any more than green threads? Does it have
green threads (os runs one thread, vm jumps between green threads,
uses non-blocking io)? Green threads turned out to be really cool in
ruby:
require 'open-uri'
results = Array.new
results_mutex = Mutex.new
threads = (1..10).map do |index|
Thread.run do |thread|
result = open("http://www.google.com").read
results_mutex.synchronize { results << result }
end
end
threads.each { |thread| thread.join }
puts results.inspect
I hope you'll excuse that little example. As maybe you can tell I much
prefer that ruby syntax the smalltalk syntax, but what I'm asking is:
under the covers at the VM level is pretty much all the same? Will
inlining remove all or most of the block structures in my example?
Would my ruby code run 10 times faster on the strongtalk VM (there's a
network call in the middle of the example, so I guess I mean, use 10%
of the cpu resources, not run 10 times faster. As far as I know the
ruby interpreter doesn't do any inlining)?
Robert Shiplett
Of course you might look at the ongoing PARROT work But there are such interesting things going on with Io and Trans ( iolanguage.com and transmuter.org ). And then there is the Alice project from Mozart/Oz ...
Given that there is no good frontend to Io ( io, the language ) it would seem that Strongtalk could be a user-friendly face for Io, which is already Smalltalk friendly in so many ways.
But there is also no good interface to Oz beyond Emacs ... or no ? Could ST look to evolve in that direction?
One interesting option is to look at the backends for Mercury - Mercury is pure and has no i/o and so no useful GUI ( and since someone once said that Smalltalk developed without regard for Prolog ... ;-) Mozart sees itself as a reaction to Mercury purists ... but seems not to be as nice a fit for Strongtalk as Io, imho. The thing about Mercury and Oz is that they come from reacting to the commercial effort at adding types to Prolog ( Turbo Prolog aka PDC Visual Prolog which now has parametric polymorphism at pdc.dk ). Types for prolog was anathema to the prolog purists, performance be danged.
Of great interest to me, personally, is a marriage of XLClaire to Smalltalk/X ( WebClaire is already reaching out to offer Choco to java with Palm ).
I hope Strongtalk will appeal to those put off by Rebol and Curl having proprietary core - when I use either I immediately think of what could be done with Strongtalk ...
prunedtree
send it to nothingness...
On May 7, 5:57 am, Richard <richard.j.c...@gmail.com> wrote:
> Does anyone know how suited the ruby language is to run on the
> strongtalk VM? I see that the ruby community has a couple of efforts
> to develop virtual machines (jruby and yarv), but I guess so far these
> have not lead to much of a speed increase, and it seems that they
> don't have the techniques employed in the strong talk VM. Being a
> rubyist myself, I often miss being able to specify types and have the
> feeling that ruby would benefit significantly having optional static
> typing. Hence a second argument for wanting to target the stongtalk
> VM.
The strongtalk VM could run most ruby semantics without any problem.
Much faster.
The optional static typing has nothing to do with the VM.
> One of the things that makes languages like ruby so popular is that
> they make it very easy to plug into existing C libraries. This is
> important because there are tones of existing C libraries out there
> that are non-trivial to duplicate (.e.g. openssl library), and why
> would you want to duplicate them anyway if you can produce a nice ruby/
> smalltalk interface to them. The interface to the operating system is
> C.
The strongtalk VM supports dll calls.
>
> Recently there was the question of how to get more people interested
> in the project in a way that they can contribute. From my perspective
> I would say: more documentation, more communication. They way to get
> more people up to speed is communicating the how, what and why of
> strongtalk and its VM. The few documents on the wiki seem to be good
> start, but there's lot more needed for people to get to the point
> where they can contribute. The PDF presentations on VM design are
> interesting, but without the accompanying lecture one is left without
> details.
The best documentation is the code. You'll need to get into it sooner
or later if you want to contribute anyway.
But feel free to ask questions on this mail-list if you don't
understand something.
>
> What is the situation with threads and strongtalk? Is there any chance
> that strongtalk will have any more than green threads? Does it have
> green threads (os runs one thread, vm jumps between green threads,
> uses non-blocking io)? Green threads turned out to be really cool in
> ruby:
The strongtalk VM uses native OS threads. The VM doesn't support
preemptive scheduling (not yet) or parallelism (probably never), but
all dll calls can be nonblocking.
>
> require 'open-uri'
>
> results = Array.new
> results_mutex = Mutex.new
> threads = (1..10).map do |index|
> Thread.run do |thread|
> result = open("http://www.google.com").read
> results_mutex.synchronize { results << result }
> end
> end
> threads.each { |thread| thread.join }
> puts results.inspect
>
> I hope you'll excuse that little example. As maybe you can tell I much
> prefer that ruby syntax the smalltalk syntax, but what I'm asking is:
> under the covers at the VM level is pretty much all the same? Will
> inlining remove all or most of the block structures in my example?
All of them, it's the most trivial case (clean blocks).
> Would my ruby code run 10 times faster on the strongtalk VM (there's a
> network call in the middle of the example, so I guess I mean, use 10%
> of the cpu resources, not run 10 times faster. As far as I know the
> ruby interpreter doesn't do any inlining)?
This is a bad exemple, because cpu ressources needed are all spent in
the network libraries, not in the language doing high level calls. But
with a fast VM, you can do more than glue between libraries, yes.
On May 7, 7:56 pm, "Robert Shiplett" <grshipl...@gmail.com> wrote:
> Could io, the language, be more promising for ST than ruby ... ?
>
> Of course you might look at the ongoing PARROT work But there are such
> interesting things going on with Io and Trans ( iolanguage.com and
> transmuter.org ). And then there is the Alice project from Mozart/Oz ...
>
> Given that there is no good frontend to Io ( io, the language ) it would
> seem that Strongtalk could be a user-friendly face for Io, which is already
> Smalltalk friendly in so many ways.
>
> But there is also no good interface to Oz beyond Emacs ... or no ? Could ST
> look to evolve in that direction?
>
> One interesting option is to look at the backends for Mercury - Mercury is
> pure and has no i/o and so no useful GUI ( and since someone once said that
> Smalltalk developed without regard for Prolog ... ;-) Mozart sees itself as
> a reaction to Mercury purists ... but seems not to be as nice a fit for
> Strongtalk as Io, imho. The thing about Mercury and Oz is that they come
> from reacting to the commercial effort at adding types to Prolog ( Turbo
> Prolog aka PDC Visual Prolog which now has parametric polymorphism at
> pdc.dk). Types for prolog was anathema to the prolog purists,
> performance be
> danged.
>
> Of great interest to me, personally, is a marriage of XLClaire to Smalltalk
> /X ( WebClaire is already reaching out to offer Choco to java with Palm ).
>
> I hope Strongtalk will appeal to those put off by Rebol and Curl having
> proprietary core - when I use either I immediately think of what could be
> done with Strongtalk ...
You talk about lots of languages, but I don't understand your point or
the relationship with strongtalk.
Ted Neward
reason why this wouldn't be a match made in heaven, but I've only dabbled so
far.
Oh, and BTW, JRuby has achieved speeds better than that of the native Ruby
interpreter when running Rails apps, according to Charles Nutter.
Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.467 / Virus Database: 269.6.4/790 - Release Date: 5/5/2007
> 10:34 AM
>
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.6.5/793 - Release Date: 5/7/2007 2:55
PM
Jim Haungs
Jruby is a very naive bytecode dispatch interpreter. It generates bytecodes from the AST and then interprets those via a big case statement. It doesn't even generate Java bytecodes. It's only faster relative to the incredibly slow AST-walking interpreter.
IMHO, Ruby would never have caught on were machines not pumping so many gigahertz these days.
Ruby, especially with Rails, does so much "duck typing" and so many method_missing tricks that I wonder what percentage of a given Ruby program would actually benefit from Strongtalk runtime typing. I'm guessing we'd get much more of a performance boost out of plain old JIT technology.
Of course, this is not to say you couldn't combine the two approaches; it's just damn hard.
David Griswold
> -----Original Message-----
> From: Richard
>
> Does anyone know how suited the ruby language is to run on the
> strongtalk VM?
Search the list for past messages about Ruby. This has been discussed
before. Ruby should be an excellent target for the Strongtalk virtual
machine. However, Ruby has a very messed-up grammar, which makes it hard to
write a new parser for it.
> I see that the ruby community has a couple of efforts
> to develop virtual machines (jruby and yarv), but I guess so far these
> have not lead to much of a speed increase, and it seems that they
> don't have the techniques employed in the strong talk VM. Being a
> rubyist myself, I often miss being able to specify types and have the
> feeling that ruby would benefit significantly having optional static
> typing. Hence a second argument for wanting to target the stongtalk
> VM.
Strongtalk's type system has nothing to do with the virtual machine.
Porting Ruby to the Strongtalk VM would not give Ruby a type system.
> [...]
>
> What is the situation with threads and strongtalk? Is there any chance
> that strongtalk will have any more than green threads? Does it have
> green threads (os runs one thread, vm jumps between green threads,
> uses non-blocking io)?
Strongtalk does not use green threads. It uses native threads. However
only one thread is allowed to run at a time, since the VM is not
multithreaded. However, use of native threads means that Strongtalk can
easily do blocking I/O. Callouts can be designated as asynchronous, meaning
that other Smalltalk threads can be allowed to proceed while that callout
executes or blocks.
> I hope you'll excuse that little example. As maybe you can tell I much
> prefer that ruby syntax the smalltalk syntax, but what I'm asking is:
> under the covers at the VM level is pretty much all the same? Will
> inlining remove all or most of the block structures in my example?
> Would my ruby code run 10 times faster on the strongtalk VM (there's a
> network call in the middle of the example, so I guess I mean, use 10%
> of the cpu resources, not run 10 times faster. As far as I know the
> ruby interpreter doesn't do any inlining)?
Current Ruby VMs are very, very slow compared to Strongtalk, so the speedup
would probably be a lot more than a factor of 10. Strongtalk is more than
10 times as fast as Squeak, which is itself faster than Ruby, I believe.
Yes, inlining should probably remove all the blocks in your example;
generally, any block that is only passed downwards as a literal argument to
sends that are themselves inlined, will be inlined.
-Dave
Xue Yong Zhi
Search the list for past messages about Ruby. This has been discussed
before. Ruby should be an excellent target for the Strongtalk virtual
machine. However, Ruby has a very messed-up grammar, which makes it hard to
write a new parser for it.
This summer Google will fund a student to work on Ruby parser wiht ANTLR:
http://www.infoq.com/news/2007/04/gsoc-series-wang-haofei
We will try our best to provide an easy-to-maintain parser so that people can build better tools above it.
I am very interested in running ruby on strongtalk and will do more research on it.