From: Ville-Pertti Keinonen <will@exomi.com>
To: Xavier Leroy <xavier.leroy@inria.fr>
Cc: Ocaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Bug? Printf, %X and negative numbers
Date: Tue, 1 Apr 2003 21:34:31 +0300 [thread overview]
Message-ID: <9437813A-6470-11D7-848D-000393863F70@exomi.com> (raw)
In-Reply-To: <20030401101946.B14164@pauillac.inria.fr>
>> 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
next prev parent reply other threads:[~2003-04-01 18:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-28 21:19 Brian Hurt
2003-03-28 22:21 ` Yutaka OIWA
2003-03-30 9:51 ` Xavier Leroy
2003-03-31 15:44 ` Brian Hurt
2003-03-31 17:13 ` Ville-Pertti Keinonen
2003-04-01 8:19 ` Xavier Leroy
2003-04-01 16:09 ` David Brown
2003-04-01 16:45 ` Tim Freeman
2003-04-01 18:59 ` Brian Hurt
2003-04-01 19:16 ` Ville-Pertti Keinonen
2003-04-01 19:23 ` Tim Freeman
2003-04-01 21:00 ` Ville-Pertti Keinonen
2003-04-01 19:56 ` Brian Hurt
2003-04-01 20:45 ` Ville-Pertti Keinonen
2003-04-01 21:03 ` Brian Hurt
2003-04-02 8:55 ` Andreas Rossberg
2003-04-02 9:20 ` Ville-Pertti Keinonen
2003-04-01 18:34 ` Ville-Pertti Keinonen [this message]
2003-04-02 11:44 ` Claude Marche
2003-04-02 18:42 Gregory Morrisett
2003-04-02 21:12 ` Ville-Pertti Keinonen
2003-04-02 21:46 ` Lauri Alanko
2003-04-03 17:40 ` Ville-Pertti Keinonen
2003-04-04 16:14 ` Brian Hurt
2003-04-04 17:14 ` Ville-Pertti Keinonen
2003-04-04 17:27 ` Falk Hueffner
2003-04-03 0:52 ` brogoff
2003-04-03 9:29 Fabrice Le Fessant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9437813A-6470-11D7-848D-000393863F70@exomi.com \
--to=will@exomi.com \
--cc=caml-list@inria.fr \
--cc=xavier.leroy@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox