[Rusky]

This is wrong. There absolutely are technical reasons why implementations of different languages perform differently- no amount of static or runtime analysis can entirely save you from performance-hostile semantics baked into the language spec.

WebGL is a huge bonus, but WebAssembly will also be important for a lot of web-based VR.

[avaer]

> no amount of static or runtime analysis can entirely save you from performance-hostile semantics baked into the language spec

You can in almost all cases check for these semantics statically, and if not found, run a super fast path. This is the whole premise behind asm.js.

Heck, even C++ has plenty of features that have performance-hostile semantics. But the compiler checks for these and you don't pay the penalty if you don't use them.

Wasm will help, but I disagree that anything in the JS spec makes the _language itself_ inherently slower than any other language, if we disregard textual compilation overhead.

[vvanders]

I'll give you one: value types.

Until you can specify memory layout you'll never come near a proper gamedev engine, regardless of GC issues(which are also a problem).

(source: I used to work on professional game engines)

[avaer]

You're right, which is why one of the fundamental optimizations in a modern Javascript engine is inferring static memory layouts for your objects. Another is getting rid of unnecessary allocations to reduce the need for GC.

[vvanders]

> inferring static memory layouts for your objects

I'm deeply suspicious that you'll do better than something purpose built. Things like arena allocators for levels. Knowing how your scene-graph and animation traversal are really hard to get right and without direct control over SoA vs AoS and the like I don't see how you get within a factor of 10 to something written in native.

[flohofwoe]

asm.js and WebAssembly give you the same control over memory layout as C (in fact the memory layout is absolutely identical to a little-endian 32-bit host) and unless you need to call a lot out into HTML5 APIs the garbage collector will be idle. These two things together are basically the magic sauce why asm.js/wasm are faster than manually written JS and faster then most 'managed languages' where most objects are created on the heap and passed around by reference.

[vvanders]

Totally, since the memory model is identical. However then you're not really talking about something that looks like JS(or a managed language) at all.

I'm actually a huge fan of WASM, I think it gives you a great escape hatch to break out of these problems(much like JNI/etc in other managed languages).

[aanm1988]

> asm.js and WebAssembly give you the same control over memory layout as C

That's a bold statement right there.

[flohofwoe]

Not at all, both asm.js and wasm give you a flat memory region (in asm.js it's a single, big JS typed array), the stack and all allocations live in this 'heap', managed by emscripten's malloc wrapper (which is jemalloc I think), the resulting memory layout is the same as on a native 32-bit platform, with the same alignment rules. There are no 'managed' Javascript objects in asm.js or wasm (unless you need to call out into web APIs).

[Klathmon]

Luckily most JS engines "unbox" simple values to "value types" if it can be determined that they will stay that way.

so aside from startup speed you get the same perf

[vvanders]

> simple values

So does every other language, where it matters is with objects. Until I can mark a whole object as a value type and fix it in memory relative to other objects then you'll pay a 10-50x slowdown for cache misses and the like.

[Klathmon]

Sorry, that should have said "simple objects".

But you don't even need to rely on that. JS has TypedArrays[0] which are basically just a chunk of memory you can read and write to.

Aside from some bounds checking, it's about as "low level" as you can get. Sounds like exactly what you are looking for.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...

[vvanders]

Typed arrays are close, but still not good enough.

On the Java side I've used ProtoBuf for similar approach(using byte[] which does have memory placement semantics). While it helps, the bounds checking and accessors that you need still have a non-trivial cost both in branching and cache thrashing(len is usually stored for an array at a different location or at the head so data items near the mid/tail will still take a hit).

Realistically you can get within about 1/5th the speed of native using cache aware data structures and techniques. As always it matters if your use case needs that speed but choosing a JS/managed based tech-stack will always limit you from getting that last 5x perf improvement.

[Rusky]

> asm.js

But then you're no longer using the language. The performance-hostile semantics are still there, you're just not using that part of the language, and thus losing out on all their benefits.

[Sammi]

Yeah the whole reason asm.js is fast is because it strips out the performance hostile parts of js.

[frandroid]

The ReactVR framework can use asm.js to gain acceleration but you as a front-end developer could stick to best JS VR practices to not get in the way of the performance ReactVR with asm.js brings you (if it uses it now or in the future).

[javajosh]

Any language that uses LLVM isn't using the language either, by this definition. That would be a shock to most C++, CUDA and Swift developers.

[Rusky]

How so? LLVM is used to implement language features, performance-hostile ones included. asm.js is a codified way to avoid language features.

You may be confusing layers here. asm.js as a compilation target is used the same way as LLVM- it is used to implement the source language's features, while simultaneously avoiding some of JS's.

[javajosh]

I'm sorry, I didn't think I needed to spell it out: LLVM front-end compiles a high-level language into an intermediate representation ("IR") which is then transformed by the backend into machine code. A compiler targeting wasm occupies the same space as the LLVM front-end. Now, in a browser there is not as obvious a back-end, but it's there: it's the JSVM JIT code.

[Rusky]

That's not at all relevant.