Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Uncle Steve Newsgroups: comp.lang.c Subject: Re: Types in C Date: Mon, 23 May 2011 23:56:32 -0400 Organization: Friends of the Galactic Collective Lines: 72 Message-ID: <3f20bcd1c8b23d8-db1ae@gmail.com> References: <43d4ef5f7d2b0f9-0f635@gmail.com> <848fd4a481072a3-7a4d3@gmail.com> <5e3bc1901a4e1d6-bdea9@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: mx04.eternal-september.org; posting-host="job9yP/rmK/fxQbJrcqEcA"; logging-data="20727"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18EPYM0E93/1dIgdT37O5R5" User-Agent: nn 6.7.3 Content-Length: 3075 Cancel-Lock: sha1:l87rj5FMLi6cb0xP+ZepEsivDmw= Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:4662 On Tue, May 24, 2011 at 01:58:03AM +0000, Seebs wrote: > On 2011-05-24, Uncle Steve wrote: > > On Mon, May 23, 2011 at 11:57:11PM +0000, Seebs wrote: > >> Don't know the size. Know the *minimum* size. You don't actually need > >> to know whether something is 32 bits, you just need to know that it's at > >> least big enough to hold some particular value. For all you know you're > >> getting a 64-bit type because that's what's fast on this hardware. > > > If I define a variable as a 32-bit integer, by definition I know what > > its range of values are. If I try to exceed that range, it is > > programmer error. If I port my code to a different platform, > > the typedefs for those types will get made so they are consisted with > > the x86 port, if possible. I don't see how that can be bad. > > It can be bad because you might end up on a machine where 32-bit types > are intrinsically slower than 64-bit types, so by mandating that ONLY > 32 bits be used, you're slowing the program down. I suppose it's possible, but that seems a bit like putting the cart before the horse. If I say "do not blaspheme" because it might piss-off God, I am presupposing the existence of God, which could very well be false. You are presupposing that a hardware manufacturer is going to build a CPU with those characteristics. How likely is that? > > I think platform specific code will (almost?) always be quicker than > > generalized code that compiles and runs on multiple architectures > > unmodified. > > Sometimes! > > > I think you're going to have to show how your logic > > works on this point. > > See above. Imagine that you have something that you know only needs to > be 16 bits, so you specify i16 for it. You have an array of them. You're > on a machine where access on anything other than 64-bit boundaries adds > noticeable latency. Poof! Well now. I think I said (or implied) that I was attempting to avoid constructs that break when assumptions about type sizes are wrong. You seem to be saying that program correctness is subordinate to performance in this instance. I beg to differ. > This kind of thing really does happen. There's a reason C gives minimum > ranges for the basic types. I suppose it does, but I am not going to assume something for which there is no supporting evidence, in relation to this particular topic. > Machine-specific code which does something that's stupid on a particular > machine is not faster than portable code which lets the compiler pick > something smart. > In general, the vast majority of code does not gain any performance from > trying to be more machine-specific, and the cases where it hurts, it hurts > BADLY. Exploding software hurts too. At any rate, I'm not being machine-specific, I am attempting to be type-specific within an arbitrary algorithm across multiple platforms. Those are two very different approaches. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?