Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: [OT programming rant] The int type 'ought to be' fast...

Author: Eugene Nalimov

Date: 21:46:44 06/15/00

Go up one level in this thread


Unfortunately, backward compatibility sometimes is more important than
performance/reliability/(you name it).

Eugene

On June 15, 2000 at 20:02:26, Dann Corbit wrote:

>On June 15, 2000 at 19:10:32, Eugene Nalimov wrote:
>>That's not true for some systems. Int is still 32 bits, but "natural" word size
>>is 64 bits.
>
>regarding:
>[snip]
>T.K.:
>>>Just define everything in your program as an int. It will automatically use the
>>>processor's word size, so problem solved. :)
>>>-Tom
>
>If a compiler implements a word size for int which is not as fast as the natural
>word size, then they have violated the spirit of the language.  The original
>intention was that it would be either the natural word size or the fastest
>integral type.
>
>Now, with C99, we have all these "fast" types:
>
>int_fast8_t               uint_fast8_t
>int_fast16_t              uint_fast16_t
>int_fast32_t              uint_fast32_t
>int_fast64_t              uint_fast64_t
>
>as defined in <stdtypes.h>
>
>But I think the old paradigm of just code as int when you want the fastest
>choice for an integral type was a lot better.  On the other hand, maybe we can
>squeeze a hair more of performance out of this new stuff so it's not all bad.
>
>There are lots of things that "gross me out" in the new language standard (don't
>even get me started on 'long long') but I can live with it.
>
>But if someone declares an int and does not get the fastest integral type for
>that machine, I think it was a bad compiler writer decision.



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.