0

Just for curiosity, which process is fastest: setting a value to a boolean (ex: changing it from true to false) or simple checking its value (ex: if(boolean)...)

tupini07
  • 518
  • 5
  • 13
  • 2
    Take a look at the code generated by the compiler. –  Mar 24 '14 at 21:14
  • 1
    @faranwath: That's a question all by itself, i.e. to know where to look and to know what to look for is not a minor task. – Kevin Le - Khnle Mar 24 '14 at 21:17
  • You mean between `foo = true;` and `if (!foo) foo = true;`? – user2802841 Mar 24 '14 at 21:18
  • @Khnle-KevinLe Oh well, what about a simple, small program that does both things? That can't be hard! –  Mar 24 '14 at 21:18
  • @Khnle-KevinLe But it's also narrow enough to be googled or found on Stack Overflow. That said, I don't think someone who asks a question like this will benefit much from looking at the generated code. At best they're no closer to an answer, at worst they get understandable but harmful misconceptions. –  Mar 24 '14 at 21:18
  • @Khnle-KevinLe, -O2 or -O3 compiler flag will render this question useless. You can go ahead and check the assembly. – Claudiordgz Mar 24 '14 at 21:19
  • 1
    @faranwath Actually, benchmarking and getting useful results from it is quite hard. You want to focus on one specific thing, but you need to include enough scaffolding that the compiler doesn't optimize it all away. You want a *representative* benchmark, but you don't want to write your whole application. You need to be aware of the dozens of kinds of noise that affect the timings, and you need to migitate them. And once you have correct measured data, you can still draw wrong conclusions from it if you don't validate your conclusions. –  Mar 24 '14 at 21:21
  • I think he means which is faster in terms of cpu cycles in which case I would say that it depends on the architecture and the instruction set. I think that checking the value should be faster however since it only involves setting a register and using the ALU. Addressing places in memory is much more complicate in practice.. These really shouldn't matter thought especially when we need to pass multiple layers of abstraction. – Veritas Mar 24 '14 at 21:22
  • @Claudiordgz, faranwath but now you assume one is already well-versed in assembly and/or machine language. – Kevin Le - Khnle Mar 24 '14 at 21:22
  • @Khnle-KevinLe, These kinds of micro optimizations are really dangerous. Some developers get obsessed that they walk all over making the code self explainable. Now, I do think there could be a case where benchmarking this would be necessary, but we would be talking about a sizable amount of `if`s. – Claudiordgz Mar 24 '14 at 21:26
  • @Khnle-KevinLe I'm no expert but it shouldn't be particularly difficult to notice a branch vs. a move. –  Mar 24 '14 at 21:26
  • How fast each of them is depends on various thngs: Optimization level (in the extreme case it may not only be optimized away, but also for some reason cause the compiler to optimize the surrounding code better, giving effectively a negative runtime), whether it is currently held it in a register, and if it has to be read from or subsequently spilled to memory, whether it is a cache hit or a cache miss, or in the most extreme case even triggers a swapping. – celtschk Mar 24 '14 at 21:28
  • Possible duplicate of [C++: Set bool value only if not set](http://stackoverflow.com/q/15033916/2802841), depending on exact meaning of OPs question. – user2802841 Mar 24 '14 at 21:34

2 Answers2

2

I think that this is so dependent on the context :

  • CPU/Architecture
  • Is the boolean stored in memory, cache, or register
  • whether what's behind the if induce a jump or only a conditional move
  • whether the value of the boolean is predictable or not

that the question doesn't finally makes sense.

hivert
  • 10,579
  • 3
  • 31
  • 56
2

The problem I have with "which is fastest" is that they are too underspecified to actually be answered conclusively, and at the same time too broad to yield useful conclusions even if answered conclusively. The only productive avenue your curiosity can take is to build a mental model of the machine and run both cases through it.

foo = true stores the value true to the location allocated to foo. That raises the question: Where and how is foo stored? This is impossible to answer without actually running the complete source code through the compiler with the right settings. It could be anywhere in RAM, or it could be in a register, or it could use no storage at all, being completely eliminated by compiler optimizations. Depending on where foo resides, the cost of overwriting it can vary: Hundreds of CPU cycles (if in RAM and not in cache), a couple cycles (in RAM and cache), one cycle (register), zero cycles (not stored).

if (foo) generally means reading foo and then performing a conditional branch based on it. Regarding the aspects I'll discuss here (I have to omit many details and some major categories), reading is effectively like writing. The conditional branch that follows has is even less predictable, as its cost depends on the run-time behavior of the program. If the branch is always taken, branch prediction will make it virtually free (a few cycles). If it's unpredictable, it may take tens of cycles and blow the pipeline (further reducing throughput). However, it's also possible that the conditional code will be predicated, invaliding most of the above concerns and replacing it with reasoning about instruction latency, data dependencies, and the gory details of the pipeline.

As you can see from the sheer volume to be written about it (despite omitting many details and even some important secondary effects), it's virtually impossible to really answer this in any generality. You need to look at concrete, complete programs to make any sort of prediction, and you need to know your whole system from top to bottom. Note that I had to assume a very specific kind of machine to even get this far: For a GPGPU or a embedded system or an early 90's consumer CPU, I'd have to rewrite almost all of that.

Community
  • 1
  • 1