Right, but that’s not tossing the interpreter–you’re just
substituting one for another. (Which isn’t to say that there’s no
advantage to Parrot, of course…
···
At 9:22 AM +0900 7/21/02, Phil Tomson wrote:
In article <a05111b13b95f91899af1@[63.120.19.221]>,
Dan Sugalski dan@sidhe.org wrote:
At 6:04 PM -0400 7/20/02, Brad Cox wrote:
At 5:45 AM +0900 7/21/02, Dan Sugalski wrote:
I was looking at the translator aspect, translating Ruby to
Objective-C. That was the part that was the real non-starter,
courtesy of continuations. (I’ve got a paper or two kicking around
about some of the interesting things that the Scheme folks had to
do to get continuations going with what’s essentially a C
environment. It’s… interesting)
If I might throw out a suggestion, if its not broke, don’t fix it.
Ruby’s written in C so its ALREADY written in Objective-C. Leave
that alone.
I’d agree. If folks want to toss the interpreter, you might as well
go all out and generate machine code directly. It turns out not to be
nearly as tricky to do semi-portably as most people think. (Well, at
least as much as I thought)
OR, target Parrot which we certainly hope will offer some speed ehancement
over the current Ruby implementation…
–
Dan
--------------------------------------“it’s like this”-------------------
Dan Sugalski even samurai dan@sidhe.org have teddy bears and even
teddy bears get drunk
Thanks, they are really helpful. And I'd like to ask a simple question if
you don't mind. How to use Objectspace to find it?
Be carefull, because this was one of my first scripts in ruby and fatally
actually it look very strange for me :-))
First you just ObjectSpace#Each_object to store the classes in a Hash
ObjectSpace.each_object do |object|
if object.kind_of? Class
anc = object.ancestors
anc.shift
parent = nil
mods =
anc.each do |c|
if c.kind_of? Class
parent = c if ! parent
else
mods << c
end
end
$class[parent] ||=
$class[parent] << [object, mods]
end
end
Then you display the Hash :
def affiche(val, level, modu, prev)
print " " * level
newm = modu - prev
mod = if newm.empty?
""
else
"\t(#{newm.join(' ')})"
end
puts "* #{val}#{mod}"
if $class[val]
$class[val].collect { |a| [a, a[0].to_s.upcase] }.
sort {|a, b| a[1] <=> b[1] }.
each do |a, |
affiche(a[0], level + 1, a[1], modu)
end
end
end
Compiling Ruby to C is a non-starter as far as I’m concerned.
Compiling Ruby to bytecodes (ala Parrot) makes a lot more sense to me.
Or for that matter, compile it to Smalltalk, Squeak (or even Java??).
That way you get Peter Deutch’s work on on-the-fly bytecode
optimization, which will bring you about as close as you can get to
C’s speed in a non-stack-based language.
···
At 8:09 AM +0900 7/21/02, Dan Sugalski wrote:
Speed, mainly. Going from an interpreted to a compiled form gives a
number of opportunities to remove overhead. Walking optrees has some
expense involved–depending on how complex the operation is, how
much optimization you do, and the CPU architecture, you can see a
speedup somewhere between 1.1 and 40 times going compiled.
Speed, mainly. Going from an interpreted to a compiled form gives a
number of opportunities to remove overhead. Walking optrees has
some expense involved–depending on how complex the operation is,
how much optimization you do, and the CPU architecture, you can see
a speedup somewhere between 1.1 and 40 times going compiled.
Compiling Ruby to C is a non-starter as far as I’m concerned.
Compiling Ruby to bytecodes (ala Parrot) makes a lot more sense to
me.
I agree on both points. (Though I admit to some substantial bias on
the second) The only real reason to go to C is if someone’s looking
to prototype a direct-to-assembly conversion, though I don’t think
it’s a particularly good one. Probably better to target MIX or
something like that if someone really wanted. (C’s ubiquity’s one of
the few things in its favor)
Still, cutting out the interpreter loop has a not insignificant win,
and boring mechanical translations to C do have even more, though
there’s still the cost of maintaining the language-specific stacks
and structures. (We’ve a straightforward bytecode->C translator that
does a plain substitution of the C source for opcodes we play with
occasionally for Parrot–letting C’s optimizer chew on the resulting
source gets a remarkably big win)
Or for that matter, compile it to Smalltalk, Squeak (or even
Java??). That way you get Peter Deutch’s work on on-the-fly bytecode
optimization, which will bring you about as close as you can get to
C’s speed in a non-stack-based language.
Or Scheme–shouldn’t forget Scheme as there’s been some interesting
work on optimizing Scheme JITs, though Scheme and Lisp both feel like
they do things backwards, and optimizing them’s rather tricky. I’ve
been hearing about some interesting research in on-the-fly
optimization of both bytecode and native machine code, though the
references I’ve come across have been a bit sketchy.
Sort of a pity there’s not much hardware support for the sorts of
things that make the more dynamic languages interesting. (I’d be thrilled if there was some way to tie into a system’s MMU and page
fault mechanisms to use real hardware COW and page protection for
stack and lexical frames)
···
At 8:41 AM +0900 7/21/02, Brad Cox wrote:
At 8:09 AM +0900 7/21/02, Dan Sugalski wrote:
–
Dan
--------------------------------------“it’s like this”-------------------
Dan Sugalski even samurai dan@sidhe.org have teddy bears and even
teddy bears get drunk
