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
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
