Announcement

Collapse
No announcement yet.

ECMA Is Working On Standardizing Google's Dart

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by busukxuan View Post
    yeah it wont be. It has practically no integration with the DOM.
    Bytecodes are by definition low level.

    The single advantage of using a bytecode is that you don't need to parse, validate complex code as you get an intermediate representation that gives the same semantics (albeit a different ugly to parse binary syntax). This will reduce the tokenizing, parse times, evaluating time and this translates somewhat to the the startup time of the application.

    Java bytecode can integrate with DOM (it does in all Java Xml DOM readers) and it would integrate as easy to a JS machine (that would support Java bytecode). If you mean for "Java integration with DOM tree of page elements", this is also done (as Java FX).

    I will not speculate about Dart capaiblity of creating a bytecode or not (I think it should be possible, even standardized, all is needed by a matter of principle is to be defined a bytecode and an AST tree visitor to fill this bytecode), but the issue it would solve, to have a less parsing time when starting Dart code, makes me think that it will be adopted still. Because when you get an error in your Dart based application, you will get a bytecode offset with an error which (imho) is against the spirit of the web.

    Also, JS parsers are really fast as of today after 4-5 years of people optimizing Sunspider. If you want a bytecode, try to hope to an Asm.JS 2.0 which expects to give the capability to precompile code (to not have the "hit" of JIT compilation), GC support, and to not forget more browser support, as of today Mozilla, Chrome are supported, but not so much WebKit or IE (IE team said that they are interested into Asm.JS).

    Comment


    • #17
      Originally posted by ciplogic View Post
      IE team said that they are interested into Asm.JS
      That doesn't surprise me. I seem to remember reading that recent versions of IE already have some kind of asm.js-like optimization backend. Detecting asm.js annotations would let them trigger it predictably rather than via heuristic detection and optimize more aggressively since they have the confidence that it's not their fault if the code proves un-optimizable and the time spent has to be written off as a loss.

      Comment


      • #18
        Originally posted by ciplogic View Post
        Java bytecode can integrate with DOM (it does in all Java Xml DOM readers) and it would integrate as easy to a JS machine (that would support Java bytecode). If you mean for "Java integration with DOM tree of page elements", this is also done (as Java FX).
        Yeah I meant the latter, I didn't know one can actually access that with Java FX, thanks for letting me know. So "webview1.getEngine().getDocment()" returns the DOM? Also does it provide access to the Browser Object Model, like "window"?

        I will not speculate about Dart capaiblity of creating a bytecode or not (I think it should be possible, even standardized, all is needed by a matter of principle is to be defined a bytecode and an AST tree visitor to fill this bytecode), but the issue it would solve, to have a less parsing time when starting Dart code, makes me think that it will be adopted still. Because when you get an error in your Dart based application, you will get a bytecode offset with an error which (imho) is against the spirit of the web.
        1. I said "should they", not "will they", so it's just opinion, not prediction. But anyway, this is the answer I have waited for, thanks~
        2. True, errors, but debugging should ensure a minimal number of errors(since comprehensive debugging is an important practice, even in languages that don't show much issue with small bugs). There will still be some errors since the correctness of very large apps are hard to ensure. Maybe the following may help:
          1. Provide code mapping between source code and bytecode, and disassamblers to support the mapping.
          2. Include a link(as metadata) of the source code of the bytecode-form program, so that code mapping and debugging can be done in a browser(which should also solve the "spirit of the web" problem).
        Also, JS parsers are really fast as of today after 4-5 years of people optimizing Sunspider. If you want a bytecode, try to hope to an Asm.JS 2.0 which expects to give the capability to precompile code (to not have the "hit" of JIT compilation), GC support.
        asm.js 2.0? sounds great~ hope there will be
        V8 and SpiderMonkey has GC already, not sure about others though.

        Comment


        • #19
          Originally posted by busukxuan View Post
          Yeah, even now that benchmark still shows dart being slower. However the official benchmarks from the dart page shows otherwise. Since it's the official one, it might not be so trustworthy, but at the very least we can still use the language to write apps and compile it to js. Note that tiny dart2js-compiled apps tend to perform worse than handwritten javascript(smaller it is more ridiculous the overhead, i guess), though large dart2js-compiled apps may go faster than handwritten js(and often so, according to their website).
          We have to keep in mind the amount of research and engineering hours that have gone into js vm's over the last 15 or so years when comparing performance. Js has received _a lot_ of work, and is ridiculously fast for what it is on the vm's of modern browsers. Dart might be slower than js on googles current vm for each of them, but might still be easier to make fast vm's for. A lot of the work done on js might transfer over to some extent, but I think we still need to allow dart vm's some time (under significant use) to mature.

          (This isn't a reply that is specifically to you, I just picked one spot in the performance discussion thread.)

          Comment


          • #20
            http://games.greggman.com/game/thoug...m-js-vs-pnacl/
            Originally posted by busukxuan View Post
            asm.js 2.0? sounds great~ hope there will be
            V8 and SpiderMonkey has GC already, not sure about others though.
            Sorry to make another correction for you, but both V8 and SpirerMonkey do not have a GC in AsmJS codes, they have it just for typical JS.

            AsmJs does allocate a big "memory pool" in which the objects are allocated by a custom allocator (like malloc, but handmade in every emscripten generated code). You cannot use the main GC as part of asm.js, you have to write your own. Hopefully it clarifies this for you.

            Please read the opinion of a developer from the Chrome's team about PNaCl vs Asm.JS and saying that they overlap:
            http://games.greggman.com/game/thoug...m-js-vs-pnacl/
            and reading it you will understand somewhat what Asm.JS is and it is compared with an open bytecode (here the curated LLVM one).

            Comment


            • #21
              Originally posted by Daktyl198 View Post
              The first couple sentences are talking about 3rd party benchmarks showing Dart native (not compiled to JS) being slower than JS.
              Please link this as I would like to look at the code. Either the Dart code is very badly written or the JS code is hand optimized.

              Comment


              • #22
                Originally posted by Pajn View Post
                Please link this as I would like to look at the code. Either the Dart code is very badly written or the JS code is hand optimized.
                Here,
                http://benchmarksgame.alioth.debian....g2=v8&data=u32
                and also,
                http://benchmarksgame.alioth.debian....g2=v8&data=u64

                These are the results pages. I'm not sure, but they are probably running on very old versions of Dart.

                Comment

                Working...
                X