[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141203050334.GF4574@brightrain.aerifal.cx>
Date: Wed, 3 Dec 2014 00:03:34 -0500
From: Rich Felker <dalias@...c.org>
To: Glenn Weinberg <glenn@...nitive-electronics.com>
Cc: musl@...ts.openwall.com
Subject: Re: Further limits/stdint issues
On Tue, Dec 02, 2014 at 11:10:58PM -0500, Glenn Weinberg wrote:
>
> > On Dec 2, 2014, at 8:02 PM, Rich Felker <dalias@...c.org> wrote:
> >
> > The fast16/fast32 types and limits are still in bits/stdint.h despite
> > not varying between archs. Removing those would make bits/stdint.h
> > tiny/trivial. Aside from PAGE_SIZE, both bits/limits.h and
> > bits/stdint.h would essentially have no information except
> > "long/pointer size" and maybe we could even eventually eliminate them
> > by having a global idea of "wordsize".
>
> I don't think it's safe to make such assumptions. Our architecture
> is native 64-bit, so we define all the fast types as 64-bit.
Could you elaborate on your motivations? There's no inherent reason
that the fast types should be defined as 64-bit just because the
native word size is 64-bit, and there are lots of reasons against it.
Lots of people misinterpret the "fast" types as "fast unit for moving
data", i.e. in the sense of "given N bytes of data to move, what's the
fastest type to move it as?" This is not the meaning the C language
assigns to them; in fact this sense is rather meaningless since C does
not permit the aliasing that would be needed to move data as any type
other than its actual type or a character type.
Rather, "fast" is a matter of "given N values, possibly with just N=1,
what type should be used to optimize operations on the value(s)?" In
this sense, it's almost always best for the fast type to be the same
as the least type, unless the least type incurs some heavy penalty
(e.g. a machine that can't do 16-bit loads and stores and has to
emulate them with byte loads/stores or atomic cas on larger words).
As an example, take x86_64, where glibc made their [u]int_fast32_t
types 64-bit. Addition and subtraction are the same speed for 32- or
64-bit operations, and perhaps multiplication is too (?), but division
is significantly slower for 64-bit, and perhaps more importantly,
using 64-bit storage doubles the number of cache lines you use and
effectively halves the size of your cache.
If you have a good reason that the fast types should be 64-bit on some
archs, I'd like to hear it. I'm open to listening to alternative views
on this.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
