Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Java versus C Speed Comparison

Author: Matt Taylor

Date: 16:22:57 01/11/03

Go up one level in this thread


On January 10, 2003 at 18:14:09, Miguel A. Ballicora wrote:

>On January 10, 2003 at 17:26:52, Robert Hyatt wrote:
>
>>On January 10, 2003 at 15:58:29, Miguel A. Ballicora wrote:
>>
>>>On January 10, 2003 at 15:06:58, Robert Hyatt wrote:
>>>
>>>>On January 10, 2003 at 12:37:20, Miguel A. Ballicora wrote:
>>>>
>>>>>On January 10, 2003 at 11:10:07, Robert Hyatt wrote:
>>>>>
>>>>>>On January 10, 2003 at 05:12:04, David Rasmussen wrote:
>>>>>>
>>>>>>>On January 09, 2003 at 17:36:11, Robert Hyatt wrote:
>>>>>>>
>>>>>>>>I think the entire concept of "short", "int" and "long" are badly flawed.  It
>>>>>>>>would
>>>>>>>>have been so much more logical and clean to simply go with int16, int32 and
>>>>>>>>int64.
>>>>>>>>
>>>>>>>>I don't personally like "long long" as it is a syntactical oddity in light of
>>>>>>>>char, short, int
>>>>>>>>and float/double.
>>>>>>>
>>>>>>>There is a reasonable explanation for this at least. The idea is that "int"
>>>>>>>should be whatever is the most natural entity of integer calculalation on a
>>>>>>>machine. In many cases, you don't care how many bits a type can store. The lower
>>>>>>>limits given by the standards is enough. You just want to know that by writing
>>>>>>>"int" you get something that on every platform is supposed to be simple, fast,
>>>>>>>signed (no weird problems with subtraction etc.),
>>>>>>
>>>>>>But _not_ for "real codes".  Do I _really_ want to use int, when it _might_ be a
>>>>>>16 bit value that won't hold the counter I need?
>>>>>>
>>>>>>No.
>>>>>
>>>>>You can use long, as you say below, if you really need bigger values than the
>>>>>ones provided by 16 bits. I do not think this is a big deal.
>>>>>
>>>>>Miguel
>>>>
>>>>
>>>>That's the point.  On a Cray, I want to use "int" and get 32 bits, vs using long
>>>>and getting
>>>
>>>Just use int :-)
>>
>>Won't work.
>>
>>I need a 32 bit counter.  I need a 64 bit bitboard.  I need a 16 bit index.
>
>Use int, long (or long long) and int, respectively. I fail to see the the
>problem.
>
>>What works on the Cray will fail on the PC, because "long" works for the
>>Cray/Alpha but not for the PC if I want a 64 bit integer...
>
>If you want portable code, use long long for both. If it is a very important
>variable use typedef.
>
>>>If you have int16, int32, int64, you never know which one is more suitable for
>>>another processor. Suppose that int16 is enough and you use it, maybe int32 was
>>>faster!
>>
>>However, IO do know which is most suitable for _my_ application.  If I need 64,
>>I
>>want 64, not whatever the compiler says is "best"...
>
>Then you sacrifice performance. Particularly for machines that do not have
>8 bit chars and weird configurations! The performance hit in those cases is must
>be huge. You cannot have 100% portability and best performance at the same time.
>C gives, IMHO, the best compromise. History showed that.
>
>BTW, there is no problem in using a 32 bit integer if you only need 16.
>
>Miguel

Perhaps you should reread what you posted.

If there is no harm in casting a 16-bit integer up to 32-bits for efficiency,
why not have a second form of int16 that allows the compiler to cast upward?
This is better than making assumptions about short. If you have a machine able
to do efficient 16-bit arithmetic, wouldn't it be better to let the compiler use
16-bit arithmetic rather than hope that short is 16-bits?

If you fail to see a problem with short/int/long scheme, then you've also failed
to look into the future. For instance, the current x86 architecture can address
1-byte, 2-bytes, 4-bytes, 8-bytes, or 16-bytes. Current implementations do not
allow 128-bit (16-byte) types because sizeof(long) == sizeof(int). Even if they
did, what would we do when the machine becomes capable of even longer datatypes?

-Matt



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.