6 ms·

I completely agree with you and I'd argue that #2 and #3 are the two biggest reasons. It is easy to forget the colossal amount of engineering resources that br

• Ajedi32 7y ago
  > For example, you can't really reuse the v8 codebase to create a Python JIT Actually, come to think of it... V8 also runs WASM right? Right now I think WASM is missing a few features (like garbage collection) which Python would need to be efficiently compiled to WASM, but once those are solved...
  • bakery2k 7y ago
    I don't think its possible to efficiently compile a dynamically-typed language like Python to statically-typed WASM.
    • buu700 7y ago
      Thought experiment: what about transpiling Python to JS? https://github.com/QQuick/Transcrypt https://github.com/QQuick/Transcrypt looks like a nice implementation, but their readme just talks about deployment to browsers — I'm curious about outside of the browser whether Transcrypt + Node might be more efficient than CPython. (Not even just CPython, but really any dynamic language implementation.) And then of course wasm could still be used for C extensions.
    • mixmastamyk 7y ago
      Not random code, but specifically written with type checking should be doable. There was an asm,js subset for example.
      • ufo 7y ago
        Calling asm.js a subset of Javascript is a bit of a stretch. It looks nothing like idiomatic Javascript, and was more of a low-level statically-typed language dressed up in Javascript clothing. At some point they realized that representing this low-level code as Javascript text instead of as specially-designed bytecode added a significant ammount of parsing and compilation overhead, which was one of the initial motivations for the creation of WebAssembly. If I had to sum up WASM in one sentence, it is that it is kind of like the JVM, except that its instruction set was designed specifically for running programs downloaded from the web. Special attention was paid to security and startup latency.
        • cwp 7y ago
          Erm... the JVM was also designed specifically for running programs downloaded from the web. Special attention was paid to security and startup latency. Javascript got its name because it was the only other language designed to be downloaded and executed in a browser!
      • firethief 7y ago
        rpython might be a better example
    • simonh 7y ago
      You’d have to compile the CPython interpreter to WASM.
  • ufo 7y ago
    At a conceptual level that would be no different than having a Python implementation targeting the JVM or CLR runtimes (aka Jython and IronPython). The usual situation for these alternate implementations is that they make it easier to interact with other code that targets those runtimes, but that they do not speed up the average speed of the interpreter. The previously-mentioned compatibility and performance issues for C extensions also remain.
    • WorldMaker 7y ago
      There was brief point in time where IronPython was faster than CPython for several major benchmarks, precisely because of the better CLR JIT and GC, plus some smart tricks implemented in the "DLR". (It's almost sad, IronPython and the "DLR" have been left to grow so many weeds since that time.)
      • ufo 7y ago
        I definitely should have been clearer in my other comment. Alternative interpreters such as IronPython can be faster but most of the time the speed stays in the same "order of magnitude" as the original C interpreter. On the other hand, good JIT can deliver a 10x or more speedup in the best case scenarios where it manages to get rid of the dynamic typing overhead. (For subtle technical reasons, running the language interpreter on top a jitting VM like the CLR is not enough. The underlying JIT has a hard time looking further than the IronPython interpreter itself and making optimizations at the "Python level")
        • WorldMaker 7y ago
          That's where some of the most "DLR" magic filled in (cached) and optimized a lot of the "Python level" in a way that the CLR JIT could take advantage. The DLR briefly was a huge bundle of hope for some really interesting business logic caching. In a past life I did some really wild stuff with DLR caching for a complicated business workflow tool. It's dark matter in an enterprise that I'm sure all of it is still running, but I'm not sure if the performance has kept up over time (and have no way to ask, and probably don't care) as the CLR declared "mission complete" on the DLR and maybe hasn't kept it quite as optimized since the IronPython heyday.
• The_rationalist 7y ago
  Why is javascript slower than Java despite being both garbage collected and v8 having more engeeners than e.g openjdk?
  • setr 7y ago
    A couple obvious reasons would be compiled vs interpreted, and static vs dynamic, both of which bear some inherit runtime performance cost.
    • jashmatthews 7y ago
      Compiled vs interpreted is not a useful distinction. Until fairly recently when Ignition was introduced, V8 had no interpreter. All the JS was compiled by the first tier “full codegen” The bigger difference is that the JVM is heavily optimized for performance after a long warmup and V8 needs to produce relatively fast code early during page loading. Java being much more static certainly helps warmup time but ultimately doesn’t really affect final performance. LuaJIT can beat C in some cases once it has time to compile all traces needed.
      • The_rationalist 7y ago
        V8 needs to produce relatively fast code early during page loading So for e.g backend js programs is it possible to ask v8 to take more time to optimize?
        • saagarjha 7y ago
          Why would would you want it to take longer to optimize?
          • The_rationalist 7y ago
            To get more time to generate betten codegen so a faster program (but slower "launch time")