Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Topaz: A New Ruby

docs.topazruby.com

Post reply on HN
Print view View original

71–80 of 190 posts

Re: Announcing Topaz: A New Ruby

#71

Post by draegtun »

Pewpewarrows wrote: post #10

Completely unscientific, but if these outputs are any indication, this is going to be great news for Rubby users in the future... $ time ruby -e "puts 'hello world'" hello world real 0m0.184s user 0m0.079s sys 0m0.092s $ time ~/Downloads/topaz/bin/topaz -e "puts 'hello world'" hello world real 0m0.007s user 0m0.002s sys 0m0.004s

To scratch a quick interesting thought that came into my head I just had a look at Cardinal, which is a Ruby implementation running on the Parrot VM - https://github.com/parrot/cardinal

So downloaded & built Cardinal (which went seamlessly however I did have Parrot already installed) then I did same benchmarks alongside ruby1.8 here:

  $ time ruby -e "puts 'hello world'"
  hello world
  
  real	0m0.130s
  user	0m0.049s
  sys	0m0.071s

  $ time parrot-cardinal -e "puts 'hello world'"
  hello world

  real	0m0.057s
  user	0m0.037s
  sys	0m0.019s
Very interesting because I thought Cardinal was supposed to be slow!

I think more diverse benchmarks are required. And when time permitting I might add Topaz & ruby1.9 into the mix.

Re: Announcing Topaz: A New Ruby

#72

Post by fijal »

masklinn wrote: post #58
steeve wrote: post #20

So Ruby on top of RPython on top of PyPy? Why not, but how does it compare to JRuby and Rubinius?

> So Ruby on top of RPython on top of PyPy? No. It's Ruby in RPython, where PyPy is Python in RPython. The pypy project is currently in the process of splitting "RPython" (the VM-development framework) from PyPy (the Python VM) to make that clearer. RPython is a general purpose, language-agnostic (ish?) core for implementing JIT-ed garbage-collected languages, it's kind-of similar to LLVM being a framework for implem…

RPython is generally language-agnostic, although dynamic langauges are much better suited for this sort of transformations. So it makes sense for any kind of dynamic language (like prolog even), but makes less sense for say Java or C.

Re: Announcing Topaz: A New Ruby

#73

Post by hencq »

Does Topaz benefit at all from the work that's been done already on Rubinius? I seem to recall that Rubinius implements as much of Ruby in Ruby as possible. It seems like this would help Topaz as well in implementing the standard library. Or are the implementations different enough that this doesn't work?

Re: Announcing Topaz: A New Ruby

#74

Post by Millennium »

Implementing other languages on top of the PyPy toolchain is an interesting concept, and I'd like to see it happen more often. But calling this "Ruby in Python" is sure to invite flamewars from all sides. The actual Topaz site seems to be careful not to do this, but if this thread is any indication, a fair number of people are already mistakenly calling it that.

Re: Announcing Topaz: A New Ruby

#75

Post by lost-theory »

I will be the first to ask: why did Alex / the pypy devs start this project? I thought the three community funded ideas were great (STM, Python 3, and Numpy). What prompted this new project? Is it meant to attract new developers to pypy as platform for implementing languages? Is it a side project? Is it a long term project meant to become the premium implementation of ruby as pypy is becoming for python? Etc.

Not criticizing at all by the way, just curious about the motivation / background / context for the project, which is missing from the docs.

Re: Announcing Topaz: A New Ruby

#76

Post by CanSpice »

llimllib wrote: post #49
vidarh wrote: post #34

I'm all for new Ruby implementations, but be very careful about judging performance of an incomplete implementation. It's "trivial" to make a fast language that looks quite a bit like Ruby. It is a lot harder that make a language that remains fast in the face of handling all the quirks of the full Ruby semantics, though, such as selectively handling the risk of someone going bananas with monkey-patching core classes…

1) Note that the post doesn't sell its speed; all it says is that they are interested in a high-performance Ruby 2) Python is a very similar language to Ruby, and Pypy already runs python very rapidly. This doesn't guarantee that the Ruby interpreter will be anywhere near as fast, of course, but it does give evidence that it's possible. 3) As kingkilr notes below, they've taken into account your argument and they bel…

The third paragraph reads "Out of the box Topaz is extremely fast." This is most definitely selling its speed.

Re: Announcing Topaz: A New Ruby

#77

Post by kingkilr »

lost-theory wrote: post #75

I will be the first to ask: why did Alex / the pypy devs start this project? I thought the three community funded ideas were great (STM, Python 3, and Numpy). What prompted this new project? Is it meant to attract new developers to pypy as platform for implementing languages? Is it a side project? Is it a long term project meant to become the premium implementation of ruby as pypy is becoming for python? Etc. Not cri…

Hi to be clear, this is project undetaken by me (Alex) independently, it wasn't funded out of the PyPy funds or anything like that. There were 3 primary motivations:

a) Because it's fun

b) To prove RPython is a great platform

c) To mess with people's heads, it's crazy!

Re: Announcing Topaz: A New Ruby

#78

Post by JoshTriplett »

andrewaylett wrote: post #48
eranation wrote: post #24

Earlier quoted context omitted.

Impressive, how does it compare to JRuby?

That's probably not a fair test to use on JRuby, as the JVM is notoriously slow to start.

That doesn't make it unfair to JRuby, it just means JRuby will probably lose that benchmark. :)

Re: Announcing Topaz: A New Ruby

#79

Post by kingkilr »

vidarh wrote: post #34

I'm all for new Ruby implementations, but be very careful about judging performance of an incomplete implementation. It's "trivial" to make a fast language that looks quite a bit like Ruby. It is a lot harder that make a language that remains fast in the face of handling all the quirks of the full Ruby semantics, though, such as selectively handling the risk of someone going bananas with monkey-patching core classes…

What you just wrote is exactly what I've been telling people about every new "Python" implementation for the last 3 years. Believe me, I understand this argument completely, that's why I made sure we had all the hard bits (monkey patching core classes, eval, etc.) before I released this.

Re: Announcing Topaz: A New Ruby

#80

Post by grn »

Pewpewarrows wrote: post #10

Completely unscientific, but if these outputs are any indication, this is going to be great news for Rubby users in the future... $ time ruby -e "puts 'hello world'" hello world real 0m0.184s user 0m0.079s sys 0m0.092s $ time ~/Downloads/topaz/bin/topaz -e "puts 'hello world'" hello world real 0m0.007s user 0m0.002s sys 0m0.004s

In order to eliminate the potential bias of startup time I run similar test in many iterations. Here's what I got:

    $ time ruby -e "10000.times { puts 'hello world' }" > /dev/null
    real    0m0.102s
    user    0m0.096s
    sys     0m0.005s
and

    $ time ./topaz -e "10000.times { puts 'hello world' }" > /dev/null
    real    0m0.098s
    user    0m0.071s
    sys     0m0.026s
Any idea why I don't see such big difference?
Post reply on HN