[Caml-list] flambda for bytecode backend

[Caml-list] flambda for bytecode backend

[Alexey Egorov]

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

Hello,

I'm curious why flambda doesn't supported in bytecode compiler? It seems that js_of_ocaml can greatly benefit from such possibility.



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

Re: [Caml-list] <DKIM> flambda for bytecode backend

[Pierre Chambart]

On 12/01/2018 19:36, Alexey Egorov wrote:
> Hello,
>
> I'm curious why flambda doesn't supported in bytecode compiler? It
> seems that js_of_ocaml can greatly benefit from such possibility.
>
It has been considered, and in fact Grégoire Henry did a version of the
bytecode compiler after flambda. But it was discarded as it was not very
useful. It couldn't work with js_of_ocaml, and there was no obvious way
how to do it properly.

The reason being that flambda takes place after closure conversion.
Hence after flambda, functions takes an explicit environment value. But
on the other hand, js_of_ocaml represents OCaml functions directly as
javascript function since the closures are working correctly.

The best we could do (without doing some magic) would look like:

let f x =
  let y = x + 1 in
  let g z = z + y in
  g

compiled to:

function f_code(x, env) {
  let y = x + 1;
  function g_code(y, env) {
    return(z + env.y);
  }
  let g = { code : g_code, env : { y: y };
  return(g);
}

let f = { code : f_code, env : { } }

This would probably be far slower than what js_of_ocaml currently does.
-- 
Pierre

Re: [Caml-list] <DKIM> flambda for bytecode backend

[Leo White]

> The best we could do (without doing some magic) would look like:
> 
> let f x =
>   let y = x + 1 in
>   let g z = z + y in
>   g
> 
> compiled to:
> 
> function f_code(x, env) {
>   let y = x + 1;
>   function g_code(y, env) {
>     return(z + env.y);
>   }
>   let g = { code : g_code, env : { y: y };
>   return(g);
> }
> 
> let f = { code : f_code, env : { } }

Pierre is right about the reason we don't use flambda with
bytecode, although I don't think that is the best JavaScript we
could produce.

It would not be to difficult to undo closure conversion within
the function body itself. This still leaves references to the
closure outside of the function body.  These aren't shown in
Pierre's example but they are produced during inlining and are
the main thing that flambda uses which bytecode doesn't
support. For these we can take advantage of the fact that
JavaScript functions are also ordinary objects, attaching the
environment to the function as fields:

    function f(x) {
      let y = x + 1;
      function g(z) {
        return(z + y);
      }
      g.y = y;
      return(g);
    }

Of course, this could still have an adverse effect on how the JIT
of different browsers deals with these functions, so some
benchmarking would be needed to confirm the viability of this
approach.

Regards,

Leo

Re: [Caml-list] <DKIM> flambda for bytecode backend

[Leandro Ostera]

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

You could also use the binding mechanism that js functions have to swap the
context they are ran in, although I’m not sure if it’s going to be faster
than the two options already provided above.

function f_unbound(x) { return (x + this.y); }

const env = { y: 1 };
const f = f_unbound.bind(env);
f(1) // 2
mån 15 jan. 2018 kl. 11:35 skrev Leo White <leo@lpw25.net>:

> > The best we could do (without doing some magic) would look like:
> >
> > let f x =
> >   let y = x + 1 in
> >   let g z = z + y in
> >   g
> >
> > compiled to:
> >
> > function f_code(x, env) {
> >   let y = x + 1;
> >   function g_code(y, env) {
> >     return(z + env.y);
> >   }
> >   let g = { code : g_code, env : { y: y };
> >   return(g);
> > }
> >
> > let f = { code : f_code, env : { } }
>
> Pierre is right about the reason we don't use flambda with
> bytecode, although I don't think that is the best JavaScript we
> could produce.
>
> It would not be to difficult to undo closure conversion within
> the function body itself. This still leaves references to the
> closure outside of the function body.  These aren't shown in
> Pierre's example but they are produced during inlining and are
> the main thing that flambda uses which bytecode doesn't
> support. For these we can take advantage of the fact that
> JavaScript functions are also ordinary objects, attaching the
> environment to the function as fields:
>
>     function f(x) {
>       let y = x + 1;
>       function g(z) {
>         return(z + y);
>       }
>       g.y = y;
>       return(g);
>     }
>
> Of course, this could still have an adverse effect on how the JIT
> of different browsers deals with these functions, so some
> benchmarking would be needed to confirm the viability of this
> approach.
>
> Regards,
>
> Leo
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

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

[Caml-list] OCaml <-> Computer Algebra

[Nicolas Ratier]

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

Hello,

We develop an OCaml code to automate repetitive calculations and to 
assemble proofs in the mathematical domain of PDE homogenization (to 
summarize in one sentence).

We now need to embed elementary symbolic calculations.

Do you know a library of "Computer Algebra" which interfaces well with 
OCaml?
Does COQ need symbolic calculus? If so, is there a core of CA in COQ?

Thank you for your help,
Nicolas


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