Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Java versus C Speed Comparison

Author: Miguel A. Ballicora

Date: 09:59:10 01/14/03

Go up one level in this thread


On January 13, 2003 at 22:55:11, Robert Hyatt wrote:

>On January 13, 2003 at 03:16:32, Miguel A. Ballicora wrote:
>
>>On January 12, 2003 at 13:43:00, Matt Taylor wrote:
>>
>>>On January 12, 2003 at 02:26:25, Miguel A. Ballicora wrote:
>>>
>>>>On January 11, 2003 at 19:23:19, Robert Hyatt wrote:
>>>>
>>>>[snip]
>>>>
>>>>>>>But it is a headache that could be eliminated.  IE on a PC you know that
>>>>>>>short=16, int=32, long=32 and long long=64.  But _only_ on a PC.  It would
>>>>>>>be nice to know something about specific types that applies to _all_
>>>>>>>architectures...
>>>>>>>int8, int16, int32 and int64 would do just fine since the older architectures
>>>>>>>with 36, 48 and 60 bits are pretty much history...
>>>>>>
>>>>>>You assume that those architectures are history, that might be true today but C
>>>>>>was not born today.
>>>>>
>>>>>Standards were done _recently_ again.
>>>>>
>>>>>three years ago in fact..
>>>>
>>>>Now I really don't know what this thread is about. It is about standard C in his
>>>>whole history (1) or is it about stantard C today (2)?
>>>>
>>>>If it is 1, you cannot neglect the other architectures.
>>>>It is is 2, C99 includes the types that you want, and I don't understand then
>>>>your criticism to the standard.
>>>>
>>>>Miguel
>>>
>>>It is about both. Myself and others like David have argued that those
>>>int16/int32 types could have been in from the start with no threat to
>>>implementation on machines with 36-bit words or other oddities.
>>
>>Not at all, historically at that point it did not make sense. Moreover, it could
>>have been int36 and not int32. Unix ran in 36 bit machines too.
>>One of the several reasons why C had a tremendous success was because it has
>>been linked to Unix, which was ported between machines of different word sizes.
>>Another, citing Dennis Ritchie:
>>"...C remains a simple and small language, translatable with simple
>>and small compilers..."
>>
>>So the spirit was to make it fast, efficient, small and not giving too much.
>>Very practical. Introducing int32 was probably the least of the things that D.
>>Ritchie wanted at that time.
>>
>>Another reason for success:
>>"...Although C was not originally designed with portability as a prime goal,
>>it succeeded in expressing programs, even including operating systems,
>>on machines ranging from the smallest personal computers through the mightiest
>>supercomputers..." (Dennis Ritchie)
>>
>>>I have further argued that special recognition of the suffix would allow the
>>>compiler to be extensible. The only operations that are more difficult to
>>>emulate at larger lengths are multiply and divide. All your basic bitwise
>>>operations are easy because each bit is seperate. For brevity I will ignore
>>>arithmatic operations (add/sub/mul/div), though there are techniques for
>>>implementing them in straight C, and most general-purpose machines have
>>>facilities to emulate.
>>>
>>>C99 has addressed current issues, but C99 -still- lacks foresight to address
>>>future issues. A 128-bit encryption algorithm is easier to implement using
>>
>>I think that this is not really related to the origin of the debate, which is
>>about strict types. This is more related to the size of them in the future, not
>>if they exist well defined (int32) or not (int).
>>IMHO, I do not think that it is practical to _force_ compilers to deal with such
>>numbers when still common machines do not support that at all. I guess that it
>>is more efficient for people in this area to use their own libraries and
>>algorithms. I guess that they would do it anyway in search for efficiency if the
>>machines does not support them, but I here I might be wrong. Since I am not an
>>expert on this, it is just a guess.
>>>128-bits. On machines that support it, it is also optimal. Current standards
>>>make no guarantees that such a type is available. Therefore it cannot be taken
>>>advantage of unless the programmer adds #ifdef glue to support platforms where
>>>no such type is available. This is resolved easily and gracefully if you accept
>>>that the standard is not perfect. The underlying problem has -NOT- been
>>>addressed by the long long type. It has merely been postponed.
>>>
>>>You said something in another post about C not being high-level. So? Do you
>>
>>I never said that.
>>
>>>think this idea is any more abstract than short/int/long? Should we code loops
>>>using conditional gotos? The level of abstraction that C supports is well beyond
>>>the level of abstraction required for types of explicit size.
>>>
>>>The argument that they are difficult to implement is likewise fatally flawed.
>>
>>It is not that it is difficult, the point was to make compilers as simple as
>>possible. That was one of the keys for success as Ritchie thinks.
>>
>>Miguel
>
>
>I believe this is "wishful remembering" on his part.  C was not developed
>and used on a supercomputer, nor on a 36 bit machine, until _years_ after
>it was originally written.  It was originally written for a Digital PDP and

According to Dennis Ritchie, C was developed in a PDP-11 but it was ported in
the same period to a Honeywell 635 (36 bits).

>nothing else.  As was unix.  years later it started to get ported to other

Unix was developed originally in an 18 bits computer (PDP-7), written in B.

Miguel



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.