[Development] QML engine changes

[Charley Bay]

Simon sayeth:

> <snip, proposed integration of new QML Engine replacing V8>


Chris replied:
> > This is really exciting news!  Good stuff!
>

+1


> > I wonder how much performance delta there is between JIT and pure
> > interpretted, with a tight enough interpreter loop, if you make some
> > simplifying assumptions (eg, types can't change at runtime / enforce no
> > property deletion or dynamic property addition to objects or prototypes /
> > disallow eval()).  <snip>,
>

+1, I'm very interested in this QML-engine integration beyond what was
possible with V8:

 *- Strong type safety
 *- Optimizations (e.g., object-paths)
 *- more/better JIT options
 *- more/better bytecode/packaging/deployment options
 *- more/better future QML tooling (e.g., runtime debugging/inspection
around the "QML-engine")

Chris:

>   > <snip>,, but I personally think that weak typing is the
> > major negative of JavaScript :-/
>

+1

Simon:

> I'm also not sure yet about the exact difference between JIT and
> interpreter,
> but type propagation is something that Erik has been working on, based on
> the
> assumption that while JS is untyped, QML is in fact strongly typed. That is
> one of those areas with a huge potential.
>

+1

Simon:

> > > > > Roberto and Aaron). We've progressed rather well and in our
> wip/v4 branch in qtdeclarative we're now passing all auto tests (as well as
> the
> > > > > ECMAScript 262 test suite). So that's why we'd like to propose
> merging this work into qtdeclarative mainline (dev branch), in the
> coming days/week(s) in time for Qt 5.2 though.
>

Chris:

> > This confuses me a bit.  Why isn't the implementation tuned
> specifically for QML, instead of being a fully-compliant ecmascript
> implementation?
>

Simon:

> Because we want to continue to support the use-case of import "Foo.js" as
> Bar;
> I've personally used that for a little spare time app I wrote, when I was
> super happy to discover that a piece of functionality I needed was
> available
> as third-party JS library that I could just exclude. But spec compliance
> does
> not imply tuning, and indeed I think generally any optimization we do will
> most likely be geared towards QML, as long as it doesn't pessimize the
> regular
> JS execution.
>

Ok, that makes sense, so I won't argue against it.  However, I agree with
Chris that  "ecmascript"  compliance isn't a big wish/need/goal for me.
 I'd prefer to give (design) priorities to:

 *- strong typing
 *- (tight) QML-engine integration with running system (e.g., internal QML
runtime system with "bindings" is quite different than the mechanisms
intended by an ECMA-script engine)
 *- performance (e.g, "byte-code", JIT, optimized object-paths)
 *- deployment/packaging options (e.g., binary byte-code)

And, of course, I totally applaud the removal of "eval()" and other runtime
code issues that block iOS deployment (I'm not targeting that platform, I
just agree with Apple's complaint about embedding V8, and don't want
opportunities for "malicious injection" in my systems).

Chris:

> > And I think some extremely
> > impressive performance improvements could be gained by integrating
> more tightly with the QML engine.
>

Simon:

> Absolutely, that remains a goal (tight integration).
>

+1, I support this direction.

Chris:

> > Something Aaron mentioned to me a little while ago, is the possibility
> of doing a two-stage binding generation (it's not too clean, but it's
> > extremely impressive): build pre-optimized binaries; run the application
> on
> > device; application emits the IR for the bindings during first time
> > evaluation, back to QtCreator; collect the IR and do a reverse transform
> > into C++ code; generate optimized binaries.  All of the type information
> is
> > generated/known at the time the IR is generated, so there shouldn't be
> any
> > problems compiling the resultant reverse transform; you end up with
> > super-fast bindings implementation, and no JIT required in the final
> > binaries.  If any bindings change at runtime, just use an interpreter to
> > evaluate the expression.
>

Simon:

> That's an interesting idea!
>

Whoa... THAT'S COOL.  I'm very interested in more on this.  Please feel
free to share thoughts on this topic or other experimentation along these
lines.

(This could be *extremely* useful; I could see tooling be put in-place to
simplify/automate this process.)

> > > > So this is a heads-up and of course a last call for objections :)
>

No objection -- :/me strong supporter!

Chris:

> > Anyway, I'm really excited about this change.  Congrats and thanks to
> Erik, Lars and yourself for your impressive work!
>

+1

-charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130624/0bfb6306/attachment.html>