From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA05381; Tue, 1 Apr 2003 20:34:34 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 UAA28080 for ; Tue, 1 Apr 2003 20:34:33 +0200 (MET DST) Received: from mail.exomi.com (mail.exomi.com [217.169.64.72]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h31IYW528187; Tue, 1 Apr 2003 20:34:32 +0200 (MET DST) Received: from exomi.com (unknown [10.0.5.5]) by mail.exomi.com (Postfix) with ESMTP id 2411C5D03; Tue, 1 Apr 2003 21:34:32 +0300 (EEST) Date: Tue, 1 Apr 2003 21:34:31 +0300 Subject: Re: [Caml-list] Bug? Printf, %X and negative numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Ocaml Mailing List To: Xavier Leroy From: Ville-Pertti Keinonen In-Reply-To: <20030401101946.B14164@pauillac.inria.fr> Message-Id: <9437813A-6470-11D7-848D-000393863F70@exomi.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam: no; 0.00; caml-list:01 bug:01 printf:01 redesign:01 pointers:01 boxing:01 untagged:01 generic:01 unboxed:01 model:01 generics:01 functor:01 slower:01 compiler:01 tagged:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >> Or, I suppose, we could >> completely redesign Ocaml to use 32-bit ints and do something else to >> differentiate ints from pointers :-). > > If you can find a "something else" that is faster than systematically > boxing the 32-bit ints, you'll be hailed as the savior in compiler > circles :-) I'm probably missing something because I don't see how this should be *that* difficult. There are language implementations that use untagged, at-least-sometimes-unboxed native integers and have garbage collection, and I don't believe they perform horribly. Representation of mixed data and stack frames can be done using various combinations of conservative garbage collection, layout descriptors and selective boxing. This is a matter of choosing a set of compromises. Most such solutions would probably have slightly higher garbage collection and memory overhead than OCaml currently does, but I wouldn't expect all of the possible approaches to perform worse than boxing all integers (with the obvious exception of cases where integers are hardly used). Generic code could be optimized by generating specialized versions of the code for the unboxed/untagged types in cases where the aren't more than, say, two or three unknown types. Unused versions can be eliminated at link time. This could also be done more efficiently and completely by changing the compilation model a bit more. Even with the current tagged integers, specialized versions of generics would significantly increase performance in some cases. Currently integer keys in polymorphic or functor maps are much slower than they need to be. ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners