Jump to page: 1 2
Thread overview
opEquals needs to return bool
May 16, 2008
Edward Diener
May 16, 2008
Manfred Nowak
May 16, 2008
Sean Kelly
May 16, 2008
bearophile
May 16, 2008
Sean Kelly
May 16, 2008
BCS
May 16, 2008
Janice Caron
May 16, 2008
Robert Fraser
May 16, 2008
Janice Caron
May 16, 2008
Frank Benoit
May 16, 2008
Georg Wrede
May 15, 2008
Because opEquals returns int, this breaks some generic code:

bool isEqual(T)(T t1, T t2)
{
    return t1 == t2;
}

class A
{
}

void main()
{
    int x1 = 5, x2 = 6;
    auto x = isEqual(x1, x2);
    auto c = isEqual("hello", "jello");

    auto a = new A;
    auto ae = isEqual(a, a); // error, cannot convert int to bool
}

Walter, you often say that some ideas can't be implemented because it would break generic code, what about this?

-Steve


May 15, 2008
"Steven Schveighoffer" wrote
> Because opEquals returns int, this breaks some generic code:

Apparently I am not the only one who thinks so :)

http://d.puremagic.com/issues/show_bug.cgi?id=1989

Can someone please dispell this myth about performance and add it to this bug report?

-Steve


May 16, 2008
Steven Schveighoffer wrote:
> "Steven Schveighoffer" wrote
>> Because opEquals returns int, this breaks some generic code:
> 
> Apparently I am not the only one who thinks so :)
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=1989
> 
> Can someone please dispell this myth about performance and add it to this bug report?

One of the first things I mentioned on this NG when looking at D for the first time is to ask why opEquals returns 'int' instead of 'bool'. After being directed to a discussion about it and Walter's explanation of the reason I said that I hoped that he would come to his senses and realize it was just plain wrong. I have not changed my opinion one whit and I am glad that others also realize it is wrong. Hopefully Walter has realized it is wrong by this time too.

IMO, even if it were so, one does not twist programming design for a performance gain.
May 16, 2008
Edward Diener wrote:
> IMO, even if it were so, one does not twist programming design for a performance gain.

One can tweak the program, but the language should help for those tweaks.

-manfred

May 16, 2008
== Quote from Edward Diener (eddielee_no_spam_here@tropicsoft.com)'s article
> Steven Schveighoffer wrote:
> > "Steven Schveighoffer" wrote
> >> Because opEquals returns int, this breaks some generic code:
> >
> > Apparently I am not the only one who thinks so :)
> >
> > http://d.puremagic.com/issues/show_bug.cgi?id=1989
> >
> > Can someone please dispell this myth about performance and add it to this bug report?
> One of the first things I mentioned on this NG when looking at D for the
> first time is to ask why opEquals returns 'int' instead of 'bool'. After
> being directed to a discussion about it and Walter's explanation of the
> reason I said that I hoped that he would come to his senses and realize
> it was just plain wrong. I have not changed my opinion one whit and I am
> glad that others also realize it is wrong. Hopefully Walter has realized
> it is wrong by this time too.
> IMO, even if it were so, one does not twist programming design for a
> performance gain.

For what it's worth, we tried changing this in Tango but it turns out that there
are some compiler changes needed as well.  I believe the problem we ran into
was that opEquals in structs stopped working properly, though I fail to
understand why the compiler would care about the return value of opEquals
for this feature.


Sean
May 16, 2008
Edward Diener:
> IMO, even if it were so, one does not twist programming design for a performance gain.

In some situations bools are slower, for example you can try this small program: http://codepad.org/pD22tteK

if at line 8 you replace:
int is_valid, went_off_right_side;

With a logically more correct:
bool is_valid, went_off_right_side;

The program runs slower (with DMD on my CPU about 4% slower).

Bools are bytes, while ints are 4 bytes, so sometimes ints are managed faster.
I agree that it's better for opEquals to return a bool.
In theory the compiler may become a bit smarter and use a size_t to represent a bool where this doesn't change the meaning of the program, but this looks not easy in general. Another possibility is to define a second faster bool type, but having two different bools looks bad in a language like D.

Bye,
bearophile
May 16, 2008
== Quote from bearophile (bearophileHUGS@lycos.com)'s article
> Edward Diener:
> > IMO, even if it were so, one does not twist programming design for a performance gain.
> In some situations bools are slower, for example you can try this small program:
> http://codepad.org/pD22tteK
> if at line 8 you replace:
> int is_valid, went_off_right_side;
> With a logically more correct:
> bool is_valid, went_off_right_side;
> The program runs slower (with DMD on my CPU about 4% slower).

In the original discussion, it came out that DMD doesn't generate optimal code for returning bools in this fashion, apparently because Walter was unaware of the relevant ASM instruction to speed this up.  It's hidden somewhere in a rather long conversation in this NG from perhaps 2 years ago.

> Bools are bytes, while ints are 4 bytes, so sometimes ints are managed faster.

So why not just make bool a 4-byte value?  Using an integer to represent a boolean operation is just silly.


Sean
May 16, 2008
Reply to Sean,

>> Bools are bytes, while ints are 4 bytes, so sometimes ints are
>> managed faster.
>> 
> So why not just make bool a 4-byte value?  Using an integer to
> represent a boolean operation is just silly.
> 

Or pad them to 4 bytes where you can (local variable).


May 16, 2008
On 16/05/2008, BCS <ao@pathlink.com> wrote:
> > > Bools are bytes, while ints are 4 bytes, so sometimes ints are managed faster.
> > >
> > So why not just make bool a 4-byte value?  Using an integer to represent a boolean operation is just silly.
>
>  Or pad them to 4 bytes where you can (local variable).

Honestly, I think I would be happy with a four-byte bool, in almost all circumstances.

For those rare cases where space is an issue, there could be a second type, bool8, implicitly castable to and from bool, but you wouldn't use that by default; you'd only use it in structs where you needed to pack stuff tight.
May 16, 2008
bearophile wrote:
> Edward Diener:
> 
>> IMO, even if it were so, one does not twist programming design for a performance gain.
> 
> In some situations bools are slower, for example you can try this small program: http://codepad.org/pD22tteK
> 
> if at line 8 you replace: int is_valid, went_off_right_side;
> 
> With a logically more correct: bool is_valid, went_off_right_side;
> 
> The program runs slower (with DMD on my CPU about 4% slower).
> 
> Bools are bytes, while ints are 4 bytes, so sometimes ints are managed faster. I agree that it's better for opEquals to return a bool. In theory the compiler may become a bit smarter and use a size_t to represent a bool where this doesn't change the meaning of the program, but this looks not easy in general. Another possibility is to define a second faster bool type, but having two different bools looks bad in a language like D.

I think bools should be of the fastest type available on the machine. On
x86 that is int. Bytes may spare you some room (only in some special
cases, I might add!!), but they really are slower.

This slowness results from the processor not being able to load and
store bytes as efficiently as ints. A byte store, for example, requires
a load of the other 3 bytes (because addresses are accessable only 4
bytes at a time on current 32 bit processors), then a computation of a
mask, the an and operation, then an alignment operation of the value
we're storing, then oring it with the mask result, and then storing the
4 bytes into memory. (Of course, this is what conceptually happens, and
some of the parts are sort-of optimized away in the pipeline or with
special datalines in the CPU. But still, this is essentially what has to
happen when storing a byte.)

With a language having the Hello World in the hundreds of kilobytes, and
only usable outside of x86 Windows/Linux by happenstance, I
find it peculiar if anybody could even imagine an excuse for having
bool be anything else than int size.

---

The above is an issue separate from that of storage. A programmer may
want to use packed bytes to store boolean values in structs, or even bit
arrays. But that is, and should remain his choice.

---

From previous experience (the Bit Datatype days), I wouldn't bet on this
changing too soon. But I sincerely hope I'm wrong this time.
« First   ‹ Prev
1 2