SDA India is an online resource for Software, Development,IT, Architecture, Open Source, Mobile, Security, Databases, Delphi, C, OS, Asp, .Net, Php, Xml, Java

Google engineers Jeremy Manson and Paul Tyma have reached to a conclusion in an article that most of the things we think we know about Java performance are actually pretty hard to quantify and according to them it is nothing but “an unending search for the truth.”

Manson and Tyma shared their insights with SD West attendees, at Spring’s Software Development West, on the assumptions that developers make while writing a code.

Manson opined that “we had been writing a lot of code such as fast code, server code, C++ code, Java code and we realized that there are a lot of myths regarding Java performance, beliefs that we just knew were not true, but had never tested.”

The common assumptions that developers make while writing a code are versions don’t matter, 64-bit code is slower than 32-bit code, thread context switching is expensive, and locking is expensive.

Putting an end to all these assumptions, Tyma further described that number of people think that they can keep on using 1.4 forever, and it won’t affect performance. But it is not the case, it turns out they have been improving Java steadily over the past 13 years, and 1.6 is a lot faster than 1.5, and 1.5 is a lot faster than 1.4. The truth is 1.4 byte code can run on 1.6 VMs.

According to Manson, the reason for those who think 64-bit code is slower than 32-bit code is that they believe the pointers are twice as large, and all of a sudden they are taking up between one and two megs of memory, and now that they are using more memory, the code is not going to fit into the L1 and L2 cache, which will slow down the code. But Manson added that this scenario does not always manifest in the x86 world, because 64-bit code has twice as many registers, so there is less register spillage, and one can have longer pipelines in processor. So code that is very intensive in terms of registers and integer performance can be a lot faster in 64-bit.

While testing the Linux 2.6 NPTL library, it is observed that context switching was not expensive at all. Even with a thousand threads competing for Core Duo CPU cycles, the context switching was not even noticeable.

Tyma noted that contended synchronization does cost more, but doesn’t tend to scale. Uncontended synchronization is cheap, and can even be free. Add a thread, and that picture changes. Synchronized locking with contention gets more expensive. The cost goes up significantly. But increase the number of threads, and the cost doesn’t change much after that.
“Don’t avoid synchronization. When doing tricky things to avoid synchronization, you end up writing really bad code,” said Manson.

Those developers, who are seeking to write faster Java code, don’t waste your time trying to take advantage of any of these kinds of performance myths. Just write the best code and profile it to find the bottlenecks, remove the bottlenecks, rinse and repeat, and there you are on your way to write faster Java code.


   Related Links

  Source