7 ms·

Performance. Looking at dependencies for certain key Javascript libraries makes me skeptical now that this is possible.

by xigency 11y ago

PeCaN 11y ago
Why would AOT compiled JS performance be better than the highly advanced JIT compilers that are _designed_ to run JS efficiently?! AOT compiling highly dynamic languages gives you very little room for optimizations.
- vcarl 11y ago
  If you compile ahead of time, you can tune your optimizations. With the right tooling you can tell the compiler that a certain path is hot and should be optimized from the beginning, or catch deoptimizations better, or just get rid of the compilation cost. Right now I'm not sure how much practical benefit there is, but there's a lot of potential.
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]
- xigency 11y ago
  Because even a just-in-time compiler is slower than native performance quite frequently. A just-in-time WebAssembly compiler can be guaranteed to be as fast as V8 in practice. Branch prediction on a CPU can be quite helpful, but if a program stops hitting the same branches it can impact performance. The point of a just in time compiler is that it compiles on the fly, which does take a certain amount of time. That could be loading time for your application. In any case, the purpose of this development would be to design something that is faster than V8. And I'm specifically speaking of compiling with inferred types or from asm.js or TypeScript, not embedding a VM or a garbage collector or an emulator. This compiler might only accept programs that would be faster.
  - vvanders 11y ago
    Native performance is only better in the cases where you can explicitly control memory layout & access. That's why asm.js runs so fast. You're explicitly translating C/C++ to arrays. I don't really see how a js -> wasm compiler fundamentally changes things. You're still working in JS which has poor memory placement semantics.
    - xigency 11y ago
      WebAssembly allows for a stack and a linear area of memory. The job of the compiler is to determine memory placement.
      - vvanders 11y ago
        Argh, I see this keep coming up and it really needs to be put to rest. Compilers don't know how to layout your data. They don't know how you'll access it or the traversal patterns. Your whiz-bang compiler isn't going to strip out class members and AoS from SoA because that's a fundamental data structure problem. Compilers are great, they fold things down, inline and unroll loops. When it comes to memory placement they can't know your intent and it's up to you to lay out your data appropriately. They might do padding but anything else is going to have memory & complexity implications and they shouldn't make those decisions for you.
        xigency 11y ago
        I don't know, you have a real mix of arguments here, as do most people. There's nothing a JIT does that an ahead of time compiler can't do without the burden of a larger footprint. This is really an issue of backend optimization to "make things like asm.js." For example, there are obvious examples of cases where a JavaScript object's properties and property types would be transparent to a compiler at compile time, with a complete graph of where those values would be stored and used. This would be stored in the WebAssembly stack, analogous to an asm.js fixed array. The WebAssembly sandbox is designed to run code directly. The JIT is designed to build code to run directly in an iterative fashion. If system designers knows how software is expected to operate, they can make choices to instrument that process and also make software which is designed intelligently. Java runs in a VM. Someone could write a just in time compiler for .java code that performs well. That's not a sufficient argument not to develop or continue to develop a javac compiler for byte code. Additionally, whether or not a language is designed to use GC doesn't mean there couldn't be research or design into avoiding or augmenting that situation for performance (in the way that a just-in-time compiler would relieve the situation). Nor reason not to build a platform and engineering methodology to deploy to two independent and cooperating runtime environments. Neither Asm.js and emscripten or C are the end of all things. Neither is dynamicism.

Performance. Looking at dependencies for certain key Javascript libraries makes me skeptical now that this is possible.

by xigency 11y ago

Performance. Looking at dependencies for certain key Javascript libraries makes me skeptical now that this is possible.

PeCaN 11y ago

Why would AOT compiled JS performance be better than the highly advanced JIT compilers that are _designed_ to run JS efficiently?! AOT compiling highly dynamic languages gives you very little room for optimizations.

vcarl 11y ago
If you compile ahead of time, you can tune your optimizations. With the right tooling you can tell the compiler that a certain path is hot and should be optimized from the beginning, or catch deoptimizations better, or just get rid of the compilation cost. Right now I'm not sure how much practical benefit there is, but there's a lot of potential.
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
xigency 11y ago
Because even a just-in-time compiler is slower than native performance quite frequently. A just-in-time WebAssembly compiler can be guaranteed to be as fast as V8 in practice. Branch prediction on a CPU can be quite helpful, but if a program stops hitting the same branches it can impact performance. The point of a just in time compiler is that it compiles on the fly, which does take a certain amount of time. That could be loading time for your application. In any case, the purpose of this development would be to design something that is faster than V8. And I'm specifically speaking of compiling with inferred types or from asm.js or TypeScript, not embedding a VM or a garbage collector or an emulator. This compiler might only accept programs that would be faster.
- vvanders 11y ago
  Native performance is only better in the cases where you can explicitly control memory layout & access. That's why asm.js runs so fast. You're explicitly translating C/C++ to arrays. I don't really see how a js -> wasm compiler fundamentally changes things. You're still working in JS which has poor memory placement semantics.
  - xigency 11y ago
    WebAssembly allows for a stack and a linear area of memory. The job of the compiler is to determine memory placement.
    - vvanders 11y ago
      Argh, I see this keep coming up and it really needs to be put to rest. Compilers don't know how to layout your data. They don't know how you'll access it or the traversal patterns. Your whiz-bang compiler isn't going to strip out class members and AoS from SoA because that's a fundamental data structure problem. Compilers are great, they fold things down, inline and unroll loops. When it comes to memory placement they can't know your intent and it's up to you to lay out your data appropriately. They might do padding but anything else is going to have memory & complexity implications and they shouldn't make those decisions for you.
      - xigency 11y ago
        I don't know, you have a real mix of arguments here, as do most people. There's nothing a JIT does that an ahead of time compiler can't do without the burden of a larger footprint. This is really an issue of backend optimization to "make things like asm.js." For example, there are obvious examples of cases where a JavaScript object's properties and property types would be transparent to a compiler at compile time, with a complete graph of where those values would be stored and used. This would be stored in the WebAssembly stack, analogous to an asm.js fixed array. The WebAssembly sandbox is designed to run code directly. The JIT is designed to build code to run directly in an iterative fashion. If system designers knows how software is expected to operate, they can make choices to instrument that process and also make software which is designed intelligently. Java runs in a VM. Someone could write a just in time compiler for .java code that performs well. That's not a sufficient argument not to develop or continue to develop a javac compiler for byte code. Additionally, whether or not a language is designed to use GC doesn't mean there couldn't be research or design into avoiding or augmenting that situation for performance (in the way that a just-in-time compiler would relieve the situation). Nor reason not to build a platform and engineering methodology to deploy to two independent and cooperating runtime environments. Neither Asm.js and emscripten or C are the end of all things. Neither is dynamicism.