The speed, size and dependability of programming languages • Hacker News Board

Re: The speed, size and dependability of programming languages

#41

Post by [deleted] » Mon, Jun 01, 2009, 1:16 AM UTC

silentbicycle wrote: post #22

by wrote: post #21

Earlier quoted context omitted.

"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.

> 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 ("rea…

[deleted]

Re: The speed, size and dependability of programming languages

#42

Post by silentbicycle » Mon, Jun 01, 2009, 2:11 AM UTC

kinghajj wrote: post #37

SwellJoe wrote: post #32

Earlier quoted context omitted.

More reason to believe JavaScript is going to be huge on the server-side. As concise and (nearly as) powerful as Python, Perl, and Ruby, but getting faster at a much more rapid clip...and already required for the front-end, so everybody on the team is already familiar with it. Library coverage will take another couple of years to reach a reasonable level, but I'd bet on it happening.

I agree. Once I learned how truly powerful Javascript really is, once you get past the horrible DOM, I knew it could one day become a general-purpose scripting language and not just a web one. As soon as someone makes a good command-line Javascript interpreter, web apps will come as soon as someone creates a CGI extension to that interpreter.

Have you ever looked at Lua?

Re: The speed, size and dependability of programming languages

#43

Post by igouy » Mon, Jun 01, 2009, 2:28 AM UTC

draegtun wrote: post #26

petercooper wrote: post #3

The references to Ruby aren't entirely what they seem in here. They seem to be relating to Ruby on the older shootouts, rather than the recent ones. That is, the uber-slow Ruby 1.8, rather than the Perl-beating and PHP-matching Ruby 1.9 which is more closely related to "yarv" on this list.

Its great to see Ruby so much faster with 1.9 because 1.8 speed was such a stumbling block in data intensive stuff that I pushed towards it. However don't count your chickens just yet with regards to Ruby 1.9 being "Perl-beating" ;-) Don't you think its odd that Perl 5.10.0 sits only just above Ruby 1.8.7 in the current alioth shootout? Quick look at the tests and I can see a problem with a known 5.10.0 speed issue b…

> Fixing this in a quick local test here makes all the difference ;-)

It makes all the difference to that one benchmark - not to the overall situation.

Re: The speed, size and dependability of programming languages

#44

Post by igouy » Mon, Jun 01, 2009, 2:32 AM UTC

avibryant wrote: post #24

herdrick wrote: post #13

This is great. If you've looked at Peter Norvig's spell checker shootout you won't be surprised much. Ex., the story on Common Lisp and Scheme implementations is the same here: MzScheme is the mediocre best of an unimpressive lot. (I want to see Clojure and Arc on this.) Python looks great again. F# looks weak here but wins big in the spell checker with reasonable-looking code. Sounds interesting. What's the deal wit…

Just a guess, but: Squeak only uses text files as an export format, and that format is more verbose than file-based source code would normally be. If you only counted the code and not the metadata, it would probably do better.

Not much - Smalltalk code is written in sentences not squiggles.

The productivity comes from reading and re-using the code that has already been written rather than duplicating stuff.

Re: The speed, size and dependability of programming languages

#45

Post by mullr » Mon, Jun 01, 2009, 2:55 AM UTC

silentbicycle wrote: post #4

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…

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

Re: The speed, size and dependability of programming languages

#46

Post by akkartik » Mon, Jun 01, 2009, 4:16 AM UTC

tlrobinson wrote: post #30

The benchmarks used for the article was from 2005. Make sure to check out the 2009 versions: http://gmarceau.qc.ca/blog/uploaded_images/size-vs-speed-vs-... V8 has propelled JavaScript into the coveted bottom-left corner, which is awesome. SquirrelFish Extreme should be right up there with it, if it were included.

I'm amazed gcc is slower than java.

And it's more expressive than scala and f#? Something's gotta be wrong there..

Re: The speed, size and dependability of programming languages

#47

Post by fauigerzigerk » Mon, Jun 01, 2009, 7:33 AM UTC

akkartik wrote: post #46

tlrobinson wrote: post #30

The benchmarks used for the article was from 2005. Make sure to check out the 2009 versions: http://gmarceau.qc.ca/blog/uploaded_images/size-vs-speed-vs-... V8 has propelled JavaScript into the coveted bottom-left corner, which is awesome. SquirrelFish Extreme should be right up there with it, if it were included.

I'm amazed gcc is slower than java. And it's more expressive than scala and f#? Something's gotta be wrong there..

You need to look at how many data points each language implementation actually produces. gcc runs all programs whereas java steady state (the one that looks faster than gcc) lacks a lot of data points (i.e programs). As you can see in the diagram gcc's star is pulled towards the right by one data point (at least it looks like one). If java steady state ran all programs its star might shift to the right as well. Or it might not. It's just not comparable as it is. You need to look at the actual numbers instead of the diagrams.

My own benchmarks that I run on our heavily algorithmic long running code consistently show Java about 10% to 20% slower than gcc (C++) and memory usage about twice that of the C++ implementation (excluding the JVM memory itself). C and C++ performance depends heavily on avoiding malloc/new. C/C++ code that gratuitously allocates and frees heap memory tends to be much slower than Java code.

Re: The speed, size and dependability of programming languages

#48

Post by gaius » Mon, Jun 01, 2009, 9:29 AM UTC

stcredzero wrote: post #36

silentbicycle wrote: post #22

Earlier quoted context omitted.

> 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 ("rea…

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

You would think we'd learnt nothing from "only Perl can parse Perl".

Re: The speed, size and dependability of programming languages

#49

Post by silentbicycle » Mon, Jun 01, 2009, 11:49 AM UTC

stcredzero wrote: post #36

silentbicycle wrote: post #22

Earlier quoted context omitted.

> 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 ("rea…

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

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.

Re: The speed, size and dependability of programming languages

#50

Post by stcredzero » Mon, Jun 01, 2009, 12:56 PM UTC

silentbicycle wrote: post #49

stcredzero wrote: post #36

Earlier quoted context omitted.

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

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.

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

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.