== Quote from Max Samukha (maxsamukha@gmail.com)'s article
> Edward Diener wrote:
> > Why is the return type of object.opEquals an 'int' rather than a 'bool' ?
> Performance is supposed to be better with ints. It was discussed here: http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html#N7933

It was shown later in that same thread that there is no performance penalty for returning a bool.  The
response is somewhat buried and it took me a while to find it last time I looked.  However, Walter indicated
that he was unaware of the ASM instruction that allows for this improvement and so the back-end used by
DMD does something else instead which is much slower.


Sean

JMNorris Wrote:

> Edward Diener <eddielee_no_spam_here@tropicsoft.com> wrote in news:fps7es$1uh4$1@digitalmars.com:
> 
> > If one were to carry the efficiency argument further, than the other possible logical conclusion is that a 'bool' should be an 'int' ( constrained to be of value either 0 or 1 ) rather than a 'byte'. But to justify a poor design decision based purely on efficiency is exceedingly silly.
> 
> If I understood the discusion in the previous link correctly, it was
> (at least mostly) the constraint to 0 or 1, not the smaller size of the
> return, that was less efficient.  Returning an int may still be silly (the
> mere existance of this thread suggests that it is at least confusing), but
> making a bool the size of an int won't solve the efficiency concern.
> 
> -- 
> JMNorris

FYI making a bool a bit is not efficient in memory or time.  The code produced ends up having to "and 0x0000_0001" in order to mask the bit value; which takes 5 bytes on top of the value and the mov instruction.

Making a bool a byte may or may not be efficient in time and space complexity, depending on how it gets used.  The x86 normal 4-byte register instructions were the most optimized for, and in most cases a byte form can be used but it takes an extra byte to tell the CPU to use the byte operand.

There are two or three particularly useful byte-operand instructions.  In my opinion it would be a considerable waste to set up boolean as a byte just to use these.  Most compilers ignore them, and I tend to agree with that.  However, if you ever hand code assembler they're quite useful.

Regards,
Dan

Putting the int/bool performance difference in relation to the whole thing:
Calling opEquals makes a virtual function call. Then at least the given object reference is compared once against this. For a useful opEquals much more can happen, eg. a dynamic cast...
Now, is it still a _relevant_ performance hit (if any), to use bool instead of int here?

Frank Benoit Wrote:

> 
> Putting the int/bool performance difference in relation to the whole thing:
> Calling opEquals makes a virtual function call. Then at least the given
> object reference is compared once against this. For a useful opEquals
> much more can happen, eg. a dynamic cast...
> Now, is it still a _relevant_ performance hit (if any), to use bool
> instead of int here?
> 

I never thought it was.

Too many people think "oh, it's inefficient to use more than a bit" but fail to recognize that x86 machine code has a finite discrete set of instructions which operate on finite discrete operand sizes.

It really was time to set up a new platform decades ago - too bad Intel tanked the Itanic.

Regards,
Dan