Bit Twiddle & Branch Removal

[Roquen]

These are more interesting for other languages since the JDK does not do a good job of inline/reg-alloc & schedule.

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46

public static final int clampPositive(int a) {   // return (a >= 0) ? a : 0;  return a & ~(a >> 31); } public static final int abs(int a) {   // return (a >= 0) ? a : -a;  int s = a >> 31;   a ^= s;   a -= s;   return a; } public static final int min(int a, int b) {   // return (a <= b) ? a : b;  a -= b;   a &= (a >> 31);   a += b;   return a; } public static final int max(int a, int b) {   // return (a >= b) ? a : b;  a -= b;       a &= ~(a >> 31);   a += b;       return a; } public static final int select(int a, int b, int c, int d) {   // return (a<b) ?c : d  return (((a-b)>>31) & (c^d))^d; } public static final int sgn(int a) {   // return (a > 0) ? 1 : (a < 0) ? -1 : 0;  return (-a >>> 31) | (a >> 31); }

[Abuse]

I especially like sgn(..) 
Surely that must be faster than the 1.5 branches needed ordinarily?

[Stranger]

AFAIK, the shifts are some expensive for Java ...

Games published by our own members! Check 'em out!

[Roquen]

The shifts are JVM opcodes and the cost will be strongly related to the hardware cost of performing a shift.

[Riven]

At that level of execution, it's more about what (surrounding) native code the JIT generates, not so much the cost of the single instruction.

[Roquen]

This is a different issue related to the execution of a sequence of instructions and is what my opening comment was attempting to say.  As individual operations, shifts are very fast. 

[pjt33]

1   2   3   4   5

public static final int sgn(int a) {   // return (a > 0) ? 1 : (a < 0) ? -1 : 0;  return (a >> 31) | (a >>> 31); }

That's equivalent to

1	return (a >= 0) ? 0 : -1;

[Abuse]

That's equivalent to

1	return (a >= 0) ? 0 : -1;

Indeed; classic case of TGTBT =)

Also, clampPositive is doing more work than it needs to.

1   2   3   4   5

public static final int clampPositive(int a) {   // return (a >= 0) ? a : 0;  return a & ~(a >> 31); }

[Roquen]

Classic case of screwing up when deleting a cast from C.  Nuked the negate.  And yeah, the &= should just be and.

(edit: I update the original code to reflect these changes)

[Jono]

That's equivalent to

1	return (a >= 0) ? 0 : -1;

Can't that one just be:

1	return (a >>> 31) ^ 1

Edit: that was for sgn(a), incase it wasn't clear

Games published by our own members! Check 'em out!

[Riven]

Can't that one just be:

1	return (a >>> 31) ^ 1

Edit: that was for sgn(a), incase it wasn't clear

sgn(int) => [-1, 0, +1]

Your code returns either a 0 or 1, never -1

[Jono]

sgn(int) => [-1, 0, +1]

Your code returns either a 0 or 1, never -1

I blame it on the early morning. First I thought sgn returned 1 or -1 only, then I was working in 1's complement instead of 2's complement. Duh.