Re: [Classpath] style question
== C Scott Ananian [EMAIL PROTECTED] writes: What I was saying, in effect, was that duplicate array bounds checks should be optimized away, *if the compiler can determine that they are, in fact, duplicate*. Yes. In this case I don't think it is too far-fetched that a compiler could discover this. Strings are used often enough that teaching a Java compiler about String.length wouldn't be unreasonable. (gcj can't do these optimizations now, but we plan to do them in the future.) Using the try-catch construct obscures this fact, so it makes it harder for the compiler to Do The Right Thing. I agree with this too. Also, since exceptions are presumably exceptional, compiler writers probably won't spend as much time optimizing them as they will on unexceptional code paths. I think we have to ask, though, what the goal is. If it is performance, then there is no single answer, since different implementations have different tradeoffs. For instance with gcj I think exceptions are a bit more expensive than they are with, say, Sun's JDK. OTOH other things are cheaper (and ultimately a redundant bounds check will be free). If the goal is clarity, then it is a little harder to judge. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Classpath] style question
On Sun, 24 Feb 2002, Eric Blake wrote: Which is prefered, performing array bound checks throughout a method, or enclosing the algorithm in a try-catch block which converts an IndexOutOfBoundsException into a NumberFormatException? For what it's worth: often adding explicit bounds checks will enable the compiler to create faster code (by hoisting these checks, and others which are implicit in the java semantics, out of the loop). I'm not sure which/any of the existing Java compilers are smart enough to do this, but they all will be, eventually. The try-catch block technique is sometimes faster for NullPointer exceptions (because the exception handling is wrapped around the native hardware memory protection mechanisms, and thus no hardware instructions are required to do the checks in the common case), but I can't imagine any case where the try-catch would be faster for array-bounds (okay, there are some w/in *imagination*, but...). In most cases, you'd be doing the same array-bounds tests in hardware as in the explicit case, but then you'd have to create the exception object and throw it, only to be caught, rebuilt as another exception object, and rethrown. Style needn't have anything to do w/ efficiency, though. YMMV. --scott Legion of Doom AK-47 DNC Rijndael Qaddafi payment Bush explosives Kennedy Indonesia biowarfare AES plastique Attache Saddam Hussein ( http://lesser-magoo.lcs.mit.edu/~cananian ) ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Classpath] style question
C. Scott Ananian wrote:
For what it's worth: often adding explicit bounds checks will enable the
compiler to create faster code (by hoisting these checks, and others which
are implicit in the java semantics, out of the loop). I'm not sure
which/any of the existing Java compilers are smart enough to do this, but
they all will be, eventually.
Notice that in my case, though, there is no loop, and the bounds check
is still in software. I'm simply proposing to remove two independent
checks of the length in decode(), (before parsing, and after parsing
0x), because they duplicated the bounds check already explicit in
String.charAt().
I am not proposing to use VM hardware array bounds checking to reduce
the amount of bytecode. And I do agree that this:
try
{
int i = 0;
while (i++)
// process array[i]
}
catch (IndexOutOfBoundsException e)
{
// ignore - we used a try-catch as flow control
}
is much worse than this:
for (int i = 0; i array.length; i++)
// process array[i]
I can't imagine any
case where the try-catch would be faster for array-bounds (okay, there are
some w/in *imagination*, but...). In most cases, you'd be doing the same
array-bounds tests in hardware as in the explicit case, but then you'd
have to create the exception object and throw it, only to be caught,
rebuilt as another exception object, and rethrown.
That's what I was asking - if anyone else thinks that my proposed change
in decode() is one of those situations.
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [Classpath] style question
On Mon, 25 Feb 2002, Eric Blake wrote: C. Scott Ananian wrote: For what it's worth: often adding explicit bounds checks will enable the compiler to create faster code (by hoisting these checks, and others which are implicit in the java semantics, out of the loop). I'm not sure which/any of the existing Java compilers are smart enough to do this, but they all will be, eventually. Notice that in my case, though, there is no loop, and the bounds check is still in software. I'm simply proposing to remove two independent checks of the length in decode(), (before parsing, and after parsing 0x), because they duplicated the bounds check already explicit in String.charAt(). What I was saying, in effect, was that duplicate array bounds checks should be optimized away, *if the compiler can determine that they are, in fact, duplicate*. Using the try-catch construct obscures this fact, so it makes it harder for the compiler to Do The Right Thing. Ideally, a compiler would a) inline String.charAt(), b) remove the check from the inlined String.charAt() since it was dominated by a similar check, and c) then remove the second bounds check in decode, for the same reason as b). I'm pretty sure the MIT FLEX compiler can do this, for example. There are so many duplicate checks implicit in the java semantics that most compilers would/should optimize them away. --scott PLO AP Cocaine Boston Hussein Albanian assassination politics RNC munitions Kojarena plastique Serbian Rule Psix President planning ( http://lesser-magoo.lcs.mit.edu/~cananian ) ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
