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

Re: [Public WebGL] Matrix objects in JavaScript



On 13-03-21 12:29 PM, Brandon Jones wrote:
Benoit,

I agree that asm.js is very promising, but I feel like you've asserted several times in the public-fx thread that emscripten compiles of C/C++ matrix libraries will yield the best performance and I have to disagree.

In my experience while emscripten libraries work fairly well, getting data into and out of them is somewhat complicated and adds non-trivial overhead. In order to use a stand-alone emscripten matrix library you need to constantly be copying values in and out of the virtual heap, and that alone would seem to negate most of the potential performance benefits.

Can't you just create a typed array view on the part of the heap ArrayBuffer that is of interest to you?

Benoit

While asm.js will improve the core computations, I haven't seen anything in that spec that would alleviate the copy problem. As such, I think that either a well written JS library or possibly an API like the one being proposed is still the best bet for performance.

Of course the situation is different if the matrix library is being used by a larger emscripten build (like a physics library), at which point I absolutely believe that a C++ library is the best option, but that's a very different situation than the proposed API is trying to address.

Beyond that point, however, I generally agree with your assessment of the API.

--Brandon


On Thu, Mar 21, 2013 at 9:05 AM, Benoit Jacob <bjacob@mozilla.com> wrote:
You'll get SIMD intrinsics for JS, eventually. There's some talk there:

https://bugzilla.mozilla.org/show_bug.cgi?id=644389

See asm.js for the most promising current approach to closing in on 'native' performance.
http://asmjs.org/
Some early performance numbers there: https://bugzilla.mozilla.org/show_bug.cgi?id=840282#c0

Benoit



On 13-03-21 11:57 AM, Tony Parisi wrote:
Benoit,

Far be it from me to argue with one of the implementers, but it seems like a properly designed set of matrix objects e.g. one that incorporates the type of features Florian is asking for, including SIMD support, will definitely be faster than the fastest and most optimized _javascript_.

For years, C++ game developers have pushed the envelope on getting C++ compiler support for these types of operations, because they wanted  their C++ to go faster. This is the same situation, but for a slower language. Why wouldn't a similar approach yield great benefits? Again, if properly designed?

Peanut gallery out;
Tony

On Thu, Mar 21, 2013 at 8:47 AM, Benoit Jacob <bjacob@mozilla.com> wrote:
That would only help if it's implemented directly in the JS engine like Typed Arrays are. Otherwise the cost of a DOM API call would dominate.

Benoit


On 13-03-21 11:21 AM, Florian Bösch wrote:
What would really help where some helper functions in native code/SIMD/platform optimized that perform basic matrix operations like inverse, transpose, multiply, determinant etc. from array buffer to array buffer/view.


On Thu, Mar 21, 2013 at 3:58 PM, Benoit Jacob <bjacob@mozilla.com> wrote:
I have been arguing on public-fx that we are better off without a browser-supported matrix library because this is best done in JS both from the perspective of performance (giving it a bit of time for JS toolchains to solve roadblocks) and from the perspective of flexibility and not blessing an arbitrary choice of matrix library over other ones (and a poor one at that).

Benoit


On 13-03-21 07:04 AM, Si Robertson wrote:
I have to say I can not think of any reason for native matrix objects to be implemented by browser vendors unless those objects (a) provide a significant performance gain over custom code, and (b) are compatible with WebGL.

Matrix operations that work on typed arrays are very fast already if the code is optimised, and it is relatively easily to avoid creating new type arrays when needed.



On 21 March 2013 10:24, Florian Bösch <pyalot@gmail.com> wrote:
On Thu, Mar 21, 2013 at 11:19 AM, Kirill Prazdnikov <kirill.prazdnikov@jetbrains.com> wrote:
Will it be a helper library or part of WebGL API ?
Neither. It would be implemented in the browser, not related to WebGL, and in  my opinion, unusable for it.
 







--
Tony Parisi                             tparisi@gmail.com
CTO at Large                         415.902.8002
Skype                                     auradeluxe
Follow me on Twitter!             http://twitter.com/auradeluxe
Read my blog at                     http://www.tonyparisi.com/

Read my book! WebGL, Up and Running
http://shop.oreilly.com/product/0636920024729.do
http://www.amazon.com/dp/144932357X