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

171–180 of 190 posts

Re: Announcing Topaz: A New Ruby

#171

Post by nirvdrum »

niggler wrote: post #166
nirvdrum wrote: post #158

Earlier quoted context omitted.

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 th…

" that would advocate for no improvements anywhere else" Amdahl's law advocates starting from the part that takes the most time. In a database application, it can be interpreted as either A) improving the connector or B) reducing the application's demand for database resources. "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 spee…

Sorry about the link comment. I'm so used to Wikipedia links being passed around I must have instinctively looked there.

In any event, we probably agree on more than we disagree. I never disagreed with working on the DB if that's truly the bulk of your cost. But, you do actually need to measure that. It seems quite common nowadays to say "if you use a DB, that's where your cost is". And I routinely see this as an argument to justify practices that are almost certainly going to cause performance issues.

Put another way, I routinely see the argument put forth that the DB access is going to be the slowest part, so there's little need to reduce the other hotspots because you're just going to hit that wall anyway. And then the next logical argument is all you need is caching. The number of Rubyists I've encountered that know how to profile an app or have ever done so is alarmingly small. Which is fine, but you can't really argue about performance otherwise.

Re: Announcing Topaz: A New Ruby

#172

Post by svachalek »

tomcorrigan wrote: post #161
PuercoPop wrote: post #155

Earlier quoted context omitted.

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…

It depends where you look for the common meaning. To native English speakers in the UK, Australia, New Zealand (ie outside North America, coincidentally including the country where the English language developed) specious has one very clear meaning I would also direct you to the usage examples in your link. All of which use specious in a context that implies deception of outright falsity. I have never ever seen speci…

I read that as "showy (obsolete)". Either way, amalag's says "wrong", the other says "deceptive" and "false", I'm not sure what anyone's arguing about. Specious data has no value.

Re: Announcing Topaz: A New Ruby

#173

Post by victorh »

tomcorrigan wrote: post #161
PuercoPop wrote: post #155

Earlier quoted context omitted.

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…

It depends where you look for the common meaning. To native English speakers in the UK, Australia, New Zealand (ie outside North America, coincidentally including the country where the English language developed) specious has one very clear meaning I would also direct you to the usage examples in your link. All of which use specious in a context that implies deception of outright falsity. I have never ever seen speci…

I disagree with your argument! If inventing the language meant you got to choose all the definitions we wouldn't have English in the first place. Shift happens. I don't think this particular usage is common, though.

Re: Announcing Topaz: A New Ruby

#174

Post by rbehrends »

grn wrote: post #80
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?

Because a puts loop is I/O bound, not CPU bound.

Re: Announcing Topaz: A New Ruby

#175

Post by charliesome »

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

How the hell is your Ruby that slow to start?

    $ time ruby -e "puts 'hello world'"
    hello world
    
    real    0m0.011s
    user    0m0.008s
    sys     0m0.003s

Re: Announcing Topaz: A New Ruby

#176

Post by d33pika »

charliesome wrote: post #175
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

How the hell is your Ruby that slow to start? $ time ruby -e "puts 'hello world'" hello world real 0m0.011s user 0m0.008s sys 0m0.003s

The first time I ran:

   time ruby -e "puts 'hello world'"
   hello world

   real	0m0.221s
   user	0m0.005s
   sys	0m0.006s
subsequent times:

   time ruby -e "puts 'hello world'"
   hello world

   real	0m0.008s
   user	0m0.005s
   sys	0m0.003s
So, I guess he ran ruby first followed by topaz and ended up with those results

Re: Announcing Topaz: A New Ruby

#177

Post by simula67 »

fijal wrote: post #18
llimllib wrote: post #15

Earlier quoted context omitted.

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.

PyPy is totally not like LLVM in many regards. It targets a very different demographics. Some differences: * RPython comes with a good garbage collector * the language where you specify what's going on is RPython in which you write an interpreter. Then you get a JIT using a few hints. This is difference than "interpreter in C + compiler to LLVM" scenario by quite a bit. * RPython comes with a set of data structures t…

So its closer to JVM than LLVM (http://stackoverflow.com/questions/454720/what-are-the-diffe...)?

Re: Announcing Topaz: A New Ruby

#180

Post by Cowen »

amalag wrote: post #132
Cowen wrote: post #67

Earlier 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?

I was using "specious" as a synonym of "flawed." Perhaps that was the incorrect usage.

But in the case of advertising a new library/project, which is arguably one of the main functions of the frontpage, flawed benchmarks (though not so far as outright lies) at least give me an objective reason to investigate further.

With no benchmarks, generally I'll open the page, mutter "that's nice" and move on with my business. I'd imagine I'm far from the only person who does that. Young projects don't help themselves when they don't effectively advertise themselves.

Post reply on HN