From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA15808 for caml-red; Fri, 12 Jan 2001 10:00:32 +0100 (MET)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA04621 for <caml-list@pauillac.inria.fr>; Thu, 11 Jan 2001 19:34:11 +0100 (MET)
Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35])
	by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f0BIY8j00479;
	Thu, 11 Jan 2001 19:34:08 +0100 (MET)
Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA04530; Thu, 11 Jan 2001 19:34:07 +0100 (MET)
Date: Thu, 11 Jan 2001 19:34:07 +0100
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Norman Ramsey <nr@eecs.harvard.edu>
Cc: caml-list@inria.fr
Subject: Re: questions about costs of nativeint vs int
Message-ID: <20010111193407.A4332@pauillac.inria.fr>
References: <200101101825.NAA17093@labrador.eecs.harvard.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200101101825.NAA17093@labrador.eecs.harvard.edu>; from nr@eecs.harvard.edu on Wed, Jan 10, 2001 at 01:25:27PM -0500
Sender: weis@pauillac.inria.fr

Dear Norman,

> We're designing interfaces for tools that will sometimes have to
> manipulate 32-bit integers, but will often be able to make do with the
> limited precision provided by the int type.  I would love to get some
> information about the relative cost of int vs nativeint in both
> parameter passing and datatype representation.

Values of type "nativeint", "int32" and "int64" are boxed
(heap-allocated and handled through a pointer), while values of type
"int" are unboxed.  So, in terms of space, we have:
        nativeint       1 word for the pointer + 2 words for the heap block
        int32           same
        int64           same on 64-bit machines, add 1 word for a 32-bitter
        int             1 word for the data
In terms of speed, operations on boxed integers are more expensive due
to the extra loads (on operands) and heap allocations (on results).
ocamlopt can avoid loads and allocations that cancel each other in
simple cases, but the fact remains that nativeint arithmetic is more
expensive than int arithmetic.

> For example, what are the relative costs (e.g., memory requirements)
> of these two definitions?
> 
>   type loc = Cell of char * int * width
>            | Slice of ...
> 
>   type loc' = Cell of char * nativeint * width
>             | Slice of ...

A "Cell" requires two more memory words in the latter case.

> As another example, what are the costs of calling these functions:
> 
>   type t
>   val add  : rd:int       -> rs1:int       -> rs2:int       -> t
>   val add' : rd:nativeint -> rs1:nativeint -> rs2:nativeint -> t

Assuming the nativeints are already available, the cost is exactly the
same: a pointer is passed instead of an unboxed integer.  However,
computing the nativeint arguments in the first place can be more expensive
if arithmetic operations are involved.

> To extend the question, what happens if I use int32 or int64 in place
> of nativeint?

No major differences.  On a 32-bit processor, int64 requires one more
memory word than the other two.  And of course 64-bit arithmetic is
slower than 32-bit arithmetic on a 32-bit processor.

Actually, "nativeint" is isomorphic to "int32" on a 32-bit platform
and to "int64" on a 64-bit platform.  The reason for having all three
types is that some applications require 32-bit integers (no more, no
less, regardless of the platform), some require 64-bit integers, and
some just want to get at the natural word size for the architecture.

> Finally, a procedural question: should I be posting these sorts of
> questions to comp.lang.ml instead of sending them to
> caml-list@inria.fr?

For technical questions about the Caml implementation, I think you get
a better chance of a reply here on caml-list.

All the best,

- Xavier