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

161–170 of 190 posts

Re: Announcing Topaz: A New Ruby

#161

Post by tomcorrigan »

PuercoPop wrote: post #155
amalag wrote: post #132

Earlier quoted context omitted.

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…

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 specious used synonymously with obsolescence.

Re: Announcing Topaz: A New Ruby

#162

Post by nirvdrum »

robryan wrote: post #159
nirvdrum wrote: post #127

Earlier quoted context omitted.

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)

This isn't a theoretical argument. I actually did this and it didn't take all that long and some of it was even fun. An added benefit is my specs run faster, too. So developer time is saved on every spec run now. You also hit that intangible of improved developer happiness.

Additionally, the X time exceeds Y cost argument really only works when people are optimally efficient. Clearly those of us posting HN comments have holes in our schedules that might be able to be filled with something else.

Re: Announcing Topaz: A New Ruby

#163

Post by losvedir »

PuercoPop wrote: post #155
amalag wrote: post #132

Earlier quoted context omitted.

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…

For what it's worth, amalog's definition of "specious" is the one I'm familiar with. My girlfriend recently quizzed me on her GRE words with that one, and my definition was the given one, too.

So I'd argue that amalog's definition IS the common one.

Re: Announcing Topaz: A New Ruby

#164

Post by chrismsnz »

jamesbritt wrote: post #154
chrismsnz wrote: post #145

Earlier quoted context omitted.

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?

I'm pretty sure his comment is indicating he _does_ use Python and that is his take on the "significant whitespace" issue.

Re: Announcing Topaz: A New Ruby

#165

Post by sciurus »

huherto wrote: post #89
stcredzero wrote: post #63

Earlier quoted context omitted.

> the lack of many core features probably helps out a lot atm. I don't understand why the lack of features would affect the time of "hello world."

Exactly. time echo "hello world" hello world real 0m0.000s user 0m0.000s sys 0m0.000s

  $ type /bin/echo
  /bin/echo is /bin/echo
  $ time /bin/echo "hello world"
  hello world

  real	0m0.009s
  user	0m0.002s
  sys	0m0.004s

  $ type echo
  echo is a shell builtin
  $ time echo "hello world"
  hello world

  real	0m0.000s
  user	0m0.000s
  sys	0m0.000s

Re: Announcing Topaz: A New Ruby

#166

Post by niggler »

nirvdrum wrote: post #158
niggler wrote: post #153

Earlier quoted context omitted.

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 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 speeding up YAML? Yet there's obviously value in improving all these areas and they speed up almost every Ruby app."

JSON parsing improves those applications that use JSON parsing, and in many applications JSON parsing is the main operation. There are many other applications for which garbage collection is the limiting factor. You are taking my comment, which was addressing the parent comment's remark that "This fallacy about DB access and not needing to optimize really needs to go away though.", way out of context. It's not a fallacy -- you need to know what is dominating execution time and how to improve that aspect.

Take it to the logical extreme -- you could just write in x86 assembly directly. The program would be faster than ruby, but the development time would not make assembly a worthwhile target.

"And even in the link you supplied"

What link did I supply? I recommend the Hennessy and Patterson "Computer Architecture" book :)

Re: Announcing Topaz: A New Ruby

#167

Post by gojomo »

sirclueless wrote: post #99
fijal wrote: post #42

Earlier quoted context omitted.

I'm actually not a native speaker, so indeed, I might not know. I checked in the dictionary though. This is an analogy, but not a very good analogy, because of the reasons that I pointed out. Are you disagreeing with any particular reasoning there? Or should I just say "they're similary, but"?

An analogy does not require that the items involved actually be similar, only that the relationships in each are the same. For example, "Gasoline is to cars, as sunlight is to trees" is a perfectly good analogy, even though gasoline is nothing like sunlight, and cars are nothing like trees. In much the same way, comparing "Apple writing a C interpreter on top of llvm" to "Alex Gaynor writing a Ruby interpreter on top…

A good explanation, and further, many times a good analogy relies on the things being very different in every way except for the one way it intends to emphasize. An analogy is often a way of saying: "Let's focus on this (often very abstract) aspect of interesting similarities. Yes, you can easily point out many other dissimilarities. That ease means I'm not talking about those aspects, so if we understand each other those don't even have to be mentioned."

Re: Announcing Topaz: A New Ruby

#168

Post by wmf »

stcredzero wrote: post #126
ephemeralgomi wrote: post #65

Earlier quoted context omitted.

Loading the standard library takes time. With a smaller (underimplemented) standard library, you can get to the user's code much more quickly.

Perl 5 had an in-memory footprint of about 768k. VisualWorks Smalltalk had a standard one of 12MB, yet loaded and started it faster than Perl did with 768k. If just your standard library takes very long at all to load, something needs attention.

Yeah, a lot of language runtimes seem to not have discovered mmap.

Re: Announcing Topaz: A New Ruby

#169

Post by [deleted] »

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

[deleted]

Re: Announcing Topaz: A New Ruby

#170

Post by pserwylo »

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

You should check out a tool I heard about recently called "ministat". An example of how to use it to benchmark multiple runs, and then compute the statistics from each run are available here:

http://anholt.net/compare-perf/

Example output:

  +------------------------------------------------------------------------------+
  |                   +                            x                             |
  |                   +                            x                             |
  |           +       +                            x x            x              |
  | +    ++   +++     +                            x xxx xx       x              |
  |++ ++++++++++++++++++                   x  x    x xxx xxx  xxxxx              |
  |++ ++++++++++++++++++ +++ +       ++   xxxxxxxxxx xxxxxxxxxxxxxxxx  xx x    xx|
  |     |______MA______|                        |________A________|              |
  +------------------------------------------------------------------------------+
      N           Min           Max        Median           Avg        Stddev
  x  57      45.62364     46.437353      45.93506     45.951554    0.19060973
  +  57     44.785579     45.534727     45.042576     45.056702    0.16634531
  Difference at 95.0% confidence
    -0.894852 +/- 0.0656777
    -1.94738% +/- 0.142928%
    (Student's t, pooled s = 0.178889)
Post reply on HN