141–150 of 190 posts
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?
Earlier quoted context omitted.
Significant whitespace in Python was a significant factor in my decision to get proficient in Ruby over Python. Yes, I hate it that much, and I know quite a few Ruby devs with similar views...
Here's how I look at it: I indent my code properly and my team does the same. If we're already doing the right thing where whitespace is concerned, why not reap some benefits from it? Of course, I also use Coffeescript and Haml...
I'm curious: why not use Python then as well?
I'm probably in the minority but I would love to see a dialect of ruby that has significant whitespace. Death to unnecessary 'end's
Earlier quoted context omitted.
Here's how I look at it: I indent my code properly and my team does the same. If we're already doing the right thing where whitespace is concerned, why not reap some benefits from it? Of course, I also use Coffeescript and Haml...
Of course, I also use Coffeescript and Haml... I'm curious: why not use Python then as well?
Earlier quoted context omitted.
That doesn't make it unfair to JRuby, it just means JRuby will probably lose that benchmark. :)
If the goal is to benchmark Ruby execution time, it's unfair. The slow startup time is a valid concern when considering short-lived sessions, but it's kind of meaningless when trying to benchmark a Ruby implementation.
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?
Earlier quoted context omitted.
There are no 'fair' benchmarks, all benchmarks should be biased to the problem you're actually solving running your actual workload. If you can't replay your workload at multiples of real volume then you should probably work on doing that before benchmarking as it helps you out with the real problem of verifying your infrastructure. In general a benchmark is probably the worst metric you could ever use for deciding o…
I don't even know where to begin with this. In all comparisons, you should remove confounding variables. Yes, you should benchmark something you actually care about, otherwise what's the point? That doesn't mean all other variables are immediately null and void. That's why I said said if your goal is to measure ruby execution time, you should remove startup time. As for the practice of benchmarking in general, you're…
Earlier quoted context omitted.
I don't even know where to begin with this. In all comparisons, you should remove confounding variables. Yes, you should benchmark something you actually care about, otherwise what's the point? That doesn't mean all other variables are immediately null and void. That's why I said said if your goal is to measure ruby execution time, you should remove startup time. As for the practice of benchmarking in general, you're…
The issue is that, to some, "ruby execution time" may include the startup time.
Forgive me for asking what may be a very stupid question: Can someone explain to me the need for a Ruby interpreter built on top of Python? He mentions performance in the announcement, but is this really going to be faster than, say, MRI? Thanks in advance.
Think of Pypy as somewhat like LLVM, except the language it's built on is a subset of the python language, called RPython. Although the most well-known language implemented in the pypy "vm" is python, the toolchain is completely language agnostic. So, this is more akin to Apple writing a C interpreter on top of llvm than it is to building a ruby interpreter on top of python.