We just got canned before we had a chance to complete that process. It was very much meant to do just that. And we got canned because it wasn’t shiny stuff people use in the valley. Hard to build for EM
I know what a lot of the words in your description of good experiments mean, but not the combination (especially on Twitter). Can you expand (or provide links)?
-
-
For arrow, this is about getting JS to work in a big data / HPC world, both internally + interop, similar to PyData world. Ex: https://arrow.apache.org/blog/2017/08/08/plasma-in-memory-object-store/ … .
-
WebCL: it's JS bindings for OpenCL (heterogenous / SIMT C) and adds security layers (ex: zeroing memory), so doing WASM without a parallel track on an equiv of this is just delaying the inevitable.
-
General GPU analytics vendors have bet on GOAI, and the
@graphistry team is involved in bringing to the web/node just so we can use it. So happy to share roadmaps + ways to get it out even faster in 2018. We're in SF: leo@graphistry :) -
WebCL missed the boat, IMO. Might as well go straight to Vulkan—which is what is happening, unfortunately with a different competing proposal from each browser vendor. GPU has a general problem though: it’s too unapproachable for almost anyone, Web *or* native, to use it well.
-
Whats your take on which proposal is winning? I'm a bit lost.
-
Last time I weighed in on the Web GPU proposals, I got in trouble. So I’ll defer to others.
-
:) No religion here: a reduced + secure version of OpenCL/CUDA/SPIR/Vulkan all empower framework developers to do ridiculous things. Imagine what the (surprisingly few) core devs of React, D3, ThreeJS, Google Maps, etc. could do!
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.