From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA11394 for caml-redistribution; Mon, 25 Oct 1999 17:32:54 +0200 (MET DST) 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 LAA22795 for ; Fri, 22 Oct 1999 11:43:09 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id LAA00592; Fri, 22 Oct 1999 11:42:51 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA22751; Fri, 22 Oct 1999 11:42:50 +0200 (MET DST) Message-ID: <19991022114250.57637@pauillac.inria.fr> Date: Fri, 22 Oct 1999 11:42:50 +0200 From: Xavier Leroy To: John Prevost Cc: Edwin Young , "'caml-list@inria.fr'" Subject: Re: 32 bit integers References: <19991021162400.01237@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from John Prevost on Thu, Oct 21, 1999 at 08:00:12PM -0400 Sender: weis > I found this implementation to be terribly slow (even slower than the > bignum stuff in many cases.) Any idea why this is? Is it just > because of the extra dereference, or is it because the compiler uses > better code for "primitive" type operations like int addition than it > does for other types? Both, actually. Boxing is always expensive, not so much because of the extra dereference, but mostly because of the extra heap allocations. (There are good reasons why the "int" type is tagged instead of boxed in OCaml...) On top of that, all operations on Int32.t are implemented by C functions, and calling a C function from Caml is expensive -- more expensive than calling a Caml function, and much more expensive than open-coding the operations. > (This second was my guess.) Is there any way > to make this kind of extension work better? There is a way, but it involves modifying the compiler itself to add special code generation rules for the primitive operations on the new integer type. - Xavier Leroy