And if array access boundary checks are not jitted out, I'm guessing most modern processors will use branch prediction (http://en.wikipedia.org/wiki/Branch_predictor) to execute the array access at the same time it's checking the bounds. Since usually the array index is within bounds, there is little chance in misprediction and little overhead in leaving the boundary checks in.
Roel > -----Oorspronkelijk bericht----- > Van: [email protected] > [mailto:[email protected]] Namens Kirk > Verzonden: 29 July 2010 10:19 > Aan: [email protected] > Onderwerp: Re: [The Java Posse] Bad benchmarks was fastest > way to parse > > Sorry, I just don't buy the standard line that C/C++ is a > safe from a performance perspective. Array access in Java > will be every bit as fast. Range checking will most likely be > jit'ed out of the code. Direct access will most likely be > jit'ed into the code.... > > Regards, > Kirk > > On Jul 29, 2010, at 9:07 AM, Alan Kent wrote: > > > On 29/07/2010 4:27 PM, Kirk wrote: > >> Microbenchmarks are as useful as any other type of > benchmarking. The problem is, they are very very very > difficult to get right. You need to do a lot of work to > validate the results you get from any benchmark, large or > small. I've missed the beginning of the conversation so I > never saw all of the code but then maybe it was never published. > > > > Just a bit of back fill (happy for this thread to die off > now) - I had some raw C struct like data in an array of > bytes. I am trying to put forward a case for using Java (or > maybe Scala) instead of C/C++ in a project. Performance is > critical. In C/C++, one argument is you can cast the > pointeer to the array of bytes and volia! you can access all > the int's etc. Very performant. Obviously cannot do this in > Java, so was trying to work out how close I could get Java to > squash this argument (if possible). Obviously the overall > application makes a big difference too. Right now C++ is > safe from a performance perspective, Java safer from a code > maintainability perspective. There is a hard performance > requirement on the project (harder than the code > maintainability requirement). > > > > Thanks > > Alan > > > > -- > > You received this message because you are subscribed to the > Google Groups "The Java Posse" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > [email protected]. > > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > > > -- > You received this message because you are subscribed to the > Google Groups "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
