Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Bug? Printf, %X and negative numbers
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Ville-Pertti Keinonen <will@e...>
Subject: Re: [Caml-list] Bug? Printf, %X and negative numbers
>> 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