4 ms·

I agree, an Unreal Engine compiled to javascript doesn't make sense. It would make much more sense if it were compiled to some kind of bytecode (like NaCl). Tha

by ma2rten 13y ago

I agree, an Unreal Engine compiled to javascript doesn't make sense. It would make much more sense if it were compiled to some kind of bytecode (like NaCl). That will ultimately give you better performance, less loading time, etc. However, maybe there are some libaries which compiled to asm.js are small enough that they can still run in a browser without asm.js support, e.g. an compression or an encryption algorithm compiled to javascript. Maybe that is the sweet spot for asm.js: You are still able to support Safari and IE though native javascript, but it's faster on Chrome and Firefox.

JoeAltmaier 13y ago
Original Java bytecode was actually worse than compiling to some real language - all the value lifetime and other optimization information was lost, even conversion to native asm produced unoptimized code. Is NaCl any different? I imagine javascript that is jit-compiled could create a pretty good binary?
- ma2rten 13y ago
  NaCl is just native machine code with some additional restrictions, AFAIK. It can make use of existing compilers and optimizers. I agree that the binary is probably relatively efficient, but a) only if your code deals with 32bit floating point numbers, b) the binary (erm js file) is probably going to be bigger (hence increased download times) c) the compilation does not come for free.
  - sanxiyn 13y ago
    For file size, see http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling... Summary: it's comparable, not bigger.
azakai 13y ago
> It would make much more sense if it were compiled to some kind of bytecode (like NaCl). That will ultimately give you better performance, less loading time, etc. Bytecode doesn't mean smaller download or faster startup, or necessarily better performance. It might, but you need numbers to show that. In practice, right now startup is faster on asm.js than PNaCl, and vice versa for execution speed, but in both cases the differences are not large. Compare for yourself: http://www.flohofwoe.net/demos.html http://www.flohofwoe.net/demos.html http://trypepperjs.appspot.com/examples.html http://trypepperjs.appspot.com/examples.html
ozten 13y ago
> I agree, an Unreal Engine compiled to javascript doesn't make sense. That demo runs at 60 FPS in my browser, allowing me to casually spend more money on more video games. Your objections seem ideological, as opposed to perf benchmarks, distribution improvements or other quantifiable terms. Can you expand on why it doesn't make sense?
- CmonDev 13y ago
  Just make sure you don't refresh your browser cache after downloading a couple gigs of assets.
  - flohofwoe 13y ago
    Well that has nothing to do with JS or asm.js, only how the game manages its assets. The Citadel demo needs to preload all data before it starts which is very easy to implement but is of course a suboptimal approach to asset loading, a proper game would only load what's really needed to start (4..5 MBytes max?), and from then on stream everything on demand in the background. It's about how much new data can be presented to the player per second, not how big the game data is overall. Asset sharing/reuse, data compression, procedural generation are all important topics for browser games in general, not just games running in asm.js.
- deleted 13y ago
  [deleted]
jerf 13y ago
"It would make much more sense if it were compiled to some kind of bytecode (like NaCl)." asm.js is a bytecode. The ".js" is misleading; it's not wrong, but it's misleading. asm.js is actually a bytecode specification that has a syntax that overlaps (but is not a superset of) Javascript, and the semantics of the bytecode overlaps (but is not a superset of) Javascript, but it is not Javascript. It's a bytecode that happens to have a serialization to a Javascript-compatible syntax. Do not be fooled by the surface appearance and the name. Look at what it does. It is a bytecode, just one with a bizarre serialization. (And as a result of that serialization, the most literal interpretation of "bytecode" admittedly doesn't quite work, but it's a bytecode in every way except for a literal fixed-length code of bytes.)
- CmonDev 13y ago
  How many CPU cores can said "bytecode" utilize at a time? Does it make a difference between value and reference types for optimal performance?
  - kevingadd 13y ago
    asm.js doesn't have support for reference types. You can access threads via the HTML5 'Web Worker' feature.
    - CmonDev 13y ago
      So, all the C++ threading code will automatically be converted to 'Web Workers'?
      - flohofwoe 13y ago
        No, but it's not a great deal to write a parallel execution subsystem in C/C++ which abstracts the differences between pthreads and WebWorkers away. Using low-level pthreads primitives directly in high-level code is a bad idea anyway.
  - flohofwoe 13y ago
    asm.js code is just numbers and functions, no JS "objects". Passing a C++ object by reference resolves to passing a pointer just like in native code (a pointer in emscripten-generated code is actually an index into the typed-array representing the heap). A nice side-effect of this is that asm.js code doesn't trigger the garbage collector.

