Proxy performance: JIT-compilation?

[Mark Miller]

So from y'all's various implementation perspectives, how does
https://github.com/tvcutsem/es-lab/issues/21 look? Do you think it would
make it easier to achieve much higher performance proxies than we could
without these subtle semantic changes? Or do you think we can as easily
achieve these performance gains with no observable changes at all?

By "subtle", I mean that it is unlikely to affect any normal code.

(Note that, even if the answer is that they don't help, these changes are
still adequately motivated by the cycle-transparency bug. But it would be
good to know.)




On Tue, Aug 8, 2017 at 3:32 PM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> Yes, it's possible to optimize them using specialized ICs on the proxy
> handler itself, but it would be *far* easier to optimize it if the ICs
> weren't necessary in the first place, since you can just build it into
> the proxy's type, almost like a lazily-generated vtable. It's just far
> less work than the otherwise-necessary complex ICs you'd need
> otherwise.
>
> Even though it is in theory possible to optimize such proxies, it's
> pretty complicated to set up, and JS engines aren't exactly magic.
> -----
>
> Isiah Meadows
> me at isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Tue, Aug 8, 2017 at 5:36 PM, Sam Tobin-Hochstadt
> <samth at cs.indiana.edu> wrote:
> > On Fri, Aug 4, 2017 at 4:52 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
> wrote:
> >>
> >> On Aug 4, 2017, at 2:22 PM, Mark S. Miller <erights at google.com> wrote:
> >>
> >> At https://github.com/tvcutsem/es-lab/issues/21 Tom and I have an idea
> (that
> >> we should turn into a proposal) for a subtle change to proxy semantics
> that
> >>     * should break essentially no current code,
> >>     * repair the cycle detection transparency violation bug,
> >>     * enable many proxies to be *much* faster.
> >>
> >>
> >> I actually don’t see why any semantic changes are needed to enable
> better
> >> Proxy performance. One abstractions are sufficiently lowered, a proxy
> trap
> >> invocation is just a series  of procedure calls (some dynamically
> >> dispatched; some to built-in procedures).  I don’t see any reason why
> the
> >> same sort of PIC+dynamic typed based specialization+inlining that is
> used to
> >> optimize more conventional JS code isn’t also applicable to Proxy using
> >> code.
> >
> > Indeed, this works well in practice with other proxy constructs in
> > other languages -- my collaborators and I have a paper showing this
> > that should be out soon. The only barrier to good proxy performance is
> > implementation work.
> >
> > Sam
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170808/4725cbf7/attachment.html>