joustlog

Java vs. C++ benchmark discussion on Slashdot

Jeremy Geelan from Java Developer's Journal posted an article about my Java vs. C++ benchmark (the article is here). That article was then posted to Slashdot here and there's a big discussion about it there now.

The two biggest complaints are about how I didn't measure memory usage, and how I used GCC & didn't optimize in the best way. Some people say I should've used -O3 for GCC, other people say I should've used the Intel C++ compiler.

I plan to revisit the benchmark later this summer with Microsoft VC++ and Intel's compiler, as well as with JRE 1.5.0 and maybe (by request) BEA JRockit VM. I may also tweak the compiler flags for optimal performance on the C++ side.

DevX system property article is wrong

I just read Return a Property Without System.getProperty on DevX and had to post something, so maybe someone who read it and thought it was a good idea, will see that DevX's article is just wrong.

The article starts with this:

"On the JVM, System.getProperty() will only return a property if that property has been set using the -D flag. But what if a property has been set using EXPORT on a UNIX platform? Use this code to return the property:"

I was confused about this until I realized that the author didn't mean system property, he meant environment variable.

The article then explains that you can call the Unix command "env" and parse its output with Properties.load.

This is a terrible way to do this because:

1. It will be slow because it calls an external process
2. It will only work on Unix systems
3. Properties may or may not parse the env output correctly; that isn't what it was designed for

So, how are you supposed to read environment variable values then? The correct way is to use System.getenv(). It's been in the JDK for a while, and new in 1.5 it's no longer deprecated!