From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <1411330.QJAbfBr5F9@blitz> <1E6996DB-2712-4AC6-A860-B09C06A8638E@quintile.net> <3E93FE94-76BC-4B38-9FB2-DEDC5C3CEF9E@quintile.net> Date: Tue, 8 May 2012 15:14:49 -0400 Message-ID: From: Comeau At9Fans To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=14dae939986d51438b04bf8b3321 Subject: Re: [9fans] integer width on AMD64 (was: Re: AMD64 system) Topicbox-Message-UUID: 85c44da6-ead7-11e9-9d60-3106f5b1d025 --14dae939986d51438b04bf8b3321 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 7, 2012 at 8:44 AM, erik quanstrom wrote: > ... > processor bw >> memory bw ==> smaller integers faster > memory bw >> processor bw ==> natural integers faster > > (this is yet another reason that int_fast* are a half-baked idea. > how does the compiler know this relation for the target machine > ahead of time?) ... > I think that is all so, and I'm not necessarily trying to defend its problems, but on the same note, similar assumptions are also make about int, and it can be argued that int_fast* etc just become par for that course, especially given that there may be command line arguments allowing the user to give some of these things a poke so to speak. And this is not alone in those kinds of things (which are probably not even really engineering compromises), for instance, take malloc. -- Greg Comeau / 4.3.10.1 with C++0xisms now in beta! Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries... Have you tried it? --14dae939986d51438b04bf8b3321 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, May 7, 2012 at 8:44 AM, erik quanstrom <quanstro@quanstro.net<= /a>> wrote:
...
=A0 =A0 =A0 =A0processor bw >> memory bw =A0=3D=3D> smaller integ= ers faster
=A0 =A0 =A0 =A0memory bw >> processor bw =A0=3D=3D> natural integ= ers faster

(this is yet another reason that int_fast* are a half-baked idea.
how does the compiler know this relation for the target machine
ahead of time?) ...

I think that is all= so, and I'm not necessarily trying to defend its problems, but on the = same note, similar assumptions are also make about int, and it can be argue= d that int_fast* etc just become par for that course, especially given that= there may be command line arguments allowing the user to give some of thes= e things a poke so to speak. =A0And this is not alone in those kinds of thi= ngs (which are probably not even really engineering compromises), for insta= nce, take malloc.

--
Greg Comeau / 4.3.10.1 with C++0xisms now = in beta!
World Class Compilers: =A0Breathtaking C++, Amazing C99, Fabulous C90.=
Comeau C/C++ with Dinkumware's Libraries... Have you tried i= t?

--14dae939986d51438b04bf8b3321--