Sounds really interesting, but we already have a dozen of incomplete alternative Ruby implementations...
Announcing Topaz: A New Ruby
151–160 of 190 posts
Re: Announcing Topaz: A New Ruby
#152Earlier quoted context omitted.
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?
what is your 'ruby'?
Good question. How many shells is rbenv/rvm executing? Do you get similar results with an absolute path?
Re: Announcing Topaz: A New Ruby
#153Earlier 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…
Amdahl's law disagrees -- the value to improving the non-DB part is limited.
Re: Announcing Topaz: A New Ruby
#154Earlier quoted context omitted.
Of course, I also use Coffeescript and Haml... I'm curious: why not use Python then as well?
He's saying that him and his team indent their code correctly anyway, so it might as well be significant
I'm asking if someone wants a language like Ruby but with significant white-space why not use Python?
Re: Announcing Topaz: A New Ruby
#155Earlier quoted context omitted.
Whenever I see frontpages for these kinds of projects like "a faster X" or "X written in Blub", the first thing I want to see on the frontpage is how this new project compares to X in terms of quality and performance. Even specious benchmarks would help more than zero benchmarks. I wish more frontpages for these kinds of projects would do that.
spe·cious /ˈspēSHəs/ Adjective Superficially plausible, but actually wrong: "a specious argument". Misleading in appearance, esp. misleadingly attractive: "a specious appearance of novelty". So you are saying you would prefer wrong information?
http://www.merriam-webster.com/dictionary/specious
1 obsolete : showy 2: having deceptive attraction or allure 3: having a false look of truth or genuineness : sophistic
So instead of taking the common meaning of specious, a deceptively attractive benchmark we have to go to a less common use of specious in order to construct an specious argument about the proper use of specious? Nevermind that it is distracting from the main point of the discussion about benchmarks in the context of Topaz.
Re: Announcing Topaz: A New Ruby
#156Could this lead to a runtime in which I can use really cool ruby modules from python and really cool python modules from ruby? I mean, seriously, these two languages both have some pretty awesome stuff, and regularly I say about one, "man I sure wish I could use $module from the other".
Re: Announcing Topaz: A New Ruby
#157I'm probably in the minority but I would love to see a dialect of ruby that has significant whitespace. Death to unnecessary 'end's
> Some observers objected to Go's C-like block structure with braces, preferring the use of spaces for indentation, such as used in Python or Haskell [braces are optional in haskell]. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken…
This.
Especially when writing a code generator. Targeting a significant whitespace language is potentially more tricky than one with explicit delimiters. I love the Haskell approach to this.
Re: Announcing Topaz: A New Ruby
#158Earlier 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…
Amdahl's law disagrees -- the value to improving the non-DB part is limited.
I'm not trying to be snarky here, but that would advocate for no improvements anywhere else. Why did Ruby 1.9 bother with a new VM? Why try to improve GC? Why bother with invokedynamic? Why speed up JSON parsing? Why bother with speeding up YAML? Yet there's obviously value in improving all these areas and they speed up almost every Ruby app.
It's overly simplistic to say the only option is to cache everything. Or that your DB is going to be your ultimate bottleneck, so the other N - 1 items are worth investigating.
And even in the link you supplied, the illustrative example is getting a 20 hour process down to 1 hour without speeding up the single task that takes 1 hour. It suggests there's an upper limit, not that because there is an upper limit you can't possibly do better than the status quo.
Re: Announcing Topaz: A New Ruby
#159Earlier quoted context omitted.
I find it interesting that reducing your EC2 usage by 50% decreased your expenses by 50%, it means one of two things, you aren't paying your employees and don't have any overhead, or the cost of EC2 dwarfs the cost of your employees and overhead. If it's the latter, I'd seriously consider colo as you can probably reduce costs by another 80%.
Obviously the discussion was scoped around non-personnel expenses. I'm not going to dump an entire P&L here. And this is now wildly off-tangent. I was illustrating that there is real world gain to be had by doing something as simple as switching to a new Ruby or spending some time with a profiler. These weren't drastic code rewrites. They didn't require layers of caching or sharding of my database. I fail to see what…
As long as it can reasonably expected to be mostly bug free and support everything you need it to with little changes to the app. It wouldn't need to require to much time playing around with it before the EC2 savings are eaten up by the wage costs of spending time on it. (Depending on how many servers you are running of course)
Re: Announcing Topaz: A New Ruby
#160Earlier quoted context omitted.
> Some observers objected to Go's C-like block structure with braces, preferring the use of spaces for indentation, such as used in Python or Haskell [braces are optional in haskell]. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken…
This. Especially when writing a code generator. Targeting a significant whitespace language is potentially more tricky than one with explicit delimiters. I love the Haskell approach to this.
(For those who don't know, Haskell has an optional whitespace-significant syntax (which most humans use) as well as a brace-delimited syntax, and these are exactly equivalent.)