Re: [Caml-list] classes not optimized?

[Ivan Gotovchits <ivg@ieee.org>]

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

On Wed, Oct 25, 2017 at 9:27 AM, <vadim@radovel.ru> wrote:

>
> Excuse me, does this mean that I should use modules instead of objects if
> its posible. For example: I have a big list of different modules with the
> same signature containing some values and functions inside - would it give
> the best performance in OCaml comparing to classes, objects, etc?
>


If you can solve your problem without relying on objects, then it is better
not to use them. There is nothing wrong with them. It just because it is a
very powerful mechanism, that sometimes is not easy to control. They give
you an extra flexibility so that you can express more complex abstractions,
but this comes with a price. Given your particular example, yes, calling a
function is faster, than calling a method, as the latter introduces an
extra layer of indirection via the virtual method table. Moreover, if a
function is know at compile time, it can be inlined, that may provide even
further optimization opportunities. It is very hard in general to inline a
method, as a compiler needs a proof that this and only this method will be
called in runtime. Moreover, if it is the case (i.e., the method can be
resolved in runtime), then it is a signal that an object should not be used
at all. Basically, objects should be used when you need an open recursion
with runtime dispatch. This is a very rare case, in fact.




>
> 25.10.2017, 12:45, "Gabriel Scherer" <gabriel.scherer@gmail.com>:
>
> Object-oriented code tends to generate large intermediate representations,
> too large to be inlined and too complex to be partially evaluated at
> compile-time. I wouldn't expect this sort of optimization to work.
>
> You might have better luck with first-class modules if you want some sort
> of tuple subtyping.
> (Performance model: with modules, subtyping coercions are compiled as a
> field-reordering copy,
> so the runtime cost is on the coercion rather than the field access.)
>
> > Also as a related question, is there a way to have the lookup semantics
> of methods without the open recursion part?
>
> We could add row-typed extensible records to the language. Given how
> little the object-oriented layer is used in practice, I am not sure that
> this highly work-demanding addition would be a good use of a contributor's
> time -- and its utility would have to be weighted against the complexity
> cost of adding yet another kind of product structure.
>
> On Wed, Oct 25, 2017 at 11:31 AM, Christoph Höger <
> christoph.hoeger@celeraone.com> wrote:
>
> Dear OCaml users,
>
> consider the following microbenchmark:
>
> <snip>
> class s (z : string)  (y : int)  (x : int) =
>   object method z = z method y = y method x = x
> end
>
> type t = { x : int; y : int; z : string}
>
> let foo_s _ =
>  (new s) "Example" 0 1
>
> let foo_t _ = {x=1; y=0; z="Example"}
>
> let one_s _ = (foo_s ())#x
>
> let one_t _ = (foo_t ()).x
>
> let fac =
>   let rec fac n =
>     let f =
>       let rec f n a = if n <= 1 then a else f (n - (one_s ())) (n * a)  in
> f (* change one_t to one_s or vice-versa *)
>        in
>     f n 1  in
>   fac
> let bench =
>   let rec bench n a =
>     if n <= 0
>     then a
>     else (let x = a && ((fac 20) == (20 * (fac 19)))  in bench (n - 1) x)
> in
>   bench
> let test = bench 10000000 true
> let main _ = test
> </snip>
>
> If I run it with ocamlopt 4.05.0+flambda and -O3, the version that uses
> one_s takes about 7.5s whereas the one with one_t uses 0.35s. I know that
> object method lookup is more costly than records, of course. This
> particular case baffles me, though. Why is the class not completely inlined?
>
> Also as a related question, is there a way to have the lookup semantics of
> methods without the open recursion part? That is, can I have a class that
> consists of values, not methods? It would love to have open tuples in some
> cases. For example, I'd like to write a function that takes a tuple of any
> length, because it only needs the first element.
>
> thanks,
>
> Christoph
>
>
>

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