Re: Introduce proper bool types - finally.
>>>> "Jan" == Jan Vroonhof
<vroonhof(a)math.ethz.ch> writes:
Jan> [I am moving this to -beta]
Jan> Martin Buchholz <martin(a)xemacs.org> writes:
> Is it really so bad to be able to say
> static size_t
> Lstream_adding (Lstream *lstr, size_t num, bool force)
> ...
> size_t chunk = Lstream_adding (lstr, size, false);
Jan> No. But it doesn't have that warm comfy feeling :-)
> Having done some benchmarking, I hereby retract the part of the
patch
> that defined a bool type that occupies a char. The first compiler I
> tried gave a 17% performance improvement in (garbage-collect) by
> making the mark bit a char. However, other compilers have not
> confirmed the advantage of this change - some work the other way
> around.
>
> Jan: By the way, this means that I'm not sure I believe your 10%
> redisplay speedup is for real - you might have just been lucky with
> your choice of compiler and machine.
Jan> Note that that choice included Solaris with its native compiler and
Jan> egcs 1.1 on i386 so I think it covers the majority of users.
Jan> However I frankly do not believe that this patch could cause a
Jan> slowdown anywhere. it does not increase the size of the structure. Are
Jan> there really compilers/machine that are faster at masking off bits
Jan> then at reading bytes. What I can believe is that there isn't a speed
Jan> up on machine that cannot do byte addressing and thus have to masking
Jan> for that too..
The obvious bit that wants to be optimized is the mark bit during
garbage collection. And yet changing it to a char caused changes
ranging all over the place:
x86 Cygnus C compiler: +16%
x86 gcc 2.95.2: +0%
sparc Sun cc: -2%
sparc gcc 2.95.2: -6%
Let's just say that optimizing a heavily accessed boolean is highly
machine and compiler dependent - may as well just use a bit.
> So let's just talk about `bool'. Is it so bad to have a
type that
> expresses the idea of a `bit' in a standard way? After all, Elisp
> also knows about bits.
>
> This patch seems to be going down in flames, but I'd really like to
> know why there is such *strong* opposition.
Jan> Because I like the fact that in C truth values (not bits) are
Jan> represented by numbers. I simply do not see the use of introducing
Jan> bolos. For instance in the example above I do not see any gain in
Jan> clarity.
Jan> It might make sense in languages that are much more strongly typed but
Jan> I cannot see it in C.
It's purely a documentation device. Have you never wondered whether
an `int' variable in C was logically a boolean or not? A name like
`force' for the variable name still might leave one wondering.
I grew up programming in a language where `?' was valid in identifier
names. It was standard practice for boolean variables to be named `foo?'
Martin