Other Software > Developer's Corner

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

(1/3) > >>

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 :Thmbsup:

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.

Navigation

[0] Message Index

[#] Next page