If you are using integers as, well, integers then there is relatively little benefit other than compatibility with data structures from other languages (e.g. wire protocols). However, unsigned integers are also the building blocks of large bit string structures i.e. bit structures that are not interpreted as integers per se. For these it is a bigger problem. It is not the range issue so much as you have a bit that behaves differently than the others e.g. for operations like comparisons.
For kernels that do a lot of manipulation on largish bit strings there are two ways you can deal with it: use some additional conditional logic that treats the sign bit as special or design your code so that it can accept "gaps" in the bit string.
The reason you might want to do direct unsigned 64-bit bit-twiddling on packed bit string structures is blinding speed. It fully utilizes your CPU's ALUs. The equivalent code when limited to signed integers injects branches, extra operations, and/or requires working in 32-bit chunks, all of which slow down the code significantly and makes it uglier to boot.
For most apps it doesn't matter. For some algorithms that work on large bit strings it makes implementation in Java more painful than it needs to be.
For kernels that do a lot of manipulation on largish bit strings there are two ways you can deal with it: use some additional conditional logic that treats the sign bit as special or design your code so that it can accept "gaps" in the bit string.
The reason you might want to do direct unsigned 64-bit bit-twiddling on packed bit string structures is blinding speed. It fully utilizes your CPU's ALUs. The equivalent code when limited to signed integers injects branches, extra operations, and/or requires working in 32-bit chunks, all of which slow down the code significantly and makes it uglier to boot.
For most apps it doesn't matter. For some algorithms that work on large bit strings it makes implementation in Java more painful than it needs to be.
reply