[Development] QML engine changes
charleyb123 at gmail.com
Mon Jun 24 17:51:38 CEST 2013
> <snip, proposed integration of new QML Engine replacing V8>
> > This is really exciting news! Good stuff!
> > 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")
> > <snip>,, but I personally think that weak typing is the
> I'm also not sure yet about the exact difference between JIT and
> but type propagation is something that Erik has been working on, based on
> assumption that while JS is untyped, QML is in fact strongly typed. That is
> one of those areas with a huge potential.
> > > > > 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
> > > > > 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.
> > This confuses me a bit. Why isn't the implementation tuned
> specifically for QML, instead of being a fully-compliant ecmascript
> Because we want to continue to support the use-case of import "Foo.js" as
> 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
> as third-party JS library that I could just exclude. But spec compliance
> 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
> 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).
> > And I think some extremely
> > impressive performance improvements could be gained by integrating
> more tightly with the QML engine.
> Absolutely, that remains a goal (tight integration).
+1, I support this direction.
> > 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
> > 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
> > generated/known at the time the IR is generated, so there shouldn't be
> > 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.
> 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
(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!
> > Anyway, I'm really excited about this change. Congrats and thanks to
> Erik, Lars and yourself for your impressive work!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development