Hi Nadav, ----- Original Message ----- > Hi Dan! > > > On Sep 28, 2014, at 6:44 AM, Dan Gohman <sunf...@mozilla.com> wrote: > > > > Hi Nadav, > > > > I agree with much of your assessment of the the proposed SIMD.js API. > > However, I don't believe it's unsuitability for some problems > > invalidates it for solving other very important problems, which it is > > well suited for. Performance portability is actually one of SIMD.js' > > biggest strengths: it's not the kind of performance portability that > > aims for a consistent percentage of peak on every machine (which, as you > > note, of course an explicit 128-bit SIMD API won't achieve), it's the > > kind of performance portability that achieves predictable performance > > and minimizes surprises across machines (though yes, there are some > > unavoidable ones, but overall the picture is quite good). > > There is a tradeoff between the performance portability of the SIMD.js ISA > and its usefulness. A small number of instructions (that only targets 32bit > data types, no masks, etc) is not useful for developing non-trivial vector > programs. You need 16bit vector elements to support WebGL vertex indices, > and lane-masking for implementing predicated control flow for programs like > ray tracers. Introducing a large number of vector instructions will expose > the performance portability problems. I don’t believe that there is a sweet > spot in this tradeoff. I don’t think that we can find a small set of > instructions that will be useful for writing non-trivial vector code that is > performance portable.