0

In Java, as well as other languages, I always use the N % 2 == 0 trick to obtain the parity of a number, but I'm pretty sure that in terms of time complexity there is some better solution.

It's probably better already by using N & 1 == 0, but does this run in constant time, i.e. does it just do the rightmost bit comparison, or does it do all of the log(N) bits composing N?

Is it possible to somehow just read the last bit of the number, which would be in constant time for sure?

J. Schmidt
  • 419
  • 1
  • 6
  • 17
  • 9
    I'm confident that the compiler already optimises that for you, so I doubt trying to do bitwise arithmetic is going to produce a measurable performance increase for your application. Moreover, doubt very much that parity checks are the bottleneck in your code - chances are that your time is better spent improving something else. – VLAZ Jul 31 '20 at 15:23
  • Yeah, this was more of a theoretical question in a sense. In other words, I'm interested in : how much slower is the `%` method compared to the `&` method? – J. Schmidt Jul 31 '20 at 15:37
  • 3
    I'm going to guess around zero. I suspect both `x % 2 == 1` and `x & 1 == 1` would compile to the same instruction set in the end. Even if it's not *exactly* the same, I doubt it's going to introduce a reliably measurable difference. Micro-benchmarking this can be quite unreliable. – VLAZ Jul 31 '20 at 15:40
  • 1
    Operations on log(N) bits generally run in constant time anyway. Hardware does not "go through each bit one by one". – harold Jul 31 '20 at 18:16

1 Answers1

3

Typically, the & operator is implemented in hardware circuitry. The circuitry runs over all the bits of the number in parallel in one single step. It does not look at bits one by one.

Integer division and remainder operations on the other hand are a lot more complex. Popular CPUs don't have special circuitry for it, instead it's implemented in microcode. It's hard to find a primary source, but different sources on the internet put integer division at about 20-40 times as expensive as bitwise operators like AND.

Compiler writers are well aware how expensive the division and remainder instructions are, and do everything possible to avoid generating code that uses these instructions - see for example Why does GCC use multiplication by a strange number in implementing integer division? It is very likely, but not guaranteed, that N%2==0 is compiled to N&1==0. To make sure, you would have to examine the machine code generated by the compiler. In Java, the compiler you should most care about is the JIT compiler. It generates native machine code on the fly. Examining its output is possible, but not easy. Also, the optimizations it does may change from one version to the next, or vary between CPU models.

If you really want to know which is faster in your application with your hardware, you should create a benchmark and test it yourself.

Joni
  • 108,737
  • 14
  • 143
  • 193