4 ms·

WebAssembly might be a Javascript killer for high-performance uses. Javascript for uses such as game development is dragged down by the garbage collector, forci

WebAssembly might be a Javascript killer for high-performance uses. Javascript for uses such as game development is dragged down by the garbage collector, forcing you to orient entire code around minimizing allocations. Without garbage collection, you have to manage memory yourself, but allocations aren't as scary as they are with GC languages and they are more explicit.

vardump 9y ago
Garbage collection contributes pretty little to Javascript's performance issues. Unless you deal with some allocation happy data structures, such as linked lists.
- austincheney 9y ago
  GC is the primary performance killer for persistent CPU intense applications, which is why there aren't many such applications written in JavaScript. The thread is locked when GC happens. In most other JavaScript applications GC is hard to notice, because it typically runs once the application has finished executing.
  - vardump 9y ago
    CPU intensive applications don't usually allocate that much. Excessive allocation makes also other languages, such as C++, very slow.
  - imtringued 9y ago
    GC is not a problem for CPU intense applications. The fundamental problem with a GC is that all threads must be stopped to perform the garbage collection. GC pauses are a problem for realtime applications because an unpredictable GC pauses can blow your time budget of 16ms (or even less) per "tick". The only way to avoid this is by not allocating anything during the realtime segments. Since the GC "infects" your entire program you are also not allowed to allocate anything during the non realtime segments. So you might as well just write C++ code. If the heap is large enough (several dozen gigabytes) the GC pauses may cause latency spikes that last more than a second.
  - fulafel 9y ago
    See eg https://v8project.blogspot.com/2017/11/orinoco-parallel-scavenger.html https://v8project.blogspot.com/2017/11/orinoco-parallel-scav... - some JS GCs are parallel and it's not the case that the "thread is locked" for the whole duration of the GC.
- vanderZwan 9y ago
  What you say is true for regular websites, but game code has different needs than the type of JS you normally use in websites. I've seen people do some very naive stuff, like: var particle = { color: randomColor(), position: new Point(x, y), // number of frames the particle lives decayIn: 50 + Math.ceil(Math.random()*100), }; ... for very short-lived particle effects. This does not scale if you want to draw thousands of particles that each last a few seconds. If they were smarter about it, they could create a pre-allocated "pool" using a maximum nr of particles and re-use them. Likely to be even faster would be preallocating one Uint32Array (for color), two Float64Arrays (one for x and y), and one Uint8Array (for decayIn), and then use an index to look up an individual particle's color, x, y, and remaining frames. Anyway, what I'm saying is: idiomatic JS definitely can result in garbage collection-related bottlenecks for game development, but a lot of this can be avoided by using non-idiomatic coding styles (like heavy dependence on TypedArrays).
  - vanderZwan 9y ago
    > but a lot of this can be avoided by using non-idiomatic coding styles (like heavy dependence on TypedArrays). Too late to edit, but this really should have finished with: ... at the cost of code that is more verbose yet the opposite of self-documenting, inherently frail even if you put wrapper-functions around those typed arrays, and likely to require massive changes all over the code-base for the smallest updates. In my opinion, unless you have a really good reason to not use alternative options like WASM or Emscripten, trying to squeeze that kind of performance out of vanilla JavaScript it's unlikely to be worth the technical debt.
andrewmcwatters 9y ago
Game :clap: devs :clap: do :clap: not :clap: write :clap: games :clap: for :clap: the :clap: web. I do not know where HN got the idea that game developers are even remotely interested in gamedev on the web, but a majority of us aren't even in the slightest. Cross-platform compilation on Unity and Unreal is neat, WebGL is nice for awwwards.com, and yeah, "b-but Little Workshop!" WebGL came too late and doesn't really serve anyone, except fucking with browser implementors and giving them more grunt work to do to comply with specs created by circlejerkers at Mozilla, because clearly it's more important to create a browser spec with Khronos et al. than making a good browser and making sure Google doesn't take away their marketshare since they're paying them to be their default search engine anyway. Now people are on Steam. If the idea was to move the web progressively forward, drop Flash, and say to the next generation of teenage content creators, "Hey look at this C API we created JavaScript bindings for, easy to use, right?" then somewhere along the line, someone was creating shit that wouldn't be used and never thought about why people wouldn't use it for more than an eye-catching <canvas> embedded in a <header> and a blog post explaining how WebGL was used. And what will WebAssembly be used for? I know Adobe will use it to create a web interface to some application no one uses, because it's important that they ship on obscure shit like Chromebooks because artists _definitely_ use those, right?

vardump 9y ago

Garbage collection contributes pretty little to Javascript's performance issues. Unless you deal with some allocation happy data structures, such as linked lists.

austincheney 9y ago
GC is the primary performance killer for persistent CPU intense applications, which is why there aren't many such applications written in JavaScript. The thread is locked when GC happens. In most other JavaScript applications GC is hard to notice, because it typically runs once the application has finished executing.
- vardump 9y ago
  CPU intensive applications don't usually allocate that much. Excessive allocation makes also other languages, such as C++, very slow.
- imtringued 9y ago
  GC is not a problem for CPU intense applications. The fundamental problem with a GC is that all threads must be stopped to perform the garbage collection. GC pauses are a problem for realtime applications because an unpredictable GC pauses can blow your time budget of 16ms (or even less) per "tick". The only way to avoid this is by not allocating anything during the realtime segments. Since the GC "infects" your entire program you are also not allowed to allocate anything during the non realtime segments. So you might as well just write C++ code. If the heap is large enough (several dozen gigabytes) the GC pauses may cause latency spikes that last more than a second.
- fulafel 9y ago
  See eg https://v8project.blogspot.com/2017/11/orinoco-parallel-scavenger.html https://v8project.blogspot.com/2017/11/orinoco-parallel-scav... - some JS GCs are parallel and it's not the case that the "thread is locked" for the whole duration of the GC.
vanderZwan 9y ago
What you say is true for regular websites, but game code has different needs than the type of JS you normally use in websites. I've seen people do some very naive stuff, like: var particle = { color: randomColor(), position: new Point(x, y), // number of frames the particle lives decayIn: 50 + Math.ceil(Math.random()*100), }; ... for very short-lived particle effects. This does not scale if you want to draw thousands of particles that each last a few seconds. If they were smarter about it, they could create a pre-allocated "pool" using a maximum nr of particles and re-use them. Likely to be even faster would be preallocating one Uint32Array (for color), two Float64Arrays (one for x and y), and one Uint8Array (for decayIn), and then use an index to look up an individual particle's color, x, y, and remaining frames. Anyway, what I'm saying is: idiomatic JS definitely can result in garbage collection-related bottlenecks for game development, but a lot of this can be avoided by using non-idiomatic coding styles (like heavy dependence on TypedArrays).
- vanderZwan 9y ago
  > but a lot of this can be avoided by using non-idiomatic coding styles (like heavy dependence on TypedArrays). Too late to edit, but this really should have finished with: ... at the cost of code that is more verbose yet the opposite of self-documenting, inherently frail even if you put wrapper-functions around those typed arrays, and likely to require massive changes all over the code-base for the smallest updates. In my opinion, unless you have a really good reason to not use alternative options like WASM or Emscripten, trying to squeeze that kind of performance out of vanilla JavaScript it's unlikely to be worth the technical debt.

andrewmcwatters 9y ago

Game :clap: devs :clap: do :clap: not :clap: write :clap: games :clap: for :clap: the :clap: web. I do not know where HN got the idea that game developers are even remotely interested in gamedev on the web, but a majority of us aren't even in the slightest. Cross-platform compilation on Unity and Unreal is neat, WebGL is nice for awwwards.com, and yeah, "b-but Little Workshop!" WebGL came too late and doesn't really serve anyone, except fucking with browser implementors and giving them more grunt work to do to comply with specs created by circlejerkers at Mozilla, because clearly it's more important to create a browser spec with Khronos et al. than making a good browser and making sure Google doesn't take away their marketshare since they're paying them to be their default search engine anyway. Now people are on Steam. If the idea was to move the web progressively forward, drop Flash, and say to the next generation of teenage content creators, "Hey look at this C API we created JavaScript bindings for, easy to use, right?" then somewhere along the line, someone was creating shit that wouldn't be used and never thought about why people wouldn't use it for more than an eye-catching <canvas> embedded in a <header> and a blog post explaining how WebGL was used. And what will WebAssembly be used for? I know Adobe will use it to create a web interface to some application no one uses, because it's important that they ship on obscure shit like Chromebooks because artists _definitely_ use those, right?