Re: comments on Matrix

2013/3/20 Dean Jackson <dino@apple.com>

>
> On 20/03/2013, at 3:57 PM, Gregg Tavares <gman@google.com> wrote:
>
> > Do we need any Matrix classes when up coming JavaScript optimization
> will likely make well written JavaScript libraries faster than these Matrix
> classes and far more flexible to different needs?
>
> I talked with our JavaScript team (JavaScriptCore) about the performance
> implications. They didn't see any issues with the current proposal, and
> also suggested that while the chaining of operations might produce extra
> allocations, it's not necessarily a big deal.
>

So what did they think about the overhead of a DOM API call for something
as inherently cheap as matrix.translate() ?

Didn't they agree that the call overhead would be dominant there, and that
therefore, making this run fast would require special shortcuts?

If a member of your JavaScript team is familiar with the constraints of
developing a high-performance matrix library, what did he think about the
fact that the boundary between the application's source code and the matrix
library's binary code is killing a lot of optimization opportunities, for
example when doing

matrix.translate(...).scale(...)

one would like to avoid introducing temporaries and traverse arrays only
once, but the JS compiler won't be able to do that if translate() and
scale() are binary black boxes implemented in pre-compiled C++ source code?




>
> They also said that a custom Matrix class would likely be faster than
> something working on Float32Arrays, since it is a fixed size class which
> the VM can allocate up front.


That's why high-performance JS code allocates big ArrayBuffer's upfront and
then creates typed array views inside of it. That's what Emscripten does,
so that's what you'd get by compiling any existing C/C++ matrix library to
JS with it.


> And for what's proposed here, it would be difficult for an enscriptened
> library to beat raw performance (and if so, would be something worth
> addressing in the engine).
>

A JS library has the inherent advantage that it puts the entire internal
logic of the matrix computation in the hands of the JS engine --- the
above-mentioned boundary between the application and library disappears.
That's key to performance (it's a big part of why C++ matrix libraries are
generally implemented in the headers rather than in binary libraries).


>
> I'm not an expert on any of this (which is why I asked the experts), but I
> think we shouldn't worry about performance too much. Design is another
> issue.
>

The basic design decision here is should matrices be done in JS or in
native code exposed by a DOM API. I'm trying to convince you that native
code is at an intrinsic, large performance disadvantage here. There will be
performance issues to be solved in JS toolchains before a JS matrix library
runs really as fast as C++ program but solving them will benefit JS
toolchains as a whole so it's very beneficial.

Benoit


>
> Dean
>
>
>
>
>