Good Article, Thanks.
The Path to Parallel JavaScript
51–58 of 58 posts
Re: The Path to Parallel JavaScript
#52Good Article, Thanks.
Re: The Path to Parallel JavaScript
#53From what I've seen, SIMD.js does make doing some calculations quicker, although it's not the 4x increase one might assume. It's more like 30% to 50%. The latency and overhead associated with moving the SIMD.js calculations into a Web Worker actually reduces the performance increase to as little as 10% to 20%.
While message passing might make sense for some tasks, it's not going to be quick enough to do things in 16ms and achieve the magical 60fps. Eventually shared memory is going to be needed, and if we get that far I think there will have to be some sort of acknowledgement that these performance-related features can't possibly be foolproof.
Oh, and an asynchronous thread safe DOM, please and thanks :)
Re: The Path to Parallel JavaScript
#54Great developments, since, imho, we really need multi-threading to make decent user-interfaces (ones without hick-ups due to blocking of the cpu-resource). I think what we need is immutable data-structures to be shareable between threads. This approach should also allow structural sharing between threads, allowing for efficient and safe data structures. Also, I could see a use for a mechanism where a thread creates a…
The proposal only is for sharing memory in between Worker threads, which can't access the DOM (which also means canvas, WebGL, etc aren't able to be accessed). It doesn't do anything to help make UIs smoother: you still have to copy to transfer data from the UI thread to the Worker threads and back. If that isn't a problem, then Workers as-is will unblock your UI: you can already do this with Workers as they're imple…
There is active work on allowing WebGL and canvas in workers, with the worker talking directly (not via the main thread) to the compositor.
Re: The Path to Parallel JavaScript
#55Earlier quoted context omitted.
How does it make it difficult?
You can only call async functions inside async functions. See also What color is your function? http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
If that was the case then async functions would be useless, since the global scope is not an async function. You can call async functions from regular functions, they will just return a promise. You can then use normal promise handing behavior (passing a callback function, which is how you'd currently handle async anyway).
In real-world scenarios though, most of the time you'll be reacting to events, and not calling async code from sync code.
Edit: To clarify I'm talking about the ES7 async/await feature.
Re: The Path to Parallel JavaScript
#56Earlier quoted context omitted.
How does it make it difficult?
I have encounter this problem https://stackoverflow.com/questions/28708238/catching-except... Basically, it's hard and prone to bugs.
The implementation in JS seems to be simpler and consequently less error prone than the one in C#. Calling an async function just returns a Promise. The await operator just yields to the event loop until a given Promise is fullfilled. Exceptions are handled "normally" inside the async function with try/catch, outside they're handled with a callback, like in existing code that uses promises.
Re: The Path to Parallel JavaScript
#57I've been thinking that something combined with the use of async functions (es7) could be used for Shared* locking...
sharedObject.lock(^() => {
/* use object, which is locked until async promise resolves/rejects */
});
This could lock the object, allowing for an async function to execute... when the async function promise resolves, the lock is released... it would have to be limited to async functions though. but that would likely hit the JS engines around the same time as any shared objects anyway.
Re: The Path to Parallel JavaScript
#58I've been thinking that something combined with the use of async functions (es7) could be used for Shared* locking... sharedObject.lock(^() => { /* use object, which is locked until async promise resolves/rejects */ }); where `^` is a short key for an async lambda function... `async` keyword could be used too... just throwing the `^` out there. This could lock the object, allowing for an async function to execute...…
For me, the biggest problems with workers, is that you can't simply pass the functions that the worker needs (separated from state) from the main window... it means you're creating a separate script for workers, which isn't so bad, just not always easy to reason around.
It also makes isomorphic interfaces (async node & browser) slightly harder.