by ma2rten 13y ago

JoeAltmaier 13y ago

Original Java bytecode was actually worse than compiling to some real language - all the value lifetime and other optimization information was lost, even conversion to native asm produced unoptimized code. Is NaCl any different? I imagine javascript that is jit-compiled could create a pretty good binary?

ma2rten 13y ago
NaCl is just native machine code with some additional restrictions, AFAIK. It can make use of existing compilers and optimizers. I agree that the binary is probably relatively efficient, but a) only if your code deals with 32bit floating point numbers, b) the binary (erm js file) is probably going to be bigger (hence increased download times) c) the compilation does not come for free.
- sanxiyn 13y ago
  For file size, see http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling... Summary: it's comparable, not bigger.

azakai 13y ago

> It would make much more sense if it were compiled to some kind of bytecode (like NaCl). That will ultimately give you better performance, less loading time, etc. Bytecode doesn't mean smaller download or faster startup, or necessarily better performance. It might, but you need numbers to show that. In practice, right now startup is faster on asm.js than PNaCl, and vice versa for execution speed, but in both cases the differences are not large. Compare for yourself: http://www.flohofwoe.net/demos.html http://www.flohofwoe.net/demos.html http://trypepperjs.appspot.com/examples.html http://trypepperjs.appspot.com/examples.html

ozten 13y ago

> I agree, an Unreal Engine compiled to javascript doesn't make sense. That demo runs at 60 FPS in my browser, allowing me to casually spend more money on more video games. Your objections seem ideological, as opposed to perf benchmarks, distribution improvements or other quantifiable terms. Can you expand on why it doesn't make sense?

CmonDev 13y ago
Just make sure you don't refresh your browser cache after downloading a couple gigs of assets.
- flohofwoe 13y ago
  Well that has nothing to do with JS or asm.js, only how the game manages its assets. The Citadel demo needs to preload all data before it starts which is very easy to implement but is of course a suboptimal approach to asset loading, a proper game would only load what's really needed to start (4..5 MBytes max?), and from then on stream everything on demand in the background. It's about how much new data can be presented to the player per second, not how big the game data is overall. Asset sharing/reuse, data compression, procedural generation are all important topics for browser games in general, not just games running in asm.js.
deleted 13y ago
[deleted]

jerf 13y ago

"It would make much more sense if it were compiled to some kind of bytecode (like NaCl)." asm.js is a bytecode. The ".js" is misleading; it's not wrong, but it's misleading. asm.js is actually a bytecode specification that has a syntax that overlaps (but is not a superset of) Javascript, and the semantics of the bytecode overlaps (but is not a superset of) Javascript, but it is not Javascript. It's a bytecode that happens to have a serialization to a Javascript-compatible syntax. Do not be fooled by the surface appearance and the name. Look at what it does. It is a bytecode, just one with a bizarre serialization. (And as a result of that serialization, the most literal interpretation of "bytecode" admittedly doesn't quite work, but it's a bytecode in every way except for a literal fixed-length code of bytes.)

CmonDev 13y ago
How many CPU cores can said "bytecode" utilize at a time? Does it make a difference between value and reference types for optimal performance?
- kevingadd 13y ago
  asm.js doesn't have support for reference types. You can access threads via the HTML5 'Web Worker' feature.
  - CmonDev 13y ago
    So, all the C++ threading code will automatically be converted to 'Web Workers'?
    - flohofwoe 13y ago
      No, but it's not a great deal to write a parallel execution subsystem in C/C++ which abstracts the differences between pthreads and WebWorkers away. Using low-level pthreads primitives directly in high-level code is a bad idea anyway.
- flohofwoe 13y ago
  asm.js code is just numbers and functions, no JS "objects". Passing a C++ object by reference resolves to passing a pointer just like in native code (a pointer in emscripten-generated code is actually an index into the typed-array representing the heap). A nice side-effect of this is that asm.js code doesn't trigger the garbage collector.