Linked by Christopher W. Cowell-Shah on Thu 8th Jan 2004 19:33 UTC
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/25/13 0:45 UTC
Linked by Thom Holwerda on 05/24/13 23:59 UTC
Linked by Thom Holwerda on 05/24/13 22:33 UTC
Linked by Howard Fosdick on 05/24/13 21:41 UTC
Linked by Thom Holwerda on 05/24/13 14:44 UTC
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
More News »
Sponsored Links



I may be able to help you a touch on understanding why the JDK beats C++ in some cases. It comes down to one of two issues:
(1) Object allocation.
Object allocatio nis highly tuned in java because the goal is to encourage solid object oriented programming which means a LOT of object creation. C allocation of memory and C++ object allocztion tend to be abyssmal. (Although to be fair, MSFT's C on MSFT"s OS is about the best at it I've seen, coming cloe to Java peformance for some tests.)
(2) Optimization
Quite simply there is more information available at run-tiem on exactly how code is going to be used then you have through static analysis at compile time. Hotspot gets its name from the fact that it sports a very sophisticated profiler built into the run-time that analyzes actual code use and comes up with best case optimizations. Some of these optimizations would be impossible at compile time because, although they are based on likely code behavior, they could be dangerous if an optimizer guessed wrong. Being a run-time optimizer however Hotspot can pursue these optimizations and then back them out if it see the critical condition occur.
A key example is what we call "agressive inlining". Hotspot will in-line any method call for which tehre is only one possible target from the current call site.
This is done by tracking what the currently loaded class hirearchy is. If the hirearchy changes (through late binding) then those in-lines are backed out.
This means that Java can effectively get rid of all v-table
calls except those where the call site actually is poly-morphic.