Re: [Caml-list] Width subtyping

[Peng Zang <peng.zang@gmail.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Monday 01 June 2009 10:21:36 am David Allsopp wrote:
> Dario Teixeira wrote:
> > Thanks -- that is also an interesting solution.  I'm guessing it will
> > be faster, though it might consume more memory in cases where only one
> > field is actually used.  I'll have to try it side-by-side with the
> > object based solution to see how they compare in the real world with my
>
> So as I wouldn't immediately be told "the overhead is irrelevant", I ran a
> "quick" benchmark before my last post. I compared summing 7 million
> 3-int-field records and 7 million 3-int-field objects using names a, b, c.
> On my machine, averaged out and with enough RAM that neither paging nor the
> GC get in the way, objects were nearly 3 times slower. I then tried with
> 10-int-field records and objects - in this case, objects were just over 4
> times slower (read on). This was in bytecode - I didn't bother with native
> code.
>
> The overhead of an object is 2 words (one contains tracking information
> about the actual class of the object and the other is a unique identifier)
> + (I think) 1 extra word for every field (because each int is boxed in a
> 1-tuple so that its tag can be recorded). Importantly, accessing fields in
> a record is an O(1) operation but for objects it's O(log n) for the number
> of fields because a binary search is done to locate the field with the
> correct tag. ocamlopt may of course optimise this search by caching the
> absolute index of the field in a "recognised" object layout; I didn't look
> in the compiler. My test between 3 and 10 fields would suggest that this
> optimisation does not apply in bytecode.
>
>
> David

This also matches what I've seen.  It seems many optimizations are not 
performed in bytecode.  As a result, the performance characteristics of 
objects change dramatically when compiled to native code.  In my experience 
objects incur a 20% hit on runtime in native code.

Peng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFKJAoUfIRcEFL/JewRAjlOAJ98T4OTRDy9+TxhzZ6bVuzu7pFjHACdFreL
gFn1gN+whdEntNO2JcZguzQ=
=1FQS
-----END PGP SIGNATURE-----