Thread overview | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
May 15, 2008 opEquals needs to return bool | ||||
---|---|---|---|---|
| ||||
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 Re: opEquals needs to return bool | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | "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 Re: opEquals needs to return bool | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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 Re: opEquals needs to return bool | ||||
---|---|---|---|---|
| ||||
Posted in reply to Edward Diener | 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 Re: opEquals needs to return bool | ||||
---|---|---|---|---|
| ||||
Posted in reply to Edward Diener | == 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 Re: opEquals needs to return bool | ||||
---|---|---|---|---|
| ||||
Posted in reply to Edward Diener | 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 Re: opEquals needs to return bool | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | == 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 Re: opEquals needs to return bool | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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 Re: opEquals needs to return bool | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | 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 Re: opEquals needs to return bool | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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.
|
Copyright © 1999-2021 by the D Language Foundation