caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Yotam Barnoy <yotambarnoy@gmail.com>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: Ocaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] How much optimized is the 'a option type ?
Date: Mon, 27 Jan 2014 11:18:23 -0500	[thread overview]
Message-ID: <CAN6ygOkuGLUJ+WR+FKZLJ+2imRsk9qZKxobsSt+hpi4PtiR07A@mail.gmail.com> (raw)
In-Reply-To: <20140127152944.GA29326@frosties>

[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]

>
> But you can't just put a float 42.0 on the heap or even stack when the
> GC might get called. That needs to be boxed in some way to avoid it
> getting misread as pointer.
>
>
It wouldn't be too hard to add a word of metadata to the stack to tell the
GC what's a pointer and what isn't. Haskell does this for function calls
(in fact, if the metadata doesn't fit in a word, it allocates a separate
metadata structure), and F# has this from the .NET runtime which has full
type metadata for everything.

Problem is that a value is a fixed size and fits in a register. A
> tuple does not. (int * float) even takes the space of 3 values on
> 32bit. You can unbox that in the optimizer for local use but in memory
> and in function calls you need to pass this as box. Otherwise
> polymorphic functions break.
>
> Putting larger structures into an array without boxing also only works
> for immutable objects and by copying them every time they are passed
> around. You can't copy a mutable and you can't pass a pointer to the
> middle of an array to another function or the GC might freak out.
>

Leaving it to the optimizer is problematic because it might cause a lot of
unneeded boxing and unboxing.
Haskell has the {- #UNPACK -} pragma to unbox types. You have to be really
careful in haskell with this, because you're also changing the evaluation
semantics to be strict. This makes for really ugly optimized haskell code,
but maybe we can do something similar (but not as ugly). F# inherits .NET's
struct types, which are similarly limited, but also useful. Of course, once
you unbox, all parametric polymorphism is lost, but because you have
control over it, you can decide where it's worthwhile.

An example of unpack usage in haskell:

data T = T {-# UNPACK #-} !(Int,Int)

which would be equivalent to something like
type t = (int * int) [@u]

Note that the whole tuple is unboxed.

In haskell, you can now do

f :: T -> Int
f (T(i1,i2)) = i1 + i2

and in ocaml you'd do

let f : t -> int = fun (i1,i2) = i1 + i2

Of course, this would require more metadata for the stack. For the heap,
you'd probably want to just use a new tag or the custom tag. For ocaml
you'd also probably have to stipulate that polymorphic marshalling cannot
be performed on this type, and neither can polymorphic comparison -- you'd
have to have specific marshalling/comparison functions, which aren't too
difficult to generate automatically.

-Yotam



>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 3898 bytes --]

  reply	other threads:[~2014-01-27 16:18 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-17  7:35 Damien Guichard
2014-01-17  7:55 ` David House
2014-01-17  8:16   ` Julien Blond
2014-01-17  8:40     ` David House
2014-01-17  9:10       ` Gabriel Scherer
2014-01-17  9:22         ` Simon Cruanes
2014-01-17 17:57           ` Gerd Stolpmann
2014-01-18  1:35             ` Jon Harrop
2014-01-19  6:19               ` oleg
2014-01-21  1:51                 ` Francois Berenger
2014-01-18  1:01         ` Jon Harrop
2014-01-24 10:06         ` Alain Frisch
2014-01-24 10:16           ` Alain Frisch
2014-01-24 13:32             ` Yaron Minsky
     [not found]       ` <CAK=fH+jfi=GsMYBZzmuo=V5UAWimyxiiamY2+DkLg6F0i8XHGw@mail.gmail.com>
2014-01-17  9:11         ` David House
2014-01-17 11:23           ` Jonathan Kimmitt
2014-01-17 13:46             ` Nicolas Braud-Santoni
2014-01-17 13:56               ` Frédéric Bour
2014-01-17 14:02               ` Yaron Minsky
2014-01-17 14:09                 ` Simon Cruanes
2014-01-17 22:52                   ` Yaron Minsky
2014-01-18  1:37                   ` Jon Harrop
2014-01-17 14:24                 ` Gabriel Scherer
2014-01-17 22:29                   ` Yaron Minsky
2014-01-18  1:27                 ` Jon Harrop
2014-01-18  1:18             ` Jon Harrop
2014-01-20 10:16             ` Goswin von Brederlow
2014-01-20 11:23               ` Jonathan Kimmitt
2014-01-21  2:05                 ` Francois Berenger
2014-01-22 21:22                   ` Jon Harrop
2014-01-22 21:26               ` Jon Harrop
2014-01-23  9:29                 ` Goswin von Brederlow
2014-01-23 23:20                   ` Jon Harrop
2014-01-23 23:28                     ` Yotam Barnoy
2014-01-24  8:22                       ` Jon Harrop
2014-01-24  8:34                         ` Andreas Rossberg
2014-01-24 16:56                           ` Jon Harrop
2014-01-27 15:29                             ` Goswin von Brederlow
2014-01-27 16:18                               ` Yotam Barnoy [this message]
2014-01-29  7:56                                 ` Goswin von Brederlow
2014-01-29  8:32                                 ` Jon Harrop
2014-01-29 16:11                                   ` Yotam Barnoy
2014-01-30 18:43                                     ` Yotam Barnoy
2014-02-01 15:58                                       ` Goswin von Brederlow
2014-01-30 21:31                                     ` Jon Harrop
2014-01-30 21:43                                       ` Yotam Barnoy
2014-01-31  8:26                                         ` Jon Harrop
2014-02-01 15:40                                 ` Goswin von Brederlow
2014-01-27 10:03                         ` Goswin von Brederlow
2014-01-17 14:36 ` Markus Mottl
2014-01-17 15:49   ` Yotam Barnoy
2014-01-17 16:22     ` Markus Mottl
2014-01-20 10:09   ` Goswin von Brederlow

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=CAN6ygOkuGLUJ+WR+FKZLJ+2imRsk9qZKxobsSt+hpi4PtiR07A@mail.gmail.com \
    --to=yotambarnoy@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=goswin-v-b@web.de \
    /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;
as well as URLs for NNTP newsgroup(s).