So which one''s faster? if(A != true) or if(A == false)? are they the same or the compiler will optimize this kind of stuff to choose the fastest?

They are exactly completely totally the same.

You''re posting in the beginner forum, so I''ll take a moment to get you started on the right track: DON''T WORRY ABOUT THIS STUFF. Micro-optimizations like this will be readily handled by the compiler. All you need to worry about is making your algorithms efficient (quicksort instead of bubblesort, etc). Don''t bother with this stuff until you''ve completed and profiled your application.

Don''t listen to me. I''ve had too much coffee.

x86 processors have both JNE (jump if not equal) and JE (jump if equal), which take the same time on the processor.

So there''s no difference.

(first of all Coz != Cozman, so he''s not replying to his own post )

If you are interested in optimization you may be interested in "More Effective C++" by Scott Meyers, as the name suggests there is a prior book, it has 50 things, is signifigantly shorter, and I read through my copy with only half the number of "ohhh, I never knew that" as the latter book that only has 35 (yet more advanced and IMHO more useful) items.

First, I post in this forun because I thought this was a beginner''s like question.
Second, the reason I post this kind of stuff is because after I tought I knew enough to make things fast(now I see I don''t ) I began to see some things that left me like "What? but it doesn''t look like it''s faster/better! they seem to be the same!"
Third, Don''t worry I don''t think too much in this kind of stuff. Just being curious
Fourth, thanks for the technical explanation. I love when people make these because most of the time I use that information to help me understand something, so thanks!
Fifth, thanks for the tip on the book, I think I''m gonna get it.

Hey Californium, weren''t you banned from the forums? (Not trying to start anything here, just an honest question )

quote:
So that is why you must do the test I suggested above: timing massive instances of each operator.

Why would Coz need to go through any sort of testing? Even if he didn''t trust what the other posters have said, it''s just a quick trip to google to look up what the CPU manufacturer lists as the timing for je and jne (who better to trust than the people who developed the chip in the first place). The problem with writing a test program for it is that since there''s no guarantee that the two programs will get the same amount of ''CPU time'' in a given period (especially under a multitasking environment) your results would probably be different each time you ran the test program(s). There are ways to make an accurate test, but seems like a lot of extra steps to go through for something that won''t noticeably speed up your application.

quote:
XOR values that aren''t equal and you''ll get a value that''s "not as easy to handle" as 00000000.

The value is just as easy to handle considering that either the answer is 0 or it''s not. If it''s 0 it''s equal, if it''s anything else it''s not. Doesn''t get much ''easier to handle'' than that.

quote: Original post by Californium
Way to find out: The Scientific Method. This can only be measured by massively using each operator over and over. So find a good timing mechanism and make two bullshit programs with, let''s say 1000 instances of each operator. See which program is faster and then you''ll know the real answer. Don''t go by somebody else''s logical deduction, for they could be wrong! I don''t know the answer but here''s a contradicting statement: At the logical operation level of gateways in your microprocessor, let''s say you are comparing two numbers, if they''re equal and you XOR them together, then the result will be a big row of zeros. Now, let''s assume that the != test uses the same logic circuit. XOR values that aren''t equal and you''ll get a value that''s "not as easy to handle" as 00000000. Get it? You see, know one here has really stated the machine level mechanics involved, which a software program can only imagine. So that is why you must do the test I suggested above: timing massive instances of each operator.

Um, this is well documented by processor manufacturers. If you really want to you should be able to find the number of clock ticks any operation takes. For things like je, and jne, they are the same. They also probably take about 1 or 2 ticks, though multiple ops can take place in the same tick, so it''s harder to count ticks with newer processors

Also, if you are going to test this using massive instances of each operator:
1. You need to use way more than 1000 to get an accurate measure of the time. Try about 10billion. Consider that most processors are at least 1GHz, i.e. 1billion ticks per second.
2. You must run it on random data. You simply can''t test the same equality over and over, because, branch prediction at the processor level could skew results.

Californium mentions that 00000000 may be easier to handle. This isn''t true. The processor doesn''t care whether you have all 0''s or 1''s and 0''s. Besides, the two different ops likely won''t use the same circuit anyway.

Ultimately, they will be the same.

Californium, you really need to learn to quit while you''re not that far behind.

a silly, pointless question has devolved into a childish argument... SOMEONE PLEASE CLOSE THIS THREAD!