3 ms·

Very good graphs. Aside from X (time) and Y (code size), the center of the star implies "typical" performance, and the relative spread of the star shows specifi

Very good graphs. Aside from X (time) and Y (code size), the center of the star implies "typical" performance, and the relative spread of the star shows specific data points. Ruby, for example, shoots out from the bottom right - to me, this says, "This is quite expressive, and if you know what you're doing, you can get reasonably good performance". It doesn't show memory usage or sample size, however - Rebol probably has significantly fewer samples than Python, for example, but it only looks like half as many. It's also interesting how the LuaJIT star has about the same shape as the Lua star, but with 1/3 the width (which is consistent with my experience); Psyco relates similarly to Python. Surprisingly, the Lua star's center appears to be at the same X as GHC's, but lower down, and LuaJIT's overlaps OCaml's. While I can accept well-written Lua being approximately as expressive as Haskell (depending on the problem), I don't think it's in quiiiite the same ballpark as OCaml, speed-wise. The most interesting shape, to me, is Io's: While the default performance seems pretty poor (the right edge meaning 8x as slow as the left edge), there are bands shooting all the way to the left, without adding any real height. I don't have any experience with Io (I'm curious, but have never had success porting it to OpenBSD/amd64); can anybody here comment on this?

magv 17y ago
> The most interesting shape, to me, is Io's There seems to be a mistake. If you compare Io to JRuby [1], you'll find that Io is always the slower one, even though the picture in the article suggests otherwise. [1] http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=io&lang2=jruby http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...
- silentbicycle 17y ago
  Ah, ok. Also, it seems to be missing about half the benchmarks.
by 17y ago
"Ruby, for example, shoots out from the bottom right - to me, this says, ... if you know what you're doing, you can get reasonably good performance" Sorry, but it does not say you can get reasonably good performance, it says this version of Ruby is slow, one of the slowest languages in the Shootout. And the graph itself says nothing about the skill level required to obtain the exhibited performance.
- silentbicycle 17y ago
  > And the graph itself says nothing about the skill level required to obtain the exhibited performance. In all fairness, neither do most people promoting C++'s performance-at-any-cost design. I think a large spread in the performance correlates with requiring skill level, though -- it means that some people using the language get good results, but that many also get very bad ones. Ruby is a really slow language ("reasonably good" < great), but it's still good enough for many purposes, provided your algorithms are reasonable.
  - stcredzero 17y ago
    Ruby is not a really slow language. It's got some really slow implementations. Ruby has a high cost to entry for a VM/tool developer because it has a relatively byzantine syntax which has been hard to standardize. You can write code that has the same tokens yield entirely different syntactic elements, based on something random, like, say, what day of the week it is, which you can do in Python or Smalltalk, but in Ruby you can do this by accident with statements that look very innocent. (This is covered right in the Practical Programmer's Ruby book.) If dealing with Ruby's syntax were easier, Ruby implementations would progress faster.
    - gaius 17y ago
      You would think we'd learnt nothing from "only Perl can parse Perl".
    - silentbicycle 17y ago
      That sounds more like, "its design interferes with fast implementation" to me. If there's a major difference between that and "it's slow language", I'm really curious what it is.
      - stcredzero 17y ago
        You missed a meta-level. The design doesn't interfere with having a fast implementation. It interferes with implementing a fast implementation. "It's a slow language," implies that there's something special about Ruby that precludes (relatively) fast implementation. There's nothing special about Ruby like this. Ruby is a very nice remix of language features that existed before. Getting a language to be fast can require many iterations. Ruby's syntax is a high barrier to entry to implementers, so fewer eyeballs have been looking at the problem. Contrast this with Smalltalk. http://news.ycombinator.com/item?id=619398 http://news.ycombinator.com/item?id=619398 Smalltalk was designed to be quickly implemented by a single programmer. Implementing a "Bluebook VM" was treated as a rite of passage for support engineers for at least one of the vendors. As a result, people have implemented many, many variations on Smalltalk. (Including an VM with built-in OODB, another that can compile down to a C++ compatible DLL indistinguishable from one written in C++, another that ran on the old Palms, one with optional typing, and many others.) I think it's fair to say that writing a Ruby VM is probably an order of magnitude harder.
carbon8 17y ago
"Ruby, for example, shoots out from the bottom right - to me, this says" "yarv" is the graph that represents what is now Ruby 1.9, "ruby" only represents Ruby 1.8
mullr 17y ago
Io can do fast vector processing if you use its vector library. That's what I assume is going on.

magv 17y ago

> The most interesting shape, to me, is Io's There seems to be a mistake. If you compare Io to JRuby [1], you'll find that Io is always the slower one, even though the picture in the article suggests otherwise. [1] http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=io&lang2=jruby http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...

silentbicycle 17y ago
Ah, ok. Also, it seems to be missing about half the benchmarks.

by 17y ago

"Ruby, for example, shoots out from the bottom right - to me, this says, ... if you know what you're doing, you can get reasonably good performance" Sorry, but it does not say you can get reasonably good performance, it says this version of Ruby is slow, one of the slowest languages in the Shootout. And the graph itself says nothing about the skill level required to obtain the exhibited performance.

silentbicycle 17y ago
> And the graph itself says nothing about the skill level required to obtain the exhibited performance. In all fairness, neither do most people promoting C++'s performance-at-any-cost design. I think a large spread in the performance correlates with requiring skill level, though -- it means that some people using the language get good results, but that many also get very bad ones. Ruby is a really slow language ("reasonably good" < great), but it's still good enough for many purposes, provided your algorithms are reasonable.
- stcredzero 17y ago
  Ruby is not a really slow language. It's got some really slow implementations. Ruby has a high cost to entry for a VM/tool developer because it has a relatively byzantine syntax which has been hard to standardize. You can write code that has the same tokens yield entirely different syntactic elements, based on something random, like, say, what day of the week it is, which you can do in Python or Smalltalk, but in Ruby you can do this by accident with statements that look very innocent. (This is covered right in the Practical Programmer's Ruby book.) If dealing with Ruby's syntax were easier, Ruby implementations would progress faster.
  - gaius 17y ago
    You would think we'd learnt nothing from "only Perl can parse Perl".
  - silentbicycle 17y ago
    That sounds more like, "its design interferes with fast implementation" to me. If there's a major difference between that and "it's slow language", I'm really curious what it is.
    - stcredzero 17y ago
      You missed a meta-level. The design doesn't interfere with having a fast implementation. It interferes with implementing a fast implementation. "It's a slow language," implies that there's something special about Ruby that precludes (relatively) fast implementation. There's nothing special about Ruby like this. Ruby is a very nice remix of language features that existed before. Getting a language to be fast can require many iterations. Ruby's syntax is a high barrier to entry to implementers, so fewer eyeballs have been looking at the problem. Contrast this with Smalltalk. http://news.ycombinator.com/item?id=619398 http://news.ycombinator.com/item?id=619398 Smalltalk was designed to be quickly implemented by a single programmer. Implementing a "Bluebook VM" was treated as a rite of passage for support engineers for at least one of the vendors. As a result, people have implemented many, many variations on Smalltalk. (Including an VM with built-in OODB, another that can compile down to a C++ compatible DLL indistinguishable from one written in C++, another that ran on the old Palms, one with optional typing, and many others.) I think it's fair to say that writing a Ruby VM is probably an order of magnitude harder.

carbon8 17y ago

"Ruby, for example, shoots out from the bottom right - to me, this says" "yarv" is the graph that represents what is now Ruby 1.9, "ruby" only represents Ruby 1.8

mullr 17y ago

Io can do fast vector processing if you use its vector library. That's what I assume is going on.