caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Markus Mottl <markus.mottl@gmail.com>
To: Yotam Barnoy <yotambarnoy@gmail.com>
Cc: Ocaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Expanding the Float Array tag
Date: Mon, 16 Sep 2013 12:29:26 -0400	[thread overview]
Message-ID: <CAP_800rsmZymec9cLuMdFNJncoCxfUXqUw18cEnYNhpg-yjBGA@mail.gmail.com> (raw)
In-Reply-To: <CAN6ygOnK+xut5W0poyzrZcC770kwZ4VgKY1du=bUsPhOeCP7sg@mail.gmail.com>

On Mon, Sep 16, 2013 at 11:26 AM, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
> Having looked through some of the ocaml runtime's code, I have a question
> regarding the Double_array block tag. Why not use a single tag for all block
> content that doesn't contain pointers instead? This would allow optimization
> of all cases where no pointers are involved, including float tuples, records
> with ints, bools and floats etc.

Floats are a little tricky, because they are always doubles (64 bits),
even on 32-bit platforms.  This requires some special identification.

Adding new tags by reducing the "No_scan_tag" might be a bad (and not
backward compatible) approach, too: the maximum number of non-constant
constructors is already pretty low at 246.  I think this number is too
small these days where 64-bit platforms are standard.  It's probably
hard to change this design decision now by reducing the overly
generous maximum "wosize".  Some automatically generated APIs can
easily blow the current limit on non-constant constructors and require
annoying, less efficient workarounds.

I guess it might be possible to allocate blocks that are known to be
all integers or atomic sum types by using the already available
Abstract_tag.  Large arrays would benefit most from that.  Doing this
in the compiler might break old marshaled data.  But if performance is
really critical, I could imagine trying that in a library with
well-hidden type representations.

Regards,
Markus

-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com

  reply	other threads:[~2013-09-16 16:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-16 15:26 Yotam Barnoy
2013-09-16 16:29 ` Markus Mottl [this message]
2013-09-16 16:49   ` Yotam Barnoy
2013-09-16 17:14     ` Markus Mottl
2013-09-16 19:09       ` Yotam Barnoy
2013-09-17  0:31         ` Yotam Barnoy
2013-09-19  9:40     ` Goswin von Brederlow
2013-09-17  9:32 ` Gerd Stolpmann
2013-09-18 15:10   ` Yotam Barnoy
2013-09-19  6:18     ` oleg
2013-09-19  9:47       ` Goswin von Brederlow
2013-09-19 10:10     ` Goswin von Brederlow
2013-09-20  2:18       ` Yotam Barnoy
2013-09-20  6:25         ` 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=CAP_800rsmZymec9cLuMdFNJncoCxfUXqUw18cEnYNhpg-yjBGA@mail.gmail.com \
    --to=markus.mottl@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=yotambarnoy@gmail.com \
    /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).