Thread overview | |||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 20, 2006 int opEquals(Object), and other legacy ints | ||||
---|---|---|---|---|
| ||||
There seem to be a number of leftovers from before we had a bool type, and many people were using the int type to pass booleans around. The most obvious is int opEquals(Object) defined in the Object class. Changing this'll break a considerable amount of existing code - but then again, the 0.163 change of making imports private by default has done this already. But there are many functions in Phobos that can be cleaned up a bit without doing much harm. Just to name a few.... std.string.iswhite std.string.inPattern std.ctype.isalnum (indeed, most of the functions in std.ctype) std.file.exists std.file.isfile std.file.isdir std.intrinsic.bt std.intrinsic.btc std.intrinsic.btr std.intrinsic.bts std.math.isnan (and other is* functions) std.math.signbit Going through the other modules will probably reveal many more, but I haven't checked. Stewart. |
July 21, 2006 Re: int opEquals(Object), and other legacy ints | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | Stewart Gordon wrote:
> There seem to be a number of leftovers from before we had a bool type, and many people were using the int type to pass booleans around.
They are typed as returning int for efficiency reasons. These functions often appear in performance critical loops, where an extra instruction or two makes a difference.
|
July 21, 2006 Re: int opEquals(Object), and other legacy ints | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright wrote: > Stewart Gordon wrote: >> There seem to be a number of leftovers from before we had a bool type, and many people were using the int type to pass booleans around. > > They are typed as returning int for efficiency reasons. These functions often appear in performance critical loops, where an extra instruction or two makes a difference. But isn't bool an int internally? Why is it less efficient to use a bool? -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D |
July 21, 2006 Re: int opEquals(Object), and other legacy ints | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bruno Medeiros | "Bruno Medeiros" <brunodomedeirosATgmail@SPAM.com> wrote in message news:e9qd21$2ueu$2@digitaldaemon.com... > But isn't bool an int internally? Why is it less efficient to use a bool? It's a byte internally. |
July 21, 2006 Re: int opEquals(Object), and other legacy ints | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bruno Medeiros | Bruno Medeiros wrote:
> Walter Bright wrote:
>> Stewart Gordon wrote:
>>> There seem to be a number of leftovers from before we had a bool type, and many people were using the int type to pass booleans around.
>>
>> They are typed as returning int for efficiency reasons. These functions often appear in performance critical loops, where an extra instruction or two makes a difference.
>
> But isn't bool an int internally? Why is it less efficient to use a bool?
It's a byte internally, and is constrained to be one of the values 0 or 1.
|
July 27, 2006 Re: int opEquals(Object), and other legacy ints | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright wrote: > Bruno Medeiros wrote: >> Walter Bright wrote: >>> Stewart Gordon wrote: >>>> There seem to be a number of leftovers from before we had a bool type, and many people were using the int type to pass booleans around. >>> >>> They are typed as returning int for efficiency reasons. These functions often appear in performance critical loops, where an extra instruction or two makes a difference. >> >> But isn't bool an int internally? Why is it less efficient to use a bool? > > It's a byte internally, and is constrained to be one of the values 0 or 1. Duh, it's a byte of course, I should have checked that. But the question remains, is it then less efficient to return a byte than a int? Why? And if so isn't there a way for the compiler to somehow optimize it? I find it a bit hard to believe that nowadays there isn't sufficient compiler and/or CPU technology to somehow make a bool(byte) return value as efficient as a int one. :/ -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D |
July 28, 2006 Re: int opEquals(Object), and other legacy ints | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bruno Medeiros |
>> It's a byte internally, and is constrained to be one of the values 0 or 1.
>
> Duh, it's a byte of course, I should have checked that.
>
> But the question remains, is it then less efficient to return a byte than a int? Why? And if so isn't there a way for the compiler to somehow optimize it?
> I find it a bit hard to believe that nowadays there isn't sufficient compiler and/or CPU technology to somehow make a bool(byte) return value as efficient as a int one. :/
Well, I'm just guessing, but I think something like
> int opEquals(Foo foo)
> {
> return this.bar == foo.bar;
> }
is compiled to something like
> return this.bar-foo.bar; // 1 instruction
but if the return type is bool, it becomes
> return this.bar-foo.bar?1:0; // 3 instructions
It's the 1/0 constraint on bools that causes the slowness, not the size (stack is usually size_t-aligned anyway)
xs0
|
July 28, 2006 Re: int opEquals(Object), and other legacy ints | ||||
---|---|---|---|---|
| ||||
Posted in reply to xs0 | xs0 wrote: <snip> > Well, I'm just guessing, but I think something like > > > int opEquals(Foo foo) > > { > > return this.bar == foo.bar; > > } > > is compiled to something like > >> return this.bar-foo.bar; // 1 instruction > > but if the return type is bool, it becomes > >> return this.bar-foo.bar?1:0; // 3 instructions If it does this, then there's a serious bug in the compiler. Moreover, what's your evidence that subtracting one number from another might be more efficient than comparing them for equality directly? > It's the 1/0 constraint on bools that causes the slowness, not the size (stack is usually size_t-aligned anyway) But if the function only tries to return 0 or 1 anyway, then what difference does it make? At the moment, I can't think of an example of equality testing that can be made more efficient by being allowed to return a value other than 0 or 1. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit. |
July 29, 2006 Re: int opEquals(Object), and other legacy ints | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bruno Medeiros | Bruno Medeiros wrote: > But the question remains, is it then less efficient to return a byte than a int? Yes. It's also less efficient to constrain the results to 0 or 1. > Why? Consider: a = 0x1000; b = 0x2000; Now convert (a == b) into a bool. If the result is an int, I can just do (a - b), one instruction. Converting it to a byte, or to 1 or 0, takes more. > And if so isn't there a way for the compiler to somehow optimize it? The math is inevitable <g>. > I find it a bit hard to believe that nowadays there isn't sufficient compiler and/or CPU technology to somehow make a bool(byte) return value as efficient as a int one. :/ I work with what the CPU makes available. P.S. Inevitably, some will ask "who cares" about these small efficiencies. The trouble is, these kinds of things often appear in tight loops, where small inefficiencies get multiplied by millions. |
July 29, 2006 Re: int opEquals(Object), and other legacy ints | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | Stewart Gordon wrote: > xs0 wrote: > <snip> >> Well, I'm just guessing, but I think something like >> >> > int opEquals(Foo foo) >> > { >> > return this.bar == foo.bar; >> > } >> >> is compiled to something like >> >>> return this.bar-foo.bar; // 1 instruction >> >> but if the return type is bool, it becomes >> >>> return this.bar-foo.bar?1:0; // 3 instructions > > If it does this, then there's a serious bug in the compiler. What instruction sequence do expect to be generated for it? > Moreover, what's your evidence that subtracting one number from another might be more efficient than comparing them for equality directly? The only difference between a CMP and a SUB instruction is where the result ends up. But the CMP doesn't generate 0 or 1 as a result, it puts the result in the FLAGS register. Converting the FLAGS to a 0 or 1 in a register takes more instructions. >> It's the 1/0 constraint on bools that causes the slowness, not the size (stack is usually size_t-aligned anyway) > > But if the function only tries to return 0 or 1 anyway, then what difference does it make? At the moment, I can't think of an example of equality testing that can be made more efficient by being allowed to return a value other than 0 or 1. I can. (a == b), where a and b are ints, can be implemented as (a - b), and the result is int 0 for equality, int !=0 for inequality. |
Copyright © 1999-2021 by the D Language Foundation