Re: [Caml-list] How much optimized is the 'a option type ?

[Gerd Stolpmann <info@gerd-stolpmann.de>]

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

Am Freitag, den 17.01.2014, 10:22 +0100 schrieb Simon Cruanes:
> Le Fri, 17 Jan 2014, Gabriel Scherer a écrit :
> 
> > There have been recurrent discussions of optimizing `'a option` to
> > avoid allocation in some cases, which is interesting when it is used
> > as a default value for example. (The nice recent blog post by Thomas
> > Leonard also seems to assume that `'a option` is somehow optimized.)
> > 
> > My strictly personal opinion is that I doubt this would be a good
> > idea, because I expect a fair share of the programming practice that
> > currently use ('a option) to move to something like (('a,
> > error-description) either) later in their lifetime, and I wouldn't
> > want people to avoid to do that for performance concerns.
> > Historically, we've rather come to see special-case representation
> > optimizations (eg. array of floats) as a mistake -- but on the other
> > hand there is not much downside to record of floats.
> 
> I think optimization of some local uses of options, such as:

I also think that local uses of options (and other variant types) could
be candidates for optimization. Gabriel is right that the GC is good at
short-living values, but that still leaves room for getting better with
ultra-short-living values.

My idea would be to try to delay the allocation of the block, and to use
two registers, i.e. one for the tag, and one for the tagged inner value.
First when the constructed value is passed to some other function, or
returned, or stored inside another block, or in another register, the
allocation is really done. Of course, this could also result in more
work in total (especially when the compiler has no idea what the desired
fast path of the algorithm is), and I guess the real problem is that you
need a good heuristics to decide when to do this. But there are at least
two criterions at hand:

 - You are not under pressure with registers
 - All consumers of the constructed value are inside the same function

I guess this would result in a quite heavy patch for the comparatively
small effect, and that's why it is not yet done.


Gerd


> let rec iter_stream f s =
>     match (try Some (MyStream.get s) with End_of_stream -> None) with
>     | None -> ()
>     | Some (x, s') ->
>         f x;
>         iter_stream f s'
> 
> where an option is used to keep the function tail-rec (I've heard
> several people tell me they often need to use this), or other cases like
> optional parameters (which are not going to move to Either), would be
> useful and future-proof. I hope the current work on optimizations will
> help with this kind of cases (removing useless allocations of local
> options, references, exceptions when no escape is possible).
> 
> </wishlist>
> </2cents>
> </</>>
> 

-- 
------------------------------------------------------------
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: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]