Re:Facebook Announces React Fiber, a Rewrite of Its React Fr...
by Dylan16807 on Tuesday April 18, 2017 @09:48PM
(#14144833)
Runtime checks don't stop you from doing heavy data processing or having microsecond-level response times. It seems like your objections fall into two categories. One is caused by it running in ring 3, which can be solved by correcting "anything" to "any user program". The other is moderate performance limitations that don't stop it from running full video game engines. Those may not be ideal but they won't stop you from running anything. Video games are among the most demanding things you can do in most ways. The single core of today is better than the multi core of a few years ago, and nobody claimed that those couldn't run all programs.
Re:Facebook Announces React Fiber, a Rewrite of Its React Fr...
by johncolanduoni on Wednesday April 19, 2017 @12:17AM
(#14145406)
The memory limits will definitely completely prevent you from running some real-world programs. Programs that don't fold well into a single threaded event loop are also a problem at the moment (including Unreal/Unity games that use background threads).
Also, unless you definition of "can run a game" includes "can run a game at 3fps" I'm pretty skeptical that the entire repitoire of games for those engines can make the jump to WebAssembly today.
Re:Facebook Announces React Fiber, a Rewrite of Its React Fr...
by colordrops on Tuesday April 18, 2017 @08:00PM
(#14144246)
Concurrency and SIMD support are in the works.
Re:Facebook Announces React Fiber, a Rewrite of Its React Fr...
by johncolanduoni on Tuesday April 18, 2017 @08:12PM
(#14144305)
I'm aware, but "If you can run a video game engine in the browser you can run anything" isn't exactly hedged on the future is it?
Trading algorithms, ultra low latency DSP, "processing data from LHC collisions or imaging satellites" are I think references to performance limitations. WebAssembly requires a fair bit of runtime checks (though some can be pawned off to the hardware if you're clever), and has a number of other quirks that hurt performance, like the fact that most languages end up needing two stacks when compiled for wasm.
The issue is even clearer when you move to processing large data sets because WebAssembly only allows a 32-bit address space at the moment. Add to that the lack of concurrency or native SIMD, and it's pretty clear it is way too early to dance on the graves of native executables.