[Caml-list] Pairs vs. Records

[Caml-list] Pairs vs. Records

[Willem Duminy]

Hi guys,

I had a progarm that used pairs int*int as the basis of the primary data
structure.  After changing it to use records {row:int;col:int} the
program runs slower.

I am wondering whether this performance was lost because of changing
from pairs to records, or whether it some other reason.

So my question is simply: is there a difference in the performance of
pairs and records when I use ocamlopt to compile an ocaml  program in
Linux.

Thank you,
Willem
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Pairs vs. Records

[Xavier Leroy]

> I had a progarm that used pairs int*int as the basis of the primary data
> structure.  After changing it to use records {row:int;col:int} the
> program runs slower.

This is very surprising indeed, because the OCaml compilers generate
*exactly the same code* for building/accessing tuples and for
building/accessing records (with no mutable fields).

(Actually, this isn't quite right: records of floats are optimized
specially, but not tuples of floats.)

So, I'd look elsewhere for the cause of the performance loss.  Notice
that with modern processors, even tiny changes in the code (such as
deleting or adding unused functions) can result in noticeable (and
highly unpredictable...) performance differences, because of code
placement effects.

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Pairs vs. Records

[Alain Frisch]

On Tue, 11 Dec 2001, Xavier Leroy wrote:

> > I had a progarm that used pairs int*int as the basis of the primary data
> > structure.  After changing it to use records {row:int;col:int} the
> > program runs slower.
>
> This is very surprising indeed, because the OCaml compilers generate
> *exactly the same code* for building/accessing tuples and for
> building/accessing records (with no mutable fields).

I guess you know this better than I ;) but one can observe difference in
generated code with pattern matching:

# fun x y -> match (x,y) with (a,b) -> a + b;;
        closure L1, 0
        return 1
        restart
L1:     grab 1
        acc 1
        push
        acc 1
        addint
        return 2

- : int -> int -> int = <fun>
# fun x y -> match {row=x;col=y} with {row=a;col=b} -> a + b;;
        closure L1, 0
        return 1
        restart
L1:     grab 1
        acc 1
        push
        acc 1
        makeblock 2, 0
        push
        acc 0
        getfield 1
        push
        acc 1
        getfield 0
        addint
        return 3


Of course, it would be surprising to find this kind of code with
records in a real program ...


-- 
  Alain

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Pairs vs. Records

[Xavier Leroy]

> > This is very surprising indeed, because the OCaml compilers generate
> > *exactly the same code* for building/accessing tuples and for
> > building/accessing records (with no mutable fields).
> 
> I guess you know this better than I ;) but one can observe difference in
> generated code with pattern matching:
> # fun x y -> match (x,y) with (a,b) -> a + b;;
> # fun x y -> match {row=x;col=y} with {row=a;col=b} -> a + b;;

Actually, you're correct.  I was thinking in terms of using records or
tuples inside data structures, but it's true that there are two
"toplevel" uses of tuples that are optimized specially: one is for 
matching multiple values, as in your first example above; the other
(specific to ocamlopt) is when passing a tuple of arguments to a known
function that expects a tuple of the same size, e.g.

        let f (x, y) = ...
        ... f (e1, e2) ...

Here, ocamlopt can avoid the construction of the pair, but similar
code using records instead of pairs will not be optimized.

Sorry for spreading misinformation :-)

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr