Article: Performance Comparison: C++, Java, Python, Ruby, Jython, JRuby, Groovy

[Armando]

I thought it was an interesting read. I was surprised at java's fairly high performance (unless I'm not interpreting the numbers correctly...), especially compared to C++. But... as I'm just starting to get into programming (Java and Python), I'm NOT able to grasp all the implications/applications/limitations of that article (and the method used...).
Any educated comments are welcome. 

[Shades]

Once you have a working Java setup on your desktop and/or server, it is actually very fast. I know a company here that makes banking software for Cooperativas (a special type of bank here in South America). It can do everything internally and externally (internet), is completely java based and works equally well on Windows and Linux.

The sheer speed of creating yearly reports handling 40.000+ customers is astonishing

No, I am not affiliated with this company (a buddy of mine here works there and showed me once).

Ah well, guess it is always true. If you know what you are doing, anything coded in whatever language will go fast.

[f0dder]

I guess that this is the article link?

Didn't look at code etc., but from reading the blurb it sounds like a laaaaaaaaaaaaaaaaaaaame pseudo-benchmark - basically over-theorizing and über-abstracting a problem. Who in their right mind would implement a fixed-size ring buffer as a linked list? (Yeah, I might've misread the blurb. I really hope I did.)

As for java performing... lol. Sure, you can even implement a quake-style BSP renderer with only 2x the hardware it took to run it native, but the SUN JVM sucks. Bigtime. If anybody thinks that SUN sued MS java implementation because it "wasn't following specs", try benchmarking a game of solitair on a 700MHz machine using both SUN and MS JVMs. Even MS's JVM was a snail compared to native code, though.

[Armando]

ooops... forgot the link -- thanks f0dder (the screenshot is now linked to the article). (Thanks for the comments too! will wait for other points of view.)

[Jibz]

The C++ version looks like it would be spending most of it's time on allocating and deallocating memory. The default allocator is not suited for small objects, and most C++ coders would write the code in a different way due to that (or use a small object allocator).

The issue rears it's head because he is not comparing the speed of an algorithm, but comparing the speed of running an algorithm one million times.

[housetier]

Everybody loves a good pointless language bashing. It gives them a chance to reiterate old points over and over again until they finally start to believe it themseves without ever having tried.

However, no language war is complete without points and counter points from http://shootout.alioth.debian.org/! Select your languages, and then carefully choose an algorithm that favors your language - there is your proof!

And if performance does not count but elegance does: http://99-bottles-of-beer.net/. 99 bottles is also artistic and emphasizes the silliness of language bashing, even more so unfounded language bashing.

[tinjaw]

I haven't seen that article, but based solely on the comments you folks have made and the fact that 99.9% of the articles of this type are crap, I feel I can make an equally factual statement here without hesitation.

I wrote a program in Python. It was fast. Python rocks. You should use Python for everything.

Again, I haven't read the article, but it sounds like another one of those... "Although nobody would every use a screw driver or a pair of pliers to hammer in a nail, I wanted to use the tools in a similar manner so I could compare them. So I pounded a bunch of nails into sand using a Craftsman #2 Philips Screwdriver, a pair of Channel Locks from Husky, and an old hammer my grandpa gave me. All three tools worked well but it is obvious that the hammer still out performs the screwdriver and channel locks despite their more recent heritage and the use of higher grade materials."

Look folks, programming languages are tools. Always use the right tool for the job; keeping in mind familiarity with fewer tools will generally mean greater proficiency with those tools and hence one's speed at building with those tools and often minimizing the development, and maintenance, time is a major requirement of a software project. YMMV.

[Armando]

Thanks for the different points of view! Forgot about this thread... Remembered thanks to the August newsletter. 

[Ehtyar]

Didn't look at code etc., but from reading the blurb it sounds like a laaaaaaaaaaaaaaaaaaaame pseudo-benchmark - basically over-theorizing and über-abstracting a problem. Who in their right mind would implement a fixed-size ring buffer as a linked list? (Yeah, I might've misread the blurb. I really hope I did.)

-f0dder (July 28, 2008, 10:03 PM)

When i first started reading I thought.."I wonder if they posted source and binaries". Then I thought "hmm, what an arbitrary assortment of languages", like where the hell is C and Perl. Thank you for confirming my suspicions, I have no compulsion to read this article.

Ehtyar.

[housetier]

Impressive, nobody read the article but everybody has a say about it.

[Armando]

I tend to agree with you... at the same time I guess that many programmer with extended experience can probably form an opinion quicker -- especially regarding simple problems/theories/hypothesis -- without the need to spend to much time analyzing. Of course, such "quickness" can also be a trap (during my PhD studies, I've seen so many very capable intellectuals critiquing theories or hypothesis without really trying to deeply understand the whole thing before... Basically, they thought they just "knew" and, more often then not... they were wrong! In this article's case, it's probably a bit different though...) 

Regarding this blog post : maybe one should keep in mind that the author seems to have done his experiment just for the sake of curiosity, not to bash a specific language or anything...mean. He also stated that :

I emphasise [sic] once again that I have carefully indicated in the original post that this is but one of many possible microbenchmarks and that you should treat the results as one of many data points. [...] This post compares performance across various languages for a specific micro benchmark (actually it isn’t really a microbenchmark - it is simply a benchmark for a specific piece of logic - but thats [sic] the closest word I could think of).

But that doesn't make it more interesting, of course...