4 ms·

The GC, and the JIT are the two main problems with Java for this use case. Both require pauses in execution, which for real time apps is a mode of failure. Al

by illumen 12y ago

The GC, and the JIT are the two main problems with Java for this use case. Both require pauses in execution, which for real time apps is a mode of failure. Also, doing things in separate threads means that scheduling of tasks also causes pauses in execution.

moonchrome 12y ago
>The GC, and the JIT are the two main problems with Java for this use case. Both require pauses in execution, which for real time apps is a mode of failure. Umm, JavaScript and DOM/HTML have the exact same problem except it's magnified by the fact that the language is much more complex to JIT compile (statically typed bytecode vs dynamic/weak typed source code) and the GC has to deal with managed/native interop in the DOM. And not to mention the cost of inefficient DOM interfaces and silly data structures/native types in JS. >Also, doing things in separate threads means that scheduling of tasks also causes pauses in execution. Yea, on the order of milliseconds at worst. Unless we're talking about real time software like games which need to execute a simulation iteration 30-60 times per second (and JS is much worse for this than Java for the reasons mentioned) delays in a reasonably well implemented UI app shouldn't matter and JIT startup time can be avoided by AOT (which is much simpler for static typed languages)
- illumen 12y ago
  Best of class UI requires at least 60fps consistently, not just for games. Of course JavaScript is not great here, but this can be achieved now on the latest mobile browsers. First run time is important, and interpreters are faster in this case. Also, JavaScript can execute as it is downloaded. I can load a whole UI, and complete my task before the JVM has loaded the code. Also, at least Firefox does AOT on JavaScript now. This is how I load and start executing 1.2MB of JavaScript in 50ms in the app I'm currently producing.
  - moonchrome 12y ago
    >First run time is important, and interpreters are faster in this case. ART AOT is on-install and that can even be changed to something like Mono AOT which is offline (you're essentially distributing precompiled native code along with IL) giving you the best of both worlds. >Also, at least Firefox does AOT on JavaScript now AFAIK this is only ASM.JS code, AOT compiling dynamically typed code would be questionable - maybe to avoid initial parsing costs but then you hit all of the problems of AOT (longer load time, need whole code) without the main benefit (performance gain).

by illumen 12y ago

moonchrome 12y ago

>The GC, and the JIT are the two main problems with Java for this use case. Both require pauses in execution, which for real time apps is a mode of failure. Umm, JavaScript and DOM/HTML have the exact same problem except it's magnified by the fact that the language is much more complex to JIT compile (statically typed bytecode vs dynamic/weak typed source code) and the GC has to deal with managed/native interop in the DOM. And not to mention the cost of inefficient DOM interfaces and silly data structures/native types in JS. >Also, doing things in separate threads means that scheduling of tasks also causes pauses in execution. Yea, on the order of milliseconds at worst. Unless we're talking about real time software like games which need to execute a simulation iteration 30-60 times per second (and JS is much worse for this than Java for the reasons mentioned) delays in a reasonably well implemented UI app shouldn't matter and JIT startup time can be avoided by AOT (which is much simpler for static typed languages)

illumen 12y ago
Best of class UI requires at least 60fps consistently, not just for games. Of course JavaScript is not great here, but this can be achieved now on the latest mobile browsers. First run time is important, and interpreters are faster in this case. Also, JavaScript can execute as it is downloaded. I can load a whole UI, and complete my task before the JVM has loaded the code. Also, at least Firefox does AOT on JavaScript now. This is how I load and start executing 1.2MB of JavaScript in 50ms in the app I'm currently producing.
- moonchrome 12y ago
  >First run time is important, and interpreters are faster in this case. ART AOT is on-install and that can even be changed to something like Mono AOT which is offline (you're essentially distributing precompiled native code along with IL) giving you the best of both worlds. >Also, at least Firefox does AOT on JavaScript now AFAIK this is only ASM.JS code, AOT compiling dynamically typed code would be questionable - maybe to avoid initial parsing costs but then you hit all of the problems of AOT (longer load time, need whole code) without the main benefit (performance gain).