[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Public WebGL] Re: typed array convenience

Well I can tell where it'll go. Do everything on the gpu, because it cannot be done efficiently in js. Once t&f, Tesselation, geometry and compute shaders are around. Pitty just you can't output audio from the gpu, yet.

On Tuesday, October 28, 2014, Jussi Kalliokoski <jussi.kalliokoski@gmail.com> wrote:
On Tue, Oct 28, 2014 at 7:14 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Tue, Oct 28, 2014 at 5:58 PM, Jussi Kalliokoski <jussi.kalliokoski@gmail.com> wrote:
I think while it can be improved, set() is pretty good for memset, but FWIW in the case of filling arrays with arbitrary data, native implementations won't be of much help. I like to think of JS as a distributed system in terms of performance, where you want to pass small data in close proximity and larger data when the distance grows (where native implementations are far and JS implementations are close).

If you care about performance, eventually you'll probably want to use SIMD intrinsics for most of the array filling cases anyway (which will of course unfortunately be even harder to read than the currently fastest implementation), so adding a method specifically for the performance characteristics of that use case seems premature.

I agree that memset/memcpy, while useful in other context, are useless to produce arbitrary data.

Where I really disagree is that this (or an even worse mess) is the "best" that is attainable. That's simply not good enough. It is inconceivable to me how JS should fail at something that python, C, C++, lua, Java, haskell, erlang, brainfuck, D, go, and so forth all solve. Efficiently filling a binary array with data. This is a joke, it's a complete joke. You're seriously promoting a joke, as "best practice". I cannot condone this, that's baggering belief beyond my capacity to even wrap my mind around that idea. That's so broken, no words, just wow.

Don't take me wrong, I completely agree with your sentiment. I'm also not promoting any best practices, I was merely reflecting on my experiences on trying to squeeze out every bit of performance out of audio processing (at that given time), as well as the state of the art JS engines where there is a barrier between native calls and JS code, so big that it's for example a bad idea to use the native Function#bind() in performance-intensive parts of your application. Maybe that's a problem that can be fixed, but for what I've seen, I can't blame people for not trying, and it's still bad.

I don't want it to be like this. In fact, probably for the past few years there hasn't been a day that I haven't cursed the most ubiquitous software development platform being bound to this broken language. On a personal level, I have pretty much zero hope of ever seeing readable and efficient JS converge. I'd be exploding with happiness to be proven wrong, though. Writing and reading for example efficient SciPy DSP code is fun and easy, instead of excruciatingly painful like with JS, and that's what I'd like to be able to do on the web as well.

- Jussi