caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Yotam Barnoy <yotambarnoy@gmail.com>
To: Gerd Stolpmann <info@gerd-stolpmann.de>
Cc: Ocaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Expanding the Float Array tag
Date: Wed, 18 Sep 2013 11:10:00 -0400	[thread overview]
Message-ID: <CAN6ygOniyQEo421humUzA4eAeMjjJvfXLKePeJounYzANhZ-Kw@mail.gmail.com> (raw)
In-Reply-To: <1379410360.10274.156.camel@zotac>

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

So here is my tentative proposal:

For 32-bit platforms, a specific tag will signify the extra header word.
This word will have 16 bits' worth of tag. I think 65000 tags are enough,
right? This isn't one of those "128KB will always be enough" kind of thing,
is it? The top 16 bits can be used for other things. For example, a
constructor with up to 16 words could specify using a 16-bit bitfield which
of its members are floats. So a constructor with floats would automatically
use the expanded header. An array of records (with no floats) could have
the record size specified in 16 bits.

For 64-bit platforms, the expanded 16-bit tag could reside in the same
header, with one bit extra used to specify the extra header word for any
given tag. With 64 bits available, this extra header can be very powerful:
it could be used to specify 64 words worth of floats for constructors, or
it could specify a 5-bit record size for an array together with 32 bits to
specify the floats in the record.

Yotam


On Tue, Sep 17, 2013 at 5:32 AM, Gerd Stolpmann <info@gerd-stolpmann.de>wrote:

> Am Montag, den 16.09.2013, 11:26 -0400 schrieb Yotam Barnoy:
> > 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.
> >
> > The only use-case I've seen so far for Double_array tags is for
> > polymorphic comparison ie. we need the type information to parse
> > doubles correctly. However, the only default comparison that's valid
> > on an array of anything is an equality comparison, which is easily
> > doable without type information. Therefore, I'm confused as to why
> > this is necessary.
>
> You also need the Double_array tags for normal array accesses on 32 bit
> platforms: If you call a polymorphic function taking an array argument,
> the function doesn't know whether it is called with a float array or a
> normal array. Because of this, the compiler generates a dynamic check
> whether the array is float or something else. For float, every element
> is 64 bits wide, but for anything else it is 32 bits only.
>
> You are right that a special "no-scan" tag would speed up the GC marking
> phase when there are large arrays profiting from it - for all other
> no-scan cases except float.
>
> Gerd
> >
> > Thanks in advance for any answers
> >
> > Yotam Barnoy
> >
>
> --
> ------------------------------------------------------------
> Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
> My OCaml site:          http://www.camlcity.org
> Contact details:        http://www.camlcity.org/contact.html
> Company homepage:       http://www.gerd-stolpmann.de
> ------------------------------------------------------------
>

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

  reply	other threads:[~2013-09-18 15:10 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
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 [this message]
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=CAN6ygOniyQEo421humUzA4eAeMjjJvfXLKePeJounYzANhZ-Kw@mail.gmail.com \
    --to=yotambarnoy@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=info@gerd-stolpmann.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